Networked physics game/engine

Features:

General

  • Runs on windows & linux, macos port abandonded last year, ios abandoned many years ago.
  • Minimal launcher.exe + reloadable game.dll. reacts on disk change. Wrote my own system, then replaced it with CR and started contributing to that.
  • C++ full-game hot-reloadable code, even when run from Visual Studio. No global variables, virtual functions or function pointers for callbacks. This is to allow easy DLL code reload.
  • No classes or class methods, except for a few tiny containers. In the rare cases an API requires any of these, a minimal wrapper is put in the launcher exe, and is accessable via a passed context to the game.dll.
  • Debug stepping of sim frames, i.e. pause the game on all clients, then progress one sim-update.
  • Render thread and sim thread decoupled, each can be using different framerates. Renderinfo is pushed from sim thread to render thread and interpolated just in time to render. App can be set to serially coupled 1:1 mode for easier debugging.
  • ECS

Compilers

  • Custom buildsystem compile.cpp starts by first rebuilding itself, then generating a Tup Tupfile which avoids unnecessary rebuilding and custom dependency rules.
  • Content compiler for Unity3d-scenes with referenced textures and models, spawnpoints and fbx-models (read with Assimp). Planning to use Godot or Blender for level design, but it was fun reverse-engineering Unity.
  • Arena/stack-based allocation for serialization of data. All content from the scene, sound files, animations, etc, are put in .pack-files with relative offsets in a TOC. These packs can be used as is in-game.

Sound

  • 3d-positional Sound effects and music using SoLoud.

Physics

Network

  • Lockstep networking with customizable render-lag. (plan to unlock)
  • Authorative handling of networked physics objects.
  • Lobby server and lobby clients, room publishing, synced join upon all present. (todo: late-join drop-in/out/rejoin)
  • Networking can either use reliable UDP via RakNet (only feature used, might as well switch to Enet) or my simulated network code for split-screen play.
  • When using simnet, N number of instances of the game are launched in the same process plus 1 instance of the lobby.
  • Router (host) migration, when the host dies.

Graphics

  • Using a patched version (for c++ dll support) of bgfx for color, textures, shadowmaps, lights. Looking at Diligent for possible switch.
  • Split-screen support with global gui + gui per simulation.
  • Imgui for inspection, tweaking, setup of simnet instances, loading of scene, the lobby_client, profiling visualization (custom scopes + Pix). (bgfx implementation of imgui).

Animation

  • Ozz for skinning animation
  • Animation control for walk,run,jump,idle,punch (meta-data from unity)

Gameplay

  • Keyboard + gamepad input via SDL, for players and freefly
  • Networked gameplay features: health, punching, pick up, throw, score area.
  • Game modes: 1. collect boxes in each player's own area. 2. punch/throw box at other players to reduce their health.
  • Game over screen :)

Additional 3rd-party libs used

  • Flag for commandline parsing.
  • PicoJSON for config files. (Should probably switch to TOML)
  • LibYAML for parsing unity scene-files. Not very useful at all. Should probably convert yaml to toml or json or anything else, before parsing.
  • GLM for maths. It's too templatey, but I don't know what to replace it with.
  • stb_image for loading textures not already in bgfx-native formats, and for writing screenshots.

Demo-videos below (sound only activated in the first one):

gameplay with sound

menus, profiling, freefly

4 player split-screen

networked multiplayer, linux lobby

live-coding