Mobile Game Development IGME-590

Goal: to create an iOS mobile game.

Teams of 1 or 2 will design a SpriteKit-based iOS game that will run on an iPod/iPhone, iPad, or both. The scope and polish of the game will go beyond what we did for Project 1.

Your team's game will demonstrate your mastery of Objective-C programming/design patterns, the SpriteKit API, and game design.

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".

Milestones

Requirements and Grade Rubric

  1. 10% - Media Requirements:
    • Sound:
      • A background sound that loops.
      • Effect sounds.
      • Use high-quality sound media (i.e. avoid 8-bit WAVs)
    • Images:
      • Optimized bitmap Graphics - most likely PNG
    • Fonts:

    Important: Make sure you checked the "copy" box when you imported your media!

    Using open source graphics and sounds is allowed as long as you give credit to the original creators in your documentation.

  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. 20% - 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.
    • A polished User Experience that respects the iOS Mobile HIG, as well as iOS 7 Design Principles (think back to the iOS game design video you watched):
      1. Clarity - it should be clear what the app does, and people should be able to use it without instruction.
      2. Deference - content is front and center - the UI should fade into the background.
      3. Depth - it should be a vibrant and life-like experience, and people should not get "lost" or be confused about what state the app is in.
  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.
    • The names of your team members must be somewhere in the application.
    • Game Design Requirements:
      • Meeting your plan:
        • It's expected that your game will change from the original design document, but overall you need create an approximation of what you planned.
      • Game Entity (Sprite) Behavior:
        • Do your sprites behave in interesting ways that go beyond what we did in class?
      • "Game-ability"/"Game-ishness":
        • Playable by at least one person, has rules, has a win/lose condition?
        • Do player choices matter?
        • As the player learns how to play the game can they improve?
        • Is the game fun and something people would want to play?
  5. 15% - 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 or warnings.
    • 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 and Airplane. This is why you must comment all of the code you write.

Resources

Rubric

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

Final Documentation - put the following into a PDF (-10% if not done)

Final Submission