Nox Futura - Traps, Machines and Context Menus

My Nox Futura work this week has been relatively scattered; the last couple of updates exposed a ton of functionality, so now I’m catching up on bugs and missing features that have been exposed as a result. It’s slow going, but very satisfying. It’s also led to some hillarious bugs.

Silly Bugs

Found a funny issue with work orders. Some critical successes let you make more than one item at a time. The “number to create” field is decremented by the number actually made. The desired number of goods was unsigned (uint8_t), and I forget to check for wrap-around - so a critical success when you had to make just 1 item made the queue show 254 remaining. Your settlers would happily make all 254. This is now fixed.
The case of the curiously recursive dinner. When you have a cooking workshop (currently camp fires, nuclear or otherwise), you gain some reactions - Roast simple meal (cooks a single component), Roast normal meal (cooks 3 components), and Roast lavish meal (cooks 4 components and a spice). A little bit of magic happens when creating the result, so you can end up with (for example) Roast Deer, Onion, Caper and Chickory (which actually sounds quite appetizing; they don’t always… Roast Strawberry, Onion and Garlic sounded awful). Anyway, I’d forgotten to differentiate between prepared meals and food ingredients - so the game would sometimes decide that a roast is an input to a meal. The name combiner then kicked in. So you could have Roast Roast Deer, Onion, Caper and Chickory, Strawberry & Sage. Repeat ad-nauseum until you have a roast whose name takes up the entire console. It got worse; I built a test settlement and told them to try and keep 10 lavish roasts in stock at all times. They obligingly started cooking, then they started taking roasts as inputs, and before long there was only one food item left in the whole game - a Roast Roast Roast… (repeated for a really long time). Oops. This was fixed by differentiating between cooked and uncooked food, which I really should have done anyway!
The case of the great tea suicide. One of the silly jokes in the game is that you can replicate Earl Grey, Lukewarm and make a mildly satisfying drink that may or may not resemble tea. As the food/drink clocks get going, this is actually quite important - you won’t starve/dehydrate at the very beginning (but when feelings are in, your settlers won’t like it!). So I ordered that 10 cups of tea remain in stock at all times. Combined with the unsigned bug above, the settlers dashed off to make over 500 cups of tea… completely draining the ship’s power banks and killing everyone.

Back-End Tweaks

Discovered that turning off real-time protection from Windows Defender more than halves my compile times.The ECS now supports using a map based back-end as well as a vector based back-end (I switch at compile time, currently). I’m still deciding if this is an improvement. The map backend has no garbage-collection overhead (deletes are instant), and reduces the overhead of finding a component belonging to an entity (it traverses the map rather than the vector). This is slower with small numbers of entities, and faster with large (the tipping point seems to be around 200 entities). I’m going to keep testing. As I add more complexity, I think the map will win.
Worked on game loading times a bit, mostly for my sanity as I repeatedly run debug builds. I’ve taken to building a fort to a point from which I can test, and saving the game. Then I reload the game and test, killing the process (savescumming my own game!) if I need to tweak and try again. I’ve managed to get it down to 13 seconds from clicking “Local Windows Debugger” to having a running game. There’s room for more optimization, particularly at the beginning while it loads textures and voxel models - but it’s comfortable working like this.
Fixed the game crashing when someone got caught in a cage trap. (The position component vanishing suddenly caused some problems).
Started investigating versioning of saves (with an automatic deletion of incompatible saves, rather than the current behavior of crashing…). This is harder than I expected!
Fixed an issue that was preventing units from seeing as much of their surroundings are intended. A view radius of 8 tiles now covers 8 tiles in all directions!
Re-enabled gravity, I’d turned it off by mistake.

Context Menus

Context menus are back. They are pretty horrible right now, lots of usability issues to fix - but they are sufficiently present for me to debug things.
You can lock doors once again, and the ship’s energy doors have a new graphic. This required the context menu - click the door and select “lock” or “unlock”. Pathing updates appropriately.
You can designate harvest from the context menu.
Now that the context menu is back, it’s possible once again to order a building to be demolished.
The context menu also lets you get to the building info panel.

Machines - Part 1 of Several!

Re-enabled the machines system, and started making it less of a usability disaster. Also added in some missing graphics for levers, retracting spikes and blade traps. This is deliberately quite generic. Buildings can have a sends_signal tag, and/or a receives_signal tag. For example, a lever can send a signal. The Machines UI lets you link any sender to any receiver. So you can link a lever to a bridge (to retract it), spikes (to raise/lower them), or a door (to lock/unlock it). There are a ton of aspirations/plans for this system, but for now I’m getting the basics working smoothly. I’ve successfully retracted bridges and toggled spikes in testing, now. Next week will be all about making the UI for this not suck. This involved cleaning up a lot of old code, some of which I’m convinced that I was asleep when I wrote it!
Balance/play questions are coming up, so I’d appreciate some input; when playing a Dwarf Fortress type game (in Fort mode), would you rather the game move fast so you can accomplish a lot without needing a ton of coffee breaks, or a more realistic building speed? I’m leaning towards the former, but it is quite unrealistic that you can get a functional settlement going in a couple of weeks of game time. On the same vein, I’m wondering how fast plants should grow? Currently, they are pretty slow (faster than real life, but not super-fast). DF has really fast farming, and I’m wondering if I shouldn’t do the same in the name of not boring players to death. I often find myself using DFHack to enable “super dwarf mode” just to get projects done in a reasonable length of time.

Screenshots

The fixed view area makes greyscaling areas you can’t see much nicer. It’s only partly grey; allowing some color in made the effect much more pleasant.