Progress has slowed to a crawl in recent weeks. I’ve had limited free time lately and the procedural history generation has grown increasingly complex, almost to the point where I need to rethink it or scrap it. I coded the barebones implementation last week but hit a wall when I added more historical event types. I’ve also spent a disproportionate amount of time optimizing the editing of history generation ScriptableObjects in the Unity Inspector. I originally conceived a solution that was heavily text-based, using dot notation to reference different attributes of entities in the history state. Thinking that this was too error-prone and user-unfriendly, I built (most of) an Inspector UI to edit the objects. I’m not sure at this point which approach is preferable; they have equal pros and cons. Relating historical events is another area that is proving to be far more difficult than anticipated, and where I’ve likely gone overboard. Increasingly, the original idea of loosely connected, randomly generated events seems like it won’t work. Initial testing revealed that the sample histories I created by hand in the design doc had many implicit connections and assumptions I didn’t factor into the procedural generation. Finally, transforming the world state produced by the history generator into concrete objects in the dungeon has exposed a limitation in how dungeon stocking currently works. Map Elements, the objects used to stock the dungeon, can be overlaid but can’t communicate with each other. For example, if a king dies and is to be buried in a crypt, the king can be placed in the crypt, but cannot be placed specifically in the sarcophagus in the crypt. There are fairly simple solutions for this particular case, but a general solution is more complicated.
The key achievement this week was deciding to have history events use the Command pattern to interact with the world state. I tested this idea using the hand-created timelines and it works well (the measure of how well it works being applicability across all of the timeline events). This solution is advantageous from an editing standpoint too; it works well in the Unity Inspector. I’m a little concerned that I’m giving editability too much weight in my solution selection, but it is an important factor because I need to be able to rapidly create many event types.
Next week, I’ll implement the initial set of world state commands. These include placing entities in locations, killing entities, adding items to entities, and aging entities. Also, I’ll try to solve the historical event relationship problem. My goal is to finalize the history generation design in February and implement the Map Element transformation in March, entering Q2 with a working history generator.
Leave a Reply