Goal: to create an arcade style mobile game.

Each student will design a SpriteKit-based arcade style game that will run on an iPod/iPhone, iPad, or both. The X-Blaster example from chapters 6 and 7 is good example of the scope I'm looking for.

Your game will demonstrate your comfort with the SpriteKit API as covered in Chapters 1-7 of our SpriteKit text.

Acceptable game genres include sprite shooters, paddle style games such as a Breakout or assorted Breakout clones, a simple platformer, jetpack joyride, or ??. Your game will most likely be a single player game.

If you designed or developed a game for another class and in another language (such as AS3 or JS/Canvas or C#/XNA) it is acceptable to "port" that game to iOS - just be sure to give credit in your "one-pager".

Requirements and Grade Rubric

1. 10% - Media Requirements:
   • Sound:
     • A background sound that loops.
     • Effect sounds.
     • Use SKAction +playSoundFileNamed:waitForCompletion:
     • Use high-quality sound media (i.e. avoid 8-bit WAVs)
   • Images:
     • Optimized bitmap Graphics - most likely PNG
   • Make sure you checked the "copy" box when you imported your media!
2. 15% - Interaction Requirements:
   • Control
     • The player should be able to control at least one sprite on the screen.
     • Use touch controls: touchesBegan:, touchesMoved:, touchesEnded:, touchesCancelled:, or the accelerometer, or a combination.
     • If using touch controls, don't have the player "teleport" to the location of your tap, but instead:
       • Tween towards your tap (using an action most likely) OR
       • Move as you slide your finger on the screen - see X-Factor for an example. This makes the entire screen a virtual trackpad.
     • Do NOT use on-screen buttons for controls - although a large tappable "region" on an iPad game might be acceptable.
3. 15% - Usability Requirements:
   • Game Screens:
     • At a bare minimum there should be three screens (done with SKScene subclasses or some other method): title/instructions screen, game screen and game over/play again screen
     • Put your name on either the title screen or game over screen.
   • Teaching: The player should have no trouble figuring out how to play the game. If necessary, provide instructions.
   • Feedback: The player should intuitively know what "state" the game is in, and if their actions hindered or helped their progress in the game. A score should be visible to the player.
   • Difficulty: Be nice to your players. The game is easy at first, then it gets harder. The player shouldn't die in 2 seconds like Flappy Birds.
4. 40% - Required Game Elements:
   • The player should be able to control at least one sprite on the screen (as mentioned above).
   • Multiple Categories (at least 4) of app-controlled Sprites:
     • Use actions (or SKScene -update) to control sprite behavior
     • Try to make some of the sprites behave in unique ways. See this post about doing custom tweening in your actions.
   • Collision Detection - something should happen when certain sprites intersect.
   • Animation - there will be at least one frame-based animation.
   • Particles - there will be at least one particle system.
5. 20% - OOP and Coding Standards:
   • SpriteKit API
   • Remove sprites (- removeFromParent) when you are done with them - even if they are not visible on the screen, they are still using up memory.
   • Separation of Concern - You should have multiple Objective-C classes, with each class having well-defined functionality accessed through a public interface.
   • D.R.Y. - Don't Repeat Yourself. Repeated blocks of nearly identical code should be factored out and placed in a separate method.
   • No "magic numbers" (unnamed numerical constants) - declare C style constants or enums instead.
   • Objective-C code conventions: public properties and methods declared in .h file, private ivars declared in .m and begin with an underscore, class names are capitalized, method names are in lower case.
   • There should be no compile time or run time errors.
   • Well commented code. Each and every method you wrote gets a comment indicating what it does.
   • Delete or comment out your NSLog() calls
   • You will only receive credit for code that you write beyond what you've inherited from Zombie Conga and X_Factor. This is why you must comment all of the code you write.

Resources

• Chapters 1-5 of the book (Zombie Conga) covers many essential SpriteKit features.
• Chapter 6-7 of the book (X-Factor) demonstrates a Sprite Shooter.
• The SpriteKit intro and tutorial you did here
• raywenderlich.com - Space Invaders
• The Interwebs
• ** Important ** - Do not begin your project with a "Save As..." of any of the textbook projects (or any others on the web). This will result in a grade of zero.

Rubric

• Good (Meet all requirements above reasonably well) = 90%
• Better (Go beyond expectations in 2 or more areas) = 95%
• Best (Go significantly beyond expectations in 2 or more areas) = 100%
• Wow! = 101%+

Working Prototype and "One pager" (-10% if not fully done)

• Due 4/10 - (Thursday Week 10) - Working Game Prototype and a nicely formatted "one-pager" giving the game name, your name, describing user control, and details about gameplay and each of the elements of your game.
• The "one-pager" will be a web page posted to a 590-game/project-1.html folder on your gibson account, and should have at least one game "mock up" image on it. Be sure to check the Students page and verify the link works.
• The working prototype will be posted to a dropbox, and installed to a device and brought to class.

Final Documentation (-10% if not done)

• Document how you met the 5 categories of requirements, and be specific about any extras you did.
• Document any resources (libraries, sounds, images, tutorials, sample code) you utilized.

Final Submission Due 4/19 - (Saturday Week 11)

• ZIP up and post to dropbox before due date of 4/19 . This is worth 15% of final grade.
• Paste the documentation into the comments field of the dropbox.