fp-arduino

Arduino Reach Grading Rubric and Guide

Reach Grading Rubric

There is no autograder for grading the Arduino final project.
The Reach will be hand-graded by the teaching staff at the Showcase.
Staff will play the game using your hardware kit.
The staff will not pre-grade any part of the project before the Showcase.

Reach implementations fall into two categories for the Arduino project:

A new game or application of your design.

Recreate a classic arcade game, or design a game or other application entirely of your making.

Implement your own version of a classic arcade or other game: Frogger, Block breaker, Simon, a platform game like a Donkey Kong clone, Side-scrolling game like Super Mario, Snake, flappy bird, Google Chrome dinosaur game, or more.
Create a new application or game of your unqiue desing. Some examples that students have created before for the final project are unique rythm-based games and puzzle games.

Note: some games or ideas are far too simple to earn full points for the Reach. Pong is an example - recreating Pong would earn 20 of the 50 points for the reach. To earn full points, it would need to be accompanied by another game of similar complexity with a simple menu system to choose a game to play. It is expected that your Reach will be equivalent or greater in complexity (challenge to implement and/or code statements to implement) than the Core Invaders game. If you have an idea, you may ask the teaching staff for evaluation of the concept to have the potential to earn full points.

The staff will grade your reach by interacting with your creation at the Showcase. Multiple staff will grade each project to provide a comprehensive evaluation.

Full Score - a working game or program from the example list above. A working game or program is one that:

Staff can play or use at the showcase to evaluate
People can interact with for at least two minutes continuously at the Showcase - i.e., it cannot be so buggy that people can only use it for a minute and it cannot be so diffiuclt that no one can play for more than several seconds. Challenging games are fine, but the gameplay should be limited by difficulty not bugs or crashing. It is okay if a staff member repeats the game after failing a few times in the two-minute period.
Has three or less minor bugs visible while evaluating the game or program. A minor bug is anything that is seen that is interpreted as a defect, but does not inhibit playing the game as designed. An example would be a “stuck” pixel that should be black but is another color until another object changes the color of the pixel.
Has no major bugs. A major bug is something that inhibits gameplay or requires resetting the Arduino. An example of a major bug is the player or object moving off the display area making the game impossible to continue.

Points are deducted when:

More than three minor bugs are visible when testing: -5 points.
A major bug is one that inhibits or stops gameplay when testing, but the game can be restarted and otherwise is playable for two minutes: -5 points per major bug of this type. This categopry of major bug will not appear in every attempt to evaluate the game or program.
A major bug that inhibits or stops gameplay every time the game is tested: -10 points. The game should still be able to otherwise be evaluated - i.e., two minutes of gameplay can be had, even if over more than one attept.
A major bug that inhibits the functionality of the game such that it is impossible to fully evaluate the Reach: -25 points. Examples are games with one level that plays for noticably less than two minutes, but the next level always crashes.
The game or application cannot be evaluated: -50 points. Examples are no one from the team presents the project at the Showcase, or the game is so buggy it cannot be evlauted.

Be advised: Tetris is a very challenging game to implement using the Arduino kit and should only be attempted if your team seeks to push the limit. A few teams have successfully implemented this game while others have tried then abondonded the idea.

Features added to the Core Invaders Game

Your team may decide to extend the functionality and features of the Core Invaders game. Below are a list of examples and the points they would earn. This list is not exhaustive - you may devise other new features which will be added to the list for future semesters. Note that your team is not limited to the number of features added but the Reach is capped at 50 points.

When you demonstrate your game at the Showcase, you should have a prepared list of features to share with the staff. An example from the list below that would earn full points for the Reach are: adding a Boss battle, powerups, and a start menu (20 + 20 + 10 points). A feature is counted when staff are able to use/see the feature when playing your game at the showcase. The same deductions listed above for bugs apply to feature additions for the Core Invaders game.

Feature	Points	Examples
Boss battle level(s) for the game	20 points per Boss level	A boss battle is a unique Invader that represents a greater challenge to defeat. To earn the 20 points, a Boss battle or level should be at least as challenging to pass as Level 5 - a randomly generated strengths level of the Core Invaders game.
Multiplayer	20	Add a second player to the game - including potentiometer and button. This is just for the second Player appearing on the display in some way and being able to interact with the game.
Powerups	20	Powerups - note this is plural not singular - are items that change gameplay. Examples include items that increase life count, activate alternate firing or Cannonball modes/types, weaken Invaders on the display, slow or speed time, etc.
Create an AI to play the game	20	The game plays itself and can continue to play without input from a person.
Start menu system with options	10	When the Arduino is reset or powered on, the game does not automatically begin at level 1. A menu appears and the person must make a selection to beging the game, and that selection changes some element of the gameplay. Note: this feature is often more challenging to implement than teams expect. It does not require a significant number of statements but is conceptually challenging to understand how to implement.
Welcome screen with start	5	Similar to the start menu, except the choice does not affect the game. Like the start menu, this is likely to be more challenging to implement than most teams expect.
Animations or Art	10	Usually displayed before the game starts, between levels, or after a Boss battle. 10 points for each of: a detailed animation lasting 10 seconds or more, a sorter repeated animation such as when the player dies, or repeated "pictures" at multiple points in the game. Note: be very careful with animations and art. These can take significant amounts of memory to implement, and you may run out of memory very quickly. If you plan for animations, you should ask for one of the limited Arduino Mega boards, or purchase one early- they are inexpensive.
Invaders move side to side	20	In addition to Invaders moving down the screen, they also move side to side. Note that the Invaders should not be off the screen.
Custom features for each level	20	Levels have different rules or features. Similar to powerups, but level dictates gameplay features instead of items that the Player collects or collides with. Note: can be comined with powerups, but the implementation must be additional and not simply overlapping. That is, to earn the 40 combined points it cannot be simply on level n powerup a is active.
Add a piezo speaker and basic sounds	5	This is a basic feature that is very approachable and adds a lot of fun to your game. All the code to make sounds is avaialbe at arduino.cc, and adding a sound when the Cannonball hits an Invader or the Player dies takes very few statements.
Propose your own minor feature	10 to 20	Propose your own minor or major feature, equivalent to the other features listed at similar point values