Assignments

Project 1

Overview

Each student will design a UIView-based arcade style game that will run on an iPod/iPhone, iPad, or both. This game will build substantially upon our Paddler or Air Hockey assignment.

A paddle style game such as a Breakout or assorted Breakout clones would meet requirements. The game can be 1 or 2 player (or both). It should add vivid colors, images, more sound, unique paddles, bricks, obstacles, pucks, power-ups, or power-downs.

Other game genres are acceptable - such as a simple platformer or sprite shooter.

If you have taken the "steering course" 4080-434 Programming for Digital Media, and are familiar with steering algorithms (seek, flee, alignment, separation, cohesion), then you could adapt the Turtle example into a viable project.

If you want to do a card game or board game leveraging off of the Acey Ducey code, talk to me in advance.

It is expected (but not required) that you will reuse much of the Paddles or Air Hockey code. Much of your grade will be based on how far you go beyond what Paddles and Air Hockey did.

Interaction and Interface Requirements

• Touch or Gesture or Accelerometer Controls
• At least one element on the screen that is controlled by the user.
• Collision detection
• Scoring
• Sound - both incidental and background
• Screen for starting and pausing the game
• The app performs well and the interaction is intuitive. Things should work as expected.
• The name of the game and your name should be displayed somewhere.

Media Requirements

• High quality images and sound - we're not building a web page, so we are not as worried about file size. Favor lossless media formats such as PNG and high quality WAV, over lossy formats like JPEG and mp3. Avoid low resolution 8-bit images or sound (unless they fit the theme).

Object-Oriented Programming and Coding Standards

• Objective-C language, and no 3rd-party libraries without prior approval
• 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.
• Well commented code. Each and every method you wrote gets a comment indicating what it does.
• There should be no compile time or run time errors.
• CADisplayLink for Animation Loop
• For best performance - also be sure to comment out all your NSLog() calls before submitting the project.

Additional Programming Requirements (Important!)

• C arrays or NSMutableArrays of sprites
• UIImageViews that display bitmap images
• Dynamically created game elements
• At least 2 additional non-trivial Objective-C classes - created by you! At least one of the classes should have a custom initializer written by you - ex. initWithPosition:(CGPoint)point color:(UIColor*)color

Mastery

The project should demonstrate that the student has begun to master the course material we have covered to date. The coding and game interactions should build on what we have done in class.

Full credit will be awarded in this area to students who significantly extend Paddles or Air Hockey (if applicable),in programming, graphics, and game play.

Grading

• 30% - #1 Interaction and Media Requirements
• 20% - #2 OOP and Coding Standards
• 30% - #3 Additional programming Requirements
• 20% - #4 Mastery of the course material to date

Deliverables

• Due 10/10 - (Thursday Week 7) - 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 mobile-games/project1/ 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.
  
  -10% off of final grade if prototype/proposal not fully done
• Due 10/17 - (Thursday Week 8) - Final Deliverable with a written description of the rules of the game, and a written summary of how you met requirements #3 and #4 above. (-10% off of final grade if documentation not fully done)

FAQ

Q: Does the project have to support both iPhone and iPad like Paddles does? A: No - you may support only one platform if you wish.

Project 2

In teams of 2 (or 3 with advance permission), create a native iOS game or experience. The exact genre is up to you as long as it meets the interaction and programming requirements below. The scope and polish of the game should go well beyond what we did in Project 1. You should also utilize multiple APIs or technologies that we did not cover in class.

One decision you will need to make is: How will our game draw to the screen?

The top 3 candidates for drawing to the screen:

• UIKit - for project 2, only allowed for card/board games. If you have a Sprite based game, move down this list.
• CoreGraphics - higher performance than UIKit - adds capabilities for custom drawing, lines, curves, shapes, gradients, particle systems and so on.
• SpriteKit Framework (iOS 7) - built-in system of scenes and nodes, a scenegraph, particle system, physics, video, and more.

Other potential technologies:

• Cocos2D and Box2D - Game API - many tutorials at http://www.raywenderlich.com/tag/cocos2d
  One advantage: Cross Platform API.
  One issue: Not as easy to work with as SpriteKit.
  Note: The Box2D physics engine can also be used independently with the 3 technologies above - see this tutorial: http://www.cocoanetics.com/2010/05/physics-101-uikit-app-with-box2d-for-gravity/
• GLKit Framework - an easier way to work with OpenGL ES on iOS
• GameController Framework (iOS 7) - To add game controller support to your game
• GameKit Framework - Peer to Peer. Here's a nice tutorial demonstrating a peer to peer game: http://www.raywenderlich.com/3276/how-to-make-a-simple-multiplayer-game-with-game-center-tutorial-part-12
• GameKit Framework - Utilize GameCenter for posting achievements and high score - you need a full $99 developer account to use GameCenter.

Requirements (changes from Project 1 are highlighted)

Interaction and Interface Requirements

• Touch or Gesture or Accelerometer Controls - and touch controls should be more realistic and akin to Air Hockey, rather than Paddles.
• At least one element on the screen that is controlled by the user.
• Collision detection
• Scoring
• Sound - both incidental and background
• The app performs well on the targeted hardware and the interaction is intuitive. Things should work as expected.
• Important! Be sure to test your project on iOS hardware and check its frame rate in Instruments (the Core Animation Template).
• The name of the game and team member names should be displayed somewhere.
• The game should pause/resume on applicationWillResignActive: and applicationDidBecomeActive:
• Screens: screens are required for the major game states: start screen (with instructions), high scores screen, and game screen. You might also want (optionally) a credits screen, a dedicated instructions screen, or an options screen. Make sure that the name of the game and the team member names are displayed somewhere.
• High scores: stored to and retrieved from NSUserDefaults. You need to store the score, and optionally the user name.

Media Requirements

• High quality images and sound - we're not building a web page, so we are not as worried about file size. Favor lossless media formats such as PNG and high quality WAV, over lossy formats like JPEG and mp3. Avoid low resolution 8-bit images or sound (unless they fit the theme).

Object-Oriented Programming and Coding Standards

• Use Xcode5 exclusively
• Objective-C language, and no 3rd-party libraries without prior approval
• 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.
• Some game data will be loaded in from plist files when the app first starts up.
• 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.
• Well commented code. Each and every method you wrote gets a comment indicating what it does.
• There are no compile time or run time errors.
• There are no compile time warnings. These are commonly seen when using deprecated APIs. Update your code to the latest iOS6 or iOS7 APIs.
• CADisplayLink for Animation Loop (in SpriteKit you will instead use update:
• For best performance - also be sure to comment out all your NSLog() calls before submitting the project.

Additional Programming Requirements (Important!)

• C arrays or NSMutableArrays of sprites
• Dynamically created game elements
• At least 2 additional non-trivial Objective-C classes - created by your team! At least one of the classes should have a custom initializer written by you - ex. initWithPosition:(CGPoint)point color:(UIColor*)color
• At least two C helper functions
• Be sure to use time-based animation that is frame rate independent. SpriteKit often takes care of this for us - but otherwise you'll have to calculate deltaTime like we did in final version of Core Pong

Deliverables

1. Proposal: Due 11/7 (start of class Thursday Week 11) - 500-100 word web page detailing your game proposal containing at least the following:
   • Game Name (see here or here), team members and target device (iPhone, iPad, or Universal)
   • Inspiration(s), with at least one screen shot
   • Summary of game and genre
   • A mock-up of the main game screen
   • How the user will control the game: (accelerometer, tap, touch-and-drag, swipe, virtual buttons, ...)
   • A list of essential game features (core mechanic, power-ups, pick-ups, ...). Here are some compilations of game mechanics you might find interesting:
     • squidi.net/three/
     • SCVNGR game mechanics
     • gamification.org - Game Mechanics
   • Art style - see these examples
   • Sound - general style or taxonomy
   • A wish-list of additional features that you'd like done this semester (time allowing)
   This web page will be posted to a mobile-games/project2/ 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.
   
   -10% off of final grade if proposal not fully done
2. Working prototype: Due 11/14 (start of class Thursday Week 12) - Should have at least title screen and game screen implemented, and core mechanic of game should be functioning on the game screen. (-10% off of final grade if prototype not fully done)

FAQ

Q: Doe we have to have a lot of Sprite arrays if we use SpriteKit? A: No - SKScene's childNodeWithName: method may make these unnecessary.

Other ways to make iOS games

We won't cover these, and they are not allowed on your projects

• Unity3D
• Flash SDK
• PhoneGap
• Unreal Engine