Thomas Slade

The First World War Mod: Statecraft, Part II

The First World War Mod: Statecraft, Part II

Last post, I made a start on setting up a whole new region in the First World War mod: the Balkans. This area (which includes all of Austria-Hungary and the land down to the Adriatic) plays an important role in the mod’s content and theme, as it was the animosity between Austria and Serbia that actually sparked the Great War, as well as both Balkan Wars involving the emerging balkan states and Turkey that foreshadowed it. Terrain types ought to reflect the particular battles that went on here, and states must support a variety of potential territorial-exchanges that can be used in things like events or focus trees.

As mentioned previously, the method I use to build areas of the map goes like this:

  1. Define terrain, historic states, key cities/towns (we got here last time), and infrastructure.

  2. Outline provinces (these are the individual tiles that a unit can stand on in HoI. A state typically has about 20 of them).

  3. Run provinces through my province generation python tool to help fill them in with unique colors (this probably saves me about a week of work and some serious carpal tunnel). Use the same suite of python scripts to assign provinces to states.

  4. Cleanup.

Cities & Forts

As mentioned in Part I, victory points in HoI serve a very important role: they provide flavour to the map, letting the player have their own little ‘battles of Stalingrad’. Victory points also typically (but not always) have the ‘urban’ terrain type in the vanilla game.

For the First World War mod, I’ve decided to:

  • Have all victory points appear on the map with some sort of ‘urban’ terrain type (since my map generally has the fidelity to do this)

  • Introduce two new types of ‘urban’ terrain: rural, which is slightly less defensible than regular cityscapes, and fortified, which is even more defensible. Fortified tiles are quite rare, but represent the real hard-points of the war that resulted in lengthy sieges (Przemysl, Kut, Liege, Verdun …).

So, once a decent amount of VPs have been picked for all states, I naturally need to add them to the terrain map.

Fortresses.png

You might also notice that for particularly large cities, I add several provinces. I usually try and find a good source on the city’s historic layout (Mapire is a great source for this). The result is the potential for street-to-street fights over sprawling neighborhoods. Though more of a WWII thing, this sort of fighting wasn’t unheard of in WWI.

(Yellow = urban, grey = rural, blue = fortified)

(Yellow = urban, grey = rural, blue = fortified)

Roads & Railways

The last type of terrain that needs to be defined is roads and rails.

Both of these have been added to the mod to replicate the important role that transit links played in the Great War. On the Western Front, rail connections running parallel to the trenches were hugely valued, as they allowed the army controlling them to quickly relocate troops. Roads were also the typical avenue of assualt when approaching an enemy city (the Somme centred on the road from Albert to Bapaume). To try and simulate this value, roads provide increased troop movement speed and increased attack, while rails provide the same bonuses but moreso. I’m still not convinced that these additions contribute much to the game, though, and may remove them if playtests say otherwise.

Naturally, my starting point is railway network maps.

As always, historical research can be really useful in informing the lay of the land. I don’t have the space to add every railway and certainly not every road: the two are defined in an abstracted density, representing the most important transit links of the war. Often times, I demote what was historically a railway to a road, just to avoid having a map that’s 90% railway links.

Drawing roads on the terrain map is simple enough. Railways, however, require some special care. To achieve the look of an actual railway, I’ve created a terrain texture composed of hexagonally criss-crossing tracks. I then create a mask that follows these tracks at 30 degree angles, which ends up looking like a single railway when rendered in-game. This does, however, restrict where exactly my railways can run, and it’s not uncommon for me to have to move a river or a border slightly in order to accomodate a railway’s position.

The complete infrastructure terrain of the Balkans.

The complete infrastructure terrain of the Balkans.

Tile Drawing

With terrain, rivers, and states finally set up, I can begin drawing individual tiles. This process, even with the python automation I’ve set up, is still a very time-consuming one.

Province-drawing can mostly be a meditative, absent-minded sort of task. But it does take a little brain-power. What matters with a province is its adjacency to other provinces. If two plain tiles intersect a range of mountain tiles, it can be considered a mountain pass. If a railway junction leading to a town borders the road coming out of the town, then what is the point of capturing the town when an army can simply move straight into the neighboring road?

AdjacencyExample.png

I also have to worry about tile sizes, tile density, and ‘X-crossings’ (where four different provinces meet, which HoI IV’s pathfinding can’t handle).

The result is a back-and forth process where I draw my province borders, adjust a few rivers, and clean up terrain to better fit the tiles I’ve wound up with. A timelapse of the whole procedure can be seen below:

Wrinse and repeat for the ~200 states in the Balkans region.

Most modders would now need to fill in each province, taking care to avoid X-crossings or inconsistent river crossing as they go. But I can just use my province-fill python tool, with a quick consultation of my validation checker, and finally the state-assigner to automatically assign provinces (roughly 3,000 of them …) to states.

ThraceTiles.png

States are auto-generated with automatic, numeric names. Frankly, these are really hard to work with, and I decided at the start of this project to give my states actually legible names. While doing my research on balkans provinces, I took care to note state names on my draft map. So luckily this step is just a case of mindless copying-and-pasting.

One brief note on this: state names are all eventually localised. However, in games like HoI 4 we have an interesting conundrum on whether or not to display a state in its English exonym, its native name, or something else. It’s a neat little flavour-trick to display a state in the name of whatever country owns it, meaning that if the player reconquers Edirne as Greece, for example, they get the satisfaction of seeing it written as Adrianople instead. This issue is especially prevalant in the Balkans which, at this time in history more than ever, maybe, was in a state of ethnic flux. But my rules of thumb are as follows:

  • If a place name is extremely well-known in English, render it in English. This is mainly for capital cities: Vienna instead of Wien, for example.

  • Most other placenames use the name given by the country controlling that state at the game’s start (in 1911). There are numerous examples of this across Hungary, where German placenames had developed over the centuries (see Erlau, Pressburg, Kaschau above). If I want to show these in Hungarian or Slovakian later in the game, I can do so by setting up special rules in the localisation files.

Getting It To Actually Work

In ideal circumstances, we’d assign states to their starting countries and basically be done here. However, while attempting to finish off my work on the balkans, I came to the point where I needed to auto-generate terrain tiles from the terrain map, and auto-register coastal tiles, both of which can (in theory) be done through HoI IV’s built-in map editor tool, Nudge.

Nudge is notoriously unstable. I had, though, been able to safely use these tools in the past when setting up France and Germany, with only a dozen crashes. But at this point, Nudge decided it was no longer going to cooperate. I needed to assign the terrain (plains/forests/mountains) the type (sea/land/lake) and the coastal status (whether or not a tile sits on the edge of a sea/landmass) of some 3,000 provinces, and it looked as though I would need to do it by-hand, in the province text file.

Creating a python script to automate this process had been a long time coming, and much as I didn’t want to lose time to it (working with numpy and skimage is fun, but frequently confusing), it was definitely better than trying to interpret and edit eight-thousand lines of this:

Definitions.png

To automatically assign a province its terrain, type, and coastal status, we need the following information:

  • The pixels a province occupies. This is already defined by the province map.

  • The terrain types within that area. From this, we can decide if it’s land or not (the only ‘sea’ terrain is ocean). And once all land/sea statuses are set up, we can check who borders who to find coastal tiles.

This also gave me a great opportunity to add a feature for terrain weights. Nudge’s own automatic terrain assignment evidently picks the most frequent terrain within a province, and uses that as the province’s terrain type. So if a province has 80 mountain pixels and 20 road pixels beneath it, it’ll become a mountain province. This is a problem in my mod’s case, since roads and rails can be so narrow (simply for the sake of looking like roads and rails on the map): a tile intended as a railway tile can end up as a plains tile, because the railway doesn’t take up enough of its area. Adding a weight multiplier in my python script solves this issue very handily.

The debug output of my province definitions generation script, which solves the instability of Nudge and gets my map working in game. This output shows coastal status, with land provinces striped in brown, and coastal ones striped in yellow. Along w…

The debug output of my province definitions generation script, which solves the instability of Nudge and gets my map working in game. This output shows coastal status, with land provinces striped in brown, and coastal ones striped in yellow. Along with this map, the script spits out a new .csv file with the correctly formatted definitions, which I can copy and paste into my mod folder.

Results!

To my relief, fixing up my province definitions was the last step needed to restore functionality to my map (sometimes other stuff goes wrong …). Here’s the map in 1911:

And some glamour shots of the balkans post-balkanisation at various stages, namely:

  1. After the Ottomans lose the 1st Balkan War.

  2. After Bulgaria gets dogpiled in the 2nd Balkan War.

  3. The chaotic aftermath of 1918.

  4. The more familiar borders that had been established by 1936.

So, the balkans are in. This means two things: first, I have a playground that was historically very active early-game (with the Balkan wars taking place in 1913), giving me a good region to begin testing pre-trench combat, and second, two more of the key movers (arguably the most important agents in the war) are available to play: Austria-Hungary, and Serbia.

My next step in development is to begin building the focus trees for these two nations. These focus trees will be designed to break (or make) the peace in Europe by 1914, while also offering both countries alternate avenues of expansion or allignment.

Total War Unit Modding: The Other Three Kingdoms

Total War Unit Modding: The Other Three Kingdoms

The First World War Mod: Statecraft

The First World War Mod: Statecraft