Hi, I slowly started moving towards making adv map objects more configurable. Note that for proper “configurable object” we need still scripting and map editor. Neither of those are in my plans - I’m mostly interested in removing hardcoded configurations for extremely similar objects - e.g. moving all ID-based checks from such objects like CGPickable. So instead of checking for object type all such data can be read from configuration. Ideally I’d like to apply this idea to ~20 objects such as School of War, Windmill, Temple, Warrior Tomb, maybe even Seer Huts, Events and Keymasters.
For now my plan looks like this:
Move all id-dependent code into initialization and add fields like “messageID” or “soundID” to objects. This will help me to see all object-specific constants. (that should be moved to config in the end)
Generalize “things” granted to player in such objects. So instead of having object-specific code that grants something to player (resources, skills, artifacts) there will be generic “give reward” method that can use any data from object configuration. In the end it should be possible to use such method for complex objects like events/seer hut rewards.
Generalize what makes object visited. Right now we have multiple sets of objects with only difference between them is who can visit objects (once per hero, once per player, once per game). I’m going to merge all of them into single class with possibility to choose “visit mode”.
Note on technical part - I want to avoid huge numbers of new classes with complex inheritance so for example this stage will be represented as one object with possibility to select “mode” instead of proper OOP approach with something like “IObjectVisitor” interface and separate classes for each mode mostly due to simplicity and to avoid more load on RegisterTypes.
Requirements to visit object - some objects give different rewards depending on day of week (e.g. double bonus on day 7 in temples) or need specific resources (tree of knowledge, School of War/Magic). These should be described in a more generic way similar to seer huts (but ofc without proper “quests” part).
Think about how this data should be organized in json config. Final part, first I’d like to have such generic object implemented in code and only then move configuration to json. At this point I will also work on proper way to add map objects from mods (dwellings and representation of modding objects on map).
Extra but somewhat necessary - expose all this information to AI and make sure that AI understands usefulness of an object.
Right now I’m still around stages 1-3 with different progress among different groups of objects so there is still quite a lot to do, will upload to trunk once I’ll finish stage 4 at least for some objects, minimum plan before I’ll consider this task finished - to have all objects but events/seer huts covered by these concepts.