Game Programming Lab Project Structure 2011

Quick Links

Due Dates

7. March at 17.00 Rough draft of the project proposal added to game notebook
8. March in class Presentation: Pitch of game idea
11. March at 17.00 Mutual project critiques posted on twiki
15. March at 17.00 Final draft of project proposal added to game notebook
21. March at 17.00 Prototype chapter added to game notebook
22. March in class Presentation: Proposal and prototype presentation
11. April at 17.00 Interim report chapter of game notebook
12. April in class Presentation: Interim demos
9. May at 17.00 Alpha release chapter of game notebook
10. May in class Presentation: Alpha release demos
16. May at 17.00 Playtest chapter of game notebook
17. May in class Presentation: Playtesting results
31. May at 16.00 Final public presentation
3 June at 17.00 Conclusion chapter of game notebook and demo video

Overview

This term you will undertake a group project to design and build a prototype game. The game design should follow the course them of "Large vs. Small." Since the course focuses on game technology, your game should highlight at least one specific technical item in visual computing, such as crowd simulation, procedural modeling, sound simulation, character animation, artificial life, etc. You're welcome to include more, but keep in mind that it's much better to do one thing very well than to do two things only half-way.

Developing a game is not trivial! Good software engineering skills are crucial. We're adopting a project structure based on 6 phases which are outlined in this document. The purpose of these phases is to assist you in developing your game and prioritizing your time.

In addition to the software you will develop, each team will also generate a detailed project notebook that tracks the entire development process. With each phase of project development, corresponding chapters will be added to the project notebook. Early chapters will include your formal game proposal and a game prototype, while later in the course you will add updates for your intermediate and alpha release deadlines, a chapter about playtesting, and a final chapter where you can summarize your experience throughout the class and comment on what worked well and where you had problems. Although the project notebook will be a significant document, you'll add to it throughout the semester so that the writing burden at any time is never too great.

We're using this twiki to help manage the projects. Each team will create a page within the twiki. This page will be used to organize thoughts about the project and post progress reports, demos, and other deliverables. It also gives you the opportunity to collaborate with other team members, due to the communal nature of the twiki software. Please create a twiki page for your team using the template linked on the main page.

Part 1 - Formal game proposal

Recommended reading: Our published paper about the game course.

Recommended reading: Game Design Workshop, Chapters 1-6

After reading this section, you will hopefully understand that the proposal is a lot of work. Thus, it's crucial that you get started early!

Game proposal chapter

A formal game proposal makes up the first chapter of your project notebook. The game proposal describes your game idea, provides a detailed development schedule, and gives a qualitative assessment of your project. The proposal should be professionally prepared, expressive, grammatically sound, illustrative of your efforts and process, and easy to understand. A good design effort can easily be hampered by a poor communication of what was done.

While the precise format of the report is up to you, you must include the following parts:

1. Game Description

Describe your game idea in detail with approximately two to three pages of text plus three pages of mocked-up screenshots and/or sketches. Pencil sketches are fine. You don't need beautiful artwork at this point.

Your description should highlight how your game relates to the course theme. Each design decision should be justified in terms of theme. Choices shouldn't seem random. Instead they should follow directly from the theme. This section should provide an overview of your game that sets the stage for the remainder of the project notebook. Describe any background or storyline associated with the game. Comment on the overall gameplay.

2. "Big Idea" Bullseye

The "Big Idea" Bullseye is meant to highlight the primary and secondary drives of your game. Your entire team should agree upon and buy into these two concepts during the design phase so that everything that goes into the project is focused and aligned around a common and unified goal. It sounds a bit obvious, but it’s a powerful tool.

Include a graphic big idea bullseye similar to the one used for Split Second. You can design your own, custom bullseye graphic. The primary and secondary drives should be short, direct, and to the point.

3. Development Schedule

The development schedule is crucial and should contain two basic parts. First, you must provide a layered development description of your game that divides the development schedule into five categories based on how crucial each element is. Second, you must provide a timeline for the course including major milestones and deliverables as well as detailed information about who is responsible for each task, when will each task be started, how many hours will each one require, etc. More information about the development schedule is given below.

4. Assessment

Tell us what the main strength of the game will be. What part is going to be the most cool? Who might want to play this game? What do they do in the game? What virtual world should the system simulate? Basically, you are setting up a world view for your subsequent design. What criteria should be used to judge if your design is a success or not?

Considerations for your game idea

Think Small

Most of the games you buy in the store involve six to twelve months of work by twenty to one-hundred trained professionals. Plus, many game titles build off of a large body of code developed by the company for previous titles or related merchandising. To be successful in this class, you need to design a project whose complexity fits the timeline of the course and the skills of your group. Thus, your game will most likely be much smaller than commercial titles you've played in the past.

Do One Thing Well

To do well in this course, you need to do one thing well. Your game needs to really stand out in one way, but not all ways. Doing one aspect of it well will get you a better grade than doing a mediocre job on a lot of things. Your game might excel in the gorgeous graphics, the witty sound effects, the clever puzzles, or the well-tuned user interface. Make it really stand out in one way.

Considerations for the development schedule

"The best laid schemes o' Mice an' Men, gang aft agley." -Robert Burns

(If you don't already know this proverb, then check out the original poem.)

Plan in Layers

You can't accurately anticipate how long each step in your project is going to take. Consequently, you need to make a detailed development schedule that is layered. Follow this structure:

  1. Functional minimum: minimal items to make something that you might call a game. You'd be embarrassed if you only got this far, but at least it'd be something.
  2. Your low target: Your target for what you want to get done--the least possible to feel sort-of OK about the result.
  3. Your desirable target: This is what you're aiming for, if things go reasonably well.
  4. Your high target: It might be possible to get this much done, if all goes extremely well.
  5. Your extras: Stuff that you know you can't get done this semester, but you might add later if you decide your game is cool enough to keep working on after the class is over, just for fun.

Structure your development so that you complete each layer before going on to the next. Plan exactly what is entailed in each layer, and which team member is going to do each component. Include this layered description in your proposal.

Task list and timeline

Develop a list of tasks for each layer above as well as which team member is responsible for each task and how long the task will take. Create a timeline for the entire term and assign tasks to each week. Include in the timeline the milestones (ie, when each phase should be finished) as well as deliverables (ie, reports, demos, etc.) based on the due dates. Note that the task list should include not only programming and technical tasks but also creative tasks (eg, brainstorm on game ideas) and assignments (eg, write report, prepare presentation). Thus, the tasks during the first few weeks will likely involve finalizing your game ideas and preparing the project proposal and presentation.

This timeline is very important. It will help you understand if the scope of your project is appropriate for the course. It's a good idea to keep it updated throughout the course by tracking both the expected number of hours to complete a task as well as the actual number of hours you spent on it. This will help you extrapolate your progress and react accordingly.

In class "pitch" of game idea

Please come to class prepared to give a ten-minute presentation of your game plan. In your talk, you must:

  1. Describe your game and how it relates to the course theme.
  2. Argue for what the main strength of your game will be.
  3. Discuss the technical computer graphics item(s) your game will include.
  4. State what tools you will use, and why you need them.
  5. Show your development schedule, and make a compelling case that you are not trying to do too much or too little.
  6. Speak for precisely ten minutes and no more (do a practice talk to check your timing--you'll be cut off when the time is up).
  7. Use powerpoint, posters, mock-ups, or other visual aids as needed.

Mutual project critiques

For this assignment, you will provide a brief critique of every other project. Every student (not just every group) should write a critique. Thus, each member of your group should post his/her critique on the group's twiki page. The purpose of the critique is to provide mutual feedback to your classmates that is useful for refining their game idea. At this early stage, feedback of this sort is especially useful and important. Thus, try to give thoughtful and practical comments.

For each group, you should answer these three questions:

1. What is your favorite aspect of the proposed game? Why?

For this question, point out what you think is the coolest feature of the game, what makes it novel, or what aspect would make you most inclined to play it. Your thoughts on the coolest part of the game may differ from those of the game designers!

2. What is your least favorite aspect? Why?

Which part of the proposed game seems to be the least fun? Is there something that might be dull or boring? Why might you get tired of playing the game or find it frustrating? Be candid, yet tactful and polite with your answer.

3. What one change or addition would you suggest to most improve the game?

Offer a helpful suggestion on how to make the game better. Maybe you have an idea on how to make the gameplay more fun. Or, perhaps your favorite feature could take on a more prominent role. You might offer a resolution to your least favorite aspect that would improve the game. Please make comments that are reasonable given the scope of the course.

Please number your answers 1., 2., and 3., for each group so that all critiques are in a consistent format. Only a few well posed sentences are required for each question. If you pay attention to the project presentations, we expect that it should take only about one hour to complete this assignment. Of course, if you prefer to give additional feedback above and beyond the questions listed here, you're more than welcome to do so. Post your critiques on the twiki.

Part 2 - Game prototype

Recommended reading: Game Design Workshop prototyping chapter.

The key goal of part 2 of the project is to develop a prototype of your game that distills out the core game play. The prototype should incorporate the game mechanics while providing only a crude approximation of other features like artwork. While this activity may seem cumbersome and difficult, it is hugely important since it forces you to think carefully about the most essential elements of your game idea. A complete and final game may be extremely complicated, but the core elements on which the gameplay is based are often very simple. In this exercise, you will isolate those core elements and demonstrate them to the class.

For this assignment you must build a physical prototype using paper, glue, and other real-life materials. The prototype should expose the core gamplay in a form that can actually be played. The prototype will model the game mechanics and provide a foundation on which to add additional functionality. By designating one team member as the "computer" and the other team members as the players, you should be able to play your game. Any confusion or difficulty that arises on the side of the computer or players is a strong hint that the core gameplay needs some modifications in order to capture a successful game.

This assignment represents the first iteration in the iterative development cycle you are following for the course. Be sure to take advantage of it! Play your game and use the experience to improve your game's mechanics. Update your project proposal as necessary to reflect any goals that have changed as a result. At this stage, it is still easy to make broad changes. Once you start coding, modifications will become increadingly difficult and costly. Try to converge on the core aspects of your game design now to avoid any misteps that could throw off your development schedule in the upcoming weeks.

Prototype notebook chapter

  • Include sketches and photos of your prototype in such a way that you can demonstrate in the report how the prototype works and how the gameplay is modeled.
  • Report on your experience playing the game. Was it fun?
  • Explain what you have learned from creating the prototype. What has proved to be harder (or easier) than expected? What design revisions have you made to your game based on your experience creating the prototype?

Final game pitch and prototype presentation

You've thought about your game idea, revised it, prototyped it, played it, and iterated on the design. Now is your chance to wow us with a final pitch of your idea and a demo of your physical prototype! Three professional game designers / developers are attending the lecture to give expert feedback. Be sure to make your presentation exciting, energetic, visual, professional, and clear.

  • Pitch your final game idea by describing the essential design elements and backing up your descriptions with sketches, storyboards, and other visuals.
  • Motivate the design decisions with respect to the game theme.
  • Show your "Big Idea Bullseye".
  • You should have worked out any rough issues present in the previous presentation, so that you have a clear and compelling game idea. Convince us that it will be a fantastic game!
  • Be sure to bring your physical prototype After describing the game idea, demonstrate the gameplay using your physical prototype.
  • The prototype should support your game pitch by highlighting the core game mechanics and proving that it is a fun, playable game.
  • Plan for a 10 minute presentation and practice ahead of time to ensure accurate timing. You can split the time between the presentation and demo however you think is most effective.

Part 3 - Interim report

Each group should add a progress report chapter to their project notebook of two to five pages. Describe how many layers you have finished. You can include screen shots to help explain your game so far, and text to describe how a user would interact with it. Our hope is that you have completely finished layer 2 and are well into layer 3. If you make weekly progress updates on the twiki, this report should be extra easy since your weekly twiki updates will already summarize what you have completed.

Explain what has proved to be harder (or easier) than expected. What design revisions have you made to your game as a result of what you've learned with the implementation? Discuss the implementation challenges you faced. Were there aspects that you wanted to build but were unable to do so?

In class, be prepared to give a live demo of your game so far, running on the Xbox 360. Show us the latest and greatest of what you have! The demo should mostly focus on actual working code. It's very important to demo your game on the Xbox, since we will deliver the Xbox binary to the course mentors. If it doesn't work on the Xbox, the mentors won't be able to try it. Have your demo ready on your XBox hard drive and bring it to class. You can also show powerpoint to supplement the presentation if it is more suited for some of the issues that you'd like to show/discuss.

Part 4 - Alpha release

At this point, you're almost done! "Alpha Release" is intended to allow you to freeze a version of your game that is suitable for playtesting. You will start real playtesting immediately after this date. For the Alpha Release, principal design is long complete. Principal coding is also complete. Ideally, you will have met the goals outlined in layer 3 (your desired target) and possibly part or all of layer 4 (your high target). In the following week you will put your game in front of customers and learn what they like and don't like.

For the alpha release, add a chapter to your project notebook which follows the same guidelines as the interim report chapter in Part 3 above. Also, bring your Xbox hard drive and be prepared to give a demo in class on the Xbox console. You should show that your game is playable. Comment on how far you have progressed and show us what is exciting about your game. Remember, your goal from the beginning is to make a game that does one thing very well. Now it's time to show us!

Part 5 - Playtesting

Playtesting is arguably one of the most important aspects of game development. It is a continuous process that should take place throughout the development cycle. In an informal way, you have been playtesting your game every time you played it and made changes based on your experiences. In this assignment, we address playtesting in a more formal setting. To prepare for this assignment, please review the slides (posted on the class website) from the playtesting lecture and be sure to read the chapter on playtesting from the Game Design Workshop.

For this assignment each group must perform a playtesting session with a minimum of five participants who are not in this class. Feel free to use any friends or family not in the class, although the more disconnected from you the better. Consider people you know from other classes, from sports teams, from clubs, etc. Maybe there's a special person who you've been wishing you had an excuse to call. Now you have an excuse!

The exact format of the playtesting session is up to you and should be tailored to your game and to the type of feedback that is most appropriate. Decide whether you prefer to conduct each playtesting session individually or have all of the testers play together. In either case, follow the guidelines in the slides and book:

  • Welcome and thank them
  • Remind them that you're testing the game, not their skills
  • Request that they talk out loud throughout and ask questions even though you won't be able to answer
  • Afterward, interview them and discuss their experience
  • Don't ask questions that presuppose or suggest a particular answer
  • Offer beverages and snacks, or some token thank-you gift!!

You shouldn't explain the game in detail or give information about your vision. Instead, just let them start playing. Observe them quietly and carefully while they play. Take notes on what they do, on any mistakes or troubles they have, and on your thoughts and impressions of their experience. If they don't think out loud, you can elicit information by asking questions like, "Why did you go there?" or "What were you thinking when you did that?" Don't answer their questions or provide help unless they are really stuck and cannot continue without intervention.

Afterward, interview them about their experience. Prepare ahead of time with a series of questions. You can ask them the questions more formally or simply select questions on-the-fly to keep the conversation going. The slides and book chapter have many sample questions which you can use.

Playtest chapter

In this chapter, describe the results from your playtesting assignment. Describe who you recruited for playtesting and how you organized the playtesting sessions. If possible, include some photos. List the questions you chose to ask the testers. Summarize their answers. Comment on overall trends you learned from the exercise, as well as any specific suggestions that were particularly useful. Finally, describe any changes you made to your game based on the playtesting.

Playtest presentation

Present the results of your playtesting session. Essentially, it is an oral version of the playtest chapter. Tell us who you recruited to play your game and how you organized the playtesting sessions. Summarize what you learned about your game. Was there a clear conclusion that you could draw from the feedback you received? Highlight any particular "gems" or comments that were especially useful. What changes to your game would you make based on the feedback you received? The presentation should be 10 minutes long.

Part 6 - Public presentation and conclusion

The final assignment encompasses the public presentation of your work and the final conclusion chapter of the project notebook.

Public presentation

The public presentations will take place on Tuesday, 31 May 2011.

We are publicizing the presentation to others in computer science and within the Swiss game community. Everyone is welcome, so please feel free to invite your friends. Last year we had a tremendous turnout. We are giving two awards based on your presentations and demos. The "Jury Award" will be selected by a jury of expert judges from the game industry. The "Audience Award" will be voted on by the audience. Both will be chosen "live" immediately after the last group presents. We're giving prizes for these awards, which provides a little extra motivation to give a good presentation!

Your presentation should have two parts: powerpoint slides followed by a live demo of your game. The presentation should be exactly 10 minutes in total. Please practice ahead of time so that you do not go under or over time.

In the first part of the presentation, explain your vision for your game and how it fits the course theme. Summarize the main idea of your game and what makes it cool and different from existing ones. This is a great time to show the concept art or mock-ups you made during the design process. Feel free to bring your physical prototype. You might compare the original sketches with similar views from the final game. We want to see how the idea got started and how it progressed during the course. Highlight the technical challenges that you overcame. Tell us any major changes you made to the original design and why you made them. Were the changes for technical reasons, due to playability, or a result of playtesting?

Try to make the presentation as fun, exciting, and entertaining as possible. Images, photos, screenshots, etc. are more exciting than text. Visual aids should back up what you are saying and help to convey your point. When discussing the development process, consider any specific stories or anecdotes that you could tell us. One or two specific anecdotes are more interesting than generalizations or summaries.

Once you have set the stage for your game and built some anticipation with the design sketches and development process, you should give a live demo. Plan your demo ahead of time so that you show off the most interesting aspects of your game. Don't just play! You should offer comments throughout that connect your live demo to the ideas and issues that you just brought up during the first part of the presentation.

To celebrate all of your hard work, the public presentation will be followed immediately by an apero and vernissage for everyone to play your game and talk to you about your experience in the class.

Conclusion chapter

In this chapter, first provide a summary of your final results including screenshots from your final game. Comment on any significant changes from the alpha release.

Next, this chapter should provide commentary about your experience during the class. How well did your initial design ideas materialize into the final game. Were you able to follow your development schedule, or did you deviate significantly from it? How did the different elements of the project structure (development schedule, prototype, playtesting, etc.) contribute to or hinder your progress?

Conclude by giving your personal impression of the course. Did it meet your expectations? Are you happy and proud of your game? Do you feel there wasn't enough time or that the schedule was too compressed? You might also consider these questions:

  1. What was the biggest technical difficulty during the project?

  2. What was your impression of working with the theme?

  3. Do you think the theme enhanced your game, or would you have been happier with total freedom?

  4. What would you do differently in your next game project?

  5. What was your greatest success during the project?

  6. Are you happy with the final result of your project?

  7. Do you consider the project a success?

  8. To what extend did you meet your project plan and milestones (not at all, partly, mostly, always)?

  9. What improvements would you suggest for the course organization? (perhaps in D1 evaluation)?

  10. Did you like the XNA framework?

Final Digital Video

Since still images don't capture gameplay very well, we also require a short digital video that highlights the exciting aspects of your game. This video should be similar to the demo you gave at the public presentations, except pre-recorded. The easiest way to produce the video is to run your game on a fast PC and use a screen recording program to record the game window. We also have a DV camera that can record the graphics card or Xbox output directly.

Acknowledgments

Much of this project structure is adapted from Tiffany Barnes.
I Attachment History Action Size Date Who Comment
PNGpng Big_Idea.png r1 manage 525.5 K 2011-03-01 - 02:34 BobSumner  

Page URL: https://twiki.graphics.ethz.ch/bin/view/GameClass/ProjectStructure2011
2024-03-29
© 2024 Eidgenössische Technische Hochschule Zürich