Team Spudnik

Game concept: How and why did your game concept change from initial concept to what you implemented?

The concept remained almost identical to what we had planned from the beginning, except that some of the complex mission ideas didn't surface.  Such as the "Pizza Delivery Mission" or the "get as much food as possible" mission.  The reason we didn't get to it was purely a matter of time that we didn't have.   We just ended up focusing on the mission "Get the Remote" because that seemed the most natural game play for a couch potato game.  So the actual gameplay itself worked out very well and ended up being very fun to play.

In addition, our concepts became more refined as the game development progressed. For example, we initially used the Duff Beer in place of the TV remote, but it ended up becoming an actual weapon in the game.

Design: How and why does your final project design compare to the initial design?

We only had time to implement one of the missions that was designed, Capture The Flag (remote), and it was slightly different than we had originally intended. Instead of capturing the remote first we ended up having a number of times the remote had to be captured in order to win.

Loading maps dynamically at runtime wasn't started early in the quarter and the idea was eventually scrapped since it would have required major changes to the code and time wasted on writing map editors/loaders that could have been spent elsewhere.

We were able to get in all of our "must have" features and several of the "really nice" ones. This was due to good planning.

Schedule: How and why did your final schedule compare with your projected schedule? You should be able to glean this from your status reports.

We successfully integrated early in the quarter, which was a double edged sword. We had made little attempt at a planned API in the beginning, we simply set off to build wrappers for each of the code elements we wanted. Integration managed to patch everything together such that we could run a rudimentary game. The problem came when we had to add to the "world" object, which had to interface with about every module. Specifically, we always had to do major thinking and planning on where to add and delete objects in our world. We also had issues getting network code to behave correctly, and didn't have code to represent a game cycle till late in the quarter. Both of these things and a couple others I would trace back to the "world" and lack of a planned interface for objects in the world.

Many of the specifics (graphics, physics, input, sound) went along smoothly and were even ahead of schedule. Our hold-ups came when modules needed to talk to each other and team members needed to understand each other's code.

What software methodology and group mechanics decisions worked out well, and which ones didn't? Why?

From the start we focused our game design around having clearly defined modules and classes and a clearly defined gameloop. For example, all graphics we put into SpudGfx.cpp, client code SpudClient, etc.  The only problem that seemed to arise from this was that we sometimes had too many dependencies between classes.  What this means, is that one change in one class affects another class.  Most of these problems were easily solved. However, if one person was unaware of how their code affected other code, then better planning and better API design would have solved these issues.

For most of the larger decisions within the group we usually all just met and talked about it.  Usually just brainstorming, and picked the most logical solution.   This worked very effectively.  When making smaller decisions, it usually got decided in sub groups of the team.  For example, anything that had to do with the graphics aspect of the project was usually decided by core graphics people in our group.   This also worked very effectively and kept everyone aware of the projects progress.

And undeniably many decisions were made just b/c they worked then and there and we were ready to move on. We were constantly weighing elegant code against what was working with minimal effort. For better or worse we can point to pieces of code where we chose the latter, but it was still good enough to give a clean demo on presentation day.

Staying up late and working in groups also seemed to work out really well. Sticking with OpenGL made things easier since most group members were familiar with it and not at all familiar with Direct3D. We could of used more commenting of code and planning things out ahead-of-time.

What aspects of the implementation were more difficult than you expected, and which were easier? Why?

Everyone in our group seems to have different opinions on this. This largely depended on where our group members spent their coding time.

Baylor's perspective - I initially worked on input, and it was relatively straight forward. My code was modular enough that I created two extremely different implementations of input, one where each device was set up, and one with action mapping. I also worked on integration of the server and client code, and I personally found it to be time consuming, but also straight forward (although bugs were nasty to trace!). The difficult part was trying to figure out how, when and where in our code we would modify the world state / object. For example, firing a weapon and having a spawn point create a new item were quite complicated, since about half our source files had to be modified.

• For a player to fire a weapon,
• the input passes up the shoot action,
• which passes through the client and sent over the network to the server,
• which is handled by the server,
• where a projectile is sometimes created, (server, world, object, physics, projectile code are all modified)
• which must be then created on all the client machines.
• The projectile must be then updated constantly
• until the hit detection determines the projectile might be destroyed.

Cyrus's perspective - It was definitely more difficult than I expected to integrate all the code we had written.  Trying to make the server work with the graphics updated the world, etc.etc.    For the most part nothing seems to work as they should of.   Mostly just minor bugs and kinks that need to be worked out, but always a challenge to sort out. 
In the graphics aspect it became quite difficult to keep the polygon count low.   Because our game relies on many objects in the world at once it became apparent very quickly that good, effective culling was essential.  I started with room culling first ( just displaying objects in your current room ) this worked but still drew objects that were out of view.  Next I tried a Frustum Culling algorithm.  This just displays objects which fall in your viewing frustum.  This was very effective but still drew objects behind room walls that were still in your Frustum.  So final I implemented Frustum Culling in relation to FOV between doors.  This worked out very well and sped things up. 

Nick's perspective - I think that using DirectPlay ended up complicating things a bit. I would have preferred to use a more socket-based implementation where I had full control of every aspect of the communication. DirectPlay was too high level, and because of this, was hard to debug when there were network problems. In addition to the networking, I worked a ton on fixing bugs as they developed and hunting down new ones before they became too problematic. This was difficult, but was made MUCH easier by the excellent debugger built in to Visual Studio. I cannot stress how useful this was. Overall, things went very well for a rapid development cycle!

John's perspective - I agree with Baylor. Even though I spent the majority of my time building our sound engine and a "gameplay" class that keeps tracks of teams / scores / etc., I think the most difficult issues we tackled as a team were spawning new items and making sure items had the correct state in the world. Because of our API (lack thereof) keeping track of a projectile or a new weapon that a player has just picked up was quite a challenge.

In implementing your project, you relied upon a number of tools from the DirectX libraries to modeling software. Do you see the opportunity and need for new libraries and/or tools that would make project development easier?

DirectX seemed very hard to learn and confusing at times, but turned out to be very useful. We used OpenGL for the graphics and worked out very well..  If we had it to do again, we probably would have written our own networking routines from scratch.

It would have been fun to have Bonsai's "Blame Annotation" feature.

Our group's experience with 3d studio max was irreplaceable. We were able to use a combination of custom models and acquired models that gave our game a much more polished look. Inclusion of realistic furniture and household items added tremendously to the games appearance in the last few weeks of development. However, even with our groups experience with 3DSMax, a good importer would have been very nice! We had models in 3DSMax that looked amazing! However, the importer we used was awful. Some of the objects we imported were missing pieces (remember the sun glasses), and the importer caused several memory access violations whenever it loaded what it thought was a "bad" model. We had a model of a beaker which was used to make the player grow, and whenever we loaded it, our game would crash. We replaced the model and our game worked great. Also, the importer didn't recognize 3DSMax texturing, just textures that came from files (it didn't even do that well!). Because of this, we couldn't use common basic shaders like Blinn, Phong, or Metal, which would have given the models much more of a realistic feel.

We did make use of some libraries to provide fonts in OpenGL, and to help sound play Mp3 format sound. But the majority of the code written interfaced directly with DirectX and OpenGL components, which gave us flexbility in debugging as well as the satisfaction that we've built our project largely by ourselves.

Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?

The API should have been better defined from the get-go with the entire game engine laid out. This would have let us work in parallel a lot more and not have people hacking together certain parts of the game digging into all parts of the code.   I also believe that we should of prioritized our work a little better.  Once the quarter got started we sometimes got bottlenecked working on things such as "Map Importer" that really was not necessary to the game play.   This large project gave us a new perspective on timelines and staying focused.  We learned when to decide "to skip it" or "go for it" depending on the timeline.    In smaller, less intensive projects issues such as these where never really considered.

What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?

The papers starting off the quarter - particularly the quake paper - were great at giving the group a glimpse of how our game model should look. Maybe more papers later in the quarter would have been useful in keeping our minds open to different solutions to our problems.

The COM book was definitely overkill for what we were accomplishing. We did have a nasty bug for a week that would bring my machine to a screeching halt (a COM problem) . But largely our problems were self-inflicted. The Writing Solid Code book should have been read by our entire group. Having read a few chapters now that I have more time on my hands, simple technique could have saved many woeful nights for us. Maybe if we were told that the chapter on "assert" is something to live by, we might have given it a better look.

For the graphics aspect it is definitely a good idea to have at least one OpenGL book.    Everything else can pretty much be figured out from the web. 

Here are some links that I found very useful.  (mostly for graphics)

www.flipcode.com

nehe.gamedev.net

I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year? I will collect your answers and place them in the course web pages for next year.

Take time to plan things out ahead of time.

Keep your priorities straight. Make sure that you have a good plan of how everything is going to fit together before starting any one component. Don't have any special cases. Comment your code thoroughly, everyone else in the group should be able to see what is going on since they all might have to make a modification.

One thing that is very important to consider is the frequency of your CVS commits. A good suggestion is to only commit STABLE, WORKING CODE so that the CVS repository always has a working copy. Even if that means commenting out code you've just done, don't commit the changes actively until you've tested it. This keeps other group members from having to debug someone else's unfinished code!

One thing our group had was communication. No one has mentioned this yet, because luckily this wasn't a problem for our group. Whenever we'd start or change something, we'd let everyone else know. We always knew what other member were doing and we kept up to date with our progress. Communication is key. Without it, you'd probably end up with two or more people working on one thing in totally different ways. You'd also expect something to be done, but it's not because no one knew they were supposed to work on it. Make sure your students next year will also do this, it's a small thing, but it's very important.

How can the course be improved for next year (beyond getting better hardware, etc.)?

A lecture on coding style/debugging would be good so that everyone knows how to use DevStudio's features and can troubleshoot easier. Many students don't have much prior experience with Visual Studio, so it would definitely be useful to briefly speak about Visual Studio features and how to use the debugger. Also a tutorial on CVS would probably have been good. I think everyone forgot to add a file to CVS at one time or another and other people couldn't compile. If we had implemented branches, merging code and working in parallel would have been easier but we didn't want to complicate things.

Perhaps a real Beta release deadline would help as well. I'd never suggest this for a class I was actually taking, but in retrospect, our team pulled together best in the final days before the presentation. If we were to come together in the same way earlier on only good things could happen.

Last updated June 15, 2001