Complexity in games

By Jason Sams, Lead Developer

I want to talk about complexity in games. I think complexity is a very misunderstood subject. Game developers are sometimes seeking to “simplify” where there’s no need, while at the same time adding complexity without realizing it.

What is “complexity?”

When I say “complexity,” I mean specifically “perceived complexity.” In other words: Is the action considered easy or hard for a human to accomplish?

Here’s a practical example: If I asked you to throw a ball at a target, would you consider that a complex or difficult task? Probably not. However, hitting a target with a projectile is a task complex enough that solving the math behind it drove the creation of the first computers.

When video games were created, lobbing projectiles at things was a rich enough subject that entire games were built around the idea, such as Artillery Duel and Scorched Earth.

Let’s look at a more recent example. Is driving a car complex? Most people consider it so easy that they do all sorts of other things while driving. Yet teams of engineers are still struggling to teach a computer to do the same thing. Analyzing visual data is so challenging, that they have to use additional sensors (Lidar) that humans don’t have, or need. Objectively, driving is very complex and yet it’s still easy for humans.

And again many games are built around the idea of driving (or flying). Most of those games are considered very easy to pick up and start playing. Perfecting your technique and winning is the real challenge.

What about an opposite example? Multiplying large numbers is so simple even a phone can do it a few billion times per second, yet ask a human to do it and many would rather drive to buy a calculator. No one would make a game like this outside of education.

In context of game design, we’re interested in complexity as perceived by a human player. In our case we are specifically interested in making the mechanics of the game easy to grasp. This idea has been a driving factor in the design of Spy DNA and is also the reason for us calling the game a Simulation RPG. (Side note: it’s also led to way more UI iteration than we ever envisioned.)

Our combat system is designed to be the best simulation we can make of combat. We chose simulation and not the traditional turn-based approach to solve the problem of perceived complexity vs. actual complexity.

I’m a big fan of realism in games. Nothing will frustrate me more than when something happens in a game that makes no sense in the real world. Some examples:

1: You move a character one step forward, you trigger an enemy group, that now all get to activate, move several times farther than your one step, and possibly attack and kill your character. All this before you can even react.

2: You find a new item in game, yet you can't use it because of some attribute or skill check. The worst ones are the cases where you lack “strength” to wear an item, yet, toss it in the backpack and you can be lugging several of them around despite them being harder to carry that way.

3: You sneak up behind a target and make a surprise attack. You stealthy weapon fails to penetrate the armor despite hitting a spot where there was none (visually). The enemy then turns around and kills you.

What all these things have in common is they are results of artificial rules imposed by a game system that don’t exist in the real world.

Human brain is very good at understanding natural things such as physics (throwing something), or processing an image, but dealing with large numbers of artificial rules is not something that comes to us naturally. Therefore games that go down this path are perceived as complex for the player.

Not all complexity is necessarily bad. There are many popular games built around artificial rules, chess being the first that comes to mind. Add a little random input and you have pretty much every card game ever. In these cases managing and exploiting the rules becomes the focus of the game.

In Spy DNA, we want you to feel like an agent in a believable world, where things that should work actually do work in-game. Or put another way, we wanted the combat system to be intuitive and realistic. We wanted the game to be about Spy DNA world and not about the combat mechanics.

When you play Spy DNA, one of the things you will notice is that we have a lot of attributes compared to most RPGs. I’ve heard people give talks saying that six attributes is too many for an RPG, and I consider that silly. I mean, if a console sports game can have 38 attributes (MLB the show), I don’t see why a serious PC RPG shouldn’t have more than 6.

 Yes, this is a scroll bar in the attributes screen!

Yes, this is a scroll bar in the attributes screen!

This is where we clearly see the difference between perceived vs. real complexity. By all accounts the simulation in the MLB game is more complex, but because each attribute is clear and easy to understand and relate to in real-life terms, it never feels difficult to understand or play.

By comparison, when you have too few attributes, the attributes have to stand for things that are not obvious from the name, such as using dexterity for speed, strength for hit points, or intelligence for spellcasting. Each game has a slightly different system, making it necessary for the player to learn a new set of artificial rules with each game. Learning abstract rule sets is a thing that humans aren’t very good at, and therefore perceive it as complex.

How could having more attributes actually make a game seem simpler? The primary way is to map the attributes to “things a human intuitively understands.”

In Spy DNA we have 21 attributes in 7 common groups. We use groups, so that players used to traditional RPG systems would immediately be comfortable. The groups simply provide the average of the sub-attributes for quick reference and ease of picking up the game for those familiar with other systems. Within each group we provide the details, so it’s intuitively clear what’s really going on.

 Screen capture of Spy DNA character attribute screen

Screen capture of Spy DNA character attribute screen

Let’s looks at dexterity, using the party sniper, Zoe, as an example. At a glance you can see at 81, dexterity is a strength for the character, as you would expect for someone specialized in ranged attacks. However, with our focus on being realistic, we break down dexterity into Dexterity, (could also be called manipulation), reaction, and flexibility. In this example the character has a clear specialization. You can also see from the description she has a “+40 enhancement”. This comes from the genetic enhancements which put the “super” in “Super Spy”. As a result of these you can end up with values in excess of the natural human limit of 100.

Reaction is simply reaction time and impacts reactive movements (duh). In-game it will make you harder to hit in a melee fight, and help with any other action that depends on quick reflexes.

Flexibility is important to martial artists or characters that want to sneak past alarms or hide in places you wouldn’t assume someone normally fits. 

By being explicit about the common traits that a character may have, it should be actually easier to parse what the attributes actually mean for gameplay. We feel that this is better than a giant array of perks because it’s clear and straightforward.

When it comes to combat, we try to simulate the world as it is, and not require people to learn a unique set of made up rules just to play Spy DNA. Let’s take cover as an example.

In some games cover is measured in increments (high, low, none), or as a percentage. In these examples the cover makes it proportionally harder to hit the target. So far so good. Now you need a mechanism for attacking a target in cover. So these games introduce the idea of “flanking”, or moving to a position where the cover doesn’t apply. Typically these are done on an all or nothing basis, leading to frustration as your character can clearly see and hit the target, but because you have not triggered the arbitrary rule that says you’ve “flanked” your target, you still miss.

In Spy DNA we deal with this in a straightforward way: if you can see it, you can shoot it. Humans understand intuitively that the more of a target is exposed, the easier it is to hit. How much easier? We solve that problem visually. We present the player with a picture of their character’s viewpoint. You see what is exposed, what the area your shot might land in is, and you make the call based on that. Visual and intuitive.

 Screen capture of the gun sight cam, showing circular error probable values

Screen capture of the gun sight cam, showing circular error probable values

I also want to talk about cover vs concealment in Spy DNA. A real-world consideration is: “Will this thing I am using for cover actually stop the bullets?” If the answer is no, it’s not really cover, but just concealment. You might use a couch or a thin door as cover, but those will only slightly reduce the energy of the shots. So if the enemy gets lucky or guesses where you are on the other side, you’ll still have a problem. The flip side of this is, that if you have a weapon with a high rate of fire and have a general idea where the target is hiding, you may be able to get them through their concealment. Just like in the movies.

This leads to the next bit, damage. In most games once you hit a target, there is a random roll for damage, and possibly a separate random roll for a “critical.” So back to that early example on math, most humans don’t have an intuitive feel for complex equations that don’t mirror something in the real world. So instead of having a good grasp of the actual probability of hitting and damaging a target, players have to develop a feel for a weapon’s effectiveness based on trial and error.

In Spy DNA we invert this equation. Damage is 100% deterministic once you hit a target. How much damage you do is based on three things.
1: What hit the target? Ex:type of bullet, fragment, knife, fist.
2: Where did it hit the target? Ex: head, arm, leg
3: How much energy did it have when it hit? More is better (for the attacker)

Those concepts should be very easy to understand, nothing feels complex about it. However, the actual simulation is very complex. It only takes a few lines of code to implement hitpoints. To simulate injuries, we have thousands of lines of code in Spy DNA. 

 Spy DNA uses per-polygon collisions to model wounds on a character

Spy DNA uses per-polygon collisions to model wounds on a character

Our models have multiple colliders so we can not only figure out if you hit your target (which we resolve per-polygon against the mesh), but also what part of the target you hit. Then our damage code takes over and models a wound based on the results. 

This creates interesting situations in-game. Looking over cover is still dangerous, even though you’re 90% covered. Why? Because if the enemy lands a shot, it’s the exposed part that gets hit, which in this case is your head. Sticking an arm out would be much safer.

The last bit I’ll talk about is the passage of time. Most similar games have made the decision to be turn-based. We are a simulation, which means every action you take, takes some amount of time. When in combat, time in Spy DNA only passes while you are doing something. The most similar game I can think of is SuperHot with their tagline “Time moves only when you move.” Time will pass for both you and the enemy when everyone in your party has something to do, even if that something is just wait.

Because you want to be able to react to the changing situation in-game while your character is performing their action, we allow characters to react to perceived threats. A character that spots a new threat will cause the time to immediately stop, so you can change your orders if you desire. This mechanic takes the place of the various “overwatch” systems that most turn-based games have.

The ability to stop time when new threats are discovered allows us to avoid the problem where you need to have characters on overwatch to protect a character that is moving, in case they trigger an enemy reaction. In Spy DNA, if an enemy becomes visible, you can just react to it if you choose. We completely bypass the complexity of having the player figure out which rule they can use to protect them against the AIs use of reaction rules. Instead, you just react to what you see when it happens.

When out of combat, you move the party around in real-time. You can manually enter combat mode if you want, and the game will automatically switch to combat mode when the first shot is fired. Exiting combat mode is always manual, unless the mission is finished.

We have put a lot of thought into how to create as realistic a game as possible, where the world feels natural and real to the player. We want you to enjoy the gameplay and story rather than having to learn and optimize for an arbitrary rule system. For many situations in Spy DNA there isn’t just one “optimal” solution, but multiple ways to accomplish your mission, which frees you up to just play the way you want.
 

Procedurally generated missions in Spy DNA

By Alex Maier, Writer of Words

Here’s a basic overview of how we generate randomized missions. We’ve built a Mission Editor tool for that, and here’s how it looks when you open a mission in it. Here we set all the basics for a mission, such as terrain type, time of day, and so on.

 Spy DNA mission editor "Map" tab screenshot

Spy DNA mission editor "Map" tab screenshot

Then we add all the interesting stuff, like the NPCs you’ll encounter on a mission: enemies, neutrals, people to be rescued, that sort of thing. This is also where we add eligible infiltration options. Not every infil option makes sense for every mission, so we make a list of the ones that do for a given one, and also describe the outcomes.

 Spy DNA mission editor "Gameplay" tab screenshot

Spy DNA mission editor "Gameplay" tab screenshot

When the mission is generated, only a subset of the infiltration options are picked.

Generally, you’ll see four kinds of infiltration outcomes, and each of them influences the mission at spawn:

Outcome

What it means for the mission

You did great and have ALL the intel

You’ll see mission markers for some of the objectives, such as hostage location and enemy camp HQ, or enemy patrols won’t be concealed by the fog of war.

You did okay, and have some intel

You’ll see a mission marker for the some objectives, but not for others. In the case of our hostage mission here, you’ll see where they hold the prisoner, but not where the enemy HQ is, or you’ll find out the enemy patrol route, but not the schedule.

You failed, and have no intel

This is the equivalent of going in without any infiltration. Nothing lost and nothing gained.

You failed, and now the enemy knows you’re there

You’ll be going in blind, and the enemy will be on high alert. They may have added more patrols, etc. Examples of such failures would be to have your recon drone shot down by enemy, or have your agent captured during infiltration.

In-game, you select the infiltration option during the mission brief meeting, and it’s simulated prior to mission start by using the stats of the character you chose to complete the infil. This will allow for different members of the squad to shine, and for the player it will make sense to pick the right person for the right task. Or not, and deal with the consequences.

Here’s how the infiltration planning meeting looks like in-game.

 You pick which infiltration option you like best

You pick which infiltration option you like best

We use Lua to script all the different things we’d like to randomize. For example, the mission description (see first and second screenshot) has all these variables, and below it there’s a box where we define them. The randomizing function pulls the values such as countries, diplomatic titles, and such from a table where we store all kinds of things, tagged with metadata for searching, and the player sees the mission description like this.

 Pardon the layout - it's a dev build :)

Pardon the layout - it's a dev build :)

Here’s how it looks in the tool.

arps-editor-names.PNG

Randomizing names is a bit trickier, because unlike the stuff that is only used in the description, the random name has to be assigned to the character when they are spawned on the mission map. We have a way of doing that when we add the character to the mission.

This is also where we pick the character template for a given NPC, which includes the types of things they wear (military uniform or civilian clothes etc.) and some other aspects of their appearance such as hair styles (again, military personnel will have simpler hair styles and natural colored hair, while the civilians may have wider choices of both).

 This is the NPC we're going to need to rescue

This is the NPC we're going to need to rescue

In most cases, unless it’s an NPC that persists throughout the game, we fully randomize gender, skin color, and body type. Military personnel will again have fewer choices in the body type department, as we will only allow them to have an “average,” “fit,” or “fighter” fitness level. Civilians get a fourth option in fitness level: “unfit.”

The level of fitness and body type aren’t just for show either, they influence the body owner’s attributes as well, so if you meet someone who looks strong and fit, they very likely are.

To make sure that the spread of different body types is more realistic, we weight the probability of each of them occurring. After all, you don’t see twenty-five MMA-fighter-level-fit people for every hundred you meet.

Body types matrix for female and male bodies:

light

average

heavy

unfit

f-un-lt, m-un-lt

f-un-avg, m-un-avg

f-un-hvy, m-un-hvy

average

f-avg-lt, m-avg-lt

f-avg-avg, m-avg-avg

f-avg-hvy, m-avg-hvy

fit

f-fit-lt, m-fit-lt

f-fit-avg, m-fit-avg

f-fit-hvy, m-fit-hvy

fighter

f-ftr-lt, m-ftr-lt

f-ftr-avg, m-ftr-avg

f-ftr-hvy, m-ftr-hvy

With that, we can populate the world with a fairly diverse set of characters for the player to encounter. And often, shoot. Oh, and also create for yourself at the beginning of the game.

Other things you will have noticed in the mission generation tool would be buildings. We generate buildings at runtime from a floor plan which we also create in our tool, but that is a topic for another post.

For now, suffice it to say that when the map is generated, the buildings are placed on it somewhat randomly, according to the parameters specified when the building is added to the mission.

Let’s not forget the objectives! They contain Lua commands to evaluate when the conditions for a particular objective have been met, or failed, such as in case of having the civilian you’re supposed to protect, die. If an objective is marked as required, failing it will mean mission failure and you’ll have to do it over, and if an objective doesn’t have this box checked, you can fail it all you want and still complete the overall mission.

 The Lua check is to make sure that the NPC 39 (our Hostage) is alive. Because this is a required objective, the mission is failed the moment the NPC dies.

The Lua check is to make sure that the NPC 39 (our Hostage) is alive. Because this is a required objective, the mission is failed the moment the NPC dies.

Some objectives are only available when particular conditions are met. Case in point: “recover drone wreckage” is only shown if you chose the drone reconnaissance option and the drone crashed. If the drone is shot down and captured by the enemy, your objective (and area of search) will change to retrieving the drone from the camp.

When everything is said and done, we’ll have a mission that can be replayed over and over, but it will never be exactly the same. You’ll get different infiltration options, the terrain will be different, and the buildings will never be in the same spot. Same goes for objectives such as which building the hostage is in, or where the drone wreckage is.

By the time we ship the Early Access version, we’ll have a number of such missions implemented, in addition to a handful of storyline ones to tide y’all over until the full version is released.

We’re also thinking of creating affordances for players to design their own mission mods, and whole missions down the road. That’s something that will have to wait until after Early Access though.

Demo prep

We are getting ready for the demo. Today we made a new video from the latest build. This is the first time we’ve shown a play-though from character creation to combat. We’ve been focused on playability over the last few weeks, so we’re fixing lots and lots of smaller issues.

The big task was working through issues with load and save of games. Because the demo takes you through character creation before you can start taking sample missions, we wanted players to be able to save a character they generated. We also implemented a loading screen while working on load game. We hope these additions make the demo more enjoyable for players.

Another significant change from our previous videos is an updated camera system. While watching people play, we found players used three camera positions frequently. So we added direct support for the most common camera uses. 

  • A low camera which shows things from the view of the character
  • A high camera which shows the tactical situation
  • A target camera which flies the camera over to the active target
  • And we still have “free” camera so the player can move it around as they desire

For the low and high camera they save the player's view height and angle so if you switch away and come back you won’t have to reset the camera each time.

We also implemented a compass; it shows which way the character is facing. More interestingly, we also added contact ticks to the compass. So you can see which way contacts are relative to your active character. Also you can click them to fly the camera over to any contact.

The map generation has been heavily tested and we have recently implemented a number of performance enhancements. Currently the large maps can strain some mid-range systems so we put some effort into improving performance. There is more to be done, but we got a very nice performance bump for the demo.

For the playable characters we doubled the number of commander appearances available for the demo. There are two male and two female commanders to choose from, each with their three outfits depending on mission. There will be many more for the shipping game.

The demo will also include default genetic enhancements for all the playable characters. You will get to see a small example of the enhancements in action. In the shipping game you will be able to select and choose how your commander is enhanced to mirror your play style.

We implemented new shaders for the trees, firing range, roof of the base, and a few other items. This was done to make them more friendly to the camera so they cut or blur away so you can continue to see the most important parts of the map.

The status screen has been updated to show not only injuries, but also attacks which were stopped by armor or implants. You can mouse over any hit and see the force and type of attack along with how much of it any armor you may have stopped. 

Movement was reviewed. and walk, jog, and sprint speeds were double checked for the demo. We spent a bit of time graphing the various movement speeds vs attributes. These are the base speeds with zero encumbrance.

 Walk speed graph

Walk speed graph

 Jog speed graph

Jog speed graph

 Sprint speed graph

Sprint speed graph

The jog (max sustained movement speed) graph is 3D because it’s based off both quickness and stamina. This was triggered when we picked up a few too many weapons at the firing range and unintentionally tested our encumbrance system.

Barring any unexpected problems we expect to have the demo out this month. Stay tuned!

Realistic weapons in Spy DNA: How deep does this rabbit hole go?

As we’ve been known to say on more than one occasion, we want Spy DNA combat to feel very realistic, and by extension this means that the weapons also need to work like you’d expect them to in real life.

On one hand, weapons need to work realistically, in the sense that they should have a range and damage specifications similar to the ones in real life. Sniper rifles are best used at ranges over 100 meters (and we’ll make sure there are maps big enough for that to matter), and handguns are a good choice for concealed weapons or closed-quarters combat, where you’d have difficulty wielding a long-barreled assault rifle.

If you’ve been following us for a while, you know that that’s a given, and a premise of our whole game, really. When we set out to build Spy DNA, we wanted to provide the player with as realistic a combat simulation as possible, while still making it a game.

The main implication is that the realism makes for a slightly different set of perks and challenges than a typical shooter. We want for the player to be able to use the common sense and knowledge of how things work in the real world to navigate the game. Basically, if you think doing something would get you (or the opponent) hurt or killed in the real world, it should be the same in Spy DNA. Case in point, head shots. Best to avoid them. Or land them on your enemies.

 Just like the real deal (P25 dart pistol)

Just like the real deal (P25 dart pistol)

But on top of that, the weapons also need to look the part. If we gave our soldiers guns that look like they’d be hard to get through an ordinary doorway, or were too heavy to even lift, the realism and the immersion go out the window. Don’t get me wrong folks, there ain’t a thing in the world wrong with games that do that, but it’s just not where we chose to take Spy DNA.

 The little screen on the back shows ammo levels and other useful info to the shooter

The little screen on the back shows ammo levels and other useful info to the shooter

So while designing the weapons, working together, Jason, Denis and I have been periodically taking a step back to check whether the weapon still looks usable, practical, and like something that you could imagine the military of 2075 using. You could overhear us having conversations about making sure that we don’t eject brass into the user’s face or hands, or make the shiny trim reveal the position of our sniper.

We put a lot of thought into the ammo feed position, grips, and how easy would it be to reload or unjam in a firefight, what accessories the owner may want to add and where, and so on. Denis put immense attention to detail into each weapon, and as a result we have game guns in which the sights align when you’re looking at them like you’d be aiming. The fact that it’s a 3rd person game where the player will most likely never see these little details doesn’t mean that we don’t pay attention to them.

Most weapons in our game will have a range of accessories/extensions such as scopes, sights, grips, bipods, and extended ammo clips that the player can choose to equip to add a touch of personalization to their kit.
If our Early Access really takes off, we should have the funds to make more customizable parts for the guns, including rare mods, color schemes, and accessories that can only be gained by completing certain missions.

Stay tuned for the announcement of our Greenlight campaign!

Procedural map generation in Spy DNA

by Jason Sams

It’s been a while since I wrote my last update. I’ve been hard at work on a few things. But as promised in the last update, today we will talk about mission maps.

We have the core of the map generation up and running. We have tested it generating maps from 128 meters square to 2 kilometers.  Map generation times are pretty good; just a few seconds in most cases.  

 Procedural map of a wooded rural area with roads and trees

Procedural map of a wooded rural area with roads and trees

The maps are complete with bushes and trees. We are planning to add grass too, but that is a little harder to do without hurting performance, so it may not make our first Early Access release.

The size of the map will have a large effect on the time a mission takes to complete, and the general flow of a mission. For example, on a small 256 or 128 square meter map, there is no reason to bring any sniper weapons with you on a mission. Most of the regular rifles are “good enough” at those ranges while being much more useful up close.

 Closer view of a procedural map, showing transition from sandy to grassy terrain

Closer view of a procedural map, showing transition from sandy to grassy terrain

We understand our players will have a variety of play styles. So we will be adding an option to the settings to adjust the map size to larger or smaller to mirror what you enjoy most. This will apply a +1 or -1 to the map size settings. The supported map sizes are 128, 256, 512, 1024, and 2048 meters. At the default settings all missions will be on maps from 256 to 1024 meters. So applying the +1 would change that to 512 to 2048. 

When you start a mission, you will be able to see all of the terrain. We assume that in the future you'll still have satellites and drones to recon the area before you deploy. Hidden or movable items such as enemy patrols will be hidden by the fog of war until a team member manages to spot them. Once spotted, they will be marked on the map. If you lose contact, the marker will remain at the last position a team member saw them.

With the upcoming demo we will be using the procedural maps to allow the player to generate skirmishes. We want everyone to have a chance to try out our unique combat system and get a feel for the game.

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.

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.