This is the 4th DevBlog in a series where we discuss the work currently being done in developing a new game in the Grand Tactician -series. The new game and the conflict it covers has not yet been announced – but the work is progressing nicely and we’re getting closer to dropping some more specific details… when we feel ready to do so.

Stages of Close Combat

In the new combat model we’ve been working on, the biggest and most visible change is in how close combat (non-ranged engagement, ie. charge and melee) works. This was a critical factor in combat and tactics before the introduction of rapid-firing weapons, even if prolonged melees became rare much earlier.

In GT1 (The Civil War) we have a rather rudimentary close combat model, focusing on melee: a unit charges another unit, when the units overlap a melee ensues. Casualties are inflicted on the fighting units, taking into account a lot of unit level factors such as unit type, training, cohesion, fatigue, used weapons, formations, number of men engaged in the melee… This continues until one unit falls back or routs.

The new close combat system is built to accommodate basically any conflict between the 17-19th Centuries, not only one specific like in case of GT1. In this new system, we have broken close combat down into multiple layers that can be described as sort of “stages”, though they are not linear or exclude one another at any specific time – it’s just easier to break the system down this way when describing it.

A unit can end up in close combat when charging an enemy unit, being charged by an enemy unit, or when opposing units overlap one another for any reason during a battlefield movement. In the last mentioned situation the nature of the close combat is unplanned, so neither unit is intentionally engaging into melee, and no charging takes place. So, let’s focus on situations where one (or both) of the units in question deliberately engage into close combat.

The Charge and Impact

Depending on the unit and tactics employed, charging can happen in different formations and speed. A cavalry unit, for example, could charge in a linear or columnar formation, or in any specific charge formations such as wedge, and usually on the trot or gallop. An infantry charge may happen even with standard marching pace. A charging unit may try to maintain solid formation or “break into a charge” more individually (“Hollywood style”). What is most interesting to us from this is the speed of the unit and the disposition of the soldiers within the unit (formation and its integrity).

The unit being charged may or may not be prepared to receive a charge. If we ignore fieldworks and use of terrain, the most important counter against a charge is cohesion of formation and the weapons employed. A dense hedgehog of lowered pikes or a wall of bayonets of infantry in a square formation could be sufficient to discourage a cavalry unit from charging home, and have it veer off instead, maybe discharging its firearms in anger at close distance. A controlled volley fired at a charging unit from a close range could break the formation of the charging unit and either blunt the charge or have the unit abort and disengage altogether. The unit being charged may also falter and decide to fall back in the face of the charge before properly engaged. With the use of our updated morale and cohesion systems, we can now simulate these outcomes which were much more common that prolonged melees throughout the 17-19th Centuries.

Image – Outcomes of a charge: A) the charging unit “flinches” and does not press home. B) the charged unit “flinches” and disengages before impact. C) Charging unit pressing home the charge and the charged unit standing its ground, resulting in an impact.

Let’s assume now, that the charging unit is dedicated and able to charge home and the target unit does not falter. What happens next is an impact, where the charging unit (could be both units) violently collides with its target in a certain formation and carrying a certain speed – let’s call the latter an “impact speed”. First off, who shall hit whom first? The weapon used is important in the soldier-level combat model. Both the attacking and defending soldiers could be armed with weapons that can outreach their opponent. A cavalryman with a 4 meter lance would outreach a musket with a bayonet, but on the other hand could be hit first if facing a soldier with a 5 meter pike. Also important is the penetration capability of the used weapon and the armour of the soldier being hit with that weapon.

Maintaining cohesion a unit receiving a charge could blunt the charge. The impact speed carried could be drained (by loss of intergrity of the formation) and the impetus lost, as the full weight of the unit does not crash into the ranks of the other unit intact. On the other hand, if the charging unit has longer weapons (such as lance for cavalry) and can maintain its impact speed, the end result could be very bad on the receiving end, with the first line being decimated by the lances (for example) and the subsequent ones receiving the weight of the mass of horses still in full speed. Let’s call this phenomenon “ranged melee”. If both sides are armed identically, any benefit of reach is naturally lost. If the unit receiving the charge has no proper counter against it, the formation could suffer severely in the form of casualties and loss of integrity as soldiers are pushed off their position. In the end the charging unit could either mow down, penetrate and completely shatter the target unit with the carried weight and impact speed, or the impetus is lost and either the charging unit is repelled or a melee ensues.

Image – Ranged melee logic: A) charging unit has longer weapons and the defending formation is broken upon impact. B) the defending unit is ready to receive the charge and has longer weapons, the charge is blunted. C) identical armament offers neither unit initial advantage.

The Melee

As described, a lot could already have happened before we find the men of our opposing units fighting it out eye-to-eye, dealing blows with any dedicated melee weapons, be it swords, bayonets or rifle butts. It’s very likely that at this point either (or both) unit(s) could already be about to disengage. As said, prolonged melees were not common. Even if the opposing soldiers would remain determined and the units intact, which should be rare, melee is tiring and messy business, and the party finding itself overpowered would try to disengage orderly to prevent a disaster.

In this case we have our soldiers fighting a “close melee” (as opposed to the previously mentioned “ranged melee”). Weapon, armour, training, morale and fatigue are important factors, but so is the cohesion and type of the formation: if the formation is shattered or spacing loose, a single soldier could be facing multiple enemies at once. Also there is the weight of the enemy formation.

In close melee, single soldiers could end up being pushed by the enemy. This will have the formation bend, while still being able to hold its ground. If the pressure gets too much, the whole unit could be pushed back, which may end up a larger battle line being bent. The depth and cohesion of formations is important, a columnar unit can concentrate its strength on a narrow front better than a linear one.

Usually, if the pressure can be maintained with determination, the line being pushed will eventually give in and break. This can be controlled, with the unit being able to reform further back, or uncontrolled, which usually results in rout.

Image – Close melee logic: A) Charging unit breaking into formation of the defending unit that stands it ground. B) Attacking unit pushing defending units, creating a bulge in the defender’s line. C) One unit is unable to withstand the pressure, formation is broken and the unit routed.

The Counter-charge and the Pursuit

When the melee ends with one side breaking (it could also end up with both sides disengaging due to exhaustion), the successful party should exploit the situation. This way the end result could be a complete defeat of a larger enemy force, a domino effect that would win the battle before it grinds to a battle of attrition ruining both armies and resulting in a pyrrhic victory in best case.

A defending unit may utilize tactics (stance) called Countercharge. When doing so, the unit will stand fast in order to repel any enemy attack and once the enemy disengages in disarray, it will immediately charge home in turn to wreak maximum havoc on the now disorganized and demoralized enemy, before disengaging in turn to regroup and to hold the line. If the attacking unit is successful, it may pursue the routing enemy unit in order to cause maximum casualties and to force the unit to surrender.

In either case, the winning unit should be in sufficient condition to exploit – an exhausted or scattered unit will not be able to pursue. A pursuing unit may become hard or impossible to control, so having fresh reserves at hand can be crucial in order to turn a tactical level success into a victory in battle. And this is of course the Art of War for the Grand Tactician – You!

Most Respy,
Gen’l. Ilja Varha
Lead Designer – Grand Engineer Corps

In this third dev diary of the upcoming Grand Tactician sequel, as well as the next ones, I’ll discuss the main changes made in the game’s combat systems. In short, this will bring a lot of further detail in the way battles play out, while also providing opportunities for multiple interesting historical settings in the GT-series.

Unit and Soldier Levels

Like already mentioned in a previous dev diary entry, with the new unit system, we were able to move much of combat calculation to single soldier level. This includes both ranged engagement and melee combat.

In GT1 (The Civil War) combat system, combat resolution takes place mostly on unit level. In ranged combat, the possibility of engaging an enemy unit is checked on unit level, taking into account terrain and own units (to avoid blue-on-blue, ie, friendly fire). If this check returns positive, a volley is calculated, using a complex formula (taking into account everything from terrain, formation, cover, weapons, morale, training, experience, etc.). The volley is calculated from soldier models, each aiming at a target unit in its possible firing arc. This allows the unit to fire at multiple enemy units at the same time. A number of casualties is calculated for the target unit(s), and the visual layer shows the casualties in the nearest “coy platforms” (the unit is broken down to multiple smaller blocks, as per previous blog).

Melee in GT1 uses a very simple model – hand-to-hand combat during the Civil War was rare. In this model, the unit engaging in melee will place itself next to the target unit, slightly overlapping, to visually communicate to the player there a melee is ongoing. The actual combat resolution takes into account unit conditions and stats, and from this, casualties are inflicted on both sides. The abstraction takes into account formation, so formation A is 10% more effective in melee than formation B, which, on the other hand, may suffer further casualties from small-arms fire. Once one unit’s morale falters, it will fall back or rout, while the winning unit will continue combat according to orders.

The resulting model is quite good and believable, especially if the values in the formulas are well balanced, but it still lacks detail. In ranged engagement a part of a unit will not be able to fire if the unit level check for line of sight fails, and units can only engage enemies in their front sector (except in infantry square formation, where four front sectors are calculated). Melee on the other hand is much more heavily abstracted.

Organic Combat from Soldier Level

In the rebuilt combat model, unit level is still a factor. Calculating everything on a single soldier level would be too much in terms of performance. Things like morale, cohesion, fatigue, cover, concealment, line of sight calculation (for fog of war, i.e. are units spotted or not), movement in terrain, are tracked per unit. These values are then passed on to the single soldier level for the actual combat and casualty calculation.

So, when a soldier fires his weapon, the hit probability is modified with unit-level values. Is the soldier tired? Is he well-trained in the use of his weapon? Is he familiar with the stress of combat, fighting in close order with other guns blazing right next to his ear and enemy firing back? Is he blinded by smoke? On the soldier level, does this soldier see an enemy in his dedicated sector? Does the weapon he carries reach that far (a single unit can have different weapons, so some may fire while others may not)? Can he fire at will, or is firing controlled per rank, for example? Are there friendly soldiers in the way? When pulling the trigger, all this is taken into account, plus also external effects like weather: will the weapon misfire? When the weapon fires and a hit on target is achieved, what is the impact of the projectile? Will it penetrate possible armour, and if so, will the target become a casualty? In case of artillery, how much energy does the round still have? Will it hit another soldier?

All this makes more “organic” combat outcomes possible, as the different outcomes don’t need to be artificially adjusted.

In this pair of images, on the left we have the GT1 engagement system and on the right the rebuilt engagement system:

In GT1 the red unit is within range of the blue unit, inside the front sector fire arc. First, the line of sight check returns positive: the unit can engage. Then the actual firing is calculated from the soldier models, which allows firing at multiple units simultaneously or limiting the number of soldiers firing (due to no enemies being in the soldier’s firing arc). Casualties calculation is done on unit level, taking into account direction of fire and creating the casualties in the nearest coy platforms. This calculation is modified with flanking fire value (simulating the higher chance of hitting a soldier further back, which is not the case if engaging from the front), which increases the effectiveness of the volley. In the end, 5 casualties are inflicted, and models on the left flank of the unit change to casualty animation and then “die”. The red unit cannot return fire, as its unit-level fire arc is pointing in the wrong direction. (What is not taken into account here is that in GT1 ,the average scale in visualization is 1:25, meaning 1 soldier model stands for 25 soldiers in the unit. To increase the visual impact, we kill more models than the calculated casualties justify. After a short time, a few more models spawn and move to “fill the gaps”.)

In the new system, each soldier (model) is constantly checking whether it sees enemy soldiers within assigned engagement directions (a soldier can have multiple, for example, as 1st priority front, and 2nd priority to left). Depending on the unit’s firing system, the single soldiers have permission to fire or are part of unit-level controlled fire, where permission to fire is given per rank. The per-rank firing to priority direction can happen as a part of single or multiple ranks firing a simultaneous volley, and may include rotation of the ranks to move soldiers with reloaded weapons to the front. Each shot by a soldier at a soldier is calculated separately, and the outcome is decided. For example, two soldiers fire at the same enemy soldier; the first one misses, and the second one hits. The rightmost soldier picks a target further back. (Also marked is the possibility for the red unit to fire back, as in the new unit system, the left flank soldiers can turn and fire at different targets than the rest of the unit.)

Even if the result in both systems is the same, 5 casualties in the red unit, the result in the new system comes through an “organic” calculation, as we like to say. There is no separate bonus from firing from the flank, as the increased effect comes directly from the soldier-level engagement modelling. In case the blue unit was in open order or the red unit had a bigger number of ranks or density of soldiers, the result could change drastically. In the left model, this comes from a separate single unit level modifier (casualty modifier per formation for red, firepower modifier per formation for blue), in the new model, such modifiers are not used and the result will be more realistic through organic means.

Like written previously, GT1 is very heavy on CPU usage due to a lot of calculation ongoing at all times, especially with large armies fighting. While the detail of combat has increased tremendously in the rebuilt combat system, the new engine handles the required calculations much more efficiently than in GT1, and performance is much better in similar size battles, even with 1:1 model per soldier scale vs. the old 1:25 scale.

In the next diary, we’ll take a look at the new melee system, which is very much a different beast in its own right – and there the soldier level approach has the most advantages.

Most Respy,
Gen’l. Ilja Varha
Lead Designer – Grand Engineer Corps

This is the 2nd blog in our new series, which discusses developing our updated engine that will power the next title in the Grand Tactician-series. We’re keeping some details, like historical setting, vague on purpose to discuss at a later stage. But, we’ll keep releasing these peeks behind the scenes to let you know what to expect in terms of game play and improvements.

The New Unit System

One of the first things we developed for The Civil War (during 2016-17) was what we call the Unit System. This is how units are created and handled in the battle layer, and it has a big impact on a multitude of other things: visuals, controls, performance, AI, to name a few.

Re-building the Unit System is a key part of improving the battle layer for the upcoming title. The results are very encouraging and we’re excited about the possibilities it brings to the table, both for game play and also for performance and clunkiness (or lack of, this time around) of the battles. This will of course work hand-in-hand with terrain and movement, group-system, combat system(s), AI, and so on.

The Old System

In the old system, we built the units from what we call “company blocks”. These are sub-elements of the units, and platforms, that are moved depending on the unit’s formation and positioning. The 3D models (or as the game originally featured, sprite soldiers!) are attached to each platform.

In The Civil War (1861-1865), or GT1, each platform has 4 soldier models in 2 ranks. This is to show line formations in 2 ranks and marching columns in 4 files. Only 1 model type is supported, and all special situations are “hardcoded” (a word we use to determine something that is non-adjustable by editing the game’s preference files). Such special situations include the officer model and the artillery units’ model arrangement. The different unit formations (line, assault column, column, square) were built by determining how the company blocks are placed side by side or behind one another.

Tracking each platform allows curving and quite OK-looking column movement (“snaking”) for each unit. When resizing the unit in battle, due to changing game settings or due to casualties, the number of platforms per unit changes. In the system, the more platforms there are, the more severe the performance hit, as the company blocks are used for many combat and terrain placement calculations. The end result could be described as “clunky”, and it also limited the performance being rather CPU heavy (like the game is, in general, instead of many modern games that stress the GPU more.)

Image 1: Here you can see how the units are built in the system. The “company blocks” are highlighted in red. Each contains a set number of 3D soldier models (2×4), the officer is added as a separate block, and the 3D unit flag simply floats in the air in the coordinates where the unit is calculated to be stationed in. When giving a movement order, the positioning of each company block is calculated, as seen in the terrain (right).

With the tools we had when developing the old unit system, we had many restrictions. For example, each unit shows only one type of soldier model (except for hardcoded special situations mentioned above), and the number of soldier models in the battle is limited to a few thousand in total due to performance. This means a regiment of 1000 soldiers is normally visualized by way less than a hundred models (in the above image the unit shows some 40). This means a 1:25 scale (one 3D model = 25 real soldiers). Not very “grand”, right?

The Rebuilt System

Just tinkering with the old unit system would have improved the situation in general by a limited degree. For that reason, we scrapped the old system completely and rebuilt the new one using the knowledge we’ve gained and also modern tools that have only become available more recently.

In the updated GT engine, units are built differently. Instead of using set coy blocks like Legos, we determine the composition of whole units, soldier by soldier. Each unit can contain many different soldier types including special ones such as officers, and drummers, each with their own 3D models and animations. The per soldier data also contains info for combat simulation. What this allows, for example, is units engaging in multiple directions depending on the combat situation and using different kinds of firing systems, such as different numbers of ranks firing simultaneous volleys or in succession.

The units now have more flexible formations for different combat situations they can assume depending on conditions around the unit, the situation of the unit itself, and the training level. As an example, a cavalry unit may use different formations for marching, battlefield movement, ranged engagement, skirmishing, and a few different for charging. Together with the more flexible firing mechanisms and ability to fight in multiple directions the battle micro-AI will have fewer difficulties in countering player’s moves on the lowest, i.e. unit, level. (The battle AI is divided into unit-level “micro-AI” that reacts to surrounding conditions and a “macro-AI” that handles moving groups of units and assigning stances.)

From a management point of view, drill is more important than before, as raw troops cannot perform the more complex maneuvers as a cohesive unit. This limits their effectiveness even more compared to GT1.

Image 2: This is a sketch of a Civil War Infantry Regiment in line. With the new unit system, a more detailed unit deployment such as this can be created, including positioning of the flags, officers, NCOs, musicians, and so on.

Sounds rather performance consuming, right? On the contrary: with the new tools and much improved coding magic, instead of showing a maximum of a few thousand soldiers in a battle (GT1 upper limit), we are talking about tens of thousands – and this with better performance than in GT1!

And much of this is moddable.

How this is technically pulled off, shall remain our secret for now, so let’s not dive deeper into details. You may read between the lines we’re quite excited about the opportunities this new unit system brings to the table. But that’s not all! In the next blog we’ll take one step deeper into what it means when we use the new system to simulate ranged and melee combat on the single soldier level – as part of the improved combat model!

Most Respy,
Gen’l. Ilja Varha
Lead Designer – Grand Engineer Corps

Gen’l,

With this log entry, we start to look into the future of Grand Tactician and what new and reworked features the next title will have when compared to The Civil War. Currently we’re rebuilding the battle layer, so we’ll focus on the changes there during this and the upcoming log entries.

The New Battle Layer.

As discussed in our earlier log entry, there are many aspects we want to change in the Grand Tactician’s battle layer. This is anything from the limited number of battlefields, rigid unit system, and visual scale of the action, to the combat system itself (especially lack of proper melee system), performance, AI… As was discussed, it’s better to do this as one big overhaul vs. trying to improve each sub-system within the main system. While doing a re-write, we can also include other ambitions, like improved moddability, support for localization, and modularity that will later make patching and further development much easier.

The first new thing to discuss has to do with the battlefields themselves. In The Civil War (1861-1865), which we will refer to as GT1 from here on, all battlefields are drawn by hand and then integrated into the campaign map using coordinates, radius, and any randomization options. The system was developed as early as 2016-17 and was among the very first things we ever created for Grand Tactician. As each map took me up to two weeks to draw and integrate into the battle layer (to create battlefield functionality for the units), this naturally meant that only a limited number of battlefields are available in GT1 – 30 historical ones and 13 non-historical ones to be exact. It took a similar time for Wasel to draw the beautiful papermaps in parallel.

How the GT1 maps were created is discussed in further detail here in an old log entry from 2019.

Image – This is how GT1’s main campaign map looks with all the historical battlefields.

This approach has its pros, but also quite heavy cons:

1. - As you can see in the above image, most of North America is void of battlefields. As each battlefield is 8×8 miles in scale, the populated area is limited. We added 4 “random map” sets to fill the void. The maps within these sets (mountainous, farmlands, wetlands, plains) are called “random” as one in the set is randomly chosen when a battle is initiated.
2. - Only the most important battlefields have sufficient reference material available. The topography of historical battlefields looks very different today, and proper maps (or battle descriptions also focusing on the topography and terrain features) are hard to come by. Even if drawing a map out of only rough or almost non-existent reference material, doing it by hand still takes a lot of time. When we look at different historical periods from the 17th to 19th Centuries, the amount and quality of reference material for the Civil War battlefields is probably the best, all other conflicts have it mostly much worse.
3. - Most importantly from the gameplay point of view, the campaign to battlefield topography link is missing. This means the cunning maneuvers on the campaign map play no role once battle is joined. As the nearest available battle map is loaded, this could be a hundred miles away from the area where the campaign map depicts the battle taking place, with a completely different topography. The river you were following and hoping to anchor your flank to is missing, and so are the roads, hills, forests…

The 20th Battle of Manassas?

We tackled all 3 main issues by developing a map generator, which creates the battle maps from campaign map data. The data is created from multiple bitmaps that cover terrain height, infrastructure and vegetation. Location data allows adding the names on the map in correct locations.

In GT1, whenever you fight a battle in the Northern part of Virginia, you end up fighting it out in the Manassas (Bull Run) map, and always more or less around the Bull Run -line. The new system allows creating an unlimited number of battlefields that will always represent the campaign map situation accurately. The terrain is generated according to data in that exact location, including all the main terrain features you’d expect to see on the map. Now, army placement on the campaign map plays a much bigger role, introducing one important aspect more to the aspiring Grand Tacticians!

While the introduction of the terrain generator does not remove the possibility to use hand-drawn maps, it also introduces two more pros: scalability and moddability. Depending on the campaign map dataset scale (i.e. how many meters does one pixel in the bitmaps represent), and the size of the “slice” (X pixels vertically/horizontally), the battlefield scale can be easily changed. The data is read from bitmaps and text files, meaning it does not require any dedicated modding tools to create a complete dataset to generate maps.

The Terrain.

We also made some changes in the terrain itself, and the unit to terrain link, to allow more realistic unit behavior in different types of terrain. These aspects are built around terrain types (and properties) and navigation data, that also control units’ pathfinding.

In GT1 the terrain types and navigation data have a quite simple connection. The terrain types are limited to only a few (open ground, fields, forest, swamp, water), while most differences are visual only. Further granularity is added through linear objects like roads, streams, fences… Units can move on all terrain but water (if not frozen), and very steep slopes, but otherwise, there are no limits. Also, how the terrain affects units is always the same: forest slows down skirmishers and cavalry brigades just the same, and does not prevent artillery deployment like in reality.

From a pathfinding point of view, all terrain is the same, so when giving a movement order (player or AI), the units do know to prioritize roads for fast movement, but do not make a difference between an open plain or swamp. This leads to units moving through difficult terrain more often than necessary, getting tired and slowing down, which in turn breaks group (for example division) cohesion, and affects especially the AI.

In the new terrain engine, the number of different terrain types has been expanded. For example, there are forests of different tree density. They are now included in the navigation engine, so each terrain type can have its own navigation characteristics. This is further augmented with unit heaviness, which determines how different types of units are affected by terrain. For example, very light units (such as skirmishers) have no issues moving through a forest, but a large cavalry formation or artillery battery cannot enter a thicket, or try to cross a swamp. This is part of pathfinding, so giving movement orders will take this into account, units preferring easier terrain, and going around obstacles – when allowed to.

Image – Left: the old terrain system. From a pathfinding point of view open terrain, forests, fields are the same, even if the latter ones slow units down more. Right: the new terrain system. Here each terrain type (different colors) has its own pathfinding properties and characteristics for different types of units.

While at it, we also added further detail on how weather affects the terrain. Instead of raining true/false as in GT1, we now track precipitation and terrain wetness separately. The former increases the latter, and when the rain stops, the terrain will slowly start to dry up. During winter, the same is true with snowing and terrain snow coverage, which increases or melts gradually.

Like said, this is the first building block in the re-worked battle layer. In the next log entry we’ll take a look at how the unit system has changed, and what kind of effects this will have on game play, performance, AI and moddability. Until next time!

Most Respy,
Ilja, Lead Designer
The Grand Engineer Corps.

Gen’l,

For some time now, an eerie silence has surrounded the Grand Engineer Corps camp. The troops are wondering, what is happening inside the fog of war? What does this mean to the Grand Tacticians, present and future? Major changes have taken place in the background, with the Engineer Corps going through a reorganization. As the pieces are falling in place, it’s a good time to share some Engineering intel from behind the scenes.

The Greenhorn Volunteers.

Grand Tactician’s story began in 2016, with Oliver (a finance banker turned coder from Austria) and Ilja (a wargame enthusiast in the Finnish Army) deciding to develop a strategy game independently. The idea was to create something unique in the genre, the game taking place in the American Civil War – a conflict of great interest to us. Soon after Peter (a chemical industry worker and mod artist from Germany) joined the team as an artist, and since then our team of three worked hard to make our dream a reality. We started from zero, new game engine, new coding language, and a lot to learn…

The Civil War (1861-1865) has been a true independent “garage project”, being developed outside the working hours as a second job. It started as a very interesting (yet ambitious) hobby project, with no commercial expectations. The development didn’t have a fixed schedule, we worked as much on the game as we could, learning as we went. We have been blessed with many helpful and talented people with enthusiasm toward our project and the will to help, and this helped shape the game into what it is today – not perfect by any means, but something we’re proud of. We managed to create a unique game among its peers. 2000 reviews with > 70% score is high praise!

What we never expected was that so many players would find the game and enjoy it, providing us ideas and constructive criticism from the Early Access of late 2020 continuing all the way to this day. This of course caused immense pressure to deliver. The post-release development has been even more hectic than the time before. At times, there was exhaustion among the ranks, as all the work was still done after returning home from a day (or night) job, work trip or even military exercise. The COVID years and increased tempo at work for some left a mark in the development as well. This was especially true during development of the Whiskey & Lemons DLC. In these circumstances, while frustrating at times, it has been very flattering that our humble game has been compared to titles created by much larger developers with much larger resources at hand.

At the same time we knew we could not continue like this in the future. Demands at work, with family and with the game were taking an increasing toll. We’re not young guys anymore.

The Long Road Ahead.

We always wanted to make Grand Tactician a game series to portray multiple wars of the gunpowder and linear warfare era (17th to 19th Centuries). If for now we disregard the personal issues we had with resources to invest in game development, we also had reached a point in the Grand Tactician -engine where small fixing here and there no longer was achieving sufficient results. Like said, we know the game is far from perfect, and there are the shortfalls here and there we want to improve. These are mostly the ones the community knows very well and have been providing us feedback about (there are also some technical ones, that are not apparent to players). “Clunkiness”, performance, AI, battle balance, player onboarding, information…

Military minded people remember the approach to putting new wine into old bottles… In order to really improve the battle AI, as an example, working on the AI itself alone no longer helps – work is required in other areas as well, like the whole unit system, pathfinding, order of battle, parts of the combat systems. Tinkering with all these systems individually to help the battle AI a bit will cause issues in other areas, that in turn need to be reworked, and the butterfly effect continues. And still we would have the old unit system, pathfinding, etc. that we want to improve anyways, and that are affecting other areas (clunkiness, performance…) So, in some cases we need a new bottle for the new wine.

During the eight years we of course learned a lot, but also the tools available have constantly developed. Especially the battle layer we developed first during 2017 is showing age and no longer facilitates much improvement without a rehaul. So, we decided that in order to move forward we need to rewrite big blocks of the game engine. This of course takes a lot of time – it’s “revolution vs. evolution”, like game developers like to call it. At the same time it allows further changes like increasing modding opportunities and adding localization.

But, back to reality and the resources… If the volunteers are worn out from years of battle, to rally the Corps, veteran regulars are needed.

The Regulars.

Recently, the Grand Engineer Corps has gone through a major reorganization. As things were still in motion and results were foggy, we kept quiet about this, while already re-working hard the first elements of the game engine. At the same time we released multiple patches to fix the remaining major issues reported by players.

Now we’re very happy to be able to say that things have turned around for us in a major way. We have teamed up with a like minded publisher, the right one for us and for our project – a Grand Tactician -series. With this move we have been able to transform from exhausted garage-developers into professionals – volunteers into regulars – resigning our earlier jobs and now working as full-time game developers! To put it mildly, life is now very different and so are our development opportunities.

What exactly we are working on will be disclosed at a much, much later date. What can be said this early on, is that we’re working on taking Grand Tactician forward in a way that earlier was not possible for us. While not much more can be said at this point, we’re planning on sharing a developer log regularly, approximately every 2-3 months, to give you a small glimpse into our upcoming game. While our vision for the next game is already set – and this takes into account the feedback we’ve received –, we do want to give you an opportunity to provide feedback, during development, at a more detailed level. We’ll start with some more technical matters, and – in full transparency – intend to hold back the major details, until there is a better opportunity to share them. We hope you share our ambition of making Grand Tactician into something greater, and that to do that we need to let the marketing machine have something to run on, when the time is right!

While our work continues, players of The Civil War 1861-1865 will be supported by the development team like before. The best way is to drop an e-mail to our message box info(at)grandtactician(dot)com, as we are deep “in the matrix” – there are only so many pairs of hands. We’ll do our best to help you with issues and questions you have. What is also fair to say at this point is that no new features or downloadable content are to be expected for The Civil War. We hope this is understandable, as large parts of the game’s engine are already cut open on our field surgeon’s table.

Having shared this piece of intel, we continue our long march toward what we hope and believe will be a bright future for Grand Tactician. Touch the elbow!

Very respectfully, your obedient servants
Oliver, Ilja, Peter
The Grand Engineer Corps.