Inner Thoughts of Designing AI in Modern Knights, Part 1

Otakon 2017 and Play NYC are both right around the corner, and we’ve been busy over the past few months improving Modern Knights and Dani AI based on the current testing feedback.  In the meantime, we’ve found the time to post about jump into the thought process of creating reusable AI.

The Scale is to Understand the Issue

As mentioned in the previous post, there are times when a non-player character (or NPC) needs to be less robotic and do more than “if A is true, then do B”.  What we mean by that statement is that given many different scenarios that the NPC will encounter, it is relatively difficult to define the conditions for each scenario.  Additionally, it would be harder to scale up and try out new ideas for the character.

For our knights, we’ve had this dilemma with the interaction between the knight and the player.  The knight is an NPC with its own set of decisions.  The player is well, a character in the game controlled by a complex system of cells using a physical interface known as a mouse, keyboard, and screen. Simply speaking, it’s pretty obvious for the knight to “remember” the player and periodically check if the player is doing anything.

Logistically, it leads to some issues:

  • Should the knight really know if the player is moving?  If so, what about crouching and sprinting? Rolling?
  • If a knight is far away, should it check what the player is doing?
  • When the player makes a sound, should every knight check if they heard it?
  • Should the knight even know what a “player” is?
Blog-Knight-1.png
The player and the knight.  The knight is completely unaware of the player.

As the player mechanics become more complex, adding new code to the AI to compensate becomes harder to do.  For example, sprinting generates more noise for the knights to hear, so we need to add a check to see if the player is sprinting.  Shooting also generates noise, so we add another check for shooting.  Eventually, the number of checks become rather too much to manage and bugfix.  Additionally, all the effort placed into those checks are wasted when the knight loses a reference to the player (“forgetting” that the player exists).

From a designer’s point of view, it’s very worrisome, since there would be a lot of downtime to get the mechanics in place to ensure that the AI is still working as intended.  From a programmer’s point of view, it’s a lot of unnecessary work that can be better spent on other parts of the game.

It begs the question:  How can we build this AI to ensure that it works, even if we’re modifying the player?

To Perceive is to Survive

The solution takes a simple approach:  What about the player does the AI care about and how do we model it?  No matter what the player is doing (running, sneaking, shooting, bashing heads with shields and swords), it boils down to three cases:

  • Player is visible
  • Player makes sounds that the knight can hear
  • Player is a threat

A threat in this case is anything that can harm the knight.  Just like real life, threats are generally a momentary thing, and we often go back to our daily lives once the threat is over (like dealing with mosquitos in the hot summer).  By making a player a generic “threat”, we don’t have to make the AI think about the player directly, freeing up the player for the designers to move forward with new ideas.

But that leaves the question:  A threat is a “thing” that a knight can detect, how do visuals and sounds work in this idea?

A threat is a perceived notion, and the knight that perceived it is going to react accordingly.  To do so, we created a simple perception model for each threat.  The model contains a reference to the source threat, as well as a number from 0 to 1 to show how well known the threat is to the individual knight, otherwise called it’s awareness.

When the player shoots, it emits an intriguing event to nearby knights, whether that’s a sound or a visual notion.  This event is simply a fraction between 0 and 1 that diminishes with distance.  The farther away the knights are, the smaller the value they receive from the event.  This value is then added to the knight’s total awareness value.  Overtime, should the player no longer emits any kind of event (death or too far away), the awareness value decreases until the knight is no longer interested.  This opens up to new moments where the player needs to be clever on how to escape as opposed to just stepping outside of the combat range.

Blog-Knight-2.png
A simple setup for detecting threats using Dani AI.  When the player makes a sound i.e. shooting with a gun, the player sends an event for the AI to pick up and try to investigate in response.

By setting up this perception system, the knight only needs to listen to a threat and do actions to raise its awareness.  The player only needs to emit its presence through events.  Should we decide to add friendly AI, they too would need to emit its presence, all without ever touching the knights.

Knights detecting the player after a few gunshots.  The knight on the right noticed faster due to its proximity and loudness of the gun.

That pretty much covers what we wanted to say for Part 1.  For Part 2, we’re thinking of covering the topic of combat AI, so stay tuned for that!

— initialPrefabs Team

 

 

Modern Knights Updates

After our last play test session at Playcrafting’s Spring Expo we received a lot of player feedback and notice some balancing issues with our latest addition, meleeing.

Meleeing was the most requested feature in our game and our last spring demo we added it. While the melee combat allowed combo attacks and somewhat fancy animations, we felt that it was a bit much for our game. Check out our gif below of the previous version of meleeing.

We found that with a two handed style, meleeing was too overpowered. It was a hit or miss situation; the amount of damage a knight gives to you is equal to the amount of damage you deal (which results in a 3 hit kill).

Instead of focusing on complicated attack patterns – we went back to basics. A much simpler attack combo (left and right strikes) with the ability to block and roll. With this kind of system we can easily scale the complexity of the player’s skills and attacks (akin to Skyrim’s third person combat). For instance, we can add more to the attack combo based on the number of swings a player does.

Above, we switched to a simple right left attack. You can cancel the attack and switch to a block or even roll and evade your enemies. The purpose is to make melee combat more viable and flexible to create intuitive player controls.

So, what of ranged combat?

Ranged combat will still exist in the game. We’re still experimenting with ranged combat, but we’re aiming to not make the game feel like a run and gun kind of game. Something like that will take us time and experimentation, because the questions we ask ourselves are:

  • How do we want the player to react given the situation?
  • Are we giving the player enough options for the said situation?
  • How can we balance the gameplay and make it sufficiently challenging for the player?

Ranged combat still has these hurdles and to do that we need to tweak our knights’ AI to accommodate for ranged combat (e.g. tactics to deploy such as flanking and taking cover). However, we’re taking things step by step and in the upcoming weeks we’ll post more updates on them.

Next Steps

So with that all said what’s the next immediate goal for our game? Well, there are two large expos this summer, Otakon and Play NYC.

From August 11th – 13th, we’ll be in the video game section at Otakon! So if you’re in the DC area, drop by video game section of Otakon, we hope to see you there!

We’ll provide more details for Play NYC which will be happening August 19th – 20th. So stay tuned for more updates!

Cheers,

initialPrefabs Team

 

 

Happy 2017!

Happy New Year!  As 2016 closes, we will leave you a quick update on what’s happening and what to expect:

Dani AI is getting a buff

We are currently working on rebuilding Dani AI from the ground up and pushing it out with our wonderful testers.  So far, the improvements we made for Dani are:

  • Adding real-time display of an agent’s thoughts, with edit support
  • Simplifying workflow to better reflect the human thought process
  • Simplifying the API to feel more like Unity’s API
  • Optimizing performance (1200 -> 2400 max agents on a Haswell Core i3, some people run on potato rigs)
  • Improving stability (handles exceptions more gracefully)

There are still some kinks to work out, but overall it is in a stable state.  Of course, seeing is believing, so here’s a clip on a bunch of knights celebrating the new year (we don’t have an actual conversation animation yet, so their way of communicating is by jumping a certain number of times).  Watch the guy in the shining armor.

And here is a clip of the knight behaving in first person:

The beauty is that we managed to sync animations with Dani via root motion, something that we haven’t been able to do so until just recently.  No more foot sliding!

If you would like to be a tester, please contact us!

The knights are becoming more human  

The previous two clips are also part of the overhaul we are making on Modern Knights, our third person shooter game.  Earlier, we focused a lot on the knights attacking and doing surprise attacks.  But a knight is not without honor and thus is humane to some degree.  When they are unaware of a threat, they will default to doing off duty things such as walking around and performing small talk with fellow knights.

When will you be able to see the more finished version?  We might be showing our next version at the Playcrafting Winter Play expo on January 26th!  Details here.

 

Again, we wish you a happy and awesome 2017!

From UGF Studio to initialPrefabs and onwards

UGF Studio, a name that have stuck with us for quite some time, is finally evolving.

Over the past year, we’ve been steadily making progress on our game, Modern Knights.  Through Modern Knights, we’ve built a flexible AI framework that allows us to build challenging knights quickly and effectively.  Our philosophy hasn’t changed much during this period: build awesome games to make awesome tools.

So, we’ve ultimately decided to change our name to better fit our philosophy: initialPrefabs.  Why initialPrefabs?  In terms of the Unity game engine (or many other engines, we won’t judge, we consider you as fellow game developers!), developers create reusable objects, otherwise known as prefabs, to quickly build the parts they need to build a game.  Our aim focuses on this aspect: we build tools to help developers build different kinds of prefabs quickly, so they can focus on what they do best: build awesome games.

What else has changed?  In terms of moving forward, we want to focus more on keeping you up to date.  The next Playcrafting Expo is around the corner, as well as the next version of Modern Knights.  But in the meantime, we’re going to show you its progress along the way.  #ScreenshotSaturday is coming back!

We look forward to what happens next!

–Jay Suong