iOS & tvOS Game Development

IGME-590

Assignments

Project 1 - Shooter of Shootiness

Deliverables

  • Teams of 2 required - declare in discussion thread by Tuesday 2/16
  • Design Document and Digital Mock up due in dropbox Tuesday 2/23. Use this template or similar for the proposal, and be sure to post it both to the web and to the mycourses dropbox.
  • Working Prototype due in dropbox Tuesday 3/1 - install a working version to an iOS device and bring it to class.
  • Final Version and Documentation due in dropbox Tuesday 3/8 - install a working version to an iOS device and bring it to class.

Overview

  • 2D Shooter using SpriteKit
    • Target phone or tablet screen size, probably not both
    • Target portrait or landscape orientation, definitely not both.
    • Minimum of 3 screens: Intro, Game, Results/High Score
    • A "ship" or player avatar is optional

Game Features

  • Simple Controls - tap to fire, maybe tilt to move, or slide finger to move (if applicable). For most players, badControls = badGame
  • Easy to learn and approachable - appeals to a broad audience, not just hard-core gamer types
  • Short bursts of play - 3 to 5 minutes or so
  • Sound - both effect and background
  • Good Onboarding - a new user can easily figure out how to play. Have an instructions screen if necessary.
  • Good Usability - not too hard at beginning, gentle difficulty curve
  • Depth - more than one way to reach the goal
  • Theme - Any!
  • Skin - beg, borrow, steal, or make the graphics yourself. Just be sure to document where you got them.

Other

  • The app must function properly on all supported devices. For example, an iPhone app should work on everything from a iPhone 4S to an iPhone 6s Plus. See Chapter 1 and 2 of the RW game book, as well as our PhonePortraitTemplate sample, to see how to do this.
  • The app must have icons for all required sizes, designed by your team. Read pages 41-42 of the RW game book to see how to import them. If you start with a 1024x1024 image, there are applications that will automatically export all of the required sizes for you. There are iOS icon tutorials online.
  • The app must have a launch screen. See pages 43-45 of the RW game book to see how to set this up.
  • Make sure the display name of your app is something meaningful, and is not something like "iPhoneGameTemplate". This link shows how to change your app's name: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/RenamingaProject/RenamingaProject.html

Programming Requirements

  • Multiple SKScene subclasses
  • At least one custom SKNode or SKSpriteNode subclass created by you
  • At least one SKEmitterNode
  • At least one SKAction
  • Use a nice font, not the default boring ones
  • Use imported textures where appropriate
  • Separation of concern: multiple classes, each with a well-defined interface. Also move reusable functions to a separate MyUtilities.swift or similar file.
  • Code comments, and organize your methods using //MARK:
  • Use groups to organize your class files in the project navigator.
  • Coding conventions - follow this style guide: https://github.com/raywenderlich/swift-style-guide

Documentation

  • Requirements:
    • Document that you met your proposal, and be specific about any work you did that truly went above and beyond.
    • Discuss any struggles or failures in the development process.
    • Describe which team member worked on what part of the project.
    • Give credit (author and link) for resources like images and sounds, and any software libraries, code snippets, or tutorials you used.
    • Be sure to give yourself credit for any graphics you created, or any code solutions you spent extra time on.
    • Grade yourself (0-100) and justify it.
    • Put all of this in a PDF and submit it with your project.
  • -10% deducted from final project grade if not done

Grade Rubric

  • Wow! = 101%+
  • Best (Goes significantly beyond expectations) = 96%-100%
  • Better (Goes beyond expectations) = 92%-95%
  • Good (Meets all requirements above reasonably well) = 90%
  • Fair (Lacks polish in 1 or 2 areas) = 80%-85%
  • Needs Improvement (Fails to meet 1 or 2 requirements) = 70%-79%
  • Not Acceptable (Fails to meet 3 or more requirements, crashes) = 0%-69%

Notes

Project 2 - Physics Game

Deliverables

  • Teams of 1 or 2 - declare in discussion thread by Thursday 4/7 (week 10). If you have an idea of what you might build, tell us.
  • Working Prototype due in dropbox Thursday 4/14 (week 11) - install a working version to an iOS device and bring it to class.
  • Final Version and Documentation due in dropbox Tuesday 4/26 (week 13) - install a working version to an iOS device and bring it to class.

Overview

  • 2D Physics Game or Toy using SpriteKit
    • Target phone or tablet screen size, probably not both
    • Target portrait or landscape orientation, definitely not both.
    • Minimum of 3 screens: Intro/Instructions, Game, Results/High Score
    • Ideas: an Angry Birds type game where you flick objects, or a "marble maze" type game where you move a sprite via the accelerometer, or any game that uses the physics system to both move sprites and have them react to one another.

Game Features/Requirements

  • Uses the SpriteKit physics system - gravity, mass/density, forces/impulses, friction, restitution, and so on. Some objects must move based on how they collide with one another.
  • Controls - tap?, swipe?, pinch?, rotate? accelerometer?
  • Sound - multiple effect sounds required (at least 3 distinct sounds). Background sound optional.
  • Good Onboarding - a new user can easily figure out how to play. Have an instructions screen if necessary.
  • Good Usability - not too hard at beginning, gentle difficulty curve
  • Depth - more than one way to reach the goal
  • Theme - Any!
  • Levels - at least 3. They can be created in the Scene editor, or created in code.
  • Skin - beg, borrow, steal, or make the graphics yourself. Just be sure to document where you got them.

Media

  • The app must function properly on all supported devices. For example, an iPhone app should work on everything from a iPhone 4S to an iPhone 6s Plus. See Chapter 1 and 2 of the RW game book, as well as our PhonePortraitTemplate sample, to see how to do this.
  • The app must have icons for all required sizes, designed by your team. Read pages 41-42 of the RW game book to see how to import them. If you start with a 1024x1024 image, there are applications that will automatically export all of the required sizes for you. There are iOS icon tutorials online.
  • The game must have a PNG logo, created by you, probably in Photoshop, Illustrator (or Flash). Display this logo on your title screen.
  • The app must have a launch screen that also displays your logo. See pages 43-45 of the RW game book to see how to set this up.
  • Make sure the display name of your app is something meaningful, and is not something like "iPhoneGameTemplate". This link shows how to change your app's name: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/RenamingaProject/RenamingaProject.html
  • Use a nice imported font, not the default boring ones
  • Use imported textures where appropriate

Programming Requirements

  • Multiple SKScene subclasses
  • At least one custom SKNode or SKSpriteNode subclass created by you
  • At least one SKEmitterNode
  • At least one SKAction
  • The game will pause properly whenever the app enters the background.
  • NSUserDefaults will be used to store high scores or some other data. This data will be displayed to the user on one of the game screens.
  • Separation of concern: multiple classes, each with a well-defined interface. Also move reusable functions to a separate MyUtilities.swift or similar file.
  • Code comments, and organize your methods using //MARK:
  • Use groups to organize your class files in the project navigator.
  • Coding conventions - follow this style guide: https://github.com/raywenderlich/swift-style-guide

Documentation

  • Requirements:
    • Document that you met your proposal, and be specific about any work you did that truly went above and beyond.
    • Discuss any struggles or failures in the development process.
    • Describe which team member worked on what part of the project.
    • Give credit (author and link) for resources like images and sounds, and any software libraries, code snippets, or tutorials you used.
    • Be sure to give yourself credit for any graphics you created, or any code solutions you spent extra time on.
    • Grade yourself (0-100) and justify it.
    • Put all of this in a PDF and submit it with your project.
  • -10% deducted from final project grade if not done

Grade Rubric

  • Wow! = 101%+
  • Best (Goes significantly beyond expectations) = 96%-100%
  • Better (Goes beyond expectations) = 92%-95%
  • Good (Meets all requirements above reasonably well) = 90%
  • Fair (Lacks polish in 1 or 2 areas) = 80%-85%
  • Needs Improvement (Fails to meet 1 or 2 requirements) = 70%-79%
  • Not Acceptable (Fails to meet 3 or more requirements, crashes) = 0%-69%

Notes

Project 3 - Final iOS Game of Awesomeness

Overview

We have 3 weeks to build a final iOS game! The rubric used to grade the game will be essentially the same as project 1. What changes is that you likely build something besides a 2D shooter. Let's look at some possible options:

#1 - Project 1 (or Project 2) Redux

This is hopefully self-explanatory. Go back and fulfill the previous project requirements, but with a whole new idea. Be advised that the overall expectations are now higher, especially for Project 1.

#2 - Radically improved Project 1 or Project 2

You should make major changes and improvements to one of your previous iOS projects. The coding, graphics, sound, onboarding, mechanics, and gameplay should all be improved. You should be striving to make the game "app store ready". Some ideas:

  • First, start over and re-architect your game (especially if it is project 1) from scratch.
  • Optimize your game for either iPhone or iPad.
  • Add depth to your game. Give the player meaningful choices. Carefully craft the difficulty and content of your levels manually, instead of relying on random generation.
  • Find people to play the previous version of your game, and act on their suggestions.
  • Use actions to better communicate to the players what is happening in the game.
  • Bling! Use dramatic animations, particle systems, and sound to grab the players attention and imagination.
  • Improve the controls - they should be easy to use and give the player satisfying control of your game.
  • Improve the sound - there should be several types of incidental sound effects.
  • Improve the graphics - get rid of all placeholder graphics and use professional quality graphics either made by you, or found online.
  • Improve the onboarding.
  • Improve the difficulty curve - it should start out easy, and then steadily get more difficult.
#3 - Improved Geometry Fighter

Take the "juiced" Geometry Fighter as a starting point and make the following improvements:

  1. Add lighting and materials
  2. Change the name of the game and the graphics (the launch screen graphics and the background). Be sure that you have a launch screen.
  3. Give the game discrete levels where the user can take a break.
  4. Give the game a "Game Over" screen that summarizes how they did.
  5. Each level is a thoughtfully designed experience, and not completely random.
  6. Give the game more depth - each level will introduce a new rule or element of the game, that gives the player the ability to make meaningful choices : Here are some ideas (we'll brainstorm some more in class):
    • The game starts out with a limited number of shapes, and introduces more as the levels increase.
    • Combos (same shape, or same color, or just not letting any escape the screen) give more points.
    • There are more "bad" shapes or colors. The bad ones can change on different levels. We're trying to trick the player into tapping a bad shapes or color.
    • Different shapes have distinct motion characteristics. Once the players learn these, they get better at the game.
    • Every nth level is a "blitz mode"
    • If certain shapes leave the screen, the player loses a life. These shapes/colors should be similar to the "bad" shapes/colors.
    • Certain shapes have to be tapped more than once to destroy them. The first tap gives them an impulse that drives them off of the top of the screen.
    • Use the z-axis

You may wish to completely re-skin the game and move away from abstract shapes - "Kitten Fighter"? or "Nazi Fighter"? - and that's OK.

#4 - 3D Game of Awesomeness

Build a game within the scope of Project 1, but this time in 3D.

#5 - Student's choice

Have an idea that doesn't fit in one of the foregoing bins? No worries, just run it by the prof as soon as possible.

Deliverables

  • Teams of 1 or 2 - declare in discussion thread by Sunday 5/1 (week 14). Also tell us what you plan to build.
  • First working Prototype due in dropbox Thursday 5/5 (week 14) - install a working version to an iOS device and bring it to class. -15% off of final project 3 grade if not done.
  • Second working Prototype due in dropbox Tuesday 5/10 (week 15) - install a working version to an iOS device and bring it to class. -15% off of final project 3 grade if not done.
  • Final Version and Documentation due in dropbox Tuesday 5/17 (Finals Week) - install a working version to an iOS device and bring it to class.