Gameplay and difficulty settings

by Jason Sams, lead developer

This month I’d like to show how players will be able to customize their gameplay experience when starting a new game. We previously showed the character customization screens for new games, and now we can show the first draft of the gameplay and difficulty screens.

First I want to talk about how we handle PC deaths on a mission. A death of the commander will always be a game-over event, where you will have to reload from a save (unless in Ironman mode, in which case the saves will be destroyed when Commander dies).

For the remaining members of the party, we’ll be implementing three options. The first (already done) is permanent PC death. This means that if a player character dies on a mission, they are lost for the remainder of the game. Now this may be considered very harsh by some players, so we will have two less severe options.

Spy DNA (64-bit DebugGame PCD3D_SM5)  2019-05-30 16_44_20.png

The first is cloning. If a character dies on a mission, they are lost for the remainder of the mission, but once you return to base, their clone will be thawed and they may continue on, sans any experience from that last mission.

The third option replaces death with being critically wounded. The PC can be rendered unconscious on a mission, but will recover once you return to base.

Next thing I want to talk about is the ability to adjust the randomness of skill and attribute checks. This will impact things such as lock picking, disarming traps, charisma checks, etc. We will give the player the ability to adjust the “fuzziness” of these checks. At one extreme, full deterministic, if your skill is greater than the check difficulty you always succeed, if it’s less you always fail. At the other extreme, skill checks are highly randomized, and luck and skill will have roughly equal weight.

The remaining gameplay options are about the type of missions you will be given, and the amount of time you’ll have to complete them. For non-storyline missions we have a pool of mission types available at any point. The sliders for mission intensity and map size will bias the selection from that pool, so the side-quest mission you see will be weighted towards the mission types you prefer.

Now for difficulty, we have talked about Spy DNA being a combat simulation. We want to maintain that feeling on both the difficult and easy modes. We do this by not altering the basic combat system, or adjusting the enemy AI. Instead we can adjust the strength of the player and the enemies.

Spy DNA (64-bit DebugGame PCD3D_SM5)  2019-05-30 16_45_19.png

For player characters, we allow some change in toughness. We do this by altering the strength of the genetic enhancements the character receives.

We also provide an adjustment for the starting skills and skill learning rate. Effectively this acts as an XP multiplier allowing the players to progress more or less quickly. The effect of both of these will be minor.

The last thing that affects the PCs is a “bad luck” adjustment. We give the player the ability to curtail random catastrophic events in combat. We do this because with a true combat sim, a bad luck event, such as getting shot in the head, is usually lethal. This will have three settings, “no one-shot kills,” each PC gets one exception per mission, and realistic.

The final knob we have for adjusting the difficulty is similar to the player options, but applied to the NPCs. You will have the option to adjust how good of equipment the NPCs get, both armor and weapons-wise, and how skilled they are.

We feel these difficulty settings will work better with our mission design, instead of adding more enemies or trying to vary the intelligence of the enemy AI.

Next month, luck pending, we will have another gameplay loop video. We want to re-play the same mission we showed before with all the progress we’ve made on map generation, AI, and attack types.

Combat hesitations

by Jason Sams, Lead Developer

In Spy DNA we have talked about how you can queue actions for your characters. When we were discussing the difference in behaviors of well trained troops or agents, vs thugs, vs civilians, one of the things that came up is how quickly a character can evaluate the situation and choose their action.

One of the concepts we have introduced to represent this in-game is the idea of a character being indecisive. To model this we introduced a skill called “Combat Tactics”. It’s a passive skill.

We used to key a character’s combat response off of their highest combat skill, but after thinking this through, we concluded this was not an accurate portrayal of how people respond in a tactical situation.

Let’s say we’ve got someone who’s a very skilled marksman while shooting at the range, but has no actual combat experience. Such a person would do worse in combat than a basic soldier who may have a significantly worse shooting skill, but has been trained specifically for a combat situation.

The new “Combat Tactics” skill will use mental quickness as its primary attribute, and mental memory as its secondary attribute. When an NPC decides to change their course of action in response to something it sees, this skill will be used to generate hesitation before starting the next action. This means some civilians and green troops may freeze for a bit once things go loud.

So how does this impact PCs?

When a PC is carrying out their queued actions this will not affect them at all. However, should you cancel your action queue, we will generate a hesitation for the character to represent this changing of their mind. Some PCs will be able to do this almost for free, either due to extreme mental quickness (Margo), or lots of training (Ivan). On the other end of the spectrum, avoid changing things up on Karsten, who’ll need some time to figure out the next steps. In effect it will be important for some characters to stick to the plan, whatever plan you made.

The “Combat Tactics” skill will improve with use, but the governing attributes will still have a large impact on how fast a character can respond to the change of orders.

Demo development update

This is Jason with a long[ish] update on our progress towards demos. We have been hard at work getting a demo ready. I wanted to give everyone a feel for what it’s like to develop a game with a small team.


Shipping a demo with combat requires the AI to behave in a reasonable way. Up to this point they have been heavily scripted, but to make a more interactive demo we have accelerated implementing a few things related to perception and reaction to threats. 

  • We now simulate “a quick glance”. If a character hears a noise and the source of the noise is in their line of sight but not field of view, they now have a chance to also visually detect and evaluate the source. 
  • We revised “contact tracking”. Previously the fog of war system was too aggressive hiding characters within the line of sight but out of field of view. Now you can track due to sound and neutral and friendly contacts are retained for longer. 
  • NPC AI now has separate tactics and actions. This allows them to return to their previous actions when interrupted and make better choices about when to take an interrupt vs continue what they were doing. 
  • AI commands can now be issued from the dialog scripting language. This was a temporary regression from switching to the new dialog editing software. 
  • Changed vision markers to appear if any party member has contact with enemy, not just selected character. 


Alex has been entering all the dialog for the demo and initial levels. This has exposed a few issues during testing and we have been fixing those as they pop up. 

  • Scripts can now be attached to any dialog node. Previously they only worked on player answers. 
  • Added support for N-way conversations. Previously dialogs could only be between the player and one NPC. 
  • Some sequences would cause the wrong portrait to be displayed in the chat. This has been fixed. 
  • Added scripting command to make a NPC face an object. 
  • Added scripting command to play a specific animation. 
  • Added item list to instruction nodes to allow item transfers between NPCs and player inventory. 
  • Characters now play a conversation animation while talking. 
  • [todo] Add sorting option to answers Fixed bug where NPC could interrupt an existing chat to start a new one. 


The game has always had a plan to present the player with specific mission objectives. We decided to pull this in [schedule wise] for the demo. So about three days ago I started implementing the objective screen. 

  • Implemented an Objectives tab in the character screen. 
  • Added a place to edit the objective list in the UE4 level editor. 
  • Linked the text descriptions to the description objects in the dialog editor. 
  • Added C++ code to track progress of objectives. 
  • Added C++ code to display objective state changes (complete or failed) to player log. 
  • Added objectives to test map and played though. 
  • Fixed bugs resulting from above additions. 
  • [todo] UI cleanup of objectives screen. Display check or X for pass and fail. 


Alex has also been cleaning up the base map for the demo. We should have done this one earlier because the improvement in graphical quality have been huge. 

  • Review post-processing settings for map. 
  • Reviewed lighting on map. Added descriptions to items, which will appear in-game as tool tips if you hover over an item. 
  • Fix some material issues where the materials were too metallic (too reflective). Floors are never clean enough to behave like a perfect mirror. 
  • Fixed window transparency to work with the fog of war. 
  • Added AI paths and tasks to NPCs on base map. 
  • Added lots of environmental items to make the map look more like a real office environment. 


  • Fixed bug where weapons could fire in a wrong mode if the player used the default mode. 
  • Added contact counts to character portraits, showing how many friendly, neutral, and enemy NPCs a character perceives. 
  • Fixed bug with NPC movement that would sometimes use the wrong movement speed (e.g. walk instead of run). 
  • Fixed bug where movement animation would not stop when a character finished following another character. 
  • Moved item descriptions from in-game editor to external tool to support localization. And yes, we hope to have the resources to localize the game. 
  • Fixed character names getting corrupted in event log. 

I hope this gives everyone an idea what two weeks of development here at Shy Snake look like. We operate at a higher than normal velocity and want our backers to know about the progress we’ve made. 

Spy DNA gets a UI update

Jason from Shy Snake here with some screenshots from our UI update. We’ve been working through our UI, going screen by screen, to make it easier on the eye. While doing this, we have kept our focus on presenting information clearly to the player.

First up the attribute screen. This posed a bit of a challenge for us because we have a larger than normal list of attributes. We chose to have many attributes, to give each character a unique feel. For example rather than simply making a “strong” character you can be quick, powerful, or have great stamina.

Each primary attribute has three sub-attributes within it, to give the character extra detail. For the players that don’t want to see this level of information you can simply look at the major groups that give you an overview.

Next up the inventory screen. Here we went with a pretty standard list of icons with numbers to designate stacks of items. Selecting any item will fill the right side with a description of the item.

In this screenshot you can see some details on one of the games weapons. I’m taking this as an opportunity to show the attention to detail we put into the weapons in this game. While the values are not final you can get an idea of what we are building. 

At the bottom of the inventory screen you can see how we track encumbrance. In this case the character is lightly loaded so the effect is minimal. No significant effect on walking speed but a minor one to sprinting. We talked at length about the mechanics in an earlier post but here you can see it in action.

We've worked hard to make these changes, and the work isn't quite done yet. Tell us in the comments what you think of these updates!

Development update: UI

We've been working hard on the UI for Spy DNA.  One of the challenges with creating realistic combat is how to present the many options that are immediately available to a real combatant in a simple and intuitive UI.

We recently did our first round of play testing.  The chance to observe people playing is very valuable to a developer. From this we made a list of UI interactions the players didn’t find obvious and have addressed each one.

One example of this is the action of changing equipment.  Watching people play a common pattern was to pause the game, go through inventory and find the weapon they wanted, then equip it.  Now because the game is timeline based this would generate an action to equip the weapon.  However, since the game was paused, it didn’t immediately appear equipped.  This created confusion.  So we now show the state at the end of all queued actions where appropriate.  

For interacting on the 3D map we moved from placing all the controls on the HUD to popping up context-sensitive controls where it makes sense.  Now you can quick-click an enemy to attack as before.  However, a long click will open up a menu with all the various attack options for the combination of attacking character and target. A quick click executes the default action as before.

The same applies to movement.  Clicking on the map selects the default movement speed.  If you hold down the left button for about half a second the speed options also appear. 

Some controls such as character selection and character state remain in the HUD.  The idea is the state of the currently selected character should always be visible and the common controls ready.