Analysis of OpenSceneGraph for building a simple network game

Aaron Knoll

Network Game Design

CS5961

The goal:

Our goal is to build a simple network 3D game that can be completed in several weeks by a team of 5 people or less. Moreover, we wish to find an existing codebase that already implements most technical aspects of a game engine, but does not tie itself to any particular client-server model. Thus, we will have to implement multiplayer functionality ourselves, but will not have to implement the core engine or tools.

The candidate:

Our candidate for this task is OpenSceneGraph ( a relatively thin API built on top of OpenGL, with numerous add-on projects that provide functionality for model loading, space partitioning, font engines, and more. OpenSceneGraph itself contains no code for network games; that is left to the user to implement.

Why is this a good choice?

Without a doubt, the primary benefit of OpenSceneGraph (OSG) is its support for non-native model formats. OSG supports Maya (obj), Max (3ds), Lightwave (lwo), Quake/Half-Life (md2) and many other formats natively, without requiring the use of exporters. OSG also compares favorably to full-solution engines such as Torque or Irrlicht in that it is relatively small and receives frequent updates. One can even choose to update directly from the CVS server used by current OSG developers.

Why is this a bad choice?

The major downside to OSG is that from personal experience, its documentation is extremely high-level and somewhat shabby when it comes to deciphering actual code. OSG was clearly implemented by skilled C++ coders, but it exhibits some over-exuberance with templatizing and a somewhat confusing pointer system. Even though you don’t have the task of sorting through a full engine with 300,000 lines of code, you will have to get in the minds of the OSG coders, which (in my opinion) is a bit trickier than understanding a more conventional game engine implemented in C++ with a balance of object-oriented and function-oriented programming.

Other criteria:

- OSG is a GPL project, meaning we can modify it all we want as long as we don’t sell it and keep the code open to everyone.

- OSG has good support for cutting-edge OpenGL techniques, namely the OpenGL 2.0 higher-level shader language. Of course, these are advanced techniques that fall outside the scope of our project, and would waste a good deal of time if pursued.