I adapted a version of the Royal Game of Ur using my custom 3D game engine, ToyMaker. Both the engine and the game are programmed in C++, and make prodigious use of the SDL, Nlohmann JSON and GLM libraries, and the OpenGL graphics API.

A small clip from the game showing a player's piece overtaking a couple of opponent pieces.

A small clip from the game showing a player's piece being launched and displacing an opponent's piece.

A small clip from the game showing a player's piece moving along the board to displace an opponent piece.

You can download and play the game from the releases page of the project repo.

Game of Ur is a competitive, two-player board game. The player who moves all 5 of their pieces to the end of the course first, wins the game. The variant implemented in this adaptation is based on a paper by Irving Finkel. See the game design document for more information.

Technologies

Game Architecture

The game scripts are divided into two parts, namely:

  • Game Data Model and Controller: The part of the program responsible for accurately representing the state of the game, as well as validating and enabling updates to that state.

  • The Visual and Interaction Layer: The part of the program responsible for visually representing the state of the game to the user, as well as translating user input to data usable by the game controller.

Game code architecture for the Royal Game of Ur.

The (more or less exact) workings of the game are described in the project’s game design document.

Game Model

All the data representing the state of the game and the rules for how the game is played is represented in the game’s “data model.” It is a collection of classes, where each class encodes some game related concept (such as dice, game board, and game pieces).

Any single instance of the game is encapsulated in and interfaced with through an orchestrator class, namely the Game of Ur Model class. The model is responsible for (correctly) updating the state of the game (through methods such as roll dice and move piece), testing actions for validity (eg., can launch piece, can advance one turn), and report the current state of the game (with methods like get current player and get all possible moves).

Game Controller

The game controller is a Sim Object which maintains its own instance of the Game of Ur Model, reports game-related state changes to other objects in the scene using signals, and, through the player controls it instantiates, provides an interface for other objects using the engine to advance the state of the game.

Interactive and Visual Layer

Game visuals with labels corresponding to the list below, figure 1, courtesy aankajhoka@gmail.com.

Game visuals with labels corresponding to the list below, figure 2, courtesy aankajhoka@gmail.com.

The visual aspect of the game, which you see on every game screen, is the collection of UI objects, 3D scene objects, and interaction logic which come together to represent and enable interaction with the current state of the game. The numbers on the diagram above correspond to the descriptions below.

  1. The game phase display. Displays whose turn it is, current game phase, and action presently required.
  2. The dice display. Has a button to roll dice, displays dice state and last turn’s roll.
  3. The common counters. No. of counters the winning player can earn.
  4. Player panels. Per player: no. of counters held, and the state of their pieces. Launchable pieces can be clicked and added to the board.
  5. End turn. Ends current turn, or begins next phase of play.
  6. The board. Divided into
    1. The battlefield, where pieces belonging to either player may be placed.
    2. Black’s region.
    3. White’s region.
    4. Rosette houses. Special tiles which allow player to win or lose counters, whose occupant gains knock-out immunity.
  7. A game piece. Clicking on it after a valid roll causes it to move forward.

Engine Architecture

The engine provides the foundation for all real-time updates and resource management in the application. It provides a single threaded update loop (through simulation step, render step, and variable step callbacks), a native observer pattern implementation, a scene representation of the world, a component-first game scripting interface, input abstraction, and a an extensible entity-component-system implementation.

ECS

An example of ECS in action.

The engine’s ECS implementation is the heart of the engine. It tightly packs related data into component arrays, and provides application loop and lifecycle updates through the system base class.

Resource Database

An example scenario involving the storage and use of resources.

The resource database dynamically loads static resources from file (or as otherwise specified), destroys them when they are no longer needed, and in general prevents the duplication of memory-heavy objects.

Scene System

The scene system provides a spatially/logically hierarchical representation of objects in a scene, in a manner that is familiar to game developers.

Sim objects and sim object aspects use the scene system to provide a component-first game scripting interface. Aspects, as implemented here, correspond quite closely to Godot script nodes and Unity MonoBehaviours.

Render System

The render system provides a set of classes that represent steps in a rendering pipeline, as well as a (hard-coded) means to glue it all together. There is much work to be done to make it more flexible.

Clip showing intermediate textures generated in the rendering pipeline

For the time being, the render system implements deferred shading using the Blinn-Phong model for lighting. The diagram below shows, broadly, how it is structured.

A flowchart describing the rendering pipeline.

The scene system’s viewport nodes has a special relationship with the render system. A viewport node which declares its own ECS world also gets its own instance of the render system. Every viewport node, regardless of whether or not it owns its own ECS world, owns a target texture, which it updates via the render system per its own configuration. It tells the render system about how it wants the render to take place, eg., through its texture dimensions and scaling mode properties.

  • Github repo – Where the project and its sources are hosted. The releases page has the latest Windows build of the game.

  • Game trailer – A simple gameplay trailer for the Game of Ur.

  • Game and engine development timeline video – A development timeline video for the ToyMaker engine and the Game of Ur.

  • Documentation – The site holding everything I’ve written about (the technical aspects of) the game and the engine.

  • Trello board – This is what I’ve been using to plan development. I don’t plan to do any more work on the project for the time being, but if I do, you’ll see it here.

  • Working resources – Various recordings, editable 3D models and image files, other fun stuff. I plan to add scans of my notebooks later on. Some standouts:

    • Productivity tracker – Contains logs of every bit of work I did (or didn’t do), and charts derived from them.

    • References – Links to various websites and resources I found interesting or useful during development.