Refactoring Delta^2

This article describes a future concept. It may still have some open issues and it was not decided, yet, whether to implement it in this way.

TODO: Format this unstructured discussion pasted from #arianne logs on 21st December 2010.

23:36 < hendrik> the problem is the way it keeps track of changes.
23:37 < hendrik> Currently almost every object is flagged as changed every single turn.
23:37 < hendrik> That means very single creature we have.
23:39 < hendrik> adding objects to the modified map of the zone is called so often that it takes about 80% of the time used in the turn thread.
23:39 < hendrik> (without players)
23:39 < hendrik> every object keeps its own list of modifications.
23:40 < hendrik> there is a loop over all zones, over all modified objects, to clear it.
23:40 < hendrik> which then recursivly clears it on all slots and childrens.
23:40 < kymara> reminds me of that psychopath comment, again
23:41 < hendrik> so simply not adding creatures to the modification list, means they won't be cleared.
23:41 < martin_> a psychopath comment? :)
23:41 < kymara> "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
23:42 < martin_> ok this one :)
23:42 < martin_> but thats not easy sometimes
23:43 < kiheru> it's safest to live in a remote place
23:44 < hendrik> well, the code is clean and easy to understand.
23:45 < hendrik> but the approach does not seem to be scaleable.
23:47 < martin_> do you have an idea for a better approach?
23:49 < hendrik> and the next thing that is slow is calculating the percepts for the players.
23:49 < hendrik> which is the main bottle neck on the servers nowadays.
23:49 < hendrik> i am currently testing a server without players, because i want to get the CPU usage of the test server down.
23:50 < hendrik> but i think that will help the main server, too, because most of the zones are player empty.
23:50 < hendrik> martin_, i have some ideas, but not ready to code it.
23:51 < hendrik> basically I think that instead of having modifcations maps for every single object, we should have one modification queue.
23:51 < hendrik> (on a per zone level, as the modifcation flag is handled already)
23:52 < hendrik> so it would be as simple as cleaning one map (per zone) to reset things.
23:52 < hendrik> It should stick to the hiearchical handling that is already there.
23:54 < hendrik> so something like object, attribute = new value
23:55 < hendrik> this way it is easy to collapse multiple changes of the same attribute.
23:56 < hendrik> and something similar for changes to slots and subobjects.
23:56 < hendrik> this approach has two advandages:
23:56 < hendrik> 1. no need to update the modify flag anymore.
23:58 < hendrik> 2. just clean the map at the top level at the end of the turn, instead of calling 5 methods for every object (plus two methods for every slot owned by them, plus the same 5 methods for every child object ,...)
23:58 < hendrik> Oh, and building perceptions may be as simple as dumping that map.
23:59 < hendrik> ---
00:00 < hendrik> but before i start to rewrite that completely:
00:00 < hendrik> * needs a good way to handle sub objects
00:01 < hendrik> * can we have a global cross zone unique id? (is it okay to double it's size to long?)
00:01 < hendrik> * how to handle private attributes in the perceptions.
00:02 < hendrik> * continious world
00:02 < hendrik> ** at the network layer
00:02 < hendrik> ** sub zones
00:03 < hendrik> The continious world thingy is the main reason, i am not just starting hacking.
00:03 < hendrik> don't want to spent lots amount of time on simething that may not be able to handle it.
00:04 < hendrik> Basically the sub zone thingy seems to be nice.
00:04 < hendrik> it reduce the network bandwith used and prevents people from hacking the client to see the compelte zone.
00:05 < hendrik> and it may further speed up things, not sure about that yet.
00:06 < hendrik> getting rid of empty perceptions would further reduce network usage.
00:06 < hendrik> but there are clients which do time measurement by counting perceptions.
00:06 < hendrik> so i don't want to break that, unless there is a good reason.
00:06 < hendrik> with sub zone there is, because it will get even more likely that there are no changes.
00:09 < hendrik> but if a subzone is as large as the player screen (so that a player gets update about 4 sub zones), it means we get a lot of subzones.
00:10 < hendrik> so the current approach of iterating over all zones a lot, will not be good.
00:10 < hendrik> --------