Recap

For August I wanted to finish up with transactions, building a UI that could execute the system I built in July.

Results

Again I did okay. With a little tip from one of the UI engineers at work I was able to get my widgets working for a UI that can display and trigger a transaction. The part I didn't get to was the actual execution of the transaction to change the state of my game.

Here you can see the new button (on the left) I added for accessing the "Marketplace" and the UI element (on the right) I added to show the current resource counts available to the player.

Here's the screen for the Marketplace. I went for transactions that would create new ships instead of resource exchanges. You can even see the last transaction is a project that requires a duration to complete. The unreadable little box is the tool tip for the button to activate the transaction.

And the final screen has the debug text that I currently have showing up when the button is clicked. The name of the transaction is included in the string as "proof" that the all the relevant data is being routed to the right places for eventual activation.

I also addressed a couple technical debt issues:

• I removed a few direct dependencies between the system that deal with the tile location of the cursor, the system that tracks the current selection, the system that deals with targeting and the system that deals with the turn order. Instead those functions route through my custom event manager.
• Added some validation to my event manager events so that the manager can handle invalid events systemically and not pass those events on to the systems listening for those events.

New Design Spec

I also wanted to get out in front of a design problem that I know I'm going to have. I currently expect to have some limited number of spots per mission for ships to send on a mission, but I don't really want it to devolve to "take my X-biggest ships" every time. What I've more or less settled on is a two-fold system for limiting ship deployments. The first is a limiter based on ship sizes, I'm calling it "tonnage" for now. Each ship will have a tonnage ranking (based mostly on size) and the total for all the ships taken on the mission must be below the tonnage limit for the mission. Hopefully this will encourage including a few smaller ships on missions instead of just a couple big ships. There will probably be a few ways to upgrade this limit, but they will be very few and it will vary primarily on the mission type/location. The second limiter would be a more traditional unit count limit. This limiter is meant to represent command and control systems and the effectiveness of actually controlling lots of ships. This limit will be more constant, usually the same for most missions, but will have ways to upgrade it globally or even based on the equipment of the ships taken on the mission.

I'll keep thinking about it for a while, I've got a couple more parts to add to tactical before I start working on an implementation.

I'm happy to hear any thoughts or comments that might make this better.

September Goals

The next step is finishing up the wiring of the UI to my other systems so that pressing the buttons actually does something (other than printing to the screen). I'll also need a new UI element that shows the active projects created through a transaction screen.

I'll also continue to address small tasks from my technical debt list.

Games I'm Playing

Picked up the new Fire Emblem at the end of July and have spent a good chunk of time playing (the save says ~120hrs ). Finished one of the 4 story lines (Blue Lions) and have started up my second playthrough (Golden Deer this time). Should be faster, they've got an interesting NewGame+ system that lets you pull progress from previous playthroughs. It's a pretty good game and I highly recommend it. My only real complaints are the class system can be a little bit unbalanced and the way they've shifted the weapon triangle into skills feels really off.