Blade Edge

Over at Game Institute I help to judge a regularly-occurring game making contest over there, which I’ve mentioned before on GDNet. The challenges are open to everyone, not just GI students. There are no prizes awarded, other than a trophy that shows in your badge area on the forums, but that hasn’t stopped people from entering time and time again. Why? Because you gain experience and get great feedback from myself and Jon (another GI staff member who judges).

There have been 11 challenges so far, and #12 will be starting in just a few weeks. Over the years I’ve judged many games and have come across many mistakes people consistently make in developing their games. Here’s a post I made on the GI forums detailing these mistakes – this information is useful for anyone looking to make a game within a rather short time-span of 6-12 weeks, whether it’s for a contest or your own self-interest.

---

Let’s get one thing straight…

Congratulations to all the entrants who submitted a game. You’ve all managed to get a semi-working or working game completed in the time allotted, which says a lot about your dedication and self motivation.

That being said, I want all the entrants to take the judge’s feedback critically, not personally. We’re not saying “you suck, why are you even trying to make games?” we’re saying “here’s what you need to do better or think about more next time.” Don’t feel bad if you open your judging sheet and see line upon line of negative comments – because that’s pretty much all you’re getting from me. I’ll pat you on the back in some cases but for the most part my job is pointing out as many flaws as possible in your game so that you can learn from them and better yourself.

Call me Peirce Morgan or Simon Cowell – I love those guys. Jon can be Dave Hasselhoff or Randy Jackson if he wants.

Let’s get one more thing straight…

Right, so congrats on completing a game (in some form or another) but that’s not what you’re being judged on. You’re being judged on how the game plays, how it looks, and how it runs. I mention this only because a lot of people didn’t seem to keep in mind the one person they should always be thinking about, which is the person playing your game. There have been a slew of horrible and bad design and user interface decisions across entire competitions – so at least you can all feel safe in that I couldn’t single out any one person to pick on.

But that’s okay, because I don’t want to name names anyways. The guilty know who they are and the rest of you can learn from their mistakes.

Mistake #1: Incomplete use of installers

For those of you that use an installer, not all of you do it properly. Some forgot to allow the game to be uninstalled, some forgot to install an icon on the desktop, and a lot of them don’t give me the option to run the game after install. There are plenty of freeware installers out there that are easy to use and have all of these options available, and other commercial-quality ones that you can use for non-profit games. I’m not saying making an installer is easy, but if you’re going to do it you might as well do it right:

• Installer should let you choose your own directory
• Installer should let you choose to place an icon on the desktop
• Installer should give you the option to run the game and view the ReadMe file after install
• Uninstaller should be included via Start Menu folder and/or Add/Remove Control Panel app
• Express install option isn’t required but is a nice bonus too

Just think if I were a publishing exec looking at your game demo and had to dig through my Start Menu to run it. I’m already grumbling and I haven’t even seen your game yet!

Mistake #2: Closing the game on exit or level end

I’ve been very, very tempted to stop judging any entries that simply shut down the entire game when either of the two scenarios occur:

• Ending game/level – Congratulations you beat the game! Thanks don’t play again! Is this you assuming that your game has no replay value? It’s even worse if I don’t make it through the game and when I die it says “Game Over” and then I hit a key and the application shuts down completely. Well, okay then I guess I won’t try again…
• Exiting the level – The most common culprit is the ‘Esc’ key, which I can understand as a quick way to exit a game during debugging but shouldn’t be left in a version other people will be playing. Even worse are games that have main menus yet when you try and exit the level, instead of going back to the main menu it shuts down completely. Anytime you have a UI path that exits the game entirely, you should pop up a dialog and ask “Are you sure?”

Mistake #3: Assuming the user is as knowledgeable as you are about the game

I don’t know what your game controls are unless you tell me. I don’t know that I’m supposed to click the mouse button or press a key to move on to the next level or return to the main menu unless you tell me. Sure, I can figure it out for myself after a few experiments (Ooops, I tried ‘Esc’ and closed the entire program) but why should I have to do that? If I see text pop up on the screen saying “Level 1 Complete!” and nothing else I’m going to sit there for a few seconds and wait for the next level to load up before I feel like an idiot and realize I was supposed to press ‘Enter’ or click the mouse to continue on.

Mistake #4: Assuming the user will play just like you do

Worst trap of all, this one. You can’t design your games around a certain style of play (like your own), because the more people feel like they’re being forced to play a certain way, the harder they’ll try to break your system and do things the way they want to. A good friend of mine spends most of his time playing games that have stats and levels by remaining on a single early stage for days and doing nothing but killing enemies on that same stage until he maxes out his character, then continues on and plays the rest of the game – at which point it’s now easy. In one of the games submitted during a past competition, I could fly low to the ground and not be able to be targeted by anything while still shooting things. Make sure you’re always thinking outside your own box.

Mistake #5: Not handling loss of window focus

This is one of my biggest gripes across the board. Windowed game after windowed game and during every one at some point I would accidentally click outside the window… and the game would keep playing. Even worse, some of them would lock the flying object’s movement direction if I happened to have a key down when it happened. It wasn’t hard to detect a window losing focus back when I was using DirectX 7, it can’t be any harder today. At the very least the game should enter a paused state.

Mistake #6: Not fully reading the contest rules

Be sure that you fully understand the rules of the Challenge before you begin. I’ve had to take points off (sometimes significantly) for entries that didn’t quite stick to the concept idea that was laid out for that Challenge. If you have any questions or are unsure about things in any way, contact Jon or the other participants.

Mistake #7: Not properly managing the game state

This is a fundamental aspect to game creation, and is something you should be managing from day one. The game state tells your program what is happening in the game – whether the user is at the main menu, starting the game, playing the game, paused the game, exiting the game, entering the in-game menu, etc, etc. For all these events there is a transition involved that requires you to manage game objects to ensure that they too know the current state of the game.

For example, when a game is over make sure that mouse actions no longer make it to the gameplay code! In the last contest (#11) I could shoot bullets and lay pieces of track after the game was over. Restarting a game without completely exiting the application is another problem that has appeared in previous contests, including the recent #11. I’ll exit and restart while still in the application and some game objects will not reset properly.

Here are your basic game states:

App Start – here you load resources, create the main window, check to ensure that everything has loaded properly

Main Menu – here you take input and direct it to the UI code to handle navigation between menu screens (help, high schore, player selection, options, etc – all are sub-states of Main Menu)

Game Start – here you initialize all game objects, set up your level, and allow the game code to start receiving mouse/keyboard input

Game Run – here you execute the actual game logic

Game Pause – throw up a pause screen/menu and block out control input from game logic, pause game objects/scene

Game Over – throw up win/loss, redirect input back to UI and no longer to game code. Upon exit to main menu, destroy all game objects (do NOT leave any in memory as an “optimization” to make a new game load faster)

App End – destroy all application objects, unload UI, unload game window, exit game instance smoothly

These are just basic high-level state descriptions. The key is to recognize the various states of your game in particular and make sure your game is only ever in one.

Getting the priorities straight

One of the best aspects to challenges like these, were you have a very limited time in which to complete a project, is that they really help to teach you how to focus on what really matters, which is what makes your game fun to play. Your priority is to get something playable as soon as possible that is fun. Not something that installs itself, or has a million options, or uses the latest shader technology. If you can’t, from the very start, write a sentence of your game idea that describes the aspect of your game that makes it fun to play, you’re not ready to start coding anything yet. If you can’t distill the entertainment in your game to something that small, you have very little chance of completing your project in the time given for this competition.

Oh, and don’t make the mistakes listed above either.