Author Topic: SimulationInterface  (Read 811 times)

silnarm

  • Local Moderator
  • Behemoth
  • ********
  • Posts: 1,373
    • View Profile
SimulationInterface
« on: 19 April 2010, 12:42:44 »
This is essentially a 'follow up' of the issues discussed in this topic: https://forum.megaglest.org/index.php?topic=4696.0

I've come to the point where I felt I needed to get this resolved, Daniel never got the tmp_refactor branch building, so I blazed my own path, and came up with a somewhat different solution.

This probably better belongs on the dev mailing list, but I can post pretty pictures here :)

The problem in a nutshell is the Network <-> Game/World interface. The NetworkInterface is created by MenuStates before the Game and World exist, but needs ultimately to interact very closely with them, this is achieved through a static object (a singleton) called NetworkManager, which creates and destroys the Interfaces as required, and provides queries for the game to determine if this is a network game, and provide pointers to the interface.

The old model:


With lots of additions to the networking code (admittedly much of it only there for debugging atm) this slightly messy approach became very messy. I've added an abstract, but highly functional, class called SimulationInterface, it's owned by the Program, and represents the Interface to a, potentially non-existent, World and Game (renamed GameState for now, pending a better name coming up...)

There is always one and only one, the three concrete types are LocalInterface (very thin), ClientInterface & ServerInterface. Initially the Program creates a LocalInterface, in MenuStateJoinGame it is told to change into ClientInterface, MenuStateNewGame might or might not change it to Server, SimulationInterface::changeRole() by default copies the GameSettings and Stats from the previous Interface to the new.

The new model:


Much of the stuff in Game that related more or less directly to the World (game speed, the Commander, etc) now lives in the SimulationInterface, along with the GameSettings and Stats, which previously has to be very carefully handed around when ProgramStates were changed.

The NetworkManager is gone, what was the old NetworkInterface and been renamed NetworkConnection, a NetworkInterface is now what used to be GameNetworkInterface (or GameInterface in very recent GAE code). 

The SimulationInterface contains some code from the Game (GameState) and some from the old NetworkGameInterface, and some from the UnitUpdater which was eliminated last week.  Anything which effects the game world goes through the SimulationInterface, so the client/server specific stuff is all handled through virtuals, the only 'network role' checks left atm are in the chat manager, and they will be coming into the SimulationInterface too.

All fairly much done and (importantly) working, I just need to go through and clean up some more, and will commit direct to trunk this week some time.

Glest Advanced Engine - Code Monkey

Timeline | Downloads

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: SimulationInterface
« Reply #1 on: 19 April 2010, 21:37:37 »
How does AI fit into the model? I imagine it is like a Network or Local Interface but might go off LocalInterface since all AI is done locally.

Types of Intelligent Agents
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

zombiepirate

  • Guest
Re: SimulationInterface
« Reply #2 on: 20 April 2010, 01:13:36 »
Shouldn't AI still be part of GameState? As far as AI goes the clients don't need to know anything about the AI aside from what it's doing with the Commander, so I don't think it should have anything to do with the network.

silnarm

  • Local Moderator
  • Behemoth
  • ********
  • Posts: 1,373
    • View Profile
Re: SimulationInterface
« Reply #3 on: 20 April 2010, 09:07:11 »

The AI is still handled the same as before. Which is to say its not handled :P The Ai bypasses the Commander and it is assumed they all pan out the same on each simulation.  This will be easy to change if we want to have Ai run by a particular participant in the future, currently all Ai commands are issued via AiInterface::giveCommand(). So only the four variants of that function would need to be modified.

I moved the AiInterfaces into SimulationInterface, the 'GameState' (desperately need to find an appropriate name for it) is now just a 'view' of a World and a 'controller' for one Faction, it's not as fully decoupled from the World as would be nice, but that can be fixed soon with sigslot.

Glest Advanced Engine - Code Monkey

Timeline | Downloads

 

anything