` CS378 - Assignment 2

Assignment Two


Assignment 2: Rudimentary single player game

Assigned: Thursday, Feb 7, 2013
Due: Thursday, Feb 28, 2013 (before 11:59pm)

Project Description

In this assignment you will turn the simple starting environment from assignment 1 into the rudiments of an actual game. You will work in 3-person teams, those have been assigned already in Piazza and you should already have contacted your team members. If you haven't done that yet, do so right away, and let me or the TA know if you are having trouble getting in touch with any of them. Your team is going to add several new capabilities to the environment you have already build to turn it into a single player game.

These include:


We're allowing three weeks for this project. This is a lot to do in that time frame, so start early. To help you keep on track, you'll have weekly milestones to meet. Each of these will be turned in via the usual turnin scheme.

  1. Week 1: You will turn in a document with the following information:

    • Overall design of your game. What are the scoring rules? How will it look (this may be pretty simple). What will the GUI control do and look like. What is your plan for sound (again, probably simple). Other aspects of the game play. Note that even if you're just going to emulate an existing game like handball, squash, or raquetball, these have different rules, use balls with different masses and restitution coefficients, and different striking implements. Specify all this. If you want to get fancy and add obstacles, or goals, or other things to customize your game, specify. There is a bigger design space here than may appear at first glance.

    • Software architecture and plan. At a high level, what does your software architecture look like? What is the game loop, part of the rendering loop, part of the simulation loop, separate? What object structure do you contemplate building? How will you keep track of game state? Relatively speaking, how much work do you estimate there will be to incorporate each of the various required capabilities. Can this be done by the deadline? If not, can you scale back to meet the deadline? When will you know?

    • Division of labor. Specifically, in terms of the delivered capabilities and the architecture you contemplate, who is responsible for which parts of the code? What are the interfaces that will be used to allow people to effectively work in parallel on these parts?

  2. Week 2: Initial demo. Yes, this is only a week after the planning document. But this demo is simple, it should just show rudimentary versions of the capabilities you're working on so we see you've made some dent in each and so you've done enough to know if you're on track. You do have to turn in something that runs, with instructions on how to make it do its tricks. But, e.g. if you have some 2d scoring display up, it doesn't have to completely work yet in conjunction with scoring, if you have sounds, you don't need all of them or all the controls, if you have basic camera control, you don't have to have worked out all the controls and glitches, etc. In addition to this demo, you will turn in a revised implementation plan, describing to what extent each part of your work is on track or not, and, if not, how far behind are you? Also, changes to your software architecture plan should be described, along with any rebalancing of your team's workload.

  3. Week 3: Final "game". You should turn in something like the first assignment, a resource tree that includes a working executable built against any installed versions of the libraries you've used. Other libraries that aren't installed must be included in your tree, obviously, and we must be able to run your game as delivered. You don't need to do any fancier packaging, just make it run as delivered on the lab machines. You should also include a user manual and a final project update that details and explains places where you've managed to do better or worse than you had planned and why. Finally, each member of your team will turn in directly to me (not as part of the team's game package) an evaluation of the performance of your team on this project, your strengths, weaknesses, what you'd do differently if you were starting again, the main things you've learned. The evaluation must include a specific evaluation of your own performance and that of each of your team members, again both strengths and weaknesses. This will be kept confidential and will be taken into consideration in grading.

Getting started

Start now. Contact your team members and start planning. There's a lot of tutorial information to look at, like the bullet manual, SDL documentation, the Ogre camera control tutorial, etc. I'll be posting more info on the sound package shortly, and that will add to your planning. Be thinking about the assignment and familiarizing yourself with the capabilities you'll need to use now. The best code comes from people who spend most of their time thinking about the design of the system, not those who spend all their time coding. So just because you're not ready to start writing code doesn't mean you aren't already in the middle of the most important part of your work, figuring out what to do.

Turning it in

See above and the instructions for assignment 1.


You'll be graded primarily on whether you've met the requirements of the assignment and whether you've done it on time. Meeting deadlines is an very important skill in the game business. If the deadline is hopeless to be able to meet without sacrificing capability, then you need to start making that case as early as you're sure, and proposing plans to scale back.

As a corollary, if you have grandiose plans to make a really fancy game that goes way beyond the requirements, be very very careful, and at the least make sure you implement the required parts first. You'll get to enhance this thing later. You won't be able to make up for points lost because you didn't finish what was required by pointing to all the stuff you did that wasn't required, extra credit is only possible once you max out the basic credit.

We'll take quality of gameplay into consideration only as a secondary criterion. This won't be a full up game without some gui controls and a scoring system, which you can put in if you get the basic stuff up. But you should still be able to navigate around and hit the ball in a reasonable way at the very least. Always remember, a fancy game that doesn't work or isn't playable is worth much much less than a simple game that works right and is fun to play.

Last modified: 02/06/13 by Don Fussell fussell@cs.utexas.edu