Welcome back! So my June "sprint" (I guess that's what we'll call these) went pretty well goal wise. I may have under-shot for the month, but it's tough when you can't be exactly sure how much time you will have devote to your project.

Recap

My main goals for June were to be able to select ships to take into combat and to be able to select the weapons that a ship had equipped/installed. A stretch goal was to get rolling on a back end that could support crafting, building and other similar resource transactions.

Results

UI Goals

I was able to accomplish my main goals and worked on a couple UI screens that allow doing those selections and causing game state changes that propagate into tactical and back to strategy.

Here you can see just the basic strategy layer screen (which isn't really that impressive with only a couple buttons).

Here you can see the starship loadout screen where you can select different ships and then choose the weapons in each slot. The ideal goal would be something more like the paper doll kind of UI's in more traditional RPG's, but that's probably a ways off.

Here's the starship selection screen with some ships selected. Once all the spots are filled, the Deploy button becomes enabled which will load into the tactical map.

Overall I'm happy with the way these turned out for now. I did run into one annoying bit with UE4 UI. I posted about it here, but didn't really get any traction. The fundamental issue was that I made a new widget type for those drop downs (basically a version of UE4's combo box, but that can store some user data along with each entry). Now, UE4 has two fundamental basis for UI elements Widget and UserWidget. The problem I was having is that I wanted my new type to work in ways that neither base is allowed to completely work on it's own. Widgets are self-contained (contain no sub-Widgets1) and are placeable from the UI Designer. However Widgets cannot be created and added to a UI dynamically, for that you need a UserWidget. Since my version of a drop down started out as basically a copy of the UE4 combo box, it was a widget. Once I encountered the limitation on dynamic creation, I figured what the heck and changed mine to derive from UserWidget instead. With that I was able to do the fleet selection UI and was happy. Later I ran into a problem that when building the loadout UI because I wanted to place my drop down directly in the Designer and it turned out I couldn't place one for some reason. I really thought I was going to have to do some crazy and annoying things to make everything work the way I wanted (which I lay out in my help post I link to), but while talking through the problem with a guy at work I realized that I was able to place other UserWidgets through the designer and it turns out that while native UserWidgets can't be place in the Designer, blueprint ones can. So I left my drop down a UserWidget and created a blueprint of the class that acts only as a way to interact with the designer. Another outcome of that talk was that I probably shouldn't have even bothered with my drop down and instead used one of the other built in UI widgets, the List View. I looked into it a little bit and it does look like it might be a better solution but for now I've just added a note in my project's backlog (ie a text document).

Other Goals

I got started on the whole transaction back end by creating definition types and test data for resources that will be used as the main kind of inputs to the system, but that's about as far as I got.

Unplanned Accomplishments

I was able to finish the UI changes about halfway through the month so I ended up letting myself get a little distracted by some other things.

1. While working up the resource definitions, I wanted them to show up better in the UE4 Content Browser and since we've done it at work I knew it wasn't a big deal. The piece that was missing was that none of my plugins had been setup yet to support an editor module. UE4 has a pretty robust runtime linking system for separating libraries from each other as well as separating parts of libraries that should only be loaded certain kinds of builds (like things that can only be loaded when there's an editor running).
2. I've been running on 4.19 for a while so I upgraded to 4.22. Since I'm using a source build this took a bit to rebuild the engine plugins, but it's not a big deal. In theory I could probably even switch back to a precompiled engine version since the one engine change I've made I didn't even port from my 4.19 depot to my 4.22 depot. It's a change that's been obsoleted by a system change that I made improving how I handle my custom event data passing. For now though it's nice knowing it's there even if only for reference.
3. Turns out 4.22 can't be run on Visual Studio 2015, so I also need to update my copy of Visual Studio Community. I went ahead and just jumped right up to 2019.
4. I haven't been as good as I want to be with commenting. I'm pretty good about writing implementations that are pretty small and self documenting, but I find it helps to have more comments in headers for member and method declarations. So I opened up all my source files and improved the commenting in most of them2, a lot were actually pretty good and didn't require anything new. This also gave me a chance to step back and look at some of the code more holistically and reconsider implementations that may have made sense at the time but might no longer be ideal given other support systems and structures that have been written in the meantime. Things like when my custom event handler could be a better option than the UE4 delegates. A couple of things I just cleaned up right then but mostly I added a lot of things to my backlog as technical debt work looking at fixing. Most of them are small items that will be good if I have a short time available to spend, but none of them actively inhibit my ability to move forward on any gameplay feature.

July Sprint

This month is going to be tricky. A four day weekend, two weekends of trips with my girlfriend, one weekend of a my girlfriend ditching me for her own trip, some house guests and other general summertime activities. Generally I plan to pick back up on the transaction/recipe system. I expect I should be able to finish the gamplay part but may not finish with the UI. I will also probably address a couple (or a few) of the technical debt items that I found, but I'm going to do my best to not let that list distract me too much.

Games I'm Playing

Really just Fate Grand Order this month. I may have played a mission from Fire Emblem. I'm really looking forward to the new Fire Emblem coming out on Switch at the end of the month and it comes out just in time that I might have a chance to play it on a road trip that weekend.

Footnotes

1. Wigets here refer only to the UWidgets class. Unreal also has another set of UI widget types for Slate. Usually a UWidget is implemented as some collection of Slate Widgets. However my point here is that a UWidget does not contain other UWidgets, that's the purpose of UserWidget. At least as far as I have been led to understand.
2. Besides the main SRPG project, I've got two plugins StrategyTech (stuff I could make another strategy game with) and CoreTech (stuff I could use for making any sort of game). SRPG currently has 141 source files and 80 asset files (blueprints and textures), StrategyTech has 162 and CoreTech has 18 files. That feels like a lot, but they're all pretty small. I was also going to give some other stats, but in Visual Studio I can't find any built in analytics for C++. Let me know if you have any recommendations (they don't have to be Visual Studio integrated ones).