Overall a pretty good month. Although I was hoping to be a little more productive, I got what I was hoping to accomplish completed so there's that.

Recap

My goals for September were:

• An implementation for the Ship configuration UI
• Support for dialog boxes
• Refactor of the project queue

And two secondary things going on were the arrival of a new laptop and a week long vacation from work.

Results

Ship Configuration

Here's the basic setup of the UI. It's not too different that the image that I showed last month except that the list of Equipment Options has been populated. The only other minor difference is that the ‘Confirm Refit’ button is disabled (because no changes to the ship have been made).

Here you can see the information panels being filled in based on mouse hovering. When the mouse stops hovering, the panels revert to their empty states.

Next is a sort of “lock” state for each side of the UI. It doesn't change the hover functionality (the panels still update based on what the mouse is over) but when the mouse unhovers the panels revert to the locked option instead of empty. Only one slot can be locked at a time so if a ship slot is locked (as in the left image) and another slot is clicked, that slot becomes the new locked slot. Ditto with the equipment options, as they're clicked on that one becomes the new locked option. Clicking on the currently locked slot or option unlocks it and when unhovered the associated panels revert to empty again.

The other restriction is that only a slot or an option are locked at a time. If one of them is locked and something is clicked from the other group, the equipment option that is locked/was clicked is assigned to the ship slot that was clicked/is locked. The panels for the ship slot are then updated to match the new equipment that is in that slot.

The ‘Confirm Refit’ button has also now become enabled because the configuration in the UI is now different than the actual state of the ship.

A couple of tasks that I've left for my future self are drag ‘n drop and extending the text in the info panels with more information like possible damage and actual ranges (at least in cases where the ranges aren't correctly showed by the firing arc widget). Eventually I'll also need to show which slots an option may or may not be able to be placed, like say the wingtips of a Klingon Bird-of-Prey. You can't put a missile weapon there, only beam-like energy weapons. But those sorts of restrictions don't even have a gameplay implementation so there's not a whole lot the UI can do about it for now (other than support a good/bad highlight state that is currently unused).

I also cleaned up my code base by removing all the code and asset that was related to the old ship configuration UI.

Dialog Boxes

They look terrible but they're functional. Here you can see the dialog box that I hooked into Starship Configuration if you've made changes to the ship and press ‘Cancel’. I've also got one if you use the drop-down to select a different ship and there are unsaved changes to the ship. I'm still getting the hang of building UE4 UI's and wasn't able to get the sizing to work out quite the way I wanted it to. That line break between ‘been’ and ‘changed’ shouldn't be there. I messed around with it some, but didn't want to waste too much time with it right now. Same with the buttons, they don't quite size the way that I want them to based on both the size of the text and the size of the dialog box as a whole.

The example here is the 2-Option dialog. I also made a 1-Option dialog and a Multi-Option (for everything above 2). It may seem like a weird way of going but it allows for more readable blueprint nodes. That was the other half of this task which was that I'd need a blueprint node that could open them up and modify the flow based on the selection. I was able to duplicate the functionality that I used for the visualization tech to create a latent node that had execution pins for each of the buttons of the dialog. This is why the dialogs are built the way they are 1, 2, Multi: because the output pins are based on variables in the blueprint so it's not convenient to make those dynamically. The Multi option has an array to input all the button names and a single additional exec pin, but that output also includes an index to identify the button. That's not very convenient for the common cases of 1 and 2 buttons, hence the specializations. Not all my dialogs are likely to be so generic. I expect there will be ones where all the text is baked directly into the blueprint class and there's little to no direct customization of the text from the blueprint node.

Queue Refactor

Finally, the refactor went fine. It's usually pretty easy to pull existing code out of one class and turn it into it's own. I added a new category type for Projects which for now is just the things that are assigned to the Shipyard. At game start I automatically create a Project Queue for each of the categories that has been defined and the projects know how to add themselves to the right project. For now this all assumes that the human is the only player that interact with these queues, but that's probably a fine assumption for now. I also left myself a backlog task to add support for multiple elements running at the same time within one queue. Like the top X elements or something. I'd like the player to gain access to more construction slips over the course of the game so each slip would allow for another project to be running in parallel with the projects in the other slips.

New Laptop

Things went pretty smoothly with my new laptop. I got an Alienware rig from Dell, that I already have noticed a big difference in iteration times. The only (sort of) downside was that it came early! And even that wasn't really the problem. The problem was the shipping info being inaccurate. For a couple days the tracking data claimed it would arrive that day, then there were a couple days of errors with the data, then it showed up. So I spent a few days not really wanting to start anything new on the old laptop. Then there was a few days where the work was installs, setups and copies from one machine to the other. Again either the computers were busy or only one was busy but still in a way that made me hesitant to start anything.

Vacation

I'm “back in the office” starting tomorrow. It was a good break, though I didn't work on my project as much as I thought I would. I mostly detoxed from caffeine, I think I slept through most of Monday and Tuesday! I'm looking forward to getting back to work though both on the professional as well as hobby projects.

October '20 Goals

• Calendar Refactor
  • The projects queue refactor really got me thinking and there another aspect of the code I pulled the queue out of which is time tracking. There's a game clock that is currently being tracked by a player specific data structure. It's not really a problem now, but eventually I'd like for it to do more and that would be easier/better if it was tied into that player data. This should be a really easy change.
• Tech-Tree
  • Back in my November/December update I talked a little bit about research and a tech tree. I think it's time to start working on that. I never really did get anything written down, but I did have a good talk back then with a couple of the designers that I work with about the jumble of thoughts that I had. More recently a Civ 6 update included an option for a randomized tech-tree which I haven't had a chance to play much of but has also been a bit of food for thought in that area.
• A new event registration node
  • A bit of systems-y task. I have a custom blueprint node for registering with my custom event handler. It works great, the only real problem is that it requires a bit of setup to place the node and make a handler for it. It's not so bad in native, but it's a little much for blueprint. It would be really nice if there were a way to do something just a little more automatic that looked like the regular event nodes you can place in the event graph. If you scroll back up to the image I include of the blueprint graph for the dialog box, it's that red box all the way to left titled “On Clicked (CancelButton)”. If I could just place something that looks like one of those it would make it a lot smoother. Of course the current method would still be available, this would only be useful for event registration that matched the lifetime of the listener. If the listener wanted to start and stop, it would have to use the nodes I already have available.
  • I'm already suspecting that an engine tweak or two or three may be required. I don't want to have to introduce a base type or even an interface that has to be derived from. It'd be nice if there was an engine hook or delegate for “new object has been constructed” but I doubt there is such a thing. So this will be a bit of an experiment. If anyone else with UE4 experience is out there and has any ideas I'd be interested to hear them.