As some of you may recognise, I am a new convert to text adventures. My obsessions tend to be short-lived, so I try to share them with others on my blog, to help connect people to things they didn’t know they would like. I wrote up some “lessons learned” from creating my first text adventure.
I don’t think much of it is new to you, but I tried to conserve my newbie perspective and there might be something in there worth discussing.
I think you summarise a number of the issues very well. It was an interesting read.
An interesting read, thanks.
we can build more detailed games at less effort
This is the thing i see as the real hill to climb for IF, going forward. It’s one of the reasons why i like to see people developing new systems. I think the existing, mature systems are not ideal at the “less effort” bit. And, you’re right, modern tools can help here.
Most people who suggest or announce new systems tend to talk in terms of various new IF features they’re adding or the technical aspects. But i think, what we really need is:
The same features we have now, but way, way easier to develop, test and deliver.
I’d like to see new systems make things easier and fun, even if they actually have a bit less in them than their existing counterparts.
Overall agree, but I have a slightly, maybe, different perspective.
For me it’s about tools that make it easier to marry the fiction and mechanics to create more satisfying experiences.
But we definitely agree that we need to see more systems and exploring more areas of the craft.
Very nice summary of your experience. BTW, a perhaps nicer way to handle * comments is:
Understand "* [text]" as a mistake ("Noted.").
This is what Writing With Inform recommends, and it avoids using After reading a command, which is the Devil’s Rule.
This is a great article and probably one that I would recommend to anyone starting out as a text adventure author.
I also read your article on text adventures and found that equally enjoyable. In this case, it’s one that I would recommend to anyone starting out as a text adventure player.
I hope you’ll write a few more articles like these.
In my opinion the best way to decrease amount of effort required to build a text-adventure is to use libraries or a class tree. Sometimes you don’t need another tool, but a library for existing one.
The C language is a nice example. It doesn’t offer many keywords, but with the help of libraries, it becomes versatile and functional.
ADL and AdvSys (compilers and interpreters) were written in C and their role is to simplify the text-adventure creation by supplying a parser, handler loop, vocabulary, object tree and much more.
ADL despite its age has many features and can be extended easily with routines. Contains many example games. Two of them are pretty large.
AdvSys has not so many examples (only one, very simple game is included), but can be extended as well with new classes.
Inform (version 6), from what I learned has more C-like features, which means they are capable of advanced in-line code and versatility.
I’m not sure how is it with Inform 7, because its paradigm is new to me.
For some people a designer program, with easy adventure definition, can simplify the work and it includes PAWS, Quill, and some other GUI based tools.
I think that libraries are the key to less-effort writing and it applies to many languages and projects.
Good GUI tools have in-line code to embed some customized actions - which I think concerns also mentioned PAWS. This is my opinion in this matter.