Spy DNA development update 2018-02-23

By Jason Sams, Lead Developer

It’s been a while since my last update. I’ve had my head down in the game code making some fundamental changes. We have made major changes to the AI system, character customization, hit location and damage system, level designer, asset loading, modding support, and a few other things. 

Let’s start with character customization. We put a lot of effort in making the players character fully customizable. Now a few of you gave us a hard time for going overboard here. The reason we put so much effort into this is we unified it with NPC generation. This will let us generate much more unique NPCs for each mission and avoid repeating the same character models over and over.

New game screenshot

During character creation you will be prompted to choose your commanders frame (skinny, average, or heavy), and condition (pro-fighter, fit, average, nerd). This choice determines which character model you will see in game and will also change your attributes. The condition choice biases your attributes towards physical or mental, while the frame choice is a speed/dexterity vs strength/toughness choice. 

Related to this we implemented our appearance reaction model. Each appearance item is rated on several metrics, such as Serious, Classy, Scary, and the ability to conceal weapons or armor. So while you may want to bring the heavy armor to the dinner party, doing so will make it much harder to get people talking, at least by verbal means. 

Wardrobe screenshot

Speaking of armor, we added the armor options to the wardrobe screen. You can now equip your characters with a variety of armor and storage options. I’ll have some updated screenshots of the overhauled equipment screen soon. Armor in spy dna is now working as intended. Armor resists bullets and other weapons, but for it to work, the weapon needs to hit the armor. This makes your aim point really matter. Unless you have the heavy weapons out, you will want to try to avoid hitting the heavily armored points on a target.

Character status screen

We updated the status screen to show where the shots have hit a character. The length of the marker changes depending on the penetration of the incoming round. The diameter represents the damage level of the shot. The hits are colored based on result. 
Green = fully blocked by armor
Yellow = blocked by dermal armor, probably still really hurt though.
Red = call the doctor and make an appointment

Attributes screenshot

We are scanning the shot against the polygon mesh of each piece the characters are wearing. We don’t want near hits/misses being mis-reported by the engine.

We have also been cleaning up the UI. We moved from using pre-drawn icons for the party to using render targets and snapping them in game. This means they will reflect the current state of the character. If you change into a delivery worker outfit to sneak into a building, the portrait will update on the fly.

Skills screenshot

And the final bit for the update is the changes to the inventory screen. We have moved a few things around and made room on the left, under the item image, for attachments or modifications. 

Inventory screenshot

We have also put a lot of time and effort into performance work. To give you just one example: The time from a level loading until you can start moving has been reduced from a minute or more it could take in the past, down to about a second. The pathfinding will prepare in the background now, using multiple cpu cores to speed things up if available.

While we basically had Spy DNA up on jackstands with the engine out and all kinds of parts strewn all over the place, it was challenging to really show and explain all the things that we had in-flight. But now that we have put the thing back together, we’ll be sharing updates on a more regular basis.

Stay tuned.

Getting ready for Early Access

It’s been a heads-down month here getting ready for early access. I’ll talk about what we are doing to go from demo to a full game. The transition from demo to full game for us has been about adding progression and content. 

The first big change is the result of a mission now affects your game. You can now also train your team at the base. Wounded characters will need some time to heal at the base before they are available for future missions. We’ve implemented the save game system and made the full character roster available. It’s all pretty obvious stuff, but it still needed to get done. 

While on mission, a character can advance their skills by using them in the field. On the skills page you will now see a count of how many times that skill has been used. Each use will improve the skill. 

The amount of the improvement will depend on several factors. First, each skill has associated attributes which govern how well your character can learn the skill. These are separate, though possibly overlapping, from the attributes which bias the ability to use the skill. For example “mental motivation” is a factor in learning most skills, however, it is used in few skill checks. These determine the character’s learning rate modifier for that skill. 

In addition each skill has a base learn rate to adjust for skills that are used frequently vs rarely. For example we don’t want to penalize hacking and lockpicking progress just because there are fewer chances to use the skill. 

Back at the base, skill training is a passive activity. You can assign each character two skills (primary and secondary) to train. Then as each day passes, any characters at the base that are healthy, will train those skills. So characters that are not taken on missions will still be making progress. A character that is not healthy may still make some progress. For example, a broken leg will prevent training physical skills, but would allow the character to keep working on mental skills. 

Injury recovery is similar to training at the base. A character will survive a mission as long as they are alive at the point when the “end mission” screen is triggered. In theory we can simulate post-mission death due to injury, but that would be an opt-in for extreme difficulty. Because we track each injury a character suffers, we do healing per-injury. Different injuries can heal at different rates. As they recover, they will automatically resume training as their health allows.

In the case of non-fatal injury to the Commander, if one or more other characters are available, you will be able to designate an acting commanding officer to cover the Commander’s duties and lead the squad on missions until recovery. If no one is available, time will fast forward until the Commander recovers. 

For early access we also wanted to make the full character roster available. So in addition to Ivan, Karsten, Nuri, and Zoe from the demo, you will now have Alexey, Marguerite, Ronda, Shinichi, and Rustam. 

Saving and loading has been implemented. The game will now autosave after each mission at the base. For initial early access saving will be limited to while at base. We will implement saving while on mission later.

We also have been hard at work on the UI. We received a lot of feedback about the look and feel of the UI and have responded with some improvements. Functionally the location of the controls is largely unchanged. What we have done is softened the appearance of the buttons, borders, and dialogs, and replaced some of the radio buttons with icon based sliders that make it easier to visualize how the controls work together.

We published a video for those wanting to see more of the new UI.

One final change for realism and game ballance we’ve made, was to implement the penalties for attacking moving targets. Simply put, it’s harder to hit something that is moving than something that is still. The mechanic implements this is two ways. One, there is a penalty to the circular error probable (CEP) for any given aim time. Two, the moving target limits the amount of time that can be spent aiming. The strength of the penalty is based on how fast the target is crossing the character’s field of view and how far away they are.

The first batches of character voices have started to arrive. Each playable character will have an unique voice and persona which they will use to acknowledge your commands and give you status updates.

The last area of getting ready was the implementation of settings screens. We have made a pass over all the sound effects and broke them into channels so each can have its own volume control (music, ambient sounds, combat sound effects, player character voices). We have also started implementing the settings for difficulty and new game options. These will be exposed soon.

With all these changes, the core engine of Spy DNA is pretty much ready for early access. What we are finishing up now is getting enough of the missions ready that the game has some content to go with the engine. 

Lumberyard

It’s been a really busy two months here at Shy Snake. We have made a few adjustments to the development of Spy DNA which we think will make for a better game. The big change is we have moved from Unreal to Lumberyard game engine. This also created an opportunity to make a few other smaller changes to the game.

We decided to move to Lumberyard because it allows us to make much more dynamic maps. Unlike other engines it doesn’t require us to pre-bake lighting to get good quality lighting on the maps. This frees us up to procedurally generate maps, allowing for a greater replay value and much more variety in missions. It also allows us to change the maps on the fly in response to player actions. This means a more destructible world. 

We are mostly complete with the port of the game code to Lumberyard. AI is the last major piece left to do. At this point the UI is mostly complete, the game logic code is ported, animations are working, and we integrated the articy code for the dialog system. We are still on the same schedule as previously announced with a public demo / early access, possibly as early as December, but for sure in Q1 2017.

Animation is another area that was impacted by the change. We are switching from in-place animation to root-motion animation. What this means for the players is the characters should move in much more realistic ways. The characters’ feet should slip far less. Also we added start, stop, and turn animations so the beginning of movements will look a lot better. 

The transition required us to re-import all of our art assets. We took this as an opportunity to replace our character models with higher quality models. To do this we switched character creation tools and are now using iClone Character Creator. 

Same character created in Autodesk Character Generator on the left and iClone Character Creator on the right.

Now that we have worked with Lumberyard for almost two months, we have learned a lot about it. If fits very well with our code base. As we have settled in the level of productivity on our game, code is settling at a higher level that we achieved with Unreal. This means we will be able to put more effort into building a good AI for you, the player. 

Now it’s not been all positive. On the art side things are going a bit more slowly. Lumberyard is an editor in transition which has created some overhead for us in making maps. In part this is offset by switching many maps to procedural generation. However, it will be a bit before we can show you the before / after of the player base. Yes, even though we can now procedurally generate maps, we can also still hand-generate them. 

We will have much more on this going forward. I believe the engine transition will allow us to ship a game which is more in line with what our players expect. It allows us to generate a much larger variety of maps, allows you to have a larger impact on the map in terms of being able to destroy objects, and allows us to invest more heavily in AI making the gameplay more interesting.

Demo Complete!

We finished putting the final touches on the demo and are sending it out to a few testers tonight.  Once they have had a chance to play with it and we address any issues, we will send it to a wider list.

We have also decided to make the demo available to anyone that has backed our Kickstarter campaign at Beta or higher.  I.e. those that wanted an early look and were willing to put up with the limitations of early builds.  It’s around 1.4Gb for the two demo levels.  

One of the good side effects of working on the demo is it forced us to address some long standing bugs that we had been putting off.  

Examples:

• Write a manual
• Add objectives to the maps
• Sort the dialog answers so “goodbye” was always at the bottom
• Put the status indicator over the character portraits
• Assign skills to the NPCs

We also added the end of mission screen which includes the status of the objectives, the party, and some statistics about the equipment used.

We also added an “event cam” to the game.  It’s purpose is to highlight important events to make sure the player is fully aware of what is happening in the game.  We will add settings for the final product so players can customize which events are highlighted.  

Changes of note:

• Added check marks to objective list

• Made movement modes available to AI waypaths

• Maps can now specify if the characters start with a weapon equipped

• Hide shooter weapon in gunsight cam to avoid possibility that weapon would block view

• Fixed bullet trails and sounds for some weapons

• Enabled event cam for kill shots

• Fixed AI bug that cause NPCs to sometimes empty the clip into a already down character

• Taught AI to reload

• Added medium and heavy combat armor

• Fixed icons for armor

• Tweaked ROF for a few rifles

• Added new pistol models

• Added descriptions to armor

• Fixed bugs applying armor to hits

• Added keyboard shortcut for previous and next target visible to selected character

• Replaced generic sounds with per-character sounds

• Removed occlusion check for muzzle flashes.  Was causing flicker.

• Greyed character portrait when stunned, unconscious, or dead

• Set skills for all NPCs on demo maps

• Replaced placeholder NPC models with correct models

• Fixed bug causing turns for unconscious characters.

• Reviewed max-texture sizes for small objects

• Added post-mission summary and stats screen

• Fixed bug with default aim point after a melee attack

• Updated 3D queue overlay to fix bug with stuck targeting line

• Fixed gun empty sound

• Hide contact counts when character is unconscious or dead

• Added sorting support to dialog answers

• Changed default to show long answers rather than short summary

• Fixed cursor hitbox for hud to resolve small dead-space area

• Added skill check for spotting and rate limit spot checks

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.

AI 

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. 

Dialog 

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. 

Objectives 

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. 

Maps 

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. 

Misc 

• 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. 

Combat in Spy DNA

This is Jason with an update on the Spy DNA combat system.  We’ve been making some graphics and demo videos for our Kickstarter pitch, and I thought we should share some of them with you. In today’s post, I’ll start with our new gunsight, that we use for aiming, and then move on to the combat system.

In Spy DNA we have put a lot of thought into making combat feel as real as we can.  One of the areas that’s often disappointing in games is the critically important mechanism you use to attack the enemy. 

Most games assign a character a simple chance to hit, usually modified by range and cover.  We use a full 3D world instead.  To avoid the problems, such as identifying obstacles and cover, when aiming in the  top-down view, we open a gunsight view when you pick a target.  

Single shot firing sequence

The biggest thing we do differently is replace the “chance to hit” with “Circular error probable”.  The rings around your aim point represent the 50%, 90%, and 99% likelihood of your shot landing within those rings. 

You trade off time aiming for more accuracy in your shot.  You can adjust it to try to get the first shot off quickly, or take some time to make sure you hit. You can also adjust the number of shots, burst, or burst length.  

When using automatic fire, burst or full auto, recoil will reduce precision of later shots as recoil adds up.  For single shot and burst your character will re-aim so follow on shots meet the same accuracy requirement you set.

Our damage model is based on your weapon and where you hit the target, not on a random dice roll.  So you will be able to aim for weak spots in the armor or for vital parts of your target.  Cover is handled the same way.  The ability to move the target point around lets you aim for exposed parts of the target. 

Now let’s talk about how our combat system works. We call our system Concurrent Turn-Based.  I’ll explain what this means.  We differ from traditional turn-based games  in some important ways.  

Let me start with what we are trying to accomplish. 

1. The player should have time to think and take in the battlefield and environment.  
2. The moves available to the player should as close as possible mirror the options that  a real-life soldier would have.
3. The results of actions should be be realistic.

After a lot of experimenting we have settled on a system where the game focuses on a character when it is their turn to start their next action.  So while combat is ongoing, the game engine cycles though characters as their turns come up.  In this way it feels like a traditional turn-based game.  There is one very important difference.  While the game is progressing to the next player turn, every character and object in the game moves.  

This was not a decision we took lightly.  We made this decision to avoid the time quantization problem that traditional turn-based games have.  Think of the frustration where near the end of the player turn you move a character and trip one or more enemies.  Now your character (or whole party) just sits there helpless while the enemy takes a turn (or full round) worth of actions.  This is a side effect of games trying to map combat to a mechanism that doesn’t exist on a battlefield.  

In Spy DNA we are trying a more direct simulation of the world.  The character that makes contact would actually have the initiative.  The characters that spots them would make a reaction time roll (based on their attributes and combat experience) to see how fast they can react.  Also because other characters in the player party may be mid-action, such as movement, you could cancel those long actions and give them a new task.

I made a short video where a character ambushes two unaware NPCs.  The action commands I give the game are:

• Throw a grenade
• Draw my pistol
• Crouch
• Aim and shoot to finish off the second target

About three seconds of game time actually elapses in this demo.

Compared to Turn Based games, we have two major differences.  The first is turns in Spy DNA are not uniform in size.  Turns come up as the character completes their previous command.  This means that fast actions such as firing a single shot will result in that character's turn coming up again quickly.  Slow actions such as moving a long distance will mean many other characters are likely to take their turns before coming back to that character. 

The second major difference is the turns progress concurrently, i.e. all at the same time.  So if you give a move order to one character, and a quick attack order to another,  each time the second character attacks you will see the first make some progress on their move order.  In effect, you will see time progress forward for everyone until one of your characters completes all the commands in their queue.

Should a character spot something needing your attention while they completing an command, the game will stop and focus on the character.  This allows you to react to things that come up mid action such as an enemy coming around a corner.  

I hope this gives everyone a feel for the type of gameplay we are trying to deliver.  

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.