Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
WIKI INFO - Build out strategic priorities a little bit. WarPriority …
…is a notable one as it is the first one that includes properties. I've tried to build the priorities so there will be a common interface. The goal being that new priorities can be added being mods, and they can still be serialized. The interface should help for this. If all of our StrategicPriorities were bespoke hard-coded, it might be convenient, but it would not lend itself to extensibility. The challenge is going to be how do we merge those priorities, convenience of writing the logic, extensibility, and serialization? This is still an evolving thought process, and I'm not totally sold on this dictionary-of-dictionaries approach, it just seemed like the most convenient way to return a weight *and* some required data about how that weight was chosen and what to do if this priority is chosen by the arbitrator. The other half of the thought process that's not yet fully coded is that if a priority is chosen, its info should be stored in the data classes. My general thought here is that by returning property maps, we should be able to store those, and a reference to the type of StrategicPriority, in the data classes, allowing us to reconstruct objects of the appropriate type, put in the relevant properties, and re-load from save. The engine will also have to be able to look up the priorities based on name... maybe a key type thing? This should also be stored in the save. So basically, on load the engine will have the key, the weight, and properties. It'll use the key to find the appropriate class, instantiate an instance, and stuff the properties onto that instance (and maybe the weight or maybe that's higher-level metadata that goes elsewhere). This yields an fully inflated StrategicPriority instance that the AI part of the engine can then reference to calculate things. Combining this with a lookup mechanism for StrategicPriorities should yield moddability. I'm reminded of Java's "Service Provider Interface" concept, the gist of which is that if you make a class that follows an interface, and register it with the JVM in a certain way in your program, the JVM magically gains new capabilities. An example is if I write an image processor for PCX files, and register it correctly, the general image ImageIO capabilities in Java can now magically handle PCX files, e.g. ImageIO.load("x_title.pcx") will just work, even though in stock Java it wouldn't know what to do with a PCX. It works for other types of services too. Our specifics will differ, but I think the goal should be similar - if you write a new StrategicPriority and follow a given interface, it'll magically be incorporated with the AI. The remaining hard part is how is the strategic AI looped in to decision-making? There are theoretically a thousand places this could be looped in, but if we want it to be extensible, we have to have standard interfaces. But the StrategicPriority also has to know enough about the situation to be able to interpret what's going on. For now I'm thinking some combination of weights and modifiers being providable by the strategic priority. E.g. for city production, it should be able to make some things be produced more often, and that's a weight based thing. But I'm sure there's other cases I'm not thinking of that make things more complex. I'm also aware of what Jon or Soren mentioned somewhere about overly generic AIs sometimes not being decisive enough. It'll be interesting...
- Loading branch information