My computer had some issues last week, so I spent most of my free time trying to fix it, and didn’t have much leftover to develop the game. However, I was still able to overhaul how scouts work, which I will be talking about today.
First off, I had decided to take another look at the scouts cause they could cause a game crashing bug when fleeing from pirates. After taking that initial look, however, I decided to switch how they work altogether. When you send scouts to their scouting location from the map, they have a variety of ways to deal with pirates they encounter along the way. Until now, they would notice the pirate and hide, doing nothing until the pirate either moved past them, or was taken care of by the player. If a pirate got close enough, the scout would run away to avoid getting killed - but this could also result in an endless chase as the pirate couldn't catch up.
After this week’s changes, the scouts act a little differently: Scouts can no longer be seen by wood tier units (axe and blunderbuss pirates), so they will simply walk past the early opponents. They will still spot them and reveal the map, but this reduces the danger to them, and makes them more effective in the early game. Scouts are still seen by more advanced pirates, so if the scout notices one of them, he still goes into hiding - at which point he will start revealing the map around his hiding location.
We are thinking of introducing some research with 0.9 that will allow scouts to also remain hidden from the stone tier pirates - and maybe even the metal tier pirates - but those plans haven’t been finalised yet. Regardless, pirate fortresses should remain a barrier to the scouts, so they will be detected when trying to run through them.
Until next week!
Weekly Update 137 - New Healing Mechanic
Hi everyone,
As promised, I uploaded a new version of the game onto the experimental branch last week, which includes the new six units. Beyond that, I also started working on a new healing mechanic, which I will be talking about today.
At the moment, the current healing mechanic is food based. Whenever a unit takes damage (from starvation or from being attacked), the damage they took will be healed whenever they eat food. For the commander, this is manual, so whenever the player decides to eat - and for villagers, this is part of their regular cycle of eating once a minute.
While this works generally well, there are some issues with it. For one, food provision is based on a villager’s house (or in the case of a soldier, their barracks). This means that a villager or soldier who has taken damage from an attack on one end of the island ends up getting healed by food being provided to their residence on the other side of the island. While this may be acceptable for villagers, it creates a bit of a strange situation with the soldiers, who essentially just heal over time with no input from the commander. The second issue is that the villagers get healed for the same amount of damage they take from a tick of starvation. This means that you can effectively provide them with food only every 2 minutes - and they will be perfectly fine regardless.
The way I am now going to address both issues is by creating a new healing mechanic. Healing will now be done by a medical building, with the use of medicine. To start with, this will be medicinal herbs being distributed by a healer’s hut - but there will be upgrades introduced with 0.9. The healer’s hut will only heal units in its immediate area, meaning that you will have to walk soldiers back to the closest base for healing, and will create “healing charges” from medicine. The healing charges are primarily there to A) allow quick healing of injured units in the area, while B) making sure that medicine can’t be used in place of food. Each medicine unit provided to a healer’s hut will be slowly converted into a healing charge, and any available healing charges will be quickly administered to injured units in the area.
There may be some further changes to this mechanic as we go through some further testing and receive additional feedback - but for now I will focus on creating a model for the healer’s hut itself.
Until next week!
Weekly Update 136 - Ammo Depot
Hi everyone,
Last week was mostly spent on ammo and all that brings with it - so I will talk about that a bit today. With the change to 6 units, the fundamentals of our soldiers and military gameplay changed quite a lot.
Before the change, we only had ranged units from the stone tier on, which meant that all of the ammo production chains were also starting in the stone tier. With the addition of the blunderbuss wielder to the wooden tier, this now means that the player has a unit that uses ammo, but no way to produce it yet. I went through a lot of different ideas on how to fix this. We could simply move the ammo production chain to the wooden tier - and maybe add a second, more efficient building to the stone tier; We could create a second type of ammo for the blunderbuss only; We could have the soldiers start with more ammo; etc. Ultimately, each of these ideas impacted changes I am already planning to make in 0.9, and would only be a temporary fix that is probably more work than it is worth.
The way I would like for this to work when 0.9 comes out is for players to have the option to buy ammo at the wood tier. This will be expensive, but can obviously support both their early and mid-game ranged units. Once the player reaches stones as a resource, they can research ammo production, and decide to set up their own supply lines. Of course this depends on being able to buy ammo, which is disabled for other reasons ahead of 0.9 at the moment - so I have increased the chance of ammo being present in loot containers in the starting area. Once the ranged units run out of ammo, they are also only marginally weaker than melee units at the wood tier, so I am hoping that this will work well for the time being.
Another change I made this week was the ammo distribution. So far, most military buildings (watchposts, towers, barracks) had an inventory for ammo, which they distributed to any unit that was closeby. While this was a good idea in theory, it turned out to not be great in practice, as players ended up with just too many buildings that could have ammo for a very limited supply early on - so it was never clear where the precious ammo had ended up, and how you could best arm your units again.
So, I am now introducing the ammo depot. For now, I have only made a wooden version, which distributes ammo in a 50 metre radius around it. Future versions at the stone and metal tier will likely get a larger range, and will take more ammo into their storage as well. On the plus side, this means that players will have much more control over where their ammo goes, which I think is a step in the right direction. On the minus side, towers will have to be built in range of both a market and an ammo depot to be supplied with food and ammo. However, considering players also have the option of putting down melee watchposts, I am hoping this will simply add another layer of planning to most bases.
I should be able to finalise some of my work on the six units this week, so there should be an update to the experimental branch before next weekend.
Until next week!
Weekly Update 135 - More Disciplined Soldiers
Hi everyone,
Last week, I was able to implement some changes to the soldiers’ behaviour which I want to discuss today.
Before I go into what changed, let me explain what I tried to address - and where that originated: When the player raises a larger army (let’s say about 40 soldiers) and moves this army to attack a large pirate fortress, the outcome tends to be a little chaotic. As soon as the first of the soldiers see the first of the pirates, both sides start running closer to each other. This often means that the last of the soldiers haven't even gotten into range yet when the first are already starting to fight. As both sides are streaming into the fight, units become broken up, and directing the fight (e.g. telling one unit to flank to attack some ranged opponents) becomes very difficult.
The reason for this is probably that there are multiple types of behaviour I have been trying to catch with the same soldier behaviour script. Pirates that are close to a jungle, for example, should behave like they are “guarding” their area. If they see or hear an opponent, they should go after them until the opponent has been out of sight for too long or they are engaging them. If a soldier has been tasked with running across the island to a new location, or has been left to guard a specific spot, they should behave similarly aggressively, defending themselves from any opponent they can perceive. However, this behaviour stands out in a battle closely observed by the commander. When units act independently and aggressively, they become unmanageable and the fight devolves into a brawl, rather than reflecting a more militarily organised battle.
Having seen this as a problem, I have been wondering about solutions for a while. Two new behaviours I have implemented are the “non-attack” move - if a commander double clicks with soldiers selected, they will now ignore all opponents until they have reached this location (the waypoint also turns yellowish/green to indicate this, as seen in today’s image). This can help in particularly tense battles, when the commander really wants some units to flank some ranged opponents, as the soldiers will now be completely single minded until they are right next to their target.
The other new behaviour is the “defence only” mode for soldiers. In this mode, ranged soldiers with ammo will only engage opponents when they are within their 60 metre shooting range (but they will report on enemies they see up to 100 metres), while ranged soldiers with no ammo and melee soldiers will only engage opponents when they get within 5 metres. This mode can help keep a reign especially on ranged units, and using both of these together already feels like you are controlling a much more disciplined army.
There are two remaining questions at this point which I need to figure out next week. The first is whether to let the player set the range at which melee units engage their opponents (e.g. 60 metres so they don't simply idle while being shot at by ranged opponents), and the second being whether to let players choose between attack and defence modes freely, or whether to link them, e.g. to proximity from the player (so the units behave aggressively halfway across the map, but are more controllable closer to the player).
Until next week!
Weekly Update 134 - Six Units
Hi everyone,
Last week I uploaded the new animations to the experimental branch (as well as some new materials for the new buildings), and I was able to put the majority of work in for the new units, which I will be talking about today.
With the change from 3 to 6 units, I was finally able to implement a real difference between melee and ranged units. Rather than the units in the stone (pistoleer) and metal (musketeer) tiers representing straightforward upgrades, each tier now has both a melee and a ranged unit, which both have their strengths and weaknesses. So let’s go through them.
All of the ranged units require ammo in order to shoot at range. They can hold up to 10 ammo at the moment (something that you will be able to upgrade with research in 0.9), and take about 10 seconds to go from idle to firing. Then they take another 8 seconds to reload. For the time being, I set all of their ranges to being the same - 60 metres - though that may change in the future. When they are out of ammo (or a melee opponent has gotten too close), they engage in melee combat, where all 3 tiers of ranged units do 20 damage every 3 seconds. Across all tiers, this is balanced to mean that if a ranged unit manages to get a shot off against their melee equivalent, they will win the fight - if they don't, they will lose the fight. So a ranged unit fighting a melee unit in open terrain will win, while a ranged unit fighting a melee unit in close range (e.g. the jungle,stationed around a bend, or in the city) will lose.
To make up for their otherwise slightly weaker nature, melee units do not need to be constantly supplied with ammo, and therefore need less production and logistics to be supported, especially further from the base. They hit their opponents once every 3 seconds (same as the melee combat for ranged units), but there is obviously no aim or reload time.
Wooden tier: At the wooden tier, we now have the axe wielder (melee), and the blunderbuss wielder (ranged). The Blunderbuss wielder does 60 ranged damage when shooting, while the axe wielder does 25 damage in melee. This means the axe wielder will defeat an opponent in 4 hits, while the Blunderbuss wielder needs one shot and 2 melee hits to defeat an opponent (assuming the opponent gets close).
Stone tier: At the stone tier, we now have the swordsman (melee), and the musketeer (ranged). The musketeer does 80 damage, meaning he will defeat an opponent with 1 shot and 1 melee hit, while the swordsman does 35 damage per hit, meaning he will defeat an opponent in 3 hits.
Metal tier: At the metal tier, the units are now the pikeman (melee), and the rifleman (ranged). The rifleman does 100 ranged damage, meaning he will currently defeat opponents in one shot, while the pikeman does 50 damage per hit, defeating an opponent in 2 hits.
Balance will of course be changed as we get feedback from you, and I am planning for many research aspects to affect this once 0.9 brings research into the game (higher damage, armour, quicker aim times, etc). As you may have noticed, the changes meant that the pistoleer was removed - so the pistol will now once again be the domain solely of the commander!
The three tiers currently have placeholder art (once again), but I tried to make them as distinguishable from each other as possible (see image). Beside some colour, the Tier 1 units have a regular, round hat, while tier 2 units have a tricorn hat, and tier 3 units have a tricorn with a feather. Pikemen still have a sword at this point, but the art should be upgraded with the units over the coming months.
There is still a bit of work to be done (e.g. making the barracks a bit more differentiated between melee and ranged and sorting out icons, etc), but I will try to get an upload of this build out onto the experimental branch over the next two week, so people can try the new units for themselves!
Until next week!
Weekly Update 133 - Many Animations
Hi everyone,
Last week’s development was again very productive, though not necessarily on the parts I wanted to work on. Instead, I decided to add a bunch of animations that had so far been missing, which I will talk about a bit today.
As I started working on better combat control for the commander last week, I decided to first test the current state to see what needed doing most urgently. This made me realise something quite quickly: There were still a ton of animations missing from the combat. I had already mentioned the missing “aiming” animation last week, but ranged units didn’t have an animation for melee combat either; swordsmen were using the construction animation to strike (with a sword instead of a hammer, of course); and soldiers throwing a torch at a building was missing both the throwing and the torch.
This has of course been a consistent state of the development of this game. I feel a lot more comfortable with coding than I do with art, and so the art has been lagging behind quite consistently. This week, I decided that this needed to change. I had mentioned a few times now that I wanted to switch the melee and ranged combat to make things more predictable for players, but when players can't see what is happening cause animations are missing, it is difficult to make anything predictable with code alone.
So, this week I added some new animations. It had been years since I last animated anything, so it took me a little while to get the hang of it again, but in the end, I managed to add a torch throwing animation (see today’s image), I added a new gathering animation when villagers are getting bananas (this had also been using the construction animation, without a hammer), and I added some animations to the ranged soldiers. Ranged soldiers now kneel down as they are taking aim and tilt their head just before shooting - to make it much easier to see how close they are to firing. Ranged soldiers now also have a distinct melee combat animation, in which they strike with the stock of their gun.
For next week, I am intending to also change the swordsman's animation from the construction- to an actual attack animation, after which I will return to the code to add some more combat control.
Until next week!
Weekly Update 132 - Aiming and Gatherer’s Hut
Hi everyone,
Last week’s development was very productive. I was able to rework the majority of the melee/ranged distinction I described last week, and I was able to get an upgrade of the gatherer’s hut done as well.
As I mentioned last week, I have been working on making the ranged and melee combat a little easier to predict for the player. Part of this was giving the soldiers and pirates a “lead time” before shooting. This is now done. A soldier who is firing at the player will first point their gun at the player, then take a few seconds to aim more finely, then shoot. The “fine aiming” does not yet have an animation associated with it, but I am currently thinking that it may be a good idea to have them kneel to take better aim - which will make it very clear for the player how close the soldier or pirate is to firing.
Additionally, I disabled the player’s ability to abort a soldier’s reload. Previously, it was possible for a move order given to a soldier to override their current reload. This meant that soldiers were more responsive to orders - and would reload just before firing the next time. However, with the better distinction between melee and ranged, ranged units will now reload directly after shooting, making them less responsive and more predictable. Considering their range and damage advantages, this will hopefully give players a good reason to use the more responsive melee units, which are going to have a distinct advantage if the player can get them close enough.
Finally, I have been slowly reworking some of our other older buildings to fit the new style we decided on. This week, I managed to finish the visual upgrade to the gatherers hut, as you can see in today’s image. The functionality has of course not changed - but I think the bamboo/wooden style fits a bit more neatly next to the banana leaves.
Until next week!
Weekly Update 130+131 - Workstreams
Hi everyone,
I had a licensing exam last week, which took up almost all of my time over the past 2 weeks. As you may have noticed, that also meant that I forgot to upload the post last week. Unlike the last time I failed to upload, I won’t do two posts today (last week would only have been an intermission), but I will use today to give you an overview of what different workstreams we are currently working on.
First of all, I am now working on re-writing some of the soldiers’ code. At the moment, a lot of the distinction between melee and ranged units is blurry. For example, melee units get an initial volley with a short range weapon, and ranged units are able to abort their reload to fight in melee. This may make sense from a “realism” perspective, but it makes commanding these units a little frustrating. The same type of unit may behave differently depending on proximity to their opponents, and our intended “soft counters” work a lot less effectively than we would like.
The current rework is meant to change this, by embracing the behaviour of soldiers a little more as a video game, and a little less as realistic. Melee units, for example, won’t get an initial shot with a firearm anymore. They will simply run into melee range to fight there. Ranged units, on the other hand, will behave more predictably as well. They will take a few seconds to aim, and will always reload directly after firing. This should make them quite devastating if their opponents are far away - and a lot weaker if they are caught in close quarters.
Secondly, John is continuing to rework the tutorial map. This is a slow process, so we are also planning out the tasks and missions we want the player to go through to learn the game. I will keep you updated on the progress.
Finally, we are also continuously improving on models and materials. I have been working with an additional artist, Tom, for the past few months, who has been helping me improve a lot of the more foundational parts of the art. At the moment, Tom is focusing on optimising my placeholder buildings, and is creating new materials for them to look better.
Until next week!
Weekly Update 129 - A Smoother Progression
Hi everyone,
Last week was spent on some playtesting, fixing bugs, and the start of addressing some feedback I had gotten about the current progression of the game.
I will start with the interesting part: As some of you will have read in previous posts, two of the big goals of 0.8 were A) to improve on the strategy gameplay, adding new soldiers, tactics, and military goals such as artefact mode, and B) to introduce more of a progression by placing advanced resources further away from the player starting area and adding pirate fortresses for the player to defeat along the way.
One of the biggest gameplay related feedbacks we got from the 0.8 experimental release was that the first fortress was too big of an obstacle. The first fortress in the stone area has about 40 pirates defending it, which requires players to raise a similarly large army of swordsmen, or to sneakily build a base in that area to get stone for pistoleers. In either case, the main military challenge ahead of taking on the fortress are either randomly spawned pirates (which can easily be defeated by the player without soldiers), or attack waves, which are best addressed with watchposts, rather than an army. As a result, attacking the pirate fortress is the first real reason to recruit an army, and then requires a very substantial investment of about 40 soldiers to be successful.
This doesn’t feel particularly intuitive. Rather than having a step by step progression that guides the player to big fights, we have a few big jumps of substantial fights which either slow down the game as the player prepares, or end in a big defeat. I’ve decided to address this in two ways: firstly, I will reduce the number of pirates in the first fortresses. Rather than having to fight 40 soldiers in each fortress (with them getting stronger from fortress to fortress), the first fortresses will be smaller, with maybe 20 pirates in the first, then 30 in the second, and so on.
Secondly, I have started to experiment with smaller pirate camps again (see today’s image). These used to exist before, but were spawned completely at random, had no reward associated with them, and made it difficult to predict the challenge they would pose - so we got rid of them. However, with our improved random spawn system, we can specify how many of them we want to spawn in each part of the map, and make them part of the challenge and progression. Rather than having to fight the fortress as the first step, the player will have to raise a small army to defeat one or two of the camps first. Additionally, the player will find a reward once they have defeated the camp, which makes it worth fighting them and adds to the progression. Overall, these two changes will hopefully lead to a smoother progression across the island - though we’ll need to do lots of balancing to make this enjoyable.
To also mention some to the bug fixes: I managed to fix a few loading issues, such as some defenders (of watchposts) not appearing when loading a game; I added a few additional checks to catch problems with soldiers falling through the world (this used to happen to pirates a lot, but apparently also happened to soldiers very rarely); and I fixed some loading issues with the newer changes to the map. These fixes will be in the next update, which I will upload as soon as Haakon and I have managed to fix one more sound issue.
Until next week!
Weekly Update 128 - The Programmer’s Folly
Hi everyone,
Sometimes, a person with a hammer views everything as a nail. Sometimes, people get tunnel vision. Sometimes, I waste days of my life on something that could have been done in 5 minutes. Today is such a story.
As John has been working on the tutorial island, I decided to continue fixing the map, with one thing that I consider particularly important: more accurately representing where soldiers can walk and where they can't. This is obviously important especially on the tactical map - the player needs to know exactly which part of a hill their soldiers can walk over (or get attacked from). The map we had didn’t properly reflect this, as the map so far didn’t take into account the new(ish) terrain rocks - and simply adding them to the render resulted in a very bad looking map that also didn’t accurately represent walkable areas.
The base layer of the map uses a camera above the terrain to take a snapshot of the landscape at the time of the start of the game, replacing the terrain material with a custom map shader. Having set it up like this originally and wanting everything to be automated, I naturally thought I could utilise the same concept to show the navmesh (or lack thereof) on the map. About a day and a half into setting up 9 different cameras, re-writing shaders, and getting rather frustrated with certain parts of Unity, I decided that this wasn’t going to work without either sacrificing a considerable amount of performance at the startup or throughout the entire game.
So, I decided to instead export the navmesh to Blender, to essentially invert the navmesh with Blender, after which I was going to re-add the new object into Unity, and could now do with a simple 3 camera setup that was going to just run at the start. A bit more work for me up front, but much more performant for the game in general. Of course, I hadn’t considered the issues I may run into with Blender. What I thought would be a simple boolean operation turned into a bigger problem of trying to separate and break down meshes, with John going as far as suggesting I should write my own boolean operator for Blender.
A day of frustration and setbacks later, I finally realised the obvious: I could simply take a picture of the navmesh in Blender, and invert it in an image editing program. This took me a whole 5 minutes, one camera, and zero performance impact in the game, not taking into account how stupid I’ve felt for not thinking of it earlier. So, after 3 days of frustrating attempts to automate things and 5 minutes of productive work simply taking a picture, the map now very accurately shows where soldiers can and cannot walk - and can easily be edited in Photoshop (result in today’s image). Goes to show that sometimes thinking before doing can save on a whole lot of doing.
