Game development: reducing scope (traffic simulation)

One of the tricks of game development, especially that done by small teams, is reducing scope of each feature or element to a minimum necessary level. It is critical to make efficient use of developers’ time since there is only so many cycles available, and the longer a project goes on the more likely it is to get cancelled or postponed. The more games you get under your belt the more you start to care more about this kind of stuff.

To give an example of this – one of the core elements of my latest game in development is a series of connected roads with cars running through them, a little like what you would see in a modern version of a SimCity-type game. Starting several weeks ago, I experimented with several different ways to implement this “traffic simulation” element in my game.

Initially, I started with the idea that I would use Unity 3D, since that would allow me to show a very realistic simulation of cars moving through a network of roads. I was inspired by the mobile game Does Not Commute, which uses a 3D engine to good effect.

However, after learning a little more about the Unity 3D workflow, I realized I would be spending a big chunk of my time on the graphics and other 3D elements, which would make the core gameplay elements (behavior, logic, rules) take that much longer to do. Though the end result might look quite attractive, I had doubts that I could finish the game on my own if I took this route.

So for the time being I decided to make the game 2D. My next decision was whether I should use a physics engine or not. I’ve been interested in physics engines myself for some time, having made very simple ones years ago, so I decided to download and experiment with a few different frameworks, including Box 2D. In only a few hours, I was able to get some test programs running and there was a surprisingly rich set of functionality for the free frameworks I tested.

But again, I posed the question to myself – do I really need detailed physics simulation? Is having cars collide, spin out of control, and follow a physically accurate path really critical to my game’s core gameplay? While this would be a cool feature, I eventually decided this was overkill, and again reduced the scope of my traffic simulation efforts.

At this point I entered into prototype development, spending my evening hours making a bear-bones traffic simulation where each car was resented with only a handful of properties such as color, location, and speed. I got this working and am now experimenting with different game objectives, and creating stages to see what is actually fun (and challenging) – the most important aspect of any game.

If things go well and I feel I’ve made an entertaining prototype, I can continue to polish the visuals, or even consider going back to 3D. With a proven game idea, the risk for failure would be greatly reduced.

If I had determined that simulating cars as individual entities was not a critical element of my game, I could reduce scope yet again and simulate at a coarser granularity. For example, in the original SimCity game (which happened to be the first game I purchased with my own money), traffic was handled by road-piece granularity, where a stock animation was selected based on the traffic density of that area at the given time. You couldn’t follow a single car around since they would appear and disappear if you looked closely. While a system of roads was important in building an efficient city, tracking an individual car from point A to B wasn’t necessary, and players had more to concern themselves with. Also, I believe the original SimCity was only made by two or three developers. In more recent versions of that series it seems that cars are modeled as individual entities.

I’ll post some more about this project as things progress.

Prototypes: an integral part of software development

This time I’d like to talk about the process of creating prototypes. Though this blog is about mobile gaming, prototypes can be a valuable tool for almost any time of software development.

What is a prototype?

A prototype is an limited version of a program which is intended to test something, such as a new game idea. It’s definition is fairly open-ended, but it contrasts from a production version which is something designed to be used by customers, as a complete game or application.

When do I need a prototype?

Creating a prototype is typically warranted when there is some uncertainty the project which needs to be worked out, essentially de-risked, before taking on the full production project. Prototypes are usually appropriate when the full version will take quite a long time, possibly months or longer with a team of several developers and other staff.

The idea is that you want to avoid expending too many resources (money, time, etc.) until you have some level of confidence the project will succeed. Success is defined differently for each project, but it can involve making a certain amount of money, or just making a game that is fun to play.

The idea of prototypes also assumes the developer(s) have the capacity to work on more than project over time. If you compare working on a single project for a year, with a 50% chance at failure, as opposed to developing 10 prototypes during that time to find which idea(s) have the most potential, the latter could be considered a more efficient use of time.

How do I make a prototype?

The most important thing about prototypes is deciding exactly where is the risky part of your project, or the element(s) you want to validate. As an example, let’s say I have this great idea for a game that is a cross of checkers and a word game, and it seems really fun to imagine how it would work. In this case, the purpose of the prototype would be to see how enjoyable such a game would actually be, and to work out some of the gameplay elements.

You can work iteratively, trying one idea until you determine it doesn’t quite work, at which point you can add or change an element and do some more play testing. For example, in our checkers-word game example, you can play around with different scoring systems to see which is fair and offers the most challenge.

Tips for making a fast prototype 

The prototype creation process helps guide you what order you do your activities in. If you are testing the gameplay of the checkers-word game, there is no need to spend any time on the main menu system, the credits page, or the sound effects. You should be spending most of your time in the risky or uncertain element you are trying to test.

With games, graphics assets are one area which can take a long time to produce, whether you are doing it yourself or with the assistance of graphic artist(s). For many prototypes, you can skimp on graphics and keep things very minimal and simple. Rather than a photo-realistic game tile, you can stick with a simple single-colored square, and so on. Of course, if your idea involves creating a game with a certain atmosphere (like a horror game), the graphics and sound might be more important than the gameplay, in which case your prototype would require more effort on those assets.

One nice thing about prototypes is that you have much more freedom. For example, you can potentially leverage a test license for a game engine which you couldn’t otherwise use for a commercial project without paying big bucks. You can do the same for other assets which are legal for non-commercial purposes, though if you switch to a more serious commercial project, you’ll have to purchase the proper licenses for everything being utilized.

Prototype coding practices

When developing a prototype, you also have some more freedom regarding how you write your code. You can probably get by with spending significantly less time on things like commenting, proper modular design, and efficient algorithms. However try and avoid taking things too far, since adopting horrible practices like stuffing all code into a single giant function would make modifications of the prototype difficult.

Also, some things which you typically try to avoid in production code, such as global variables and cryptically named variables, would probably be OK in a prototype. Proper memory deallocation can also be put off, since you can always restart the app as often as you like during test.

Levels of grey in prototyping

Prototyping isn’t all or nothing, in the sense that you don’t have to throw all your code away after a prototype. You have the option of reusing parts of your code in the production version, probably after some refinement, or even in another project.

After writing many prototypes, I’ve gotten into the habit or always writing “TODOs” in my code so that if I do get to make a production version, I know what I need to fix. I also always think about whether it’s worth the few minutes to write a block of code properly, or decide to leave it in a quick, “hacky” state. Spending the few extra minutes to write proper code also makes you a better developer in the long run.

Prototypes need planning too

If your coding is just as a hobby in your free time you can do whatever you like, but if there is a chance you will try to go commercial or enlist the help of other people, it’s good to have a plan even for your prototyping.

First, decide roughly on how you are going to measure the success of the prototype. Will you just play it yourself for a few hours and see if it feels fun enough? Or will you show it around to your friends to get their feedback? You could even target an app store (mobile or desktop) as an end goal to your prototype. You probably won’t get too many downloads because of the lack of polish, but the process of getting on a store is always a learning experience.

Second, get a general idea of how long you think the prototype should take. Generally, I would say a few days to a few weeks is a good range. If your prototype is taking more than a few months then I wouldn’t really consider it a prototype anymore.

For new developers

For those new to software development or game design, your first few projects will probably all be prototypes, whether you think of them that way or not. In that sense, the goal of your effort doesn’t have to be to make a great app or game, but instead just learn something.

As your coding skills improve, you’ll be able to write a rough prototype in a shorter span of time. Saving code you’ve written in the past and reusing it when possible is a great time saver.

A real life example

Recently I had an idea for a casual mobile game which I felt had great potential, so I tried to make a quick prototype to vet the idea. By surgically ripping out parts of a previous project, I managed to make a working prototype in only two hours, and then added a computer AI player in another two.

The idea turned out to be a little less interesting than I imagined, so I’m glad I didn’t try writing everything from scratch. But at the same time, I feel with a few tweaks the gameplay might be taken to a new level, so I’m going to try a few more things when I get a chance.

All prototyping is essentially an experiment, so have fun!