• Register
Post news Report RSS Development report: Campaigns #2

An outline of the different kinds and parts of the campaign system is given. Starting with the types of maps and limits. Noting single- and multiplayer mode and the dynamic change of such (if allowed by the single player). Describing Campaign design, how open|infinite maps work (streaming).

Posted by on

Definitions: i.e. := id est, i.e. latin for "that is"; e.g. := exempli gratia, i.e. latin for "for example"


Map streaming limits

Dynamic map expansion can be constrained, e.g. useful if no computer cluster available | economically|ecologically sensible to prevent the simulation hitting a single system or a small network too hard.
From biggest to smallest:

  • world (continuous or hard constraint at "edges")
  • cluster
  • galaxy
  • star system
  • planet
  • continent|ocean
  • (country; borders not consistent across history, thus an especially dynamic case where the map shrinks and grows over time based on historical record - not too much fun though as the player has no possibility to influence this as no simulation data (events, state, ...) is maintained for anything surrounding the country e.g. no chance to deter Sovjet and German dissolution of Poland 1940)
  • region
  • city
  • village
  • settlement

If such a limit is defined, then the map will not stream once you hit the outer edge of the currently loaded chunk (3D).

A campaign is like a river, but it flows in both directions.

Transition from Multi- to Singleplayer match and vice versa

A simulation can be started either by one player or by multiple.
The AI takes over whenever a player resigns or moves in course of HybridAI transitions. Examples are the loss of your character without any kind of revival cheats, or loss of power due to sunken loyalty, or seeking harbor in an exile or in the wilderness with or without loyal remnants or family.
Similarly an AI supervisor node can be replaced by a human player.

In neither case is there any loss of information - like e.g. plans - thanks to the Capability system at the heart of the simulation which spreads knowledge in a distributed way across your citizens and organizations (mostly stored in real items that can be destroyed or stolen).

This is an important aspect of the distributed campaign system of 0 B.C.E. Time Machine. At its core are the HybridAI services and the persistence of information.

Performancewise a multiplayer match has disadvantages because the way across the network may be longer compared to a local network or - in the most advantageous case - multiple threads on a single system.

In addition to the commands of players within currently loaded map chunks, isolated simulation data must be shared across the network* on demand (e.g. when a player wants to check the game statistics, restricted to what it "knows", i.e. has explored, following HannibalAI concept, which worlddevelopment ports to the head revision of 0AD). Note an AI player is treated no different than a human one.
Resource-wise it does relieve the local system (network) of the hoster unless the different AIs are spread outside of the local network, too. But the overall resource costs are equal or greater in an internet multiplayer session.

This data isolation may seem counter intuitive at first, but it is required to separate loads like pathfinder calculations which would otherwise bring a system to halt pretty quickly, unnecessarily limiting our fun living through and trying to change history (the major campaign of the time machine). Of course custom campaigns or other modes are possible too, see "Open map" which next to Scenarios and Campaigns covers an endless type of match - with or without time continuity - with or without pitching all civilizations from all epochs for a very imbalanced fun match.

As a nice side effect such a distributed approach with proper interfaces (the binary streaming) brings multi threading capability. The design does not care if the calculations run on a thread or GPU of this or another physical system.

* A lightweight operating system like Alpine, Arch or Void Linux is recommended. Expect the first release of 0BCE to be a Void package.

gallic wars 1 village from south

Campaign

A campaign can be described as a set of missions|objectives to achieve or fail, structured into scenarios.

The focus often lays on a certain swiftly changing, i.e. unstable, region where control of one power lessens and others fill the void (or push forcefully). A kind of anarchy well can arise locally in such circumstances.

The achievements of prior missions are kept. The storyline machine handles the achievements and streams the corresponding new map data both on success and failure. It then either includes the simulation of this chunk if there are no foreign powers (non-gaia) or starts a new thread on a machine of the network.

This leads to a very adventurous system where you can be thrown back to an earlier stage if failing in a part of a later scenario - even partly, e.g. loss of the core castle due to an under estimated incursion at your left flank. You will have to live with that and iron it out across this or the next levels of the campaign (or ignore it if it you can employ a strategy that nullifies the gain of the enemy).

campaigns 2 sail far away stream

Open map

The free map endeavour is very interesting. Consider creating a map of the entire planet Earth's surface using a consistent satellite imagery resolution. The engine streams only the map parts into memory that are required thanks to the by design backwards|forwards compatible binary format.

Say you want to start a Roman Republic in 200 BCE. The simulation loads the historical guidance data (without mods contrary to a saved game) and lets you build your cities and empire.

Now you have all freedom, you can decide to turn another city than Rome into the capital due to your secret plan to confuse the adversaries of the civilization you lead as one of the elected Consules.
Or you can decide something exotic as happened often throughout history: send a fleet to Asia over seas for example.

This is where the distributed nature of the virtual time machine excels. As your fleet proceeds, the map data is streamed - as is relevant interfacing information of cultures that so far lived along calmly in a thread that lightly kept a system on the network from boring idle. :)

Once the coordinates of your entity enter the chunk of the foreign system, in addition to your pathfinder taking remote entities of the entire chunk (or at least those nearby), also the remote pathfinder takes your sent entities into account, this means the commands have to be shared and the simulation run deterministically on both machines concerned.

If an entity is out of reach, then the only information is that of spies, either under camouflage or citizens of the other civilzation that you have "bought" or convinced otherwise to transmit position and other information to your base.

Two cases can be distinguished (ordered from less to more ideal):

  1. Fixed static chunks + transitions zones|interfaces:
    The pathfinder responsible for the chunk takes over entities identified via the sender's node ID + the entity ID within the sender's simulation.
    Interface zone is defined by hitting the edge of the loaded map chunk (frequent check required similar to a range check but with fixed coordinates - comparably costly performancewise).
    Here as long as your spies are not disclosed, the simulation must not be run on both machines.
  2. Stream dynamic chunks (surrounding):
    Requires the relevant player commands be shared and those concerning the entities within your currently loaded surrounding to be filtered and applied in a deterministic way.
    It is more computing intense because the streamed chunk, i.e. the surrounding, changes dynamically compared to the static chunks requiring a greater amount of entity transitions be handled (just like a range check).
    Here even if your spies are not disclosed, the simulation must be run on both machines.

At first sight, number 1 looks more promising, especially as performance not suffers no matter how many such other network systems you conduct intelligence on. Unfortunately the bill lacked a decisive item: The player that sent the spies wants to be able to see and also interact with the entity and its surrounding it conducts reconnaissance in. Commands must be transferred too unless you want to go for super realism and require a second entity to forward messages as of e.g. a changed plan to the spy. And what about radio transmission then? The message could be beamed with a delay on a carrier radio wave entity with corresponding speed. Of course that works. Currently it is just not certain if it's wise.

The bidirectional nature of the endeavour (seeing what your spy discloses in real time) however favors version 2 while realism favours version 1 with e.g. a video transmission or conference stream for technologywise more advanced civilizations. For rendering that video in realtime the entity positions will be required - and again the lack of direct bidirectionality hits version 1 hard.

Pathfinder issues virtually fixed as side effect

Last but not least the distributed nature fixes the current performance problems of many moving units. If the computational limits are still hit in case of an impact of very big armies, then a new thread could handle these entities exclusively, two threads within the same loaded chunk so to say.
As the surrounding is dynamic, the problem can even be further decomposed on demand.

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: