Everyone knows that in order for a game to be finished, it is going to require a good amount of polish. However, few people seem to be able to define what this means exactly? If you ask a professional developer, they will likely say you need to juice it or that polish is fixing all the small details. You can’t disagree with those statements, but they are pretty meaningless as they can’t really be acted upon. In order to polish the last 10%, you need to complete the first 90%. So how does a developer, especially one that has never created a “AAA” product, know when they have hit that threshold? Can this threshold be quantified?

The answer is yes, so let’s walk through what I call the five steps to polish. I have created a very simple game to help illustrate these steps. There are three core elements to this game 1) a scoreboard to display the points, 2) every two seconds or so, an object will spawn randomly somewhere on screen, and 3) every time an object is clicked, the player is awarded 100 points. At no point will we change these elements in a way that alters their functionality, such as randomizing the point value or having the objects move around the screen. We will purely focus on polishing the experience as it is.

(more…)

 

One of the features I see many people struggle with when creating their games is the ability to pause the game. Part of the reason for this is that it is usually something they try to tack on late in development, which usually means adding a lot of conditional code to most scripts. This becomes very tedious and ends up adding in a bunch of bugs. In this tutorial, we will create a simple system that can help make pausing the game much easier.

(more…)

One of the biggest issues I see everyday with aspiring game designers is they often haven’t thought through what their game actually is. Sure, they have a general idea of what mechanics are in the game and a theme, but that’s about as deep as it goes. The first question I ask is if they have written a one pager. The answer is almost always “No”. The reason I am often given for not doing this is that they felt they didn’t have time waste writing a document when they could be building the game itself.

It doesn’t help that there are a lot of developers out there who have been quite vocal in the “uselessness” of documentation. I will agree that building a 300 page game design document before building ANYTHING is probably not the best use of a designers time, but to forego all documentation is foolish. Design by definition is a “plan”, which means documenting what is to be created. To me, the one pager is the most useful document there is as it forces the designer to clearly breakdown what it is they are trying to attempt. If you can’t explain what you want to do in a single page of writing, how are you ever going to build it?

After becoming frustrated with having to explain how to write an effective one page document for the millionth time, I decided I needed to provide an example. With that in mind, I wrote a one pager on writing one pagers which I am sharing with the world now. Oh, and for people who have seen this in the past, I have just updated it to make it even better. Enjoy! (more…)