You come across a great game that has turned wildly popular. You observed how easy it is to be made and want to make it to reap the same rewards. If you are not a good programmer, it would take you months to complete the game development project. Even if you are a good programmer, you still have to work on debugging, distributing, marketing. All in all, it is not small effort. Then your game hits its sixth month on the app store. Barely anyone downloaded your game, let alone clicked on the ads. You get reviews saying that your game is yet another clone in an ocean of clones.

Or, you are enamored by a game idea that you had as a child. It captivated your imagination all your life and you want to put on flesh to its bones. But first, you have to work on its bones. After not being able to complete it having spent months, you lose steam and motivation. You then stop developing any games for nearly a year before attempting that game project again. You’ve definitely learned a lot in the past experience that would speed up your work this time, right? Three months in, you realize how much farther you are from the goal. The only experience you seem to have gathered is to know more quickly how badly it would end this time.

The problem

Game development is often described as an art and a science. As an art, it is an expression of creativity. As a science, even artists needs sufficient technical knowledge to make logical decisions like the feasibility of the projects, and the ability to code well enough. It is when the art side of things start to take over that it gets easy to not look at things logically.

Cue QPark getting taking over by something else:

And like all commercially successful artists, the business mind also has to kick in to make sure that their captive audiences receive their products (aka their completed works). When you combine all these requirements, you pretty much need to quantify a project before even launching it.

The end in mind

Stephen Covey made popular the term “begin with the end in mind”. In the case of game development, the end isn’t merely the product, but the reception from the market as well as the commercial reality (not unless you don’t intend to make a living with game development).

You have to anticipate how your project’s outcome is going to be. Begin at the very end of gamer reception and ask what does it take to get there. Go backwards to how distribution will get to the gamers that you want in order to get that reaction. Then go backwards from there on how the product – your game – has to be like. With the end product in mind, that’s when you can better map out the genre, features and appearance of your game. And you can finally appreciate the scale of your project.

With experience, the vision of our end result gets more and more realistic. With that, we must understand that we may need to complete game development projects several times (whether with success or with failure), in order to get a better grasp of the industry. Therefore, let us establish right here and now that you have to complete the project.

The fastest way to read a book is to not read the book at all. It can also be said about projects (game development included), that the fastest way to complete a project is not to do it at all. However, you always want to take away the best experience from projects that you have decided not to embark on. The only way is to quantify a project on paper.

Know thy game development project

Often, understanding the scale of the project should be sufficient to answer a key question: Do I have the skill and time (and sometimes money) to complete the project?

It proves to be a good idea to have a written project specification. What a project specification will do for you the game developer, is to force articulation of at least the project objectives, the scale, and the cost (skills, time, effort, money). With these three important sets of information, it gets very much clearer how feasible this project is worth starting on. While this article does not go into greater detail about writing a game development project specification (a future article might), this one does.

Depending on the complexity in finishing your project, it might make sense to not do it alone. This might mean collaborating or hiring help in areas that is not feasible for you to do them yourself. For example, you may be a decent coder but you are not good enough in user interface. Hence you may want to work with someone else skilled in this area.

Or with an already written project documentation, it gets clearer what scale may not be immediately necessary for your first release of the game. You can then logically study your written project specification and remove features, thus reducing the scale.

So… should you still do it?

The project specification will already answer the feasibility of whether to even embark on the journey or not. Common cases will be that you do not have those required domain knowledge or skills yet, and acquiring them first will take too long to stay motivated in completing your project. Sometimes, the project specifications may show you an undesired side of your vision that you were not able to see it previously. You may then come to a choice of removing certain ideas or not getting started in the first place, so that you can move on to another idea quickly. Or it may be a happy ending, whereby quantifying the project convinces you that you should put the pedal to the metal, and get started on your project immediately.