Rules around unit statuses + player's memory of units

Discussions on game logic and rules used in MoM IME
Post Reply
User avatar
Implode
Site Admin
Posts: 434
Joined: Fri Feb 24, 2006 3:35 am
Location: Newfoundland, Canada
Contact:

Rules around unit statuses + player's memory of units

Post by Implode » Tue Jul 16, 2013 2:35 pm

Firstly thought would be useful to make a new subforum for talking about how some of the game rules work. Am trying to keep the info here as rules that will make sense to anyone familiar with the game, without necessarily having any technical coding knowledge.

Now one complication I've got right now is the data structures in the Java are more complicated than the old Delphi version. For e.g. the overland map, cities, buildings and so on in the old version, the server has (n+1) copies of the data - one being the 'true' copy of exactly how things are right now - but each player can only see what their units can see, so for a game with n players in it (raiders being 1 player, monsters in nodes/lairs/towers also being 1 player), the server then also has a copy of what that player knows about - which [unless they've cast Nature Awareness] won't be the whole map. The client only has 1 copy of the data, what that player knows about. But the old Delphi version didn't support that for units, it was just too complicated to deal with [for technical reasons that I won't get into], so the old Delphi server just had 1 copy of the unit data, and each player could either see a unit or not, they had no 'copy' of 'what they know' about each unit. Now in the new Java server they do - which means converting a lot of the routines across means taking that into account, so isn't as simple as just converting the code line-by-line.

So was struggling to get my head around how all this had to work when I was trying to write some of the code, and write tests for some of the code, so in the end decided I had to sit down and just write out all the rules about how unit statuses and updating player's memory of units worked, so I then had a reference to check all the code against. So now my head hurts x.x Anyway wanted to share this because thought people might find it interesting:
MoMIMEMessages.xsd wrote:Different statuses that a unit can have. This is extremely complicated now that there are 2 copies of the unit data to worry about
(the server's true memory, and the player's memory both as held on the server and client which should be identical) plus that the monsters player has its own special rules.

The server's true memory always knows about all units - they can never go out of sight. So:
- Heroes start at "Not Generated" or "Generated" depending on settings, then move to "Alive" when summoned.
- Regular units are created at "Alive".
- Units and heroes dying in combat move to status "Dead".
- At the end of combat, units at staus "Dead" are removed entirely.
- Even after the end of combat, heroes at status "Dead" are kept forever (since while dead heroes cannot be re-summoned,
they can be brought back with the life spell "Resurrection").
- Combat summons (like fire elementals or phantom warriors) go to status "Dead" when killed, and are removed entirely when the combat ends whether they were alive or not.

The player's memory (both server and client side) never has "Not Generated" or "Generated" heroes - heroes are only added once summoned. Players' memory of their
own units otherwise works as per the server's true memory, since players can always see and retain up to date info on their own units. So:
- Our units and heroes dying go to status "Dead", and after combat dead units are removed entirely but dead heroes are kept, same as in server's true memory.
- Enemy units that we kill in combat (i.e. we're involved in the combat) are retained at "Dead" for the duration of the combat and then removed entirely.
- Enemy heroes that we kill in combat are removed immediately since we can't Raise Dead or Resurrect them.
- Enemy units and heroes that somebody else kills in a combat for which we are an outside observer (e.g. standing next to 2 unit stacks
both owned by other players watching them fight) are removed immediately since we can't Raise Dead or Resurrect them. And therefore by implication,
if one of the players involved in the combat -does- Raise Dead the unit, for any outside observers to the combat, its treated like a re-add.
- Combat summons (like fire elementals or phantom warriors) go to status "Dead" when killed, and are removed entirely when the combat ends whether they were alive or not.
- Player's memory only contains monsters in nodes/lairs/towers when we are in a combat with them, so the monsters are added to the player's memory on the server
and sent to the client in the StartCombat message, go to status "Dead" when killed, and are removed from the player's memory when the combat ends
whether they were still alive (monsters won) or not.
- Combat summons (like fire elementals or phantom warriors) go to status "Dead" when killed, and are removed entirely when the combat ends whether they were alive or not.
- Outside observers to a node/lair/tower combat never get to see the monsters - they'll just see the attacking units taking damage.
- Enemy units that we can no longer see on the overland map if the units FOW setting = forget are removed entirely.
- Enemy units that we can no longer see on the overland map if the units FOW setting = remember are retained as we last saw them, including that if they get killed,
we don't know about it and will continue to remember the last place we saw that unit.

The monsters player (who owns the units guarding nodes/lairs/towers as well as rampaging monsters walking around the map) has a the exception that
they obviously are aware of their own units, so are the only player who knows the exact units in nodes/lairs/towers even when not involved in a combat there.

abazigal
Posts: 1
Joined: Sun Oct 05, 2014 4:59 pm

Re: Rules around unit statuses + player's memory of units

Post by abazigal » Sun Oct 05, 2014 6:20 pm

Hi implode

I dont have a lot of knowledge about code but would it be an idea to keep the 'true' sheet on the server and include the visibility of a unit as a status effect in relation to a player?
Just as it is currently treating units as being dead or alive? That way you would only know what your units know. The server would be the gamemaster and inform the connected clients about the progress of their individual games and what they can and cannot do.
You wrote that you are now writing in java and that players now have information about each unit unlike what was possible in Delphi. Isnt that just complicating things? Or is it nessesary for the client to have that information to make things work over a network?

Regards,
Simon

User avatar
Implode
Site Admin
Posts: 434
Joined: Fri Feb 24, 2006 3:35 am
Location: Newfoundland, Canada
Contact:

Re: Rules around unit statuses + player's memory of units

Post by Implode » Mon Oct 06, 2014 11:00 am

Simon,
abazigal wrote:keep the 'true' sheet on the server and include the visibility of a unit as a status effect in relation to a player?
That's (as far as I can tell) how the original MoM works with units, and how MoM IME works if you set the fog of war to "Forget". So if you see something with a scout unit, then walk away, it disappears (becomes invisible, as you put it).

Now for setting the fog of war as "Remember as last seen", think about how it works with city data and buildings. A scout unit might find an enemy city with 5 buildings and 6,000 people. You then run away again. 20 more turns pass. When you right click the enemy city on the map, it still looks to you like it has 5 buildings and 6,000 people, because that's the most up to date info you have on it. In reality its probably now got 8 buildings and 9,000 people. Or maybe its been captured by someone else. You don't know because you don't have a scout there watching it anymore.

Units (since the Java server in 0.9.4) can now also be put on "Remember as last seen". So take that same city, when your scout saw it maybe there were 4 units guarding it. Then you run away again and 20 turns pass. When you right click the city, you still see 4 units there because that's the most up to date info you have about them. Maybe in reality those units are now dead, or somewhere else. So its more complicated that simply, are the units visible to your player yes/no. You remember everything about them - not just what type, but what health and experience they were on. If heroes, what items they had.

That was a major blocker to me being able to start on the AI. After an AI scout unit finds an enemy city and then walks away, if the AI immediately forgets what units it saw in that city, how can it make any reasonable estimate at the size army that it needs to build up in order to attack that city? The AI has to remember, right when I saw that city it had 4 mediumly good units in it, therefore before I attack it I need to get 6 medium-strong units. It has to know, oh right that city was full of magicians with missile immunity, so there's no point me attacking it with a bunch of archers.
abazigal wrote:Or is it nessesary for the client to have that information to make things work over a network?
The client only knows whatever unit data the server sends it, so the client only knows about what you (your player/wizard) can see/has seen. The server has to remember everything, from everybody's point of view. If you're in a game against 1 other player, the server will have 3 copies of all the building data, all the spell data, all the unit data, all the map data:
  • The true full info about every building/spell/unit/full map.
  • What you know or remember.
  • What the other player knows or remembers.
Basically what the server is doing is, every time something changes (in the true details), it then checks every player one at a time to see if they can "see" the change (i.e. do they have a scout unit watching the location where the change is happening). If yes, the server updates its copy of what that player knows, and sends the same info over the network to that player. If no then you don't find out that change.
abazigal wrote:Isnt that just complicating things?
Yes, and? :)

Post Reply