Making Games Quickly

Posted on 2018-08-14

When No Time To Play started, finding ways to make games more quickly and easily was high on our list. It proved an elusive goal. Programming languages, specialized tools, graphical styles... they were all fun to learn, and resulted in a good many games. Most actually got finished. Some even enjoyed a degree of success. Few, however, seemed especially easy to make, until recently.

It's not a new thing for me to pick up an abandoned demo or prototype after several years and complete it. Electric Rogue is the culmination of no less than five years of experiments. City of Dead Leaves was started one year, finished the next, then converted to a different platform. At least that way I avoided burnout. After working for months at a time on a single project, failure is a more bitter pill than usual.

Because as it turns out, even with the infinitely better means and access to knowledge we have today, it still takes a bedroom coder around 3 months to make a small commercial-quality game, the same it did in the mid-1980s — or for that matter during the casual game boom last decade. And large scale projects still take years. Sometimes many years.

Except... this July I was on a roll with reviving old unfinished projects, and couldn't believe how quickly they all went:

I'm not even counting the five games I created earlier in spring over as many weeks: that happened at my usual pace. Or the Bitsy game I made in three days last autumn, while learning the platform. The latter is at least designed to make game development into a fun, casual play.

No, I'm talking work that by rights should have taken a lot longer. Talk about stumbling upon a long-sought secret and failing to recognize it!

So what exactly is it I discovered?

Programmers like me are a dime a dozen. Especially nowadays, when visual tools can help a lot of people learn how to program even as they insist that what they're doing isn't programming. Which is awesome, but that's another story.

Sure enough, the breakthrough games I made in July are the end result of incrementally refining one particular genre, in this case shooters. They're also simple. Perhaps too simple, but people appreciate that in an age of overwrought games. Besides, it's easier to add more mechanics and content on top of a solid foundation than to first build a Jenga tower then try to figure out how to keep it standing.

Another must-have is a strong theme. Without one, you'll just flail around not knowing what else to add. Sunset Flight didn't gel until I figured out a premise for the original Attack Vector. Likewise with Laser Sky. Even if it's just 100 words, write them down. Does it sound compelling enough to you? Because everyone else will start out even less interested.

Last but not least, while a scripting engine can make a game core infinitely flexible, custom behaviors are still code, with all the complications that come attached. And the solution is closer to home than you think. Did you know Lua was first conceived as a data description language? Take advantage of it. Python and Javascript, too, are very good at that: they even gave birth to JSON.

Yes, that's about it, strange as it may seem. If you were expecting a thick tome chock-full of immortal wisdom, sorry to disappoint. To be honest, I'm still figuring this stuff out. Recent results however seem to suggest this approach works. Refinements can wait.

As for what you gain by making games quickly, cost savings are of course a factor if you also hope to make money from it. Mostly, however, it's about avoiding burnout, and preserving momentum. Finishing something you can play, and show off, is the best thing that can happen to your morale. And you need to be in good spirits, because you're in it for the long haul, at least if you want to get anywhere interesting.

The journey may be more important than the destination, but it's not much of a journey if you get bogged down spinning your wheels before the first checkpoint. So be wise.