In my last article, I explained why text adventure games are some of the most Steampunk computer games out there. I even shared a free Steampunk text adventure game that I'd made myself!
Now, I grew up playing text-based games (which are now known as interactive fiction) such as Zork, Lurking Horror, and Starcross. I even played some MUDs (the predecessors to MMORPGs) for awhile.
And yet beyond a rudimentary attempt to program one of my own on a Commodore 64 as a child, it never occurred to me as an adult that I could write such a thing myself. So I can only assume that there are many other people out there who either haven't thought of text games for years, or just never realized that they could write one themselves.
The great part about text games is that you don't need to be an artist or a hardcore computer programmer to make them.
I can make 3D art with some mild degree of proficiency, but when it comes to 2D art, I suddenly become all thumbs. Likewise, I can code in HTML and BASIC, but when it comes to real code, my eyes glaze over and I suddenly find something else to do.
So if you like video games but don't have the ability to bring a fully-realized 2D or 3D game to life, you should consider text games! My experience with them has been pretty fun and fulfilling, and I can only hope that others find the same!
Before I get into the specifics, let me give you an idea of the difficulty.
I learned enough about interactive fiction coding in five days to write the game that I linked to in the last post. I started from having absolutely no knowledge and went to being somewhat proficient in only five days. That's not so bad, all things considered. However, it is very difficult, and there were certainly times when I wanted to bang my head against a wall.
So while it's not the hardest thing in the world, don't expect it to be a walk in the park!
The very first thing you need to do is get your hands on a compiler. They're free on the internet, like most interactive fiction resources.
The one that I used is called Inform 7, and it's the easiest one to learn because it's all written in plain English. There's no crazy code that you have to learn, just a new type of syntax. In many ways, learning Inform 7 was like playing a text game, in that you have to figure out what words it wants you to say to accomplish different tasks.
The other contenders are Alan, Hugo, and TADS. As I haven't used them, I can't give you a full rundown on their usage, but here's an article that compares all the compilers side-by-side. You'll note that almost all of them except for Inform 7 use odd symbols and weird coding things. In that way, Inform is the easiest for non-coders to understand, so that's why I picked it. My understanding is that it's used widely throughout the interactive fiction community.
One of the benefits of Inform 7 is that it has an extensive tutorial section that fully explains the various usages and functions of the compiler. I used nothing but the in-program documentation to learn how to use it. It was very helpful, providing both explanations and examples.
Even so, I still had trouble doing exactly what I wanted from time to time. Let me give you some examples. And for the sake of this article, I'm going to assume you're using Inform 7. The code in each one is different, so these are all specific to Inform 7.
First, let me introduce you to the interface. The compiler is divided into a split screen so that you can see the code at the same time as the game, or the documentation, or whatever else you'd like.
In the case of the file above, I have it open to the source code on the left, and the documentation on the right. You can see how extensive the documentation is... Each of those chapters has at least five subchapters, and sometimes as many as 15 or more!
Note: You can also check out the manuals online if you want.
So, let's say that you want to write a really simple game. You're staring at the blank source code page and wondering where to start. Well, what you need to know is that the compiler automatically comes with a variety of commands understood, including movement between areas and relationships between objects.
Take a look at this picture:
In it, I've written some really simple code on the left, and then pressed the "go" button at the top left, thus allowing me to play it on the right side. I input a few commands so that you could see what happened.
Let me break down the code one part at a time so that you understand what's going on here. The code can get pretty complicated later, but to write a very simple game, I really only need to show you two examples. The one above is the first.
The first thing I do is to tell the compiler that Steampunk R&D is a room, thus establishing what sort of thing it is. After that, the compiler will treat it as a room. The description immediately follows, and that should be pretty obvious.
The next thing I introduce is the admin, who is an NPC. I said that he's 'here', so that it knows that he's in Steampunk R&D. That's currently the only room in the program, so I don't need to further specific where he is. Then I specified what his description is.
Then I placed an article in the room, and specified that it was edible. Then gave it a description. This is all really simple stuff, and pretty much all examples of the same principle: displaying 'things', be they rooms, articles, or people.
The last thing I did is to say "Instead of eating article: say 'blahblah'".
This introduces the first really, really important bit of coding. If the player inputs a command, you can subvert that command by saying that instead of doing it, to do something else. In this case, rather than actually eating the article, you're cleverly rebuffed.
This leads to my last example for now.
In the following example, I'll introduce another room, and the 'if' mechanic. Between those two, you should make it pretty far!
The first thing you may notice is that I added a second room, called WonderHowTo. I didn't even have to call it a room in the code, because the compiler knows that if an object is east (or west, or north, or whatever) of another object, it's probably a room.
Since there are two rooms now, I had to edit their descriptions to say where they were in relation to each other so that players can easily navigate between them.
The most important part, though, is the "Instead of going east" section. Much like the "instead of eating article" that I included before, this time I provided a circumstance in which the player could continue to the East.
When the player types 'go east', the program will check to see whether they're carrying the article. If so, it will go ahead and move them to the room. If not, it will rebuff them by saying that they need to take an article with them.
This simple mechanic of 'if' will allow you to create incredibly complicated situations and relationships.
Of course, as I said, things can get much, much more complicated, but this quick tutorial should have you hit the ground running.
As I mentioned earlier, there's a thriving interactive fiction community out there. If you just want to share the game with your friends, you can host it somewhere and then use Parchment to let people play it online. That's what I did.
There doesn't seem to really be a market for games like this, but it's a fun and rewarding thing to make!
If you do make your own, please share a link to it below so everyone here at Steampunk R&D can play.
Want to master Microsoft Excel and take your work-from-home job prospects to the next level? Jump-start your career with our Premium A-to-Z Microsoft Excel Training Bundle from the new Gadget Hacks Shop and get lifetime access to more than 40 hours of Basic to Advanced instruction on functions, formula, tools, and more.