AI War 2:Threading Model

From Arcen Wiki
Revision as of 16:52, 29 September 2021 by X4000Chris (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Youtube Threading & Multiplayer Modding/Programming Guide

Coding With Chris: AI War 2's Threading & Multiplayer Part 1: Challenges

Coding With Chris: AI War 2's Threading & Multiplayer Part 2: Data Flow For Unusual Solutions

Modders: Do you need to watch all of the above?

1. Not one bit if you're not coding anything. If you're making xml mods, you can completely ignore the above.

2. If you already think you understand how RTS networking works, then just read the below images and then skip to about the 30-minute mark in the second video.

New Diagram For Modders/Programmers: AI War 2 Threading Model

AI War 2 Threading Model.png

New Diagram For Modders/Programmers: Multiplayer Data Transmission Model

AI War 2 Multiplayer Data Transmission Model.png

Slightly Older Explanation

This is from a discussion with Chris about how threads work in AIW2. It's almost certainly irrelevant for anyone who isn't a dev or an extremely advanced modder.

Here are the types of Threads in the game.

1. MainThread. This is where a VERY small amount of sim happens. Mostly this is user input. GameCommands are NOT processed here.

2. ExeutionContext. I think this is sometimes called SimBG. This is the main sim loop, essentially, and it spawns all the short term threads. After they are done, it does some more work to integrate their data back into the main game. This is also where GameCommands get executed.

3. ShortTermProcessing. There are a bunch of these. These are technically also part of the sim, and so I refer to them as "sim background threads," but they all run independently of one another before the ExecutionContext brings things back together.

4. LongTeamContinuous. There are like 5 of these. They run only on the host, and don't wait for the sim or have any direct impact on the sim. These do things like stack and unstack things, target planning, and so forth. Every so often they dump GameCommands into the main thread, which later sends them through the network and the executioncontext thread parses them. Even on single player, it sends it through loopback network and serializes and deserializes the commands, FYI. Keith and I did that to verify performance for multiplayer, since serialization is one of the slowest things.

5. LongTermIntermittent. There is one of these per faction TYPE. You're well familiar with these, as they execute the faction logic. However, some of the faction logic is executed on the "main" thread, which actually is the executionContext thread, so in that sense it considers the ExecutionContext to be the "main" thread. This disparity is largely because at one time it WAS the main thread, before we shifted it to have ExecutionContext in between.

--- In general the naming can get slightly confusing because the model grew at one point.


Want to know what context a thread is running in? Make sure that ArcenContext is passed into them, and then DebugOutput the context.ThreadName. If you want the thread type (this is a relatively new thing), then you can use context.ContextType. It has these values:

       MainThreadDirect,
       CustomTempContext,
       ExecutionContextThread_Aka_MainThreadBGIndirect,
       ShortTermPlanning,
       FactionPlanning,
       LongTermContinuous