Recap

For October I wanted to get a strategy map up and running.

Results

It was kind of a good news/bad news sort of month. I did get the strategy map generation hooked up, though not much thought has gone into what it's generating so it's not really an interesting map but that can come later. I also started on the screen for navigating the map. I ran into some problems with getting widget sizes when I needed them, but was able to work around that. That's when I hit two hurdles. The first being that line drawing doesn't seem well supported in the whole widget-ness of UMG (UE4's UI toolkit), so that was kind of an unexpected downer that, combined with the sizing problem, demotivated me a bit on moving forward. The other hurdle was that some of the systems that I've written have not been exposed to Blueprint (UE4's content scripting toolkit) enough to give me access to the data that I needed for building my new UI. That was at least a solvable problem.

First a digression: For various reasons almost everything I'm building/writing is on an as-needed basis and is as close to the minimum required feature set for whatever feature I'm trying to add. For starters I just think this is generally good practice to only build what you need and not build anything too speculative. Then you add onto your systems with concrete use cases, refactoring along the way. Occasionally you may need to do a larger refactor, but at that time you at least have a significantly better understanding of the system that you need than you did to start. This goes for professional projects as well as hobby ones, but we'll get back to that in a second.  The other reason I've been doing this is that I have an admittedly vague idea of what this game is supposed to be. I'm not a professional designer, I don't have well thought out design docs or explicitly planned content for exact weapons, or ships or even the narrative, which means my concrete use cases to start a system are very narrow and can be supported by very little code. The only content I've really built are more in the vein of test cases to provide variation that can validate what I've built. Contrast this to my current professional work where there are professional designers and design docs and specifications. Sure they change, game development should be iterative, but they provide a significantly higher bar for minimum viability than anything I've been doing at home. So while my engineering process might be the same, different input results in different output.

There have been a few exceptions to this when I have built more fully flesh out systems that included things I didn't need at the moment. My data structure that stores the model (in the MVC sense) of the game is based on what we did in XCom2 so there was a sense of familiarity there to build out a complete system based on how I knew I wanted to be able to use it without having to modify it repeatedly. Similarly the transaction system I was working on for so long was because I was building a more future proofed system that what I needed right now. We just happened to be building a similar system for our project at work and while I was not involved in writing it directly I was involved in working through the design space of what it needed to support. So this was an instance where, when I went to write one for this project, I have a significantly clearer and confident understanding of what I was going to want out of that system.

Anyway, back to my solvable problem: my game state model (again in the MVC sense) was not reasonably accessible to Blueprint. It had the one or two calls I needed to make all the previous UI's. So since I was kind of dejected about my strategy map UI I decided to keep up my general development momentum by improving my low level system integration into Blueprint. This was pretty straight-forward if a little time consuming since it mostly involved creating a duplicate version of the native interface to be called by Blueprint. Sure, some functions were able to use the markup UE4 provides so that a native function and a Blueprint one are the same thing but it's not an option. Firstly, my game state model enforces a pretty strict const-correctness on it's data and const instances of things aren't supported in Blueprint (in-fact, if you try to return a const pointer from a blueprint callable function, you get a compile error in their auto-generated code). Second, my data structure that stores the model relies quite a bit on templates to provide the best/most reasonable access from native code (which is my primary user) and there isn't an easy way (that I've ever seen or found) to expose those to blueprint. Thirdly, though related to the second, the functions for blueprint involve slightly different parameters so as to provide the best/most reasonable access when being called from blueprint.

The thing that I got really excited with as I was doing this were custom blueprint nodes. I had a few cases where just marking up a native function (even one designed specifically for blueprint) wasn't really giving me what I wanted usability-wise. At work I had done a little work with the feature that UE4 provides that allows creating blueprint nodes from scratch and manually specifying everything instead of trying to find markup to allows the engine to turn a function call into a blueprint node. Everything I had done at work involved deriving from a specific node that UE4 provides for creating objects, but that wasn't what I needed to do so I dug in a little deeper and started building a few nodes basically from scratch (only deriving from the most basic node type that allows it to be placed on a blueprint graph). It's almost like a weird sort of assembly language connecting inputs and outputs of other nodes through code instead of graphically. In the end I built four nodes (three concrete ones and one that they share) that provide a robust interface for those data accesses that mirror the robustness of their native versions. And I took what I learned and immediately solved a similar problem at work to make way better blueprint nodes for a couple of tasks than what were using before. I joked a little at work that I'd gone power-mad with what I could do with the custom blueprint nodes, but just a joke since they still can't do anything that's not somehow supported by native interfaces. If you're willing to dig into it, custom nodes can be a great way to expose native functionality without having to compromise engineering principles just because of the limited markup. And that work continues, hot on the heels of those successful nodes I started a node for my custom event handler but ran into some stumbling blocks I haven't had a chance to investigate yet.

November Goals

Finish getting a working strategy map integrated into the rest of the existing systems.  I may continue to punt on the line drawing and just come up with another solution to convey the same information but we'll see. I'd also like to see what I can do about my custom event handler node. This month will be a bit complicated by holidays and other things on my social calendar. On the other hand I am having to use up a bunch of vacation before the end of the year so I'm only working 4-day weeks during this month. I will probably try to dedicate those Fridays off to working on my game.

Games I'm Playing

Fate Grand/Order - No reason to stop so far

Disco Elysium - Every so often there's a point and click adventure that seems to strike that I'll get into.  Not often, the last one was Syberia which I played on it's original release in '02. I like the detective angle and the noir meets lovecraft(ish) feel.

The Outer Worlds - I can't say enough good things about this. It scratches those good Fallout itches. I was a big fan of Fallout 3, 4 and New Vegas and was disappointed in what had been announced for Fallout 76. Multiplayer games aren't really my jam, so I didn't even start. I have my complaints (I'm playing on PS4 and the text could stand to be larger), but so far nothing that ruins an overall positive impression.

Fire Emblem Three Houses - Slowed down on this. All the story battles playing through a second storyline are the same, just with different narrative justifications. It's still good to have as a mobile option or when I don't have control of the TV for Outer Worlds.