My past post was the game that I made for the Ludum Dare game jam. It was a text based game using the interactive fiction engine Twine. Twine started out as a modification of the HTML and JavaScript modifiable web page thingy tiddlywiki http://tiddlywiki.com .
Mostly, what you can make with it are really specialized web pages. It's all click this link to go here and click here to go back. This leads most people, rightly, to use it for creating choose your own adventure style stories and games. Ever since I learned about Twine, I wondered if maybe it could be used in a slightly different way.
Choose your own adventure books can be done on paper and they aren't significantly improved by being on a computer. The fighting fantasy series of gamebooks Incorporated information tracking and random events, but both of those can be handles with a pencil and paper, and a couple of dice. If I was going to use Twine on a computer to make a game meant to be played on a computer, I wanted to make that meaningful.
Using a computer gives you a couple of things. You can process a lot of information very quickly, and you can hide the it all from the player. That lets you create the sort of interactions you get in your pac-mans and your galagas. Fast, reactive experiences also known as video games.
Using a game creation tool like Twine that is tailored toward slower, text based, or narrative games meant that fast was probably off the table. What I could do though was use the computer's ability to process information in a way that is mostly invisible to the player.
The theme for the game jam was “running out of power” and I fairly quickly settled on the idea of a never ending chase where the only possible outcomes would be to die from exhaustion, or be caught and devoured. Fun stuff, but that is also the basic plot of Pac-Man and look at how well that turned out.
Ever since zork, I had wanted to create a text adventure, but one that changed every time you played it. For that I went the easy route and just had the computer randomly select from lists of possible descriptions, this was something that was easy to implement, but not really a great solution since that adds more writing work, and it doesn't provide any meaningful difference to the choices you have to make. Game jams aren't really about great solutions, they are about making the thing go as best as you can as quickly as you can. To that end, the random approach did it's job.
The other thing I wanted to add to the text adventure genre, was an ever changing environment. Each time you play it, it should be different. I didn't have time to come up with a better solution so I went for the random approach again. Only this time the game would select one of four maps and place you somewhere in the middle of it. The effect is disorienting and sort of annoying. That was by design and I was glad that it worked.
For the maps, I started out planning them on a grid system. I was going to build all of the possible movement directions semi manually, but quickly realized that would take way too long. Then I started to build the maps in a sort of branching series of Twine nodes (passages) but that would require a lot of custom writing to say things like “you can move left or right from here”. Then I thought that maybe I could store the map in a series of arrays, since I had read that Twine could deal with arrays. After a few searches, I found that not only did Twine support arrays, it supported 2 dimensional arrays, which I did not expect, and someone else had already made a tutorial using them to create a navigation system very, very, much like the one I had thought up. So I partook of a time honoured programing tradition. I copied the code and modified it to work in my project. Now I could make maps on an x,y grid where certain cells would have custom descriptions while others would use the random descriptions for that particular map.
The whole time you play, the game is keeping track of your exhaustion and how far away the devouring hoards from you. And that's it, you move up, navigating an unknowable maze and totally fail to avoid death. That's the whole game. It's not much but coming from knowing almost nothing about Twine to making something that will run perfectly over and over in 48hours is no small task. I'm happy with how it turned out.
Mostly, what you can make with it are really specialized web pages. It's all click this link to go here and click here to go back. This leads most people, rightly, to use it for creating choose your own adventure style stories and games. Ever since I learned about Twine, I wondered if maybe it could be used in a slightly different way.
Choose your own adventure books can be done on paper and they aren't significantly improved by being on a computer. The fighting fantasy series of gamebooks Incorporated information tracking and random events, but both of those can be handles with a pencil and paper, and a couple of dice. If I was going to use Twine on a computer to make a game meant to be played on a computer, I wanted to make that meaningful.
Using a computer gives you a couple of things. You can process a lot of information very quickly, and you can hide the it all from the player. That lets you create the sort of interactions you get in your pac-mans and your galagas. Fast, reactive experiences also known as video games.
Using a game creation tool like Twine that is tailored toward slower, text based, or narrative games meant that fast was probably off the table. What I could do though was use the computer's ability to process information in a way that is mostly invisible to the player.
The theme for the game jam was “running out of power” and I fairly quickly settled on the idea of a never ending chase where the only possible outcomes would be to die from exhaustion, or be caught and devoured. Fun stuff, but that is also the basic plot of Pac-Man and look at how well that turned out.
Ever since zork, I had wanted to create a text adventure, but one that changed every time you played it. For that I went the easy route and just had the computer randomly select from lists of possible descriptions, this was something that was easy to implement, but not really a great solution since that adds more writing work, and it doesn't provide any meaningful difference to the choices you have to make. Game jams aren't really about great solutions, they are about making the thing go as best as you can as quickly as you can. To that end, the random approach did it's job.
The other thing I wanted to add to the text adventure genre, was an ever changing environment. Each time you play it, it should be different. I didn't have time to come up with a better solution so I went for the random approach again. Only this time the game would select one of four maps and place you somewhere in the middle of it. The effect is disorienting and sort of annoying. That was by design and I was glad that it worked.
For the maps, I started out planning them on a grid system. I was going to build all of the possible movement directions semi manually, but quickly realized that would take way too long. Then I started to build the maps in a sort of branching series of Twine nodes (passages) but that would require a lot of custom writing to say things like “you can move left or right from here”. Then I thought that maybe I could store the map in a series of arrays, since I had read that Twine could deal with arrays. After a few searches, I found that not only did Twine support arrays, it supported 2 dimensional arrays, which I did not expect, and someone else had already made a tutorial using them to create a navigation system very, very, much like the one I had thought up. So I partook of a time honoured programing tradition. I copied the code and modified it to work in my project. Now I could make maps on an x,y grid where certain cells would have custom descriptions while others would use the random descriptions for that particular map.
The whole time you play, the game is keeping track of your exhaustion and how far away the devouring hoards from you. And that's it, you move up, navigating an unknowable maze and totally fail to avoid death. That's the whole game. It's not much but coming from knowing almost nothing about Twine to making something that will run perfectly over and over in 48hours is no small task. I'm happy with how it turned out.