?

Log in

No account? Create an account

TADS 3 System Development

Mercury?

TADS 3 System Development

Mercury?

Previous Entry Share Next Entry
The other, other area I've been working on - and this is a heck of a lot more speculative than the system features I've been talking about - is a new library.  This isn't a new adv3 version, and it's not a replacement for adv3.  It's a whole new library that I intend to sit alongside adv3, as a different option for developing games.

The "high concept" for the new library is pretty simple and compelling: it's the tads 3 library for tads 2 users.  My feeling is that there's a portion of the community that's been kind of left out in the cold as TADS and Inform have evolved.  These are the people who want a relatively simple and traditional system, something on the level of TADS 2 or Inform 6 in terms of learning curve and overall complexity and programming style.  But they also want to know that what they're using is still being actively developed, so that they can expect ongoing new features and bug fixes and so on, and that there are other game writers out there for technical support.  Adv3 is off the deep end in terms of complexity - not gratuitously, since you get a lot of power in return for the work of learning it, but for people who don't need all that power that's not an appealing bargain.  And Inform 7 is a radical departure in its own way; while the bulk of Inform 6 users and a lot of newbies have embraced the new approach enthusiastically, there are some people out there who'd be happier with a "normal" programming language. 

Hypothetical user base aside, the real impetus that got me working on this is that I count myself in that disenfranchised tads 2 camp.  When you're working for free I've found it's best to work on the stuff you'd like to use yourself.  Adv3 is really cool in a lot of ways, but whenever I use it I find myself battling with the layers of details and wanting something simpler.

So I'm thinking of calling it something like Mercury: the smaller, lighter, faster option, compared to the Mega-Jupiter that is Adv3.  Any other ideas for names?  It's still very much a WIP and an experiment, so I don't know if it'll ever see the light of day; but I really hope it does because there are (in my opinion, anyway) some cool new ideas in it.
  • Hmm. "T3 library for TADS2 users" seems like kind of a weak high concept (though presumably there's more stuff there).

    The thing I was kicking around on my walk home was, ok, what about a library where someone who knows the language could learn the whole thing in a week? Going along with that, what about a library that didn't include stuff unless it was going to be in 90% of IF games -- so don't include 100-200 verbs, include 20-30; don't include classes for food or keys or doors; don't include code for hunger or sense-passing or even darkness.

    Then in production accompany that with a recipe book of useful things, like the I7 manual but with the examples as the primary text and organized in a helpful way.

    I think this'd feel much less overwhelming than the existing T3 library, and people would be able to get a solid understanding of the core system and be able to use the elements there in solid ways to implement all the other things.

    Like, I said before that the core library shouldn't implement darkness. If someone does need a dark room, in the vast majority of cases, this kind of implementation would be totally sufficient for their needs:

    Cellar: Room 'The Cellar'
        "[if self.is_dark]It's too dark to see anything.[else]The cellar is dimly-lit and has spiderwebs.[end if]"
        beforeAction() {
           if (self.is_dark && !gActionIs(Up) && !action.is_system_verb) {
              "It's too dark to see anything.";
              exit;
           }
        }
        is_dark() {
          return !lantern.isIn(self) || !lantern.isOn;
        }
    ;
    


    Like, yeah, this won't handle other verbs, it won't handle crazy sense-passing stuff, but most of the time it just doesn't matter, so why burden the library and the author with all the effort of handling sense-passing? And if they really want it, they could easily modify this implementation to support whatever else they need -- it'll be less efficient than the existing implementation, but mostly only in pathological cases (at which time there is probably some other situation-specialized solution to increase efficiency).
    • Then in production accompany that with a recipe book of useful things, like the I7 manual but with the examples as the primary text and organized in a helpful way.

      I think this'd feel much less overwhelming than the existing T3 library, and people would be able to get a solid understanding of the core system and be able to use the elements there in solid ways to implement all the other things.


      I can see the usefulness of having a minimalist library to which you add custom code as needed, just so long as it doesn't mean reinventing a whole lot of wheels from scratch.

      What might also been neat would be to have a modular library (or a set of standard extensions) that made it easy to add things like doors or darkness (or whatever other such common features weren't in the core library) simply by including them in the build, so that it was easy to pick-and-mix which features you wanted. That is, many of the recipe book examples could also be supplied as standard extensions.
      • What might also been neat would be to have a modular library (or a set of standard extensions) that made it easy to add things like doors or darkness (or whatever other such common features weren't in the core library) simply by including them in the build, so that it was easy to pick-and-mix which features you wanted.

        If I understand you correctly, it would split the entire Adv3 library into a simple library and various optional extensions, so that it could satisfy at the same time people who want the simplest library, others who want the full Adv3, and still others who want anything in-between? And Mike would have only one (big, but not bigger than now) library to maintain?

        I don't know nearly enough about IF programming to be sure, but it does look like an ideal solution. But would it be actually possible?
        • I wasn't really thinking in terms of a common modular library both for Mercury and as an adv3 replacement; I was rather developing inky's idea for how the mini-library might work (although Mike probably has his own ideas for that already). The adv3 library is integrated pretty deeply, and I don't think there'd be much mileage in trying to undo that. On the other hand, if the base Mercury library was truly minimalistic, there'd be scope for a number of modular extensions to avoid people having to reinvent very common wheels.
    • Your thinking is actually pretty much along the same lines. Adv3 has two distinct sources of its complexity. One is the core "physics" model - the sense passing and all that; the other is the kitchen-sink full of feature classes. In my view the plethora of bonus feature classes makes the library hard to learn, while the core model complexity makes it hard to learn *and* to use.

      Lopping off feature classes and making them into add-ons is easy; if that were the only thing needed it would just be a matter of partitioning Adv3 into more granular chunks and calling some of them extensions. The thing that got me started on doing a whole new, alternative library is that most games are happy (happier, in fact) with a much simpler core model, and that's something that can't just be pulled out into an extension.
      • I7 serves as an existence proof for a system where the base library is quite pared down but there are lots of extensions and examples to add what you need. I'm all for this. Way back when T3 was really getting started I planned on doing a T2-like alternative library.

        Then I graduated from Duke and got a job.
  • This sounds an interesting idea, but I have slightly mixed feelings.

    On the one hand, I can see there might well be a demand for it, and from time to time I've seen the odd person posting a vague intention to develop a cut-down library for TADS 3 (although none of these ever seems to have been taken any further, so far as I'm aware). And of course we've all seen people complain of the complexity of the adv3 library, and I can see that the proposed Mercury library might give such people the best of both worlds (the increased power of the TADS 3 language with the relative simplicity of something akin to the TADS 3 library), as well as providing them with an option that continues to be actively supported.

    On the other hand, I can't say this is something I'm exactly pining for myself, since I'm perfectly happy with the power and complexity of the adv3 library. Maintaining two TADS 3 libraries will also be extra work for you (which you may or may not regard as worthwhile), and I can foresee certain problems with support and extensions: Will it always be clear which version of the library someone is asking a question about or reporting a bug about? Will it always be apparent which version of the library an extension is intended for? Is there a danger of Mercury spawning a whole set of extensions that simply reinvent wheels already present in the adv3 library?

    On balance, though, I don't want to come over as a nay-sayer, and I assume there are ways round the issues I've raised (which you may well have thought of yourself). Also, I'm be as intrigued as anyone else to see a new library that has "some cool new ideas in it". What might also be cool is if the Mercury library (and I like the proposed name) could function as a stepping stone for some people who want to learn TADS 3 but don't want to start by mastering the adv3 library, while having the option to move onto it should they need its greater power.

    • Well, I wouldn't expect you to be the target audience for this, Eric. :) You're thinking the same way I am, though, in terms of having something approachable for the library but with the more modern and powerful programming language underneath. In addition, some of the ideas from Adv3, such as the implied command mechanism and adaptable message generation, can be carried over into a simpler overall framework. So in the end I expect this to be somewhere between TADS 2/Inform 6 and TADS 3 - closer to the former on the ease-of-use scale, but with some of the more advanced features of the latter.

      It'll be a while before I'll know if this has been at all successful, though.
  • This has been something I'd be really interested in. I've been very tempted to port Tads 2 functionality over to Tads 3.

    With this in mind... is there any chance of moving the GrammarProd mechanism further from the compiler so that the components of a GrammarProd definition might have equivalent method representation? What I'd like to see is a way to execute new GrammarProd() from within a code block and build a grammar dynamically ... or simply define grammarProd objects the way any other intrinsic can be defined in source.

    Another thing I've been interested in is seeing a library that defines classes, but instead of defining methods on objects makes use of the multi-method approach. I find the uniformity of syntax of a function and method call very appealing.

    --Kevin
    • I'll make a note about 'new GrammarProd' - that's something I should definitely add at some point, but I haven't had it on my to-do list. I'm not sure how much work it would be to add, but it might not be that big a deal, in which case this round would be a logical time to add it.
Powered by LiveJournal.com