Friday Rewind #14: Of character movement and E3 highlights

14.6.2019 – HP Noronen

In this week’s rewind we will dive into major rework on our movement systems. In addition, we invaded E3, so let’s have a quick look at a few highlights from there.

 

Rethinking character movement

Starting point

As you might already know, the player controls 1-2 characters in the game at any given time. It is possible to either walk or run with characters. Running is obviously faster, but also louder and therefore tends to attract unwanted attention. Different movement speeds coupled with the possibility to either move a single character or both characters together, we have four different movement modes all told. Originally, we had four different buttons to select the mode we want to use.

 

This takes up quite a lot of screen space, just for movement actions, which is something we have wanted to reduce. We also had some concerns over playability relating to movement, especially with the fact that most often in combat you’d like to move the characters one at a time, while outside of combat you want both characters to follow your instructions together. As the movement mode was dictated only by the player’s selection, we often got into situations where the player accidentally moved both characters when they intended to move only one. This was mainly a minor nuisance, but it is better to not have even that minor nuisance!

 

Renewed system

So, what did we do?

First of all, we decided that as the most common case is that the player wants to move the characters together outside of combat, and individually during combat, we will make that our default behavior. Therefore we removed the separate group and individual movement buttons and instead forced it so that whenever characters are out of trance/combat, they will move together and whenever in trance/combat they will move individually. This works really nicely in most cases.

There are rare cases where you’d like to group move during combat or move just one character when adventuring. However, those are so rare that we didn’t want to clutter our UI with another button to control that. This was solved by adding a keyboard functionality. Now when you hold down CTRL, the group/individual movement mode is inverted and it therefore allows you to give individual movement commands out of combat, or alternatively move both characters in combat.

This still left us with different buttons for walk and run actions. It was pretty straightforward to simplify by turning that to one toggle-button which allows you now to switch between walk and run.

Small things, but as you can see they make things much more simple for our UI. From four buttons, we pared it down to one, with no loss of functionality and a big improvement in playability.

 

Iron Danger at E3 2019

We are also participating in E3 during the week. We didn’t have a public booth, but instead we had some pre-booked press meetings. Most of the articles and videos are not yet out, but here are a few highlights already.

“It’s only been one day on the E3 show floor, but I have a strong feeling Finnish developer Action Squad Studios’ tactical RPG Iron Danger has done enough to mark itself out as one of standout titles as the show. “RPGamer did write a very nice piece about the game.

In addition, we managed to even claim “Best of E3” nomination from two different gaming sites, RPGFan.com and TechRaptor.net. Looking nice, eh?

 

Now that the game is on, let’s hope that in the future exhibitions there is more to come.

We will likely be writing a bit more about the E3 trip after our E3 traveling band comes back home, so keep coming back if you want to hear more!

Friday Rewind #13: A field of grain

7.6.2019 - JP Lyytinen

reference

It’s asset creation time. This one is about creating an entire field of grain in real time 3d. The problem with assets like these is that you’ll need a certain level of visual complexity for the asset to remain plausible yet you are bound by the technical limits of the render engine. Another problem comes with the amount of stalks required. A single stalk is easy to get right, but once they start filling the screen the visual clutter increases. 

So Basically,

  • I need a lot of stuff
  • I can’t have a lot of stuff

 

Simple! Let’s not worry about technical stuff just yet and let’s focus on the visual side of things. Here’s a grain prototype:

Looking decent I suppose. At this point I’m only guessing how it will eventually look like in the game but I know I need a certain level of simplifying and exaggerating the scale of things a bit. The asset should read like a stalk of grain even from a distance.

 

Furthering the shapes. A real life grain stalk tends to be rather plain so i’m adding a few knots and a few leaves for the silhouette to have something in there.

  • The more detailed the silhouette, the more visual clutter it generates, but…
  • The more detailed the silhouette, the less individual stalks I might need in my grain field.

It’s an balancing act. I’m doing my best to keep the singular asset as plain as possible yet keeping as much detail as I think is required. Some things are inherently noisy and in this case you’ll need the noise for the asset to look correct.

 

I’m using Modo for texturing. As the asset is rather monotonous you can get pretty good results using a single variation texture. This colours random mesh parts with the set gradient.

 

So what about the field of grain? To have some idea how the asset would look like in multiple numbers i’m using Modo replicators for previewing. I have a base ground mesh, a surface particle generator and a replicator item placing the grain meshes in the scene.

Pretty dope. Of course this has very little to do with how the asset will look when rendered real time. So let’s have a look at that next. The offline render preview is using a polygon budget of an entire game so we need to simplify things a bit. I need to translate the high poly information to a low poly approximation. The lower the geometry resolution the less rendering resources the asset will be spending. The minimum visible polygon component is triangle. After some intensive testing I came to a conclusion that I can get away with baking the details into a simple quad.

 

 

Feeling spendy! I have added a few rotations and curves on the geometry in hopes of avoing a zero width polygon edges staring straight at the camera. That’s it! The game model consists of a single batch of grain meshes and these will be duplicated in engine to create a whole field.

 

Testing the asset in game.

 

 

Friday Rewind #12

31.5.2019 - Jussi Kemppainen

There are lots of minor improvements that we’ve been working on lately, including optimizations on memory consumption, visual quality configurations and so on. In addition we are still actively working on some new features

Mini-map changes

Some more work was put into the minimap. We created out first hand drawn maps for levels and they were so clear and readable that I changed the minimap in the corner to show that map instead of the top down rendering. This also came with performance improvements.

Custom images for map in minimap (and elsewhere).

Patrol path actions

For our AI units, we added a simple tool to have them perform any action at a patrol path waypoint. This allows us to have the enemies carry out scripted sequences of actions, making them more lively. This is pretty rare in a tactical turn-based game. Characters can sit and chat, they can fix machinery, rummage trough boxes, hunt, target practice, mine for stuff and other cool things! This has pretty much no added gameplay value, but adds to the immersion of the world.

A soldier fixing a piece of machinery.

A troll waking up from it’s years long slumber.

Damage visualization

We used to have a streak that was drawn in the air by the character weapon. But it was not actually attached to any gameplay function. it was purely a visual thing. We replaced that with a more gamified visual that is timed with the actual damage event and actual damage range.  Also different characters have a different look in the damage visualizer, so it is a bit easier to tell who is inflicting the damage. We also render this element on top of everything, so it does not get lost in the clutter. This simple thing makes the game combat a lot more readable.

Dead bodies

This feature has been on the to-do list for ever! Dead bodies of fallen teammates cause alarm and concern for NPC characters. Finally we added that in. It is a pretty self explanatory feature: when an enemy sees a dead teammate, they come and investigate.

 

 

Friday Rewind #11: Improved ranged targeting

23.5.2019 - HP Noronen

There are lots of minor improvements that we’ve been working on lately, including optimizations on memory consumption, visual quality configurations and so on. In addition we are still actively working on some new features and improvements.. of which one is improvement of ranged attacks targeting.

 

Improved ranged targeting

Some time ago we improved the targeting with most of the melee attack, changing them from directional attacks to such that you directly aim for given enemy. After making the change we soon realized that we should extend it to ranged attacks as well.  Even though it is important to be able to aim your arrows freely to respond to future happenings in the game, most of the time it’d be smoother gameplay that you can just target given enemy and the game would predict their movement as part of shooting.

The new version of ranged aiming allows you to directly target characters and props. However, when not hovering on top of such target, you will be able to shoot your arrow in directional way such as before.

You can see both free and targeted shooting in the following video clip.

Friday Rewind #10: Deep dive into level rework

17.5.2019 - Antti Kemppainen

Rethinking the temple

This week we felt it was time to revisit one of the first levels ever made for the game.
The first time our heroes travel to an underground ancient temple in search of a magical shard.

The previous version of the level was made a long time ago and it felt like the focus and pacing was not quite right for that point in the game and story anymore. The game has come a long way since then especially with recent visual and AI changes that make the gameplay much deeper.

The temples are an important part of the game both in terms of mechanics and story so the first temple should introduce a variety of mechanics but also show the player this part of the Iron Danger world for the first time.

The end of the previous level is an intense battle against the rotspirit Keyus on an abandoned farm and the chaos can reach quite heights so it felt natural to begin the temple level with a more peaceful atmosphere. Give the player time to breathe and have a look around. I used the entry hall from the old version of the level as I quite liked the moose head sculpture and natural stone of it but instead of putting the player in small rooms and tight corridors I decided to have the entry hall open up to a larger hall lit by a lightstone operated by ancient magic.

 

 

This space has only the function of introducing the temple environment to the player with enough room that it feels safe to explore for a moment. These first steps also introduce a door mechanism with levers that the player must operate in order to open paths. As the kind of player that likes to explore all the nooks and crannies of every game in search of loot, I put a small room to the side with some health and other types of items for those who wish to veer off the path.

The large room seemed a bit empty so carvings and statues were added to the walls, pillars and a staircase to a slightly higher platform were made. We even explored paintings for floors and walls. The look of the painted elements might still evolve before the game is released but they instantly added something very important to the feel of the scene. The paintings seemed like a great way to point out certain gameplay elements and I went around adding the art everywhere.

 

The introduction to the part of the game and gameworld felt like a success. The space felt mysterious, abandoned or empty and old. With nice touch of creepy. This was the easy part of the process though. The main function of the level was to introduce a few mechanics and even a couple of new enemies. First one of the new enemies was the Keyu Shaman. A rot spirit bubbling out of a corpse with the power to revive fallen Keyus in battle. I wanted to create an area or two where no matter how the player played the game a Keyu Shaman would be able to revive a Keyu at least once. Making sure the player knew of their ability and how it would affect future battles against the fairly easy to kill Keyus.

I wanted to create a scenario where the player, not knowing what to expect was drawn into a simple and easy battle against two Keyus but a Shaman would be nearby to revive them if the player killed one. I tried a few solution sand found that the Shaman should be easily visible to the player but not as easy to get to as the regular Keyu Brawlers.

 

The solution was to make a room split in two by a broken floor. A path at the back of the room can be used to run up to the Shaman but the player would need to face the Keyus to get there. After some testing I felt the room worked nicely. The battle is simple and the new revive mechanic brings a new twist to the simple fight with Keyus. I felt clarity was king in the design here and wanted to make sure every player knew what the Shaman was capable of after the encounter.

I took similar steps designing the few remaining battles of the level. I put in a possibility try to avoid all out combat for the next encounter. Then I made a larger combat where the player would face two Shamans.

 

Suddenly the battle requires a completely different tactic from the Keyus in the previous level.
I felt like a more challenging variation of the big Keyu-battle should be put into another later dungeon in the game, where the player has more skills at their disposal.

Normally when I make a level I focus on giving options and paths but this time as we were introducing new mechanics, I tried to keep the areas simple. Open spaces and just the player party against the rotspirits, not too much anything else to add chaos. I felt like the first third of the game needed a bit of this clear and laid out style of design just so that players would feel like they aren’t making the wrong decisions. Later the levels open up and allow for many types of approaches but at this early stage it can be intimidating.

The big battle against the Keyus and two Shamans is definitely not a breeze even though the layout is simple and clear as you can see from the carnage.

I also spent some time thinking about how to make a temple with such a linear layout feel mysterious and like there was a function to the space a long time ago.
I made some spaces appear much larger and added areas the player could not reach such as the bridge on the lower level in this screenshot.

After this reworking of the structure of the level I felt confident it was doing its function in the bigger picture of the game a lot better. Guiding the player but letting them figure out for themselves how to best solve the encounters. I’m already excited about working on the other temple levels and taking them visually to the same level as the first one is while making sure each one has their own mood and feel.

It’s always fun to revisit old work and make sure it’s still up to par and sometimes the changes are small, sometimes quite huge. There’s one thing I hardly touched at all in the level in addition to the very first entry hall and it’s quite huge too. But I quess you’ll find out about that when the game comes out. …It’s a bird. It’s a huge bird all right. Huge bird fight.

 

Friday Rewind #9: Minimap

10.5.2019 - Jussi Kemppainen

Minimap

We have been working on various bugfixes and things this week. One level was even almost completely remade from scratch as we were unhappy with it.
But during the last few days I have been focused on our long neglected minimap.

Map terrain

For the longest time our minimap only had mission objectives and enemies visible. It was missing the actual map.

We were tossing around ideas of how to create the map. Hand painted maps, procedural generation and vectors were on the table.
For some reason we had ruled out simply rendering a second camera. I tried that as a minimum viable solution for now this week, and it actually looked pretty decent!

Markers

So, now we had a terrain. Next, I added visualizations for game characters. Simple stuff. it soon became apparent that we need to show the character direction on the minimap as well.

I also tested how showing the game cursor on the minimap feels. It felt great! Adding the cursor to the map made it so much easier to reference minimap locations to actual game screen data.

After adding the cursor, we felt it would be a good idea to also add the walk target to the minimap. telling the distances to the player better. It too was a great idea.

For enemies, I also made their markers appear when you examine the enemy. In the past, the enemy markers only appeared when the enemy was less than 15m away from a player character.

Fog of War

For rendering the fog of war on the minimap, I created a simple solution of rendering a plane in the actual game level, only visible to the map camera. The fog of was texture is rendered to the plane’s alpha channel and as it is in the actual level the minimap camera sees the plane and renders it in the minimap. The plane is hidden from the game camera.

 

Field of View

While I was at it, I also added a projector for the game main camera, projecting borders around the in-game field of view. When you moved the in game camera, the borders would always render on top of the game geometry at the very edge of the screen. I also made these borders only visible to the minimap camera. Bam, we had accurate, always updating representation of the game field of view in the minimap now no matter how the camera is oriented!

I am pretty happy with how the minimap got a long overdue face-lift with only a few days of focus.

Friday Rewind #8: Polish, polish and polish

3.5.2019 - HP Noronen

 

During the last week our focus has been very much on bug fixing and fine tuning gameplay flow and visuals in each level. We still have some bigger changes coming before we reach beta, but our main focus is on polishing and ensuring that all the levels work nicely after the recent changes.

Due to that, this week’s Friday Rewind is more about sharing a few recent screenshots with all of you, and about one minor AI improvement.

 

Improved AI group perception

There are many ways for AI characters and groups to notice the player and gain awareness of their situation. Firstly, all the AIs have visual and listening perception. This means that AI characters can spot characters by seeing them or react to some noise in theur environment. Such noises can be caused by running characters, explosions, combat, most spells, and many other things. 

AIs are able to communicate this information with other AIs in the same area that belong to the same faction. This allows enemies to engage in battle whenever their nearby allies notice the player characters. However, there are some situations where we would not want AIs to communicate with other AIs at a distance. This is the case in closed spaces where some AIs might be nearby but in a different room. In some cases, we would like enemies not to alert nearby groups of AIs for level pacing reasons.

In the screenshot below, we can see a situation where such an issues could arise.

The red rectangularish area is where characters are in combat with some of the AIs. However, in nearby rooms there are AIs that might traverse close to the combat area but behind the walls. These are marked as red circles. This could lead to them being alerted by AIs in combat. This is due to the fact that the actual distance between them is short, even though they might need to take a long route to reach the battle, or are behind thick walls that should prevent them being alerted.

To tackle these kind of situations, we improved our AI grouping so that that in addition to faction checks, we can define specific, smaller AI groups that enemies belong to. The communication between different groups is now much more restricted, and therefore by setting enemies in different rooms to different groups, we can eliminate most of those scenarios. It can still lead to situations where some noise can attract them, but those are specific cases which can be handled by level design choices.

Visual polish

As promised, here area  few screenshots of some of the polish done recently. These are screenshots from the mystical Forest Cover dimension, which was designed with a unique visual atmosphere.

 

Are you interested in hearing more about the development of Iron Danger, or having a chat with us?

If so, you are most welcome to join our Discord server at https://discord.gg/IronDanger

 

Also, please remember to subscribe to our mailing list. You can even win a free copy of the game through that!

Friday Rewind #7: Sliding with mecha bears

26.4.2019 – HP Noronen

 

Time to rewind and take a look at some of the recent improvements to the game.

Quadruped movement and inverse kinematics

One of the hardest nuts to crack in games is natural looking movement for quadruped creatures. Even though our game does not have that many of those (at least not yet), there is one that is really massive and therefore all the issues with movement show up even more clearly. That one is our mecha bear.

We’ve had two major issues with bear movement. Firstly, we’ve struggled with the monster’s feet sliding very visibly during turning. In addition, matching our turning animation blending with the character’s actual facing has been pretty clunky in many cases.

Lately, we’ve been working on improvements for it, and we’ve made some nice progress. First of all, we decided to implement IK (inverse kinematics) for the feet to ensure that there would be less sliding due to terrain itself. For that purpose, we picked Final IK from the asset store. Even though Final IK had some initial issues, such as its quadruped grounding scene bugging badly, it ended up being reasonably easy to get a first draft running with it, and in a couple of days our bear was walking quite nicely in uneven terrain. So far, it has proved to be a very good addition to our toolkit.

Some clips of the smooth progress to get IK working as it should

 

However, the foot sliding and clunky turning were still major issues. To tackle the turning, we once again went with IK and configured the character’s head to use Aim IK. At the same time, we totally got rid of special turning animations and only used the standard walk and run cycles in combination with Aim IK. In addition, we made some changes to turning and path prediction logic for the AI. When these were combined, we were looking at quite nice, smooth turning animations, which was a huge improvement over earlier.

Smoother turning, but with foot sliding


As the foot sliding was still an issue, we decided to go and implement a small extension to the IK system that allows us to “glue” the grounded feet to the same spot on the round until certain conditions are met. As this is tied to the IK system itself, it helps the feet to stay on the ground a bit better when turning. This does cause a bit of jerkiness and snapping in some cases, but with some smoothing it’s not really a problem anymore.

Tackling foot sliding with our own "glue"

 

So, it’s been quite a task, but there’s been lots of progress as well. There is still some work to be done getting the movement to look even smoother, and to get rid of some bugs that still happen with rewinding IK, but we are getting there for sure. One thing that I’d still like to try out is to blend our current attack animations with aiming IK, to get turning while attacking to look more smooth and natural. However, that is such a level of polish that it remains to be seen if we’ll have time for it.

 

Improved fog of war

As discussed in our earlier post about fogs, one of the fogs that we use in game is fog of war. It’s both a visual treat, and important in hiding areas that the player hasn’t investigated yet, where we may have surprises waiting to be revealed only at the right time. 

For fog of war, we have used a 3rd party volumetric fog plugin that is also available in the asset store. The plugin has worked quite nicely, but it’s also had a blocky look that’s not quite on par with the rest of our environment graphics. We decided to give an updated version of that plugin a try. With the new version, we have a more smooth look for our fog (in addition to some other improvements).

Comparison between the old (below) and new (upper).

 

Are you interested in hearing more about the development of Iron Danger, or having a chat with us?

If so, you are most welcome to join our Discord server at https://discord.gg/IronDanger

 

Also, please remember to subscribe to our mailing list. You can even win a free copy of the game through that!

 

 

Friday Rewind #6: UI Polish

19.4.2019 - Jussi Kemppainen

 

We are deep into polishing the game, and this week I spent some time working on the UI – especially our timeline.

Timeline Visuals

First, I redid all the UI elements with a more hand drawn style we have been gradually bringing everywhere in the UI. After this step, we added a preview for how many heartbeats (our action points) it takes for a character to move to a certain location. As we were talking about icons we could use there, we thought about using a heart to tell that this number is heartbeats, but that makes no sense as heart is health. The we talked about using an ECG as an icon for the heartbeat and immediately it clicked that instead of using dots to mark the cut off points in out timeline (like we used to) we should use the ECG curve to separate the heartbeats. So we did.

Also, I added a clearer indication for the currently selected timeline (blue border). It is now much easier to see which timeline is active. I also added a blue container to mark the currently on-going heartbeat to better visualize what the current time is.

Action Predictions

Small changes were made to the way we visualize predicted actions, as I already mentioned, we added a number next to the cursor when in walk more to show you the amount of heartbeats your movement command is going to take. We already were showing that on the timeline as ghosted action cells, but as it turns out, that information was pretty hard to translate into useful information in the player’s head. We now do both, show the number and show the prediction.

The color of the prediction was also changed, it is now orange, so that it is clearly visible on the blue timeline. Also the prediction is now slightly larger that the committed action, so that predictions and existing actions overlap better.

Hotkeys

We also finally implemented the hotkey-system. Adding hotkeys to all commands. The hotkey is also visualized in the UI to make selecting skills using the keyboard much faster!

Damage Indications

I had always planned to have the timeline break apart when the player character receives damage and now I finally got around to adding it into the game. I think it really emphasizes the damage events and makes them stand out from player’s own actions.

Someone on our community Discord server also suggested us to flat-line the ECG after a character has been killed, so I suppose we will add that feature next!
Why don’t you jump in to give us share your great ideas with us as well!

 

Friday Rewind #5: Dive into the depths of the fog

12.4.2019 - Jussi Kemppainen

Fog Sandwich

As a great fan of old-school adventure games. I wanted to achieve some of that aesthetic in our game as well. For me, the clear style choice those games utilized was the black void around the scene.

The volumetric upgrade we started last week was finalized this week. Which is a huge contributing factor to this look. As you will see.

Image copyright LucasArts

So, the ways we used to achieve that iconic look, was to create a way for us to dim the foreground and add black to the background. This is how we built that look.

 

Foreground

The first thing we did was to add an inverted fog to our game view. A fog, that makes the foreground completely black. We also animate the depth of that fog based on camera distance from the player character in order to control it’s effectiveness more.

Game view without foreground fog.

 

The same view with the fog dimming out foreground objects.

 

Background

The “unfogged” base image.

Our base render of the game is pretty contrasty. This is by design as the post effect we will lay on top will affect the look a lot.

Distance fog

Fog-of-war applied. This further makes the image dark and even empty. Wait for it.

Instead of creating the background with a distance based fog, we opted to go with fog of war. A dark area that will be cleared when the player moves into it. To me, this feels like uncovering a mystery. Like exploration. It has no game-play value for us, the fog of war has no effect on aiming or AI functionality. It is purely a stylistic choice and I just love how it feels. I think it reminds me of the original UFO: Enemy Unknown.

The black fog of war alone is not a good look though. It makes the game look super dark and low quality. So we need something to counter that look.

Volumetric lighting

Boom! The final image with all layers of fog applied on top of each other.

Volumetric lighting simulates the humidity and dust in the air. We can add a really nice layer of depth and really boost the look of the lighting by adding volumetrics to the mix. The solution we are using is called Aura 2 and it is really really good! It allows us to precisely control the look of our dark backgrounds and the dusty / humid illusion in the atmosphere. Our look highly relies on the atmosphere being visualized as you can see in these screenshots.

So there you have it. Our method of creating the look of Iron Danger!