Wobble Final Report

Physics

Proper physics were the key to making this game fun. We iterated over several physics models starting simple movement and moving all the way to true pool-ball collisions. We did a lot of research online and spent many hours deriving mathemical formulas, time well spent as it plays such a prominent role in our game.

Networking

The multiplayer aspect adds so much to the game that we designed our code from the beginning with multiplayer support in mind. We settled on a client-server architecture allowing a single host to coordinate the game and maintain an authoritative game state. In fact nearly all the computation is done on the host, including collisions among players and bot motion. In order to make this manageable, we abstracted the code using a post office or message passing metaphor.

AI

Following the multiplayer theme, the addition of computer controlled opponents was also critical to the success of the game. Much of their intelligence was borrowed from the physics of potential fields. Several bot types treat players and boundaries as charges and navigate the potential field they create.

What went right

• Extreme programming -
  At the beginning of the projected we used pair programming methodology. This gave both of us an excellent understanding of the core engine and paved the way for effective code division.
• Extensible core -
  Our initial project design was truely a success. We spent a lot of time kicking around ideas and developed a game plan around a simple core game idea. This allowed us to collaborate closely on the engine and ensure it's quality before branching off towards extra features.
• Scheduling -
  In a similar vein, we found that prioritizing and scheduling the remaining code kept us on task. This seemingly trivial managerial trick made it possible to divide and conquer towards the end with clear milestones. Although the deadlines we set weren't always met, we allowed for a spare week at the end which let us slide the goals a little without falling too far behind into an insurmountable crunch.
• Quick Ramp-up -
  Another success was getting a playable game running very quickly, in under a week. This was made possible by having a simple concept and we soon became addicted to the game. Having this instant gratification made debugging bearable and allowed new features to be made available instantly.

What went wrong

• Lack of focus -
  Beyond the core engine, we didn't dive deeply enough into any features. For instance once the networking code was working, we felt little need to improve it. Thus much of our networking code is in dire need of profiling to allow it to scale to larger groups and harsher networking environments.
• Late feature additions -
  Much of the non-essential code was added too late in the development cycle. It often demanding features from our engine that we had not anticipated and needed to hack together. If we had thought of these requirements earlier we could have redesigned some of the interfaces.
• Tendancy to patch code -
  We found collision detection particularly challenging and despite a sustained debugging effort could not make this critical feature perfect. This code became very fragmented and full of unmaintainable hacks. In retrospect it should have been rewritten from scratch.

Lessons learned

• Pair programming -
  Pair programming (aka Extreme Programming) is good. It let us get the engine running quickly and almost entirely bug free.
• Graphics benefits -
  Using simple textures and models is fairly straight-forward and makes the game look a lot better.
• Internet resources -
  There are many resources available online, google let us quickly find useful web pages addressing questions that we weren't sure how to solve.

Project Proposal