Project structure

Overview

This term, you will undertake a group project to design and build a prototype game that should follow the course theme. Since the course focuses on game technology, your game should also highlight at least one specific technical item in visual computing, such as crowd simulation, procedural modeling, sound simulation, artificial intelligence, level editor, etc. You are 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 are 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.

Project Notebook

In addition to the software you will develop, each team will also generate a detailed project notebook that tracks the entire development process. A Download LaTeX (ZIP, 394 KB) template is provided for you, and with each phase of project development corresponding chapters in the notebook should be completed. 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.

MonoGame Engine

You will use external page MonoGame to create your game. It is a powerful framework to implement cross-platform games in C#. The teaching assistants will present you the basics of MonoGame to start a project, and more detailed instructions are available online.

GitLab & LFS

We use GitLab as a central code repository hosted at ETH. Each team has its own repository. It is mandatory to host your project in this repository. However, Git does not handle large files (audio, video, assets) well and performance would degrade drastically. ETH also enforces a repository size for each project. You have to setup external page LFS (extension to Git), which internally manages large files. Once setup properly, you can upload both, small and large files, with the same Git commands, and Git + LFS will manage the storage for you. Besides code, Gitlab will also be used to organize thoughts about the project and upload reports, demos, and other deliverables. More information about how to use the Git repository will be presented by the TAs.

Slack

external page Slack is a great tool for team collaboration and communication. We encourage you to use it for writing to each other and to discuss within the team and with the TAs. You should receive an invitation to use slack.com at the start of the course. If you didn’t receive an invitation, please let the TAs know!

Part 1 - Formal game proposal

Recommended reading: external page Game Design Workshop

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 notebook chapter

Max 10 pages

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. Team structure

Each member should be assigned one or several roles within the team. Are you a Game Designer, a Producer, a Programmer, a Visual Artist, a Quality Assurance Engineer, a Specialized Media, etc.? Organize your team according to the preferences and skills of each member. There are two important rules to respect: (1) Everyone is a Game Designer; (2) There is one Producer. The Producer will be the person in charge of making sure that you are on track with respect to the timeline, there is a good communication and repartition of tasks within the team, and the deliverables are handed out on time.

2. Game Description

Give a title to your game and 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.

3. "Big Idea" Bullseye

Supporting the two sections above, The "Big Idea" Bullseye is meant to highlight the primary, central, most important conceptual idea of your game, as well as the central, supporting, extra-special and impressive technical component. 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 in your game proposal. The primary and secondary drives should be short, direct, and to the point.

4. Technical Achievement

As this is an ETH course and all of you are technical superstars, technical achievement is also a core part of the course. To this end, your game should include at least one core technical item. This technical element should help your game stand out in an innovative way by providing an element that goes beyond the normal functionalities. This is your chance to select a concept from another course or something that you have always been interested in and implement it in the context of your game. Try to impress us, while still ensuring that the concepts you target fit within the scope of the course.

This section should detail the core technical item you plan to include. You are free to present more than one idea, but remember that it's better to be super successful at one item than to try to include many and fail.

5. 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.

6. 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 external page 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. Low target: Your target for what you want to get done--the least possible to feel sort-of OK about the result.
3. Desirable target: This is what you're aiming for, if things go reasonably well.
4. High target: It might be possible to get this much done, if all goes extremely well.
5. 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 in a Gantt diagram form. 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.

Mutual project critiques

During the lecture, you'll ppitch you game idea. Feel free to provide a brief critique to the other teams too. Every student (not just every group) can comment the project of other groups. 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. You can give your comments directly after the teams presentation, or during live discussion, or via Slack.

For each project, you should ask yourself 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.

Part 2 - Game prototype

Recommended reading: Game Design Workshop, Chapters 7-8

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

Max 5 pages

• 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 learn 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?

Part 4 - Alpha release

Recommended reading: Game Design Workshop, Chapters 11

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.

Alpha release notebook chapter

Max 5 pages

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, be prepared to give a demo in class on your target hardware. 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

Recommended reading: Game Design Workshop, Chapters 9-10

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 notebook chapter

Max 5 pages

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.