Progress Update: Save/Load, Unit Leaders, Titles

Just a quick update to celebrate that I’ve finished the new Load/Save code and gone through a few rounds of testing and bug fixing. I know this possibly seems like a weird thing – every game has Load/Save, how can this be such a big deal? Well, it is, because writing Load/Save code which is fast, robust and maintainable is a pain. A lot of developers sacrifice performance and flexibility in order to use 3rd party libraries and save time. I have taken no shortcuts and loading a game, including the randomly generated world takes a few seconds. I’m very happy with this, as I really hate long loading screens, and want to do my utmost to make launching the game as fast as possible. I’ll make a short video showing this during the coming week, which will hopefully make up for the sin of this being yet another “all-text” progress update.

On other fronts, I’ve added unit commanders, with names and titles relevant to the culture/unit type. These are mostly for flavor at the moment – they can interact with various event chains, but you cannot send them on missions like other followers. Their stats will become relevant to more than story events when I finalize the new battle system, and at that point I will also add functionality to promote or replace them (since it might really annoying to have a craven lunatic leading your elite cavalry.

This also gave me a chance to spend some time improving the title generation code. Military, religious and noble titles are generated with language and culture taken into account, and the range of possible titles has been increased.

The next thing I will be working on is finalizing the latest iteration of the dungeon mechanics, which incidentally is the theme of the next design diary. I am somewhat delayed with regards to that post, mostly due to time spent on save/load, but hopefully the video will make up for the wait.

Progress Update (… and a bit of rambling)

As an interlude while working towards the last of three design diaries, here’s a short progress update on the general development situation. I am currently focusing on two areas: save game functionality and expanded dungeon mechanics (incidentally the subject of the upcoming design diary). Why two things at once, as a single developer, working in his spare time? Isn’t that counterproductive. In general, yes. But some parts of development are just plain boring, and it’s healthy for motivation to break the monotony with work on more interesting parts of the game.

(TL;DR at the end – rambling has begun)

Save game functionality, as regular readers may remember, is one of the areas I find pretty boring. It was present and functional at one point, quite some time ago, but I wasn’t happy with the technical design as it was brittle and heavy to maintain. One thing I’ve often been asked as a programmer (or heard asked of colleagues) is “Why don’t you just do it right the first time?”.

It’s an interesting question and there are many valid answers, all of which can help understand the rather arcane nature software development. One of them is that as programmers, when working on new software, we’re in many ways closer to the realms of biology and chemistry than to the realms of mechanical engineers and physicists. We have some materials, a very good understanding of what they do, a world of examples and prior work, but still we are dealing with complex and unpredictable system, the viability of which are not really known until quite late in the process.

Making the save game system is like creating a medicine for an artifically engineered life form. I’ve made medications before. I’ve engineered life forms. So I know what definitely doesn’t work, and I have a host of different approaches, that I know can be made useful. Unfortunately Wizards and Warlords isn’t a completely finished being yet. The DNA is in place and so is the basic physiology. But the details are still being worked out, and that requires constant modifications to the save game “medicine”.

It turned out the basic design was not optimal and was requiring a lot of extra work to maintain, so I decided to shelve it and return to it later. This saved me the maintenance work, and also let me rework some of the parts of the engine which were troublesome in relation to save games.

Later is now, as the lack of save game functionality is impeding testing and also making the game difficult to enjoy as a real game. But the good part is that I’ve become very familiar with the biology of the game, and can use the lessons learned from my early save game code to make a much better system, with less overhead and more robustness. I am probably close to halfway done, which since I am a programmer, and thus chronically optimistic about my own progress, means I have done about a quarter of the needed work.

That was an awful lot of rambling and perhaps not as good an analogy as I initially thought it would be. So here is the TL;DR I referred to above:

TL;DR:

• Working on Save Game functionality, which is one of my goalposts for reaching Beta
• Working on expanded dungeon mechanics
• After Save Game drudgery is done: Custom wizards, more tool tips, focus on early game mechanics and balance, SUPER SECRET BATTLE SYSTEM VERSION 1, improved follower skill system.

The Wizard’s Workshop: Golems and Constructs

As a wizard there are many ways to wage war. But even with a vast array of powerful spells at her disposal and a host of powerful heroes to send on epic quests or missions of diplomacy and espionage, there is almost invariably a need for the raw might of an army.

The armies of a wizard can mirror those of a warlord: regiments of mortal soldiers and mercenaries, their loyalty secured through gold, respect, fear or arcane enthrallment. Many wizards supplement these forces with monstrous, fantastic or extra-planar creatures summoned or bound to servitude. In broad terms such units are covered by the mechanics of recruitment, binding and summoning. 

There is a fourth method of raising troops: constructs. This category covers golems and certain undead monstrosities. It could be mindless clay giants controlled through sheer willpower and elemental mastery, wooden soldiers given primitive life with fay magic, necromantic flesh golems imbued with restless spirits of great warriors, or ironclad constructs made possible through the marriage of steam power and runic magic.

In the game the way this mechanic works is that when playing as a wizard, through research, one can unlock the ability to customize construct units. Depending on the mastery and research of the wizard, various base types of constructs are available.  After choosing a base type, the player chooses from a variety of other parameters, including shape (humanoid, beast, etc.), power source and armament. These choices determine the stats and abilities of the resulting unit, and of course, the cost to create and maintain it. This functionality is implemented in the alpha as of now. Here is a screenshot of the current UI:

With these fundamentals in place, I am now adding a few extra steps – primarily to impose some limits for balance reasons, and to create some interesting game play. This is not deterministic and predictable technology, but the creation of magic constructs, and the mechanics need to reflect this.

The first step is that after a golem type is designed, the wizard needs to create the final schematics for mass production. This will require a certain amount of research effort, time and resources, and will result in the design becoming available, with a small chance of getting a “critical success”-type event and a relevant bonus. Failure is a possibility in a few cases – but will mostly be relevant when utilizing new material or power sources for the first time, and will in most cases be relatively harmless and merely require some additional investment of time and resources.

It’s generally not fun to have something like designing a new unit fail and waste resources, so this needs to be balanced carefully. The player shouldn’t feel unduly punished for playing the game, but on the hand there is the opportunity for some very memorable events. E.g. golems with a spark of sentience, who suddenly start to assert independence. Another possibility could be golems powered by souls or spirits, and these unexpectedly retaining or regaining memories and/or free will, with unpredictable results. But it’s silly and annoying if advanced golems always end up rebelling, so these events have to be relatively uncommon.

The second step is that in order to actually produce golems, a relevant facility needs to be present. Simple constructs can be created in a wizard tower without any upgrades, but more advanced golems will require workers to be assigned and/or specific upgrades to be present. Some cultures have mastery of golem construction as a trait – their cities can have a golem workshop built at a much lower cost.

These expanded mechanics also open up the possibility of golem schematics and workshops as a reward from exploration or events – and as a target of espionage and sabotage.

Rivers and Roads

The latest feature I have been working on is rivers, and roads are following in short order, so I thought I’d do a write-up on the design decisions involved. Please note the map graphics are still placeholders and not the final assets – especially the province borders, rivers and (non-existent) coastlines. For example, the final river graphics will make the stream direction more obvious.

I am really happy to finally have rivers in the game. Almost every fantasy world has a couple of rivers of geopolitical and historical significance, e.g. the Brandywine and Isen of Middle Earth, River Reik in the Old World of Warhammer, and the Trident of Westeros. In our world, the ancient civilizations and empires arose on the banks of  the Nile, Euphrates, Tigris, Indus, the Rhine, the Seine, the Danube, the Volga, etc.

Rivers have a dual nature, forming a natural barrier useful to a defending army or as the site of a castle, but also providing a travel route for invaders and merchants. These aspects make good mechanics in a strategy game and help create an interesting world for the player to explore.

In Wizards and Warlords, the world is generated randomly. The first step of this process is creating a height map – a topographical map of the world. This divides the world into oceans, lowlands and hilly/mountainous highlands. Climate bands and the roll of the dice then distributes biomes throughout the world, resulting in forests, swamps, plains, jungles, deserts, tundra, etc. After this comes special natural resources and the more fantastical element. Finally the races, cultures, organizations and religions/pantheons are created.

The newly added generation of rivers is done after the topography is created, but before biomes and terrain are assigned. Rivers flow from mountains and hills, following the slope of the land, probably snaking through a continent before reaching the sea. The very first design decision I had to make was whether rivers should be placed ON tiles or BETWEEN tiles.

All tile-based strategy games have to make this choice, and there are advantages and disadvantages to both. Having rivers on tiles makes it easier to have cities and castles centered on them, and it is conducive to movement. The disadvantage is that it makes crossing the river a strange thing. Does it happen when entering a tile? When leaving it? Should the penalty be postponed and applied depending on how movement continues out of the tile, etc. And how if the tile has roads, it can really strange as the roads often up “overlaid” on the river in an odd way. Here is a mock-up of how this river implementation could look:

I ended up using the other approach, where rivers are located between tiles. This makes it very straightforward and intuitive to determine when the river is being crossed. The downside is that it becomes less obvious when a city located in an adjacent tile is actually located on the river. This will be solved by making the border of tiles a valid location for sites. This also makes great sense for coastal cities, border forts, castles guarding a mountain pass, etc. Here is a screenshot of a river in this style:

When generating rivers, something that occasionally will happen is that the river ends up flowing into a valley or basin, so it cannot continue towards the sea. It looked rather silly to just have a river abruptly end, and having rivers flow upwards is even more strange, even if this is a fantasy game. So I modified the world generator to create a lake in this scenario. Sometimes the lake will have end up taking up enough space to be adjacent to a downward slope, and be able to have a connecting river continue towards the sea. Like this:

I am still working on roads, but they will be inside the hexes, as the rivers in the first screenshot. This also means that a road crossing a river will have a bridge or ford – an interesting geopolitical objective and a great site for dramatic battles. As the final art assets are added, these will of course be represented by actual images of bridges, natural fords, etc.

Rivers are taken into consideration by the world generator when creating the terrain – swamps, jungles and forests are more commonly found near rivers than deserts and wastelands. Magma fields will tend to give way to basalt plains if they adjoin a river. I would like to add more fantastical waterways – rivers of lava, blood or acid, but that’s for the feature backlog while more essential game play elements are expanded upon.

The toponomy system will also be expanded to name the rivers and lakes – as it currently does with provinces, nations and mountain ranges.

While the current graphics are quite raw, I hope that the addition of a few screenshots to this design diary helped convey the concepts, and give an idea of what the final result will look like.

The next blog post will be focused on magical constructs – such as golems and undead monstrosities, and how the player can customize these units depending on what arcane secrets have been unlocked by the wizard.