Marbles – The Post Mortem
How Marbles Originated
A team of reluctant students were banded together to form a project for their final term project. A suggestion was made to make a pinball type game, but the idea was quickly shot down due to the potential complexity. As a compromise, the idea was scaled down to a simple ball racer similar to Marble Madness and Super Monkey Ball.
Implementation
The final project is a fully playable game. The player can control the ball in a single or multiplayer (2-4 people) with a mouse, trackball or the arrow keys. Multiplayer games are chosen from a drop down box of IP’s which were registered with a master server. Players spawn at a map specified spawn point and finish the game at a map specified end points. On the way to the end players will encounter multiple routes usually one which is slightly shorter but carries more risks and one that is longer but is more tedious with no risks. Players can enjoy a full 3d sound environment with background music and collisions between players and walls. Finally the player is rewarded with an end of game menu showing the time of completion.
What Went Right
Switching to the Right Game Engine
On the initial days of research and development, each team member examined popular open source game engines. The main criteria for the engine were to be multi-platform compatible and had enough useful documentation. The initial choice was the Ogre3D rendering engine. However, after several builds with Ogre3D, it was discovered that the additional components required for game development was not easily implementable into the Ogre3D code framework, and the engine implemented an incomplete version of BSP maps. Half-way through the development of marbles, the team switched to the Irrlicht game engine. With the new engine, the team was able to port all features implemented in Ogre3D to Irrlicht in two days.
Keeping the Gameplay Simple
By only using point-to-point racing aspect, the team was able to focus on creating fully function framework system. This kept stress levels low and allowed the team to work on their own modules without having to worry about the other modules.
Modular Coding
With each team member focused on only one element of the game, each person is able to write their own functions. This allowed each person to easily integrate code if the main code is ever changed drastically.
What Went Wrong
Going Multi-platform
In the initial design phase, one team member demanded that the project to be multi-platform compatible. While the rest of the team members thought there was no harm from this decision, it later came back to haunt them. Several issues arose when builds where starting to fragment and needed to be reintegrated. This broke a few code sections and prevented one version or the other to not be able to compile. A lengthy meeting ensued afterwards with the final decision to force development on one platform first and then fix or port the code later on for the other.
Choosing an Open Source Engine
While the benefit of using an open source engine is not having to pay any licensing fees, the downside to this is not having any reliable support when things go wrong. Any code support comes mainly from minimal wiki documentation and old forum postings.
One major problem that needed to be dealt with is level creation. Most open source engines support Binary Space Partition(BSP) maps. However, the only available method of creating BSP maps is with old level editing tools for Quake 3 Arena. Not only are the level editing tools are not easy to use, but required specific configurations in order for the tool to compile proper levels for the project. With proprietary engines, level creation tools are often given with the engine and are designed specifically with the engine code.
Standardizing Coding Conventions
Each person has their own preferred method of coding styles. With time constraints, that the team was not able to fully discuss standardizing coding conventions at the beginning of the project. This led to future frustrations when attempting to debug code. Fortunately, by keeping the game modular and meeting twice a week, the frustrations were kept to a minimum.
Conclusion
The biggest lesson learned in this project is understanding and working with strict time constraints. If more time was properly allocated to the research and design of the project at the start, the outcome of could be a lot more different than it is now. Most of the problems from the project are tied to the team’s inexperience in the field. Thanks to the team’s skill, the project is able to recover from some bad decisions. Overall, this was an enlightening look into team dynamics and dedication.
File Link
http://rapidshare.com/files/118685935/Marbles_release.zip.html
Instructions
For offline play:
- run _newProject_launch.bat
For host network play:
- first run _master_server_launch.bat,
then _server_launch.bat,
then _newProject_launch.bat
For client network play:
- first run _server_launch.bat,
then _newProject_launch.bat
To change the IP address:
- simply edit the .bat files
