Rich Media Web App Dev IGME-330

Project 1 - HTML5 Canvas Game or Experience

Goal

To create a significant HTML5 Media Experience or Digital Game that is aesthetically pleasing and highly interactive.

Ideally the experience will run in all modern browsers, but at a bare minimum it must run in Chrome (on both Windows and Mac).

The objective of this project is for you to demonstrate your mastery of HTML5/CSS/JS and <canvas> programming in a rich media context. You will be evaluated on your creativity, the quality of the experience you create, the soundness of your programming, and how far you went beyond what we did in class, as described below.

HTML5 Media Experience Examples

There are many kinds of applications you could create - here are some ideas:

HTML5 Game Examples

Note: a simple game that is well-executed is often better than an ambitious game that is incomplete. Games like Shoot the Moon (App Store & YouTube), Boomshine (Web & App store), Squares 2 (Web & App Store), Falling Balls (App Store), Pixel Sniper (App Store), and 10 Second Run (DSI Ware - YouTube) are all good examples.

Requirements and Grade Rubric

  1. 20% - Media Requirements:
    • Sound (required on game only):
      • A background sound that loops
      • Effect sounds
      • Keep your sound file sizes as small as possible. Primarily use MP3's; WAV's are OK for short sound effects
      • DO NOT use the sounds that were given to you in class
    • Images:
      • Consistent theme or style
      • Optimized bitmap Graphics (JPEG or PNG) must be used, NOT BMP, TIFF, and so on
      • DO NOT use the graphics that were given to you in class
    • Text/Fonts:
      • Text must be displayed in theme appropriate embedded Web Fonts - Times New Roman need not apply!
      • Size the text so that it is easy to read
      • google.com/fonts and fontsquirrel.com have a wide variety of free fonts
      • Hint: this page has 3 embedded google web fonts - "view source" to see how to use them
      • Important! Put your name somewhere in the project so that it is visible to the user. A game will have your name either on a title screen or game over screen.
    • Canvas Drawing/Animation:
      • Most or all of the game/experience will be drawn into an HTML5 <canvas> tag utilizing the Canvas 2D drawing API.
      • The project should have visually engaging graphics and effects.
      • Use a variety of <canvas> capabilities including the ability to draw paths, bitmaps, gradients, shadows, the globalCompositeOperation property, and so on.
      • Libraries that completely encapsulate the canvas drawing API such as Three.js, Processing.js, and EaselJS are NOT ALLOWED.
  2. 20% - Interaction Requirements:
    • Control (game)
      • The player should be able to control at least one sprite on the screen using mouse and/or keyboard.
      • Controls should be easy to use, responsive and intuitive.
      • Some guidelines:
        • Mouse and onscreen buttons preferred over keyboard shortcuts. You can create "canvas buttons" by drawing a rounded rectangle "button" into the canvas, or use the <button> tag and absolutely position the button over the canvas element.
        • Map controls to both WASD and arrow keys if appropriate. DO NOT map to PC-only keys like PageUp or the Home key.
    • Control (experience)
      • HTML Widgets checkboxes, radio buttons, sliders, drop-downs, etc - will allow the user to alter parameters of the experience
      • Giving the user the ability to interact with the experience via Mouse interaction is encouraged.
      • The user should feel they have sufficient and satisfying control of the experience.
  3. 20% - Usability Requirements:
    • Game Screens:
      • At a bare minimum there should be three screens (i.e. game states): title/instructions screen, game screen, game over/play again screen
    • Teaching: The player should have no trouble figuring out how to play the game/experience. You should probably provide instructions.
    • Feedback: The player should intuitively know what "state" the game/experience 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 should be easy at first, then it gets harder. The player shouldn't die in 2 seconds like Flappy Birds.
  4. 20% - Game Design/Experience Requirements:
    • Meeting your plan:
      • It's expected that your game/experience will change from the original design document, but overall you need to 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-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/experience fun or engaging and something people would want to play?
  5. 20% - OOP and Coding Standards:
    • JS libraries (other than PreloadJS and SoundJS) may only be used with prior approval only.
    • Code runs with no errors
    • Code Conventions and Practices:
      • Separation of Concern/JS Module Pattern - there must be multiple JS files with logically related code grouped together so that each script has well-defined functionality.
      • D.R.Y. - Don't Repeat Yourself. Repeated blocks of nearly identical code should be factored out and placed in a separate function.
      • "use strict" at the top of every JS file
      • Function constructors that will be called with the new operator must be capitalized.
      • All other variable and function names must begin with a lowercase letter.
      • Every JS statement ends with a semi-colon - don't rely on the JS interpreter to insert them for you.
      • Always use the var keyword when declaring your variables.
      • Well-commented code. Each and every function gets a comment indicating what it does.
      • Delete or comment out your console.log() calls
    • Function Constructors and prototypes - at least 2 new Function constructors (like Bullet, Enemy, ...) that were created by you.
    • You will only receive credit for code that you write beyond what you've inherited from our ICEs.
    • Any borrowed libraries or code fragments must be credited (author and URL) in both your code comments, and in the final documentation of the project.
    • Both partners must produce code that appears in the final version of the project. Failing to do so will result in a -20% grade penalty for the non-contributing partner.

Extras

Rubric

Final Documentation (-10% if not completely done)

Final Documentation will be posted to the Final Submission dropbox, and must be in Word Doc or PDF format. Both partners must submit separate documentation with the final project submission.

  1. Describe what changes were made in your game/experience from your original design
  2. Elucidate how you met the 5 categories of requirements, and be specific about any extras you did
  3. Discuss what went right and what went wrong. List what features you would have liked to add to the project if you'd had more time
  4. Declare any non-course resources (libraries, sounds, images, tutorials, sample code) you utilized. Note: You don't have to document that you used the code I gave you in class
  5. Precisely detail the contributions of each partner to the overall project
  6. Give yourself and your partner an overall grade on the project

Project Proposal (-10% if not done, late submissions not accepted)

See the game proposal instructions and template here and the Experience proposal instructions and template here. This is due (in dropbox and posted to web) the beginning of our first class meeting week 7.

Working Prototype (-10% if not done, late submissions not accepted)

Create a working prototype that illustrates the core mechanic of your game/experience. This is due in the dropbox the beginning of our first class meeting week 8.

Final Submission