GNE – Game Networking Engine (Archived)

GNE is an archived project since 2012. GNE, or the Game Networking Engine, is a cross-platform, multithreaded, C++ networking library with an API specifically addressing the needs of game networking. There are two parts of GNE, the first being the mid-level classes that handle packeted, error checked, and bandwidth throttled communication between two peers. These were completed with GNE 0.5, although they still go under refactoring from time to time, and will until GNE 1.0.

The second part is the high-level classes which were never completed and was to handle things like unique player ID’s, player-to-player text communications, and develop a framework for a game server. It will also have a list server which is a server list players can connect to find games to play in.

This project was hosted on SourceForge back when it was as big as GitHub is today (in 2025). I have uploaded an archived copy of the source code as well on GitHub. My thanks still go to both organizations for their many years of high-quality free open-source hosting.

Intended Audience

GNE was designed to take the latest in object-oriented programming and modern C++ (at the time, ISO C++ 98) techniques and apply them to provide a clean, safe, and robust API for game development. While the concepts in the mid-level API could be applied to more than just games, the high-level GNE API is extremely game focused. While I discovered other networking libraries, I found that most are very “C”-like and none took advantage of all (then) modern C++ advancements such as templates, inheritance, exceptions, RAII, and smart pointers. I believe that proper design leads to easier development and robust code that deals gracefully with network errors and exploit attempts.

GNE was never not meant to be scalable to large environments, thus GNE is not suitable for running an MMORPG server, although it may be acceptable on the client side with a component implementing the GNE protocol on the server side. I published the protocol information so that other implementations (possibly ones more scalable) could be created, but this is no unlikely useful today even as a base for a new protocol.

GNE was designed to do as much work for you as possible. It is called Game Networking “Engine” and not Game Networking “Library” because it is meant to be a framework to build the networking portion of your game rather than a set of “utility” functions. Thus, GNE is aimed towards developers wanting to use an architecture rather than something to help them develop their own.

Feature List

GNE development stopped with development after the 0.70 release but most of the way to the 0.75 release. The below list shows the features in the source code, in the last release, and in the intended next and final releases.

Legend: In latest code :: In GNE 1.0

• Provide a C++ class interface for threads, mutexes, and condition variables.
• Provide a C++ class interface for timers and timer callbacks.
• A very capable and flexible logging and debugging system which is filterable and reports various events to the log file (file name, line number, class, this pointer, thread name, and printf style messages).
• Provide a simple C++ implementation of console I/O functions to be used for the GNE examples, and for text-only servers using GNE. This implementation is different from ncurses or conio because it is thread-aware to allow output and input to happen from multiple threads at the "same" time.
• Provide a C++ class interface for packets, from which the user is expected to derive their game-specific packet classes from.
• A set of standard packet classes.
• Provide a proper way of serializing packets in endian-independant format. Some of this functionality will be handled by HawkNL. The serialization routines detect and prevent buffer underflow and buffer overflow, highlighting bugs while developing and preventing exploits.
• Provide the user with a base client/server protocol framework, handling these specific events, common to virtually any game:
  • Low-level connections which are bandwidth monitored and controled.
  • Checking for server/client network protocol versions.
  • Handling text messages to be sent to all players.
  • Assigning unique IDs to players, and managing player lists, allowing you to distribute data to the whole group, or parts of it.
  • Players entering, leaving, or timing out at any time (the user can restrict joining to game start only), handled directly by the GNE code.
  • Time Syncronization between peers. (implemented currently as an explicit feature of PingPacket, but high-level GNE will do this automatically).
• Provide the user multiple quality of service guarantees on a per-packet basis over the same logical Connection.
  • All packets arrive and arrive in order.
  • Packets are not guaranteed to arrive or arrive in order.
  • Packets are guaranteed arrival but are not guaranteed to be in order.
  • Packets are guaranteed to be in order but are not guaranteed to arrive.
• Provide an event-driven scheme for responding to sockets in a clean generator-listener idiom using modern C++ and object-oriented features such as smart pointers.
• Provide a framework/protocol for a server list server, similar to networks like battle.net or Half-Life, supporting multiple types of games with optional game-specific information. Unlike battle.net, the server list will simply act as a database sending a list of IP addresses, their game type, and the optional game-specific data.

Historical Documentation

In case you are interested in seeing documentation for such a project designed in 2001, you can find it below:

• doxygen-generated API reference documentation
• High-Level API Design
  • ObjectBroker
  • Server
  • Connecting (PNG)
• A post on multithreaded networking in a game engine
• Protocol Specification

Dependencies

If you actually get this to build, you should get a prize. Unfortunately, the prize won’t be the library, too old to use and not completed (although what was implemented was working at the time).

• CMake build system, version 2.2 or higher in UNIX, 2.4 for Windows.
  • Ubuntu dapper/edgy, Debian etch users: (apt-get cmake)
  • Debian sarge: 2.0 is too old – backport or download (no compiling needed, binary needs only libc6)
• ISO-1998 compliant C++ compiler (apt-get build-essential)
  • Out-of-the-Box for:
    • Windows: MSVC.NET 2002, 2003, or 2005, MingW
    • Linux: GCC 3.x, 4.x (GCC 2.9x and earlier is no longer supported!) 4.2.4 and 4.3.0 recently tested
  • Might work
    • Solaris 8: Worked as of GNE 0.55, no testing done for GNE 0.75
    • Mac OS X: Theoretically…
• The HawkNL networking library written by HawkSoft, version 1.68. As of 2025 HawkSoft still seems to be run by the same person (Paul Hawkins) but no longer hosts this software. Contact me if you need source, I have a Subversion repo snapshot that I could pull files from.
• The Boost template library, 1.34 is known to work. You do NOT need to compile any part of Boost – GNE uses the headers only. I have a
  • Debian/Ubuntu users: apt-get libboost-dev
• Optional dependencies, for building documentation:
  • Doxygen HTML documentation generation system (required to build documentation) (apt-get doxygen)
  • dot from graphviz for building graphs in doxygen (optional even if building documentation) (apt-get graphviz)
• Extra dependencies for UNIX only:
  • pthreads implementation (in Linux, included as part of libc now) (apt-get libc6-dev)
  • curses/ncurses implementation. Anything should work, but libncurses5 and libncurses6 tested (apt-get libncurses)

At the SourceForce files section there is pre-compiled HawkNL for MSVC.NET and mingw 1.0 (GCC 2.95.3-6) and a minimal version of boost 1.34 headers. The HawkNL is likely totally useless being so old.

Once you have the dependencies, this should work (obviously not tested since 2012):

cd gnelib
mkdir build
cd build
cmake ..
make install