Slow, but steady seems to be the name of the game.

Recap

In July I wanted to finish up with my transaction system.

Results

I did okay. I was hoping to at least get started on the UI side of things but just didn't have the time. I did finish all the initial gameplay elements that I'll need but that's about it.

Since I didn't do any new UI, there aren't any pretty pictures so instead I'll discuss the transaction system that I put together.

I actually started by spending some time taking a look at the Actions/Weapon definitions that I already have and use for the actions you can take in Tactical. In a lot of ways the transactions are analogous as the actions that you can take during the Strategic portion of the game. So it seemed appropriate that maybe there was something that could be shared between the two. In the end I decided against it. There's a fundamental difference between the two (at least when I was considering it), and that is state. Weapon definitions have accompanying state for remembering ammo counts or cooldowns or any other gameplay element. Transactions shouldn't. They will modify state for sure, like how much of a resource you have, but they themselves are just kind of fire-and-forget.

With that decision out of the way I started on setting up the actual transaction definition. The transactions are meant to be pretty simple so it's basically just a set of inputs and a set of outputs.  Unreal has a pretty interesting mechanism available for member of asset types called instancing that allows having object pointers that can be configured in data to create an instance of a selected type. Then you can setup that type so that you can also edit the instance as part of that asset as well. Where this comes in with transactions is that those sets of inputs or outputs can be sets of a base type (which defines the basic API for an input or output), mark them up to be treated as instanced and bam! to add a new input or output type you just have to derive off the right type and you can plug it into any existing transaction. The other nifty thing is that since it's all reflection powered I can have the transaction code "live" in my StrategyTech plugin and define all the concrete versions of the inputs and outputs in the game plugin.  This isn't the first time I'm doing this, the weapons work pretty similarly for the things that they can do to mutate the state of the game, but it is a pattern that works pretty well given the way the Unreal engine is setup.

I also wanted to setup up transactions that had a little state, but only after you executed them (in contrast to weapons that have state all the time). I called these Projects and they are transactions that have a temporal element. I thought about making time just another input type, but couldn't make that work since it could impact how every other input/output of the transaction has to work. So instead I made a derived type of transaction and overrode a few functions. It also meant that I built in to the input/output types the possibility of multi-step execution. They each support a Start (for when the transaction is executed), a Refund (if the project is cancelled) and a Finalize (when it becomes no longer possible to refund). There's also a helper that calls Start immediately followed by Finalize, this is what the base transactions do since there's not supposed to be any opportunity to refund them.

Lastly there's a class of objects created by the inputs and outputs that act as receipts of a sort to track what the parameter actually did that can be used by Refund or even by a UI. These classes aren't quite one-to-one with the input/output classes but pretty close. They are shared by the same inputs and output types that manipulate the same type of data. So, while there are separate classes for using a Resource as an input vs using a Resource as an output, both classes can use the same receipt type. This becomes more important when the input or output relates to information that you can't easily rebuild just by looking at the static transaction data. For example, I already made an output type that can be used for spaceship construction.  The output type can't hold onto any sort of reference to it (since it's static/const). So the receipt type does that.

I also did a few of the issues from my technical debt backlog. Not many, but they a lot of small things that I can work on during the week without feeling to burdened by work or what needs to be going on at home.

August Sprint

More transactions, but this time I'll be working on the UI and actually executing the transactions. I'll need to make a few test transactions so that'll probably be super simple, 1:1 resource conversion options. I'll also add something really simple to allow completion of projects since I don't have an actual "passage of time" mechanic yet.

Games I'm Playing

Fate Grand Order as always. Picked up Fire Emblem: Three Houses and it is a blast. I'm a little worried that the narrative is a little too "on rails" with no way to delay the next story mission if you need to grind out some experience or money. It hasn't been a problem so far, but I've delayed story progression in previous ones, so we'll have to see.