You are examined on your demonstrated understanding of game design and game programming, through your work: * the game product * presentations (game seminar, final oral examination). It is not about if your game is good, fun, or will sell. You may have made a bold attempt at something innovative and not succeeded. This is still better than a clone of something standard. Don't be afraid to take risks, though you might not succeed in terms of a product, its the knowledge we grade. *Examination is individual!* Everyone in a team must know and understand all technical and design-related aspects. Teams larger than two will have to implement bigger projects. A situation may arise where students working together may not all pass, this has actually happened in the past. Teams of one is perfectly OK, sometimes even preferable. Examination criteria: * Quality of completed tasks and game project. (What is quality: see below - tip its not size or number of features) * Ability to incorporate game-design knowledge into the game project. * Volume of work - with regards to number of participants. Grading criteria: * Well tested, polished game: the game works flawlessly and intuitively with regards to controls. It is a complete game experience. * Teaching the game through the experience: teaches without stopping the player from playing. Gives visual and auditory cues and feedback that makes understanding the game easy. This is excluding tutorials and instructions. * Progression: the games evolves from easy start into a suitable challenging level also including elements of variation * Skill: the game has a skill element, where experienced players can play at a higher level than noob. * Complexity of the game development platform vs. the game content: e.g. using Game Maker, pygame or Construct 2 compared to Godt, Unity and Unreal requires much more and more balanced game content.