Dev Diary 13 – Front Lines

We’re in that happy place where you put together a bunch of existing, but previously disconnected pieces and they all start working together seamlessly.

We have a front line now. Graphically, this is nothing new, as the front line renders in much the same way as the movement boundary. However, previously, we did not know where the front line was, as we were still working on the game state. So it took us maybe two hours between realization that hey, we can now add this, and seeing it live in the game. I could get used to days like that…

We’ve improved on hills, which were the least readable type of terrain in UoC, and not much better in the new game either. The new version is a big improvement but I’d still bet this is not the last we hear of hills. We’ve also added rail, as the new game makes a distinction between rail, and paved and unpaved roads. Rail is always touchy graphically, as sleepers create an aliasing effect when zoomed out. I think we’re doing a good job but feel free to weigh in.

Meanwhile in the Gulag

Just so you don’t think developer life is all awesome, all the time, here is some other stuff that’s been on our plate lately. We made sure that all apps (game, scenario, and map editor) setup and teardown cleanly, and that we have no texture or buffer leaks.

I did the same check for leaks in the 2D Renderer, which turned out to be leak-free (yay!). Aaand, while doing 2D, I managed to spend an entire day tracking one truly shifty bug related to UI animation (“tweening”). On reflection, that one sprung into existence with the sole purpose of ruining my day, can’t be anything else.

Ante did a bunch of work improving the code that assigns hex types based on what objects are on the map. The map editor is freeform – it lets you put objects wherever you like on the map. It then works out the terrain type by itself with the logic of: if there are trees in a hex, it must be a forest. However, if the placement of objects is ambiguous, it will flag the hex for your attention.

Campaign and HQs

While we’re working on the code, design work continues with Daniel. I haven’t given any updates on this lately so here you go.

Headquarters are made persistent in the campaign. This is a twist on the typical core units mechanic, which is perhaps too gamey for our tastes. Here, each HQ owns its subordinate units (in the campaign sense). When there are changes in the OOB, or units get wiped out, this is generally soaked up by the HQ force pool. There is some micromanagement, but we’re doing our best to not have you manage 50 or 100 divisions individually.

We also allow you to upgrade HQ abilities over the course of the campaign. If you go back to Developer Diary 4, it explains how HQs perform actions like Emergency Supply or Set Piece Attack. Each action costs some number of Command Points to perform. You are able upgrade both: the overall number of CPs or boost individual abilities.

The basic currency for upgrades is Earned XP. This models the training aspect of an HQ, and strongly rewards leveling-up of green and regular units. There is a genuine trade-off here: you have to expose your regulars to action (to earn xp), but at the same time they shouldn’t take too many losses.

The upgrade paths are different for each faction and should give them strong historical flavor. With all that said, keep in mind that HQs are clearly a secondary mechanic. For example, a typical HQ can reorg 5 steps per turn (same as in UoC1), or it can perform 1-2 actions like Emergency Supply. The main focus is still on maneuvering your forces, and the HQ is there to give you these secondary abilities in a neat, abstracted way.

Soldiering on!