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:

• User-controlled racquet(paddle, hand, whatever): Obviously, the most basic capability you'll need to make this into a game is to have a player controlled paddle that can be used to hit the ball. This can be a simple rectangular box that can be panned and rotated under user control to put it in a position to hit the moving ball in a particular direction. If you choose to make it look fancier, that's up to you, but for ball control, flat surfaces with simple shapes have real advantages. This will involve a much more extension use of the input system than the canned input controls you have used up to now. OIS is the library the Ogre demos have used for input, and you've already built against that, but not used it much yourselves yet.

• Camera control: You have to see what you're doing to play. This means you have to move the camera around to look at what you're doing with the paddle. This shouldn't be complicated, you should let paddle control move the camera for the most part, explicit camera control can be added if you really need it. Basically, this could be done with a 3rd person style camera that moves around with the paddle, and you may well want to control how far away the camera is and what angle of view is used. And you'll have to make sure that nothing blocks your view when you move to various positions. It's worth noting in this regard that in your initial demo, you can move the camera outside the box and still see in, since by default the system is culling backfacing surfaces, so the wall you're behind doesn't get drawn. This might not always be enough, though.

• 2D GUI and scoring system: You'll need to use a GUI system to put up 2d overlays over your 3d world view to show the score and other salient aspects of the game state. Your team gets to design this. You can also use the GUI system to have a separate mode for game parameter control if you like, perhaps to set up parameters at startup or even to use at will in the game. This is optional, but you must at least use the GUI system for score display. CEGUI is a GUI system that plays well with Ogre and for which there is a tutorial in the Ogre wiki, I recommend you use that, but if you have a good reason not to, you can use something else if I approve it.

• Sound effects: You need to add some simple sound effects to make the game compelling. The minimal set is sounds when the ball hits something, and sounds when the score changes. You should be able to turn the sound feature on and off(that can be GUI controlled, keyboard commands, or both). If you want to add more sound effects, those are your design decisions, as are the specific sounds used. If you put music in, beware of copyright violations, and make sure you can control the volume separately from the effects volume and turn it off separately from turning off the effects. (More detail about library to use and sound sources to come)

• Physics engine for physics and collision detection: We're going to use the Bullet physics engine for both of these capabilities. Ogre plays well with this and several other physics engines, and there are even wrappers that have been developed to integrate this with the Ogre engine. Some of these are described in the libraries section of the Ogre Wiki. They don't appear well supported, so if you want to use one of them, make sure early on that it will work with the current versions of Ogre and Bullet. The only required addition for physics simulation will be gravity and a ball restitution coefficient smaller than unity (which was presumably what you had in your first assignment by default). You get to pick your ball's restitution coefficient since that will be a significant aspect of how the game plays. You don't have to allow it to be changed by the player, although you may choose to do so. Gravity should be Earth standard (although options to change that can be allowed), and the ball should have a reasonable mass (comparable to an actual ball in a real game of the type you're designing).

  Note that we've made using Bullet optional for this assignment, although it is still recommended. If you're using Windows for development, you can download the Bullet source code. If you want to build it to be compatible with Ogre and it's use of DLL's and the DLL multithreaded C runtime library, then build it with this solution file rather than the one it comes with.

  There is now a standard installation of Bullet on the kol machines in the lab. You can build your application against this using variants of the standard 4 build files we used in assignment 1. I've included starting files for that here, you'll have to edit Makefile.am to change to your executable file name and to put in the lists of .h and .cpp files you're actually using in your application as in assignment 1. You should note the changes that have been made to configure.ac and Makefile.am to include the Bullet libraries in the build. This can serve as a template for you to use in including other libraries. I've also left the first two lines in both buildit and makeit commented out. If you build your own versions of any library you want to use, you can uncomment these lines and modify them to point to your installation of these libraries. If you then make appropriate changes to configure.ac and Makefile.am as described above, you should be able to build anything needed for this assignment.

  For those who might want to try out the OgreBullet wrapper (I don't particularly recommend it, I think it's easier just to integrate Bullet yourself), the source tree for it is here. This should build on Windows using VS10 if you change the configs to point to your particular include and library directories for both Ogre and Bullet. I haven't tried to port it to Linux as yet, however.

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: 03/01/12 by Don Fussell fussell@cs.utexas.edu