Assignments

Projects

Project 2 - AIR Mobile Game of AWESOMENESS

Constructed in 3 phases. See below for details. (And if you don't wish to do a game, see me to work out the requirements.)

Overview

By yourself or with a partner, your mission is to create a Mobile AIR Game targeted at either Android or iOS, that is fun, visually engaging, and highly interactive.

Choose an existing game genre or come up with something new! If you choose an existing example such as the platformer or any of the examples from the text, be sure to add substantially to it.

The goal of this project is to demonstrate your mastery of AIR programming in a mobile game context. You will be evaluated on your creativity in game design, the quality of the experience you create, and the soundness of your programming, as described below.

Note: A simple game that is well-executed is better than an ambitious game that is incomplete. Games like Boomshine (Web & App store, Squares 2 (Web & App Store), Falling Balls (App Store), and Pixel Sniper (App Store) are all good examples. (But don't be afraid to go up in scale if you think you'll get good results!)

Required Design Elements

• Player Input & Feedback - the game will be controlled by buttons, taps, swipes, gestures, or device orientation. The controls should be easy to use in a mobile context.
• Game Animation and Effects - these should be engaging, but be careful they don't negatively impact performance.
• Sound - both background and incidental.
• Game-specific embedded fonts. Times New Roman need not apply!
• Screens:
  • Title Page
  • Instructions
  • Gameplay
  • Payoff (Win / Lose)
  • Credits
  • High Scores
• Performance - the game should perform well without any hiccups on target hardware. There shouldn't be an memory leaks.
• Data
  • Initial game data is loaded from a local XML file.
  • High scores are saved to the device.

Programming Requirements

• Object-Oriented Programming:
  • Separation of Concern - classes have 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.
  • Design Patterns - use Inheritance, Interfaces, Abstract classes, Singletons, Model classes, and so on as appropriate.
• Event-Driven Architecture:
  • Use event handlers and custom events when appropriate. Remember that custom events have more system overhead than simple method calls.
• Free of Runtime Errors:
  • Utilize error event handlers, guard statements, and try/catch blocks.
  • Test your code under error conditions such as bad user input, malformed URLs, and lack of Internet connection. It should fail gracefully.
• Follows Coding Standards:
  • Class Names are capitalized
  • Method names (other than the Class Constructor) begin in lowercase, and are camel-cased.
  • Instance variables begin with the letter 'p' and are camel-cased.
  • Library symbols are capitalized and end in '_Clip' for MovieClips, and '_Button' for Buttons.
  • Stage instances (what you drag to the stage during authoring mode) names begin in lowercase letters, and have the suffix '_mc' for MovieClips, and '_btn' for Buttons.
  • Event handler names always begin with "on" as in onXMLLoaded(e:Event) or onMouseEnter(e:MouseEvent)

Final Documentation

• Comments in your Code
• Written Document:
  • Title Page
  • Abstract
  • High-Level Architecture
  • Design Decisions
  • Technical Decisions
  • Extras

Deliverables

The following schedule will hopefully keep you on track.

Phase 1 – First Prototype – Week 8

A) Implement some classes of your game. Use temporary artwork to get a "gray box prototype" up and running. Rough out the mechanics of your game before you worry about the visuals. DUE FIRST CLASS MEETING OF WEEK 8 – WILL BE DEMO’D AND DISCUSSED IN CLASS

B)An abridged Game Design Document (at least 1000 words). This document will be college-level work, well organized with section headers, containing proper spelling and punctuation. You should draw upon any work in previous GDD courses, and it should contain the following:

• Game Title - ex. "Hare Trigger Part 2 - Hare Razin'!"
• Team Members
• Inspiration - names (and links if appropriate) to games that have inspired your idea.
• Target OS and Hardware - Android or iOS? Handheld or tablet? Fullscreen?
• High Concept/Abstract - ex. "A top-down SHMUP set in a post-apocalyptic world where the player takes the role of a heroic and heavily armed genetically-engineered rabbit who is trying to save his clan's burrow from his former captors, the evil mutant scientists and their cybernetically-enhanced forest creature minions. To succeed, the player will need both quick reflexes and the ability to cleverly manage their limited resources."
• Audience - kids, casual gamers, ???
• Characters - describe the appearance and personality of each character, both protagonist and antagonist, and include a back story if you like. Ex. "Hare Trigger the rabbit still bears scars from his time as a prisoner of the labs, and is driven by the thirst for revenge, the need to protect his family, and his unrequitted love for the beautiful Ms. Fluffy. His achilles heel is that he sometimes overreacts to threats by using a hand grenade on a mosquito, and ends up unleashing even greater perils."
• Story and Game World - flesh out the world, character motivations, and events that will drive the gameplay.
• Gameplay - describe all of the features of your game such as camera, genre, levels, weapons, player capabilities, enemies, hazards, victory conditions, etc...
• Controls & UI
  • Controls: Buttons, gestures, accelerometer?
  • UI: HUD or minimal?
• Art - describe the style: 8-bit, vector, realistic, photo-quality, or ???
  Screen shots or actual examples would be nice.
• Sound & Music - describe the style of the background music and sounds effects.

Phase 2 – First Playable – Week 9

Go further with your artwork, and have your mechanics 90% of the way complete. At this point, you should be able to turn in the project and get a B. But don’t stop there! Get some feedback from me on what could be improved before the final submission.

Phase 3 – All Done! – Week 11

Mobile Experience Requirements

Keep these in mind while working on this project, but for project 2 some of these may not apply.

Respects mobile usage patterns and the mobile context:

• frequent and short use (be sure to save state)
• carried everywhere (easy to use no matter environment)
• single user (remember their info, don't make them retype things to login, this isn't a web app!)
• social context (let them share things from your app)
 

Respects the end user:

• don't make the user wait.
• (REQUIRED!)let the user know what's going on - spinners? animation?
• save state when the user quits. Restore that state when the app starts back up.
• (REQUIRED!)"Fail gracefully". For example, if there is no Internet Connection, let the user know and give them some sort of offline functionality.
 

Take advantage of mobile hardware capabilities (if appropriate):

 

• Location
• Multi-touch
• Accelerometer

Final Documentation Requirements

Extras (be sure to document these)

Doing the above well means a 'B' - we need to see "Above and Beyond" to award an 'A'

---

Project 1

Constructed in 3 phases. See below for details.

Overview

Drawing from the RIT RSS Reader that we created in class, teams of 2 students will create a visually rich mobile application that displays the contents of a web service.

The exact web service used is up to the students, but music and game related APIs have been popular. Other examples include an application that allows users to visualize USGS Earthquake data, or view sports scores, search for book information, see Woot deals, view nearby concerts (Last.fm), nearby restaurants (Yelp), or nearby gas stations.

www.programmableweb.com/apis/directory is another place where you might get ideas.

The application will have an attractive and intuitive interface, with appropriate animation.

If you choose to do an RSS reader or Weather application, it must go significantly beyond the Yahoo Weather App and RIT RSS Reader that were provided to you.

Some Flash Examples that use Web Services

• kuler viewer
• Yahoo Weather Fetcher

Student Web App Examples

• Movie Hub
• Femmelicious
• Audio Tuned
• Super Awesome News
• Pentax Camera Lens Search
• Band Lookup

Deliverables

The following schedule will hopefully keep you on track.

Phase 0: Get a partner

Get a partner and a vague idea(s) of what you might build. Due: end of class, Tuesday 3/27

---

Phase 1: Conceptualization

Write down some ideas, make some sketches, and decide what your application will do. Write a concept document (which may be recycled into your final documentation) describing:

1. The name of your project and the names of the team members.
2. A product definition statement - What's it do? Who's it for?
3. Which web service(s) it will utilize. Give names and URLs.
4. Is it a mobile or tablet app?
5. Target platform: Android or iOS?
6. What kind of Navigation System? Single screen, tab bar, utility, navigation, split view, combination, or something else.
7. Does the app support portrait or landscape or both orientations?
8. How the user will interact with the application (ex. choosing from a list , virtual keyboard, ...).
9. A full list of features you could possibly implement to meet the product definition statement. Apple's Mobile HIG has an example of this and the next requirement.
10. A filtered list of features to meet the product definition statement (and fit into our time frame)
11. A sketch or mockup of your UI. (this can be a sketch, JPG file, or Flash Mock up)

---

Phase 2: Prototypes

Get started coding if you haven't already! Show your prototype to others and let them use it. Use their feedback to refine the app.

---

Phase 3: Final Product

You're done with your first real mobile app!

Design Requirements

• The app downloads data from a web service in an XML or JSON format. Data should be dynamic depending on user input. A simple RSS reader would not meet this requirement.
• The data is displayed in a meaningful way to the user. The interface should be attractive and intuitive.
• It is expected that you will use the MADComponents library. Custom MovieClips of your own creation can also be used.
• The user should be informed of what is going on as they use the app. Activity indicators and sound should be used to convey the application state.

Mobile Experience Requirements

Keep these in mind while working on this project, but for project 1 these are mostly optional.

Respects mobile usage patterns and the mobile context:

• frequent and short use (be sure to save state)
• carried everywhere (easy to use no matter environment)
• single user (remember their info, don't make them retype things to login, this isn't a web app!)
• social context (let them share things from your app)
 

Respects the end user:

• don't make the user wait.
• (REQUIRED!)let the user know what's going on - spinners? animation?
• save state when the user quits. Restore that state when the app starts back up.
• (REQUIRED!)"Fail gracefully". For example, if there is no Internet Connection, let the user know and give them some sort of offline functionality.
 

Take advantage of mobile hardware capabilities (if appropriate):

 

• Location
• Multi-touch
• Accelerometer

Programming Requirements

• Object-Oriented Programming:
  • Separation of Concern - classes have 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 function.
• Event-Driven Architecture:
  • Use event handlers and custom events when appropriate.
• Free of Runtime Errors:
  • Utilize error event handlers, guard statements, and try/catch blocks.
  • Test your code under error conditions such as bad user input, malformed URLs, and lack of Internet connection. It should fail gracefully.
• Follows Coding Standards:
  • Class Names are capitalized
  • Method names (other than the Class Constructor) begin in lowercase, and are camel-cased.
  • Instance variables begin with the letter 'p' and are camel-cased.
  • Library symbols are capitalized and end in '_Clip' for MovieClips, and '_Button' for Buttons.
  • Stage instances (what you drag to the stage during authoring mode) names begin in lowercase letters, and have the suffix '_mc' for MovieClips, and '_btn' for Buttons.
  • Event handler names always begin with "on" as in onXMLLoaded(e:Event) or onMouseEnter(e:MouseEvent)

Final Documentation Requirements

Extras (be sure to document these)

Doing the above well means a 'B' - we need to see "Above and Beyond" to award an 'A'

---