Team Game Quest (Project)
Build a game! Okay, you need more than that…
Every game will be different, so there’s no way to say “you must have X feature” in reality. But here is how the staff will evaluate your games.
Is it a working game?
Simply put, the game should function without any obvious bugs or failures. The game should:
- play and feel like a completed product, not something still in beta form;
- have an obvious start and end to the game, with the ability to “play again,” depending on the nature of the game;
- have working and understandable controls.
Points are earned for how well the game performs during playtesting.
Is the game engaging?
Does the game grab the player and make them want to play more? A successful game will:
- draw the player in and entice them to keep playing;
- have a unique and interesting mechanic;
- feel good to play (appropriate controls, difficulty, etc.);
- be fun/enjoyable to play.
Does the game meet its aesthetic goals?
Can a staff member quickly and easily identify one or two aesthetics from your game? Does your game focus on and emphasize those aesthetics?
How polished / refined is the game?
We do not expect perfect art assets or anything like that. We do expect the game to look “put together,” is playable, and feels like something that could be given to someone not in the class and they could play it without a ton of assistance.
How did the team work together?
Game documentation, team evaluations, use of GitHub all fall under this category. XP is earned here through:
- high evaluation marks from teammates;
- the documentation submitted follows the outline and contains all necessary information;
- GitHub was used effectively, showing good software development techniques.