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
- Team and idea due start of class Tuesday 4/29 (week 13) - see mycourses discussion threads
- "one-pager" due start of class Tuesday 5/6 (week 14) - post link to discussion thread
- Working Prototype due start of class Thursday 5/8 (week 14) - install on iOS device and bring to class
- Last day of class is Tuesday 5/13 (week 15)
- Final Version Due Thursday 5/22 at 2:45PM (the scheduled final exam time during finals week)
- If you borrowed an iOS device from IGM or IST, you must return it at the time of our final meeting - and don't forget the cable.
Requirements and Grade Rubric
- 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:
- Use custom fonts for your project -
Times New Roman
andArial
and the like are hereby banished. - Do this either in graphics or by importing .otf/.ttf files - see this post: http://stackoverflow.com/questions/21737788/custom-fonts-in-ios-7
- Use custom fonts for your project -
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.
- Sound:
- 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.
- Control
- 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.
- At a bare minimum there should be three screens (done with
- 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):
- Clarity - it should be clear what the app does, and people should be able to use it without instruction.
- Deference - content is front and center - the UI should fade into the background.
- 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.
- Game Screens:
- 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.
- Use actions (or
- 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?
- Meeting your plan:
- 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
- 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)
- 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-2.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 - put the following into a PDF (-10% if not done)
- Document how you met the 5 categories of requirements, and be specific about any extras you did.
- Document any external resources (libraries, sounds, images, tutorials, sample code) you utilized.
- Document previous projects you utilized.
- Document who worked on what part of the project.
- Toot your own horn. Document artwork you created, and coding problems you creatively overcame.
- Give yourself a grade (A-C) and justify it.
Final Submission
- ZIP up and post to dropbox, install on iOS hardware, and bring to the scheduled final exam time. This project is worth 25% of final grade.
- Submit the documentation PDF to the dropbox.