CS 426 Spring 2008 Class Schedule & Logistics

Version: January 17, 2008

Class Groups

• Students form a mini game company consisting of 3 students in a group.
• There are individual roles for each group member, you should pay attention to these roles when you recruit your team members:
  • Technical director - works with programmer and artist to integrate game code with game art; maintains web documentation on game progress; leads final game demonstration and ensures group dynamics run smoothly. Usually there is a separate project manager that fulfills this role but you are a startup company so you are expected to wear more than one hat.
  • Game developer - focuses on developing most of the code for the game.
  • Artist - focuses on creating and/or collecting media (3D models, sound effects, music) for game elements and contributing necessary code for enabling the use of the media- e.g. functions to play back sounds.
• If someone in a group drops the class then the remaining 2 students will have to share the load.
• If both members of the group drop the class then the remaining student will join another group.
• If you have a dispute in your group, try to resolve it amongst yourselves. You are your own game company so as "employees" YOU have to deal with these kinds of issues on your own.  A useful "management" tip - if there is a problem, bring it up early rather than later- before the problem festers. In the middle of the semester and at the end of the semester you will fill out a form to evaluate your other team members. I will use this to decide how to assign grades to each person in the team. I will know if you are not pulling your own weight.
  

Assignments

Brainstorm Presentations: In 5 minutes present your game concept showing the class your final storyboards. Post these storyboards on the web. We will be using a web browser to bring each of the storyboard pages up.

Game Engine Presentations: In 10 minutes talk about why you chose the game engine and show me it is working with the Wii controller.

Mid-semester Game Progress Report: Give a 15 minute demonstration and presentation on the status of your game.

1. You end your presentation on time. I will kick you off if you go over time.
2. You have readable slides with large enough fonts and a readable color scheme.
3. Your thoughts are well organized.
4. The Demo Works!
   

FINAL Demonstration: Most of your grade for the class hinges on this.

• Final presentation and demo
  • Describe:
    • Game play
    • The game engine and tools you used.
      
    • How the AI and the graphical/audio effects are implemented.
    • Especially highlight any capabilities that you thought were particularly impressive. e.g. a clever AI scheme, a visual effect, a sound effect.
      
    • Features of the game that you put in because you thought it would make the game fun.
    • Concepts that you learned from the lectures that you applied or attempted to apply to your game. For example:
    • From the game programming lecture have you used a finite state machine for your game?
    • From the Game Design lecture on "What Do Players Expect" what categories have you tried to incorporate in your game? e.g. Players expect a consistent world.
    • From the Sound and Psychoacoustics lecture, what characteristics of sound have you tried to incorporate? e.g. Sounds set a pace to the game.
    • From the Perception lecture, what aspects of the human perceptual system have you attempted to take into account? e.g. I have created low detailed health bars in the corners of the screen where your peripheral vision does not have the resolution to resolve the detail during an intense game experience.
    • Tradeoffs that you had to make in the game and what ultimately led you to the final decision.
    • How would you have approached the development of the game if you had the chance to do it all over again.
    • How has this experience affected the way you think about commercial games?
• Completed web site that includes:
  1. Gameplay design document.
  2. Screenshots of sketches.
  3. Screenshots of the actual game screens.
  4. Screen capture of the game in play. Use a program like Fraps (www.fraps.com) to do the capture.
     
  5. Explanation of all design tradeoffs that you had to make- ie what you originally envisioned vs what you accomplished.
     
  6. Explanation of the overall software design- including data structures, finite state machines, pseudo-code algorithms for the graphics, AI, sound, main game engine.
     
  7. Explanations of how specific visual and audio effects were achieved.
  8. Downloadable ZIP file containing an executeable that runs as a standalone game.
  9. Downloadable ZIP file containing the source code and image and music files.
  10. All the above in 1 giant ZIP file placed at ftp.evl.uic.edu/pub/INcoming/cs426
      
  11. Email me when the giant ZIP file is put there.

Grade Scoring

Late assignment turn-in policy

• None. Every class project in the last several years have said that the number one thing they could have done better was to manage their schedules. Groups that were able to keep to their timelines usually got an A. Groups that didn't, were usually developing code for several days without any sleep right up to the deadline only to get a B, or worse, a C in the class. So whatever motivates you to keep on time, DO IT. This something you will face in the real world (both industry and academia), and especially in the game industry- so better get used to it now.
  

Final Exams

• None. Final grades will be determined by what you have been able to achieve through the class and mainly the quality and quantity of work you are able to demonstrate at the end of the semester when compared with your peers. Basically I rank the game groups and give the top 3 groups As, the next 3 groups Bs, and the last 4 groups Cs or Ds.  This is assuming that all your personnel evaluations show that everyone is doing their job.
  

 LSU's Class Web Site