Assignment Two

Handball

Assignment 2: Single player game

Assigned: Tuesday, Feb 14, 2012
Due: Tuesday, March 6, 2012 (before 11:59pm)


Project Description

In this assignment you will turn the simple starting environment from assignment 1 into an actual game. You will work in 3-person teams that I'm assigning (the team assignments are given here). Your team is going to add several new capabilities to the environment you have to turn it into a single player game.

These include:

Milestones

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. More details on this and how to turn it in later

Getting started

Start now. Your team members and contact information will be posted shortly. Contact each other and arrange to start planning as soon as that happens (I'll announce it in Piazza). But in the meantime, there's a lot of tutorial information to look at, like the bullet manual, the Cegui tutorial, 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.

Grading

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 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 as a secondary criterion. It should at least be possible to play your game as a game, without it being trivial to rack up ridiculous scores or impossible to play at all. Beyond that, I'm hesitant to put much weight on judging how fun things are, but you will be extra credit for playability beyond these basic requirements. And 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: 01/14/13 by Don Fussell fussell@cs.utexas.edu