When I started coming up with ideas for my first iDevBlogADay post, I considered writing about everything from procrastination to Xcode folder references. It took a couple helpful tweets to make me realize I should write about something I really know about: the process of developing Trainyard.
Trainyard is my iPhone game. It’s a grid-based logic puzzle game where the goal is to get each train from its initial station to a goal station. Every train starts out a certain colour, and most puzzles require the player to mix and merge trains together so that the correctly coloured trains end up at the right stations. The player’s only method of input is drawing tracks for the trains to follow. It’s kind of hard to explain with words, so if you’re confused you should watch the trailer.
I came up with the idea for the game a year and a half ago, during a period where I was actually working on ideas for Flash games. At that time I didn’t have any iPhone development experience, and had barely even looked into Objective-C. I did, however, have an hour long commute by train which gave me plenty of time to come up with interesting game ideas. My main game prototyping tools were (and still are) a notepad and an Acer Asprire One netbook. Yes, a netbook. I’ll probably write more about that little guy in a future post. For now let’s focus on the notepad.
Every game designer should carry around a notepad as much as possible. You never know when the spark of a great game idea is going to come to you. I went through notepads and notebooks of all shapes and sizes while working on Trainyard, so I really don’t think it matters which kind you use as long as you’ve got one. I suppose you could try an iPhone app for recording ideas, but there’s something special about being able to sketch with a pen.
A notepad is more than a place to write down the gist of an idea, it’s also a great place to flesh concepts out and figure out how you’re going to execute them. In the case of Trainyard, my initial idea (as you can see on the page above) was “each train starts with a solid colour that they have to mix and deliver”. So far so good. Ok, let’s look a little further down that page: “[trains] can collide, have two cars, and pick up paint”. That’s quite different. My original idea was that each train had several cars to pull, and each train would also have its own control panel where you could adjust the speed before pressing “Go”. Confusing? Yes. Would it make for a good game? Maybe, but it’s definitely not Trainyard.
On this second page you can see some more questionable ideas: “Game could be hex based instead of square”, “limitations include fixed quantities of pieces”. At this point in the process I was thinking of limiting the user’s selection of pieces like a lot of other similar puzzle games do. After thinking through the mechanic over the next few days, I realized that I could make it work without limiting the user’s piece selection. I think the flexible unlimited-track nature of Trainyard is now something that really makes it unique. At one point a lot later in the prototype process I even made a hex based prototype (flash link) just for fun, but it felt weird and confusing.
After those first few sketches, I worked over the course of a few days to eliminate most of the extraneous ideas and the concept gradually got closer and closer to what it is today. About a week after coming up with the initial idea the core gameplay mechanic was transformed into something nearly identical to what it is now. Keep in mind that at that point I still hadn’t coded anything; it was all on paper. I even have a sheet of paper with a detailed solution to the very first Trainyard puzzle ever created, which actually made it into the game as The Original. Unfortunately I couldn’t find that piece of paper in time for this post, but when I do I’ll be sure to put it here.
The moral of the story: as developers, we’re often tempted to go straight to our computers to make prototypes and tests, but sometimes it’s good to just sit down with a pen and paper and flesh out an idea.
I hope you enjoyed this first little look into the Trainyard development process. I’m planning to post at least a couple times a week, so please add http://struct.ca/feed/ to your RSS readers and whatnot. I’ve never had my own blog, so my writing style is going to be a bit rough for a while, but bear with me, it’ll get better over time If you didn’t come here from iDevBlogADay, make sure you check all those other blogs out, there’s some great stuff there.