I've been working on the map view implementation and am currently at the point, where a Python script (the view schedule) needs to update the position of the map view based on the position of a character (so that the view stays centered on the character as he moves around the map).
The way the schedules are implemented, they get the instance of the view (from which they can acquire the map) and a tuple with additional arguments (which can only contain ints and strings, otherwise it cannot be serialized when saving the state of the view). In order to access the character from the schedule, I would pass in the character Id. And that is where I ran into issues. So far, we have two parts of the character implementation: one for role playing purposes (containing the unique id) and one for moving about on the map (containing graphics and location). And so far, they are distinct. I checked the v0.3 code base, and there the map character extended the rpg character class. But I do not really like this implementation. The idea was to have all rpg characters instantiated, even if they are not present on the current map, so that they can be affected by plot related events (i.e. changing their dialogue or schedule, stats or inventory). So it should be possible to load the rpg character instance and place it on a map later. So here are more ideas: 1) Let the map character instance be a member of the rpg character class (as its graphical representation, which can be loaded or unloaded at need). 2) When adding a character to a map, specify also the rpg instance Id and keep in map character instance 3) Instead of just the Id, store the rpg instance itself in the map character 4) Keep mutual references from map character to rpg character and vice versa The problem is, I do not know which would be the best. For each, I can find pros and cons: 1) + The two character classes belong together. Given the Id, they can easily be retrieved from the same place. - Maybe there shouldn't be such tight relation between rpg and map stuff - Given the map character instance, there's no simple way to get the rpg instance (i.e. character fell from cliff, need check stats, apply damage) 2) + Map and RPG stuff is kept separate - Map and RPG Instances need to be retrieved from two different places - We'll run into the same problem with items (also have rpg and map instances), which have no unique id (yet). I'd rather find a solution that works for both 3) + RPG character instance can be either accessed via Id or map character instance - Maybe there shouldn't be such tight relation between rpg and map stuff - Given just the id, there is no easy way to get the map character instance (exactly the issue with the mapview schedule) 4) + Given Id or either map/rpg character instance, other instance can be accessed very easily. - design nightmare (cyclic references are evil) - probably run into issues with building win32 dlls, which can't have undefined references With the above, I'd tend to solution #2. It shouldn't be a huge deal to add a unique id to items in order to apply the same solution here. But I'd also like to hear what you guys think ... any better ideas? Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel