I solved the big history generation problem I mentioned last week (the first bullet below). An uninterrupted half-day last Sunday got me across the finish line. To increase weekly game dev time I added 30 minutes of dev time to the start of each weekday (5 AM). It’s a small amount of time, but I find that I naturally work faster because of the limitation.
- History event entity attribute combination validation. That’s a mouthful. It’s best explained with an example. A history event that builds a new Barracks room will have two entities: the Map Block (the physical space where the Barracks will be built) and the Map Element (responsible for populating the Map Block with the Barracks content). The Map Element entity has two attributes: the Map Element Type (Barracks) and a reference to the Map Block entity. The Barracks Map Element can only be placed in Map Blocks that are larger than 6×6. Previously, the history generator randomly selected from all of the Map Blocks when determining where to place a Map Element. This caused Map Element placements to fail when the selected Map Block didn’t meet the Map Element’s placement criteria. Now, by checking that an entity’s combination of attributes is compatible, the history generator will only place Map Elements in Map Blocks where they fit.
- Multi-room purposing and stocking. Using the recently developed component model, the map and history generators can now designate a purpose, such as a bandit hideout, for a portion of the map and stock the rooms accordingly. This is a critical feature for achieving my level design vision. In addition to populating levels in a rational manner, it bridges the gap between history and map generation. For example, there is a history event type where faction A invades faction B’s settlement. This event type couldn’t be implemented by the map generator because the faction settlements weren’t defined. Now, the map generator can determine the exact area of faction B’s settlement and place invaders from faction A there.
- Room repurposing. Rooms can now be repurposed by the history generator. For example, an ancient shrine could later on be used for goblin barracks. When the room is stocked, first the shrine Map Element (statue, decor) is placed, then the barracks Map Element (beds, chests) is placed. Map Elements have always had this capability, but the history and map generators didn’t support it until now. Yet to be done is modifying the previous Map Element in a room when a new Map Element is placed. Although this feature still needs a lot of refinement, it already shows great potential. In testing, I’ve seen a number of room type combinations I wouldn’t have thought of on my own that create interesting situations.
- New history event type: New Bandit Hideout. This event type uses the new multi-room purposing capability to populate a subsection of the map. The rooms composing the subsection are set to room types found in a bandit hideout (barracks, guard posts, armory, etc.).
- Cleaned up history generation code. I did this to make it easier to reacquaint myself with the code. I did some refactoring (combining and removing methods, simplifying branching, renaming), documented methods, and deleted commented-out code.
- Bug fixes.
Next week, I’ll refine the new features added this week and update history event types to use the new features.