Game development competitions (shorter ones are called “game jams”) have scoring systems to determine the winners of the competition, but it can be difficult to design a scoring system that causes the best game to win.

Here I propose model judging criteria for a game development competition that have several advantages:

• They can be used by even untrained judges to score games fairly.
• They reward all aspects of game design and development.
• They reward games with the most effort behind them.
• They provide a lot of feedback to the game developers.

You are free to use these criteria in your own game development contests, or to modify them for your contest’s needs. They are based on the criteria I used in 2010 for the UFEC contest which were in turn based on the criteria of GameDev.net’s Four Elements series of contests. 

Here’s the criteria. I describe the judging system and details on the criteria further below.

The judging system. Many judging systems are compatible with these criteria. In general, you’re going to have one or more judges who each assign scores for one or more criteria on one or more entries.

For example, UFEC used the following system:

Each contestant and anyone from the public may each grade any number of games. You can’t grade your own game. You don’t need to grade each game on each criterion. For each criterion where you put a grade (a number from 0 to 10), you must submit feedback as text as well. To get the total score of game, sum the average score of each criterion. The winner is the game with the greatest total score.

Details on the criteria.

• Technical. This category rewards technical craftsmanship and attention to detail.
  • Stability. A game should be rewarded for not having game-breaking, progression-breaking or annoying bugs.
  • Best practices. This is a catch-all technical criterion for various minor features such as those that I list in Gamedev Technical Best Practices.
  • Performance. Games are usually expected to be able to run at 60 FPS on a standard gaming PC at some reasonable configuration. 
  • Documentation. Admittedly less standard than in the past, documentation still enhances the player’s experience. It is better to have documentation available in-game, such as with an in-game encyclopedia. Documentation is more required for complex rules-based systems, such as turn-based strategy games, and less so for action games.
• Production. This category rewards the art aspects of game development.
  • Graphics. Good art can exist in any medium, even in retro-style low-pixel-count games, and that’s one aspect of grading, but also some games simply have better graphics than others, and a modern FPS shooter should always get a higher score here than a box-sliding puzzle game: this category includes grading the art on its own merit.
  • Audio. A game that’s voice-acted is better than one where you must read the dialogue yourself. Music and sound effects are expected in all games.
  • Writing. This includes both the instructions being understandable, and the writing being fun and enjoyable to read, perhaps because the story is original or the characters interesting or relatable. Grammar and spelling errors should cause the grade to go down.
  • Polish. This is a catch-all criterion for how technically and artistically polished the game feels. 
• Gameplay. This category rewards game design and the implementation of mechanics.
  • Fun (immediate). A good game should catch the judge’s attention from the start and shouldn’t force them to sit through thirty minutes before it starts to get good.
  • Fun (longterm). But also games should be rewarded for either their replayability or amount of content. A short quick game that only gets you a couple of minutes’ worth of fun should be graded worse than a 40-hour RPG.
  • Originality. It is more difficult to create a game that isn’t a gameplay clone of an existing game but such efforts should be rewarded.
  • Accessibility. A game’s difficulty usually shouldn’t come from learning its user interface or from trying to get it to run. The best difficulty curve is usually smooth.
• Theme. This category rewards compliance with the competition theme.
  • Theme cohesion. The developer should be rewarded for inventing their core game based on the theme rather than preparing a game in advance and then “bolting on” the competition’s theme onto it.
  • Theme-based. And if the developer bases their game on the theme to such a level that the game couldn’t work at all without it, then that’s worth extra recognition.
  • General cohesion. This is an extra subjective criterion that you may wish to roll into Production’s Polish criterion.
  • Completion. When you complete the game, do you feel like “this was the appropriate point at which the game should have ended” (good), or do you feel like “the developer ran out of time at this point and just packaged the game”?

Conclusion

I proposed model criteria for a game development contest that rewards complete games rather than prototypes of a work that still needs to be finished. 

It is my hope that more game dev competitions will adopt judging criteria similar to these because contests with such criteria test a wider array of skills and also result in more complete and fun games available to the general public.

If you create or know of a contest like that, let me know in the comments or at petrhudecek2010@gmail.com, please!