Page 1 of 1

thoughts on program design

Posted: Sun Sep 21, 2008 12:15 am
by Virm
With absolutely no intention to tread on toes, Implode, I suddenly had a few thoughs on the design of IME (based on the last information in the forums about it that I remember) and wanted to run them by you to take, shoot down, or to do with whatever you please.

overland map and fog-of-war:
Quite some time back when you were rewriting everything to make the work right, there was a lot of discussion on how best to store the data and how it should be handled by the server and clients. I can't for the life of me recall what (or if) you said was the design you used for the current product and I can't seem to find it on the forums now.
It occured to me that what might be most efficient and secure (vs client-side hacking and the like) would be to maintain exactly one full copy of the world map and some structure holding the units and cities (and other things not part of the landscape) in a map-position indexable way. An alternative to the structure containing all units would be having a matrix or array of shorts or ints, the array/matrix being 1-to-1 in size with the map, and the values being a reference to a list of unit stacks/cities/etc. roaming the world. You could then have a bitfield or byte array/matrix assigned to each player, where each map square only need 2 bits to be represented.

0 = not explored
1 = explored, fog-covered (send map data only)
2 = currently visible (also send unit/stack data)
3 = (not used, possibly treat as 0? or use for additional option I may have forgotten)

Doing this would (I think) reduce memory overhead from needing to store the complete map multiple times, and would let the server send to the clients only those parts of the map which each client should receive, without any possibility for client-side tamper.


Having now typed all of that, I'm sure there was something else I'd though of, but I can't remember it at the moment. Will post it later if I think of it again.

Re: thoughts on program design

Posted: Mon Sep 22, 2008 1:15 am
by Implode
Virm wrote:server send to the clients only those parts of the map which each client should receive, without any possibility for client-side tamper.
Its already like that, that was core to the way I wanted the FoW to work.

Your 0-2 works fine for the default of "can see terrain changes, forget all units" but not for other settings. But on "recommended", you can remember what you saw of the terrain but not see updates to it.

So for example, you may remember seeing a city when it was size 5,000 that may now be 6,500. So you can see you do need a copy of every players' memory separately for things like this. The only item that the current code cannot remember is units, so the only FoW settings for units are "can always see" or "forget". But I've come to the conclusion that I'll have to add that feature as part of doing the AI (the AI will have to remember what units it saw in a city so it knows how big of an army it needs to build up to be able to come back and capture it).

And no, I don't mind questions/ideas at all, you might come up with something I haven't thought of :)

Implode.

Re: thoughts on program design

Posted: Fri Sep 26, 2008 5:11 am
by Virm
you're right, I'd totaly spaced off the idea of 'memory' from the fog.

In that case, would it be cheaper (in terms of memory/processing) to just keep a different stack/list/set/hashmap/etc. listing units, cities, and other dynamic map info for each player? then you could just update that structure whenever a player actually sees something new or different and just read from it for the fog areas. Areas not explored wouldn't be a problem because the player hasn't seen anything there yet so there's nothing added to the 'memory' structure in those areas. Similarly, this would prevent a player from 'seeing' a new city appear in the fog, as the city was never in actual sight and was never listed in the 'memory' structure.

Immediately prior to this sentance I was going to suggest that each item in the 'memory' structure could just be a reference/pointer to the unit involved, but then I ralized that that would allow a player to track the experience/health/growth of arbitrary field units of the enemy, regardless of their real position. I suppose that means that the 'memory' structure would need to contain actual copies of the objects from the time they were actually seen at that location. And to properly implement such a structure would mean allowing the possibility for a single actual unit to appear multiple times within the structure. This may mean using that last bit-combination in the aforementioned map structure being used to determine if a unit/object/other was seen at that location and must be looked up in the 'memory' object.

having such a 'memory' construct would also (I think) be a very efficient way for the AI to do a lookup for any potential threats/targets based on the last known forces in a particular place or direction. The only tricky bit in that regard may be inventing a heuristic to have the AI inteligently 'guess' at what location a unit is actually at when an identical unit shows up multiple times in the same general area of the 'memory' map.

one possible way to cut down on the memory used by the addition of object clones to the 'memory' structures would be to make something like a memory_item structure and only keep info in it that would actually be available when trying to look at those remembered objects. Again though, I don't know if this is actually a reasonable thought or if persuing it would be pure folly at this point.