openage architecture

openage is separated into many modules (“subsystems”).

Overview

Some of the components are already implemented, others are not. All of them need to be revisited to implement the goal architecture.

Components

Utilities

  • Datastructures

  • Error handling

  • Filesystem abstraction

  • Job dispatching

  • Live reloading

  • Logging system

  • Python interface

  • Random number generator

  • Test and demo infrastructure

Information flow

Current architecture

The current data flow of openage is just to display the raw simulation data.

input -> simulation -> renderer -> output

Goal architecture

0 input ->
1 network ->
2 simulation ->
3 network ->
4 prediction/interpolation ->
5 renderer ->
6 output

For singleplayer we could bypass 1 network and 3 network by using direct function calls or talk to a local socket. For multiplayer this means that we will have a single authoritative server that is just running the simulation. Each client then receives the data visible for it.

The current architecture can be extended by adding the missing components in between.

The prediction/interpolation reuses the simulation code, but is non-authoritative: The data provided from 2 has higher priority.

There exists a link of 0 input -> 4 prediction so that input is immediately accounted in the prediction, thus displayed.