We’re happy to announce that Dani AI is updated and published on the SELRES_f293b73c-d43f-4e06-9b9d-689d986dc5b4SELRES_da64acfe-5d32-4fb0-bf00-c0fe072ce9f0SELRES_6f151572-3815-4628-b422-071309bde7a9SELRES_33efaa19-25b6-4597-a858-b1f601a443ceSELRES_1ad3ed5a-ae11-4c8d-a3de-514ef145fdc4SELRES_431021c7-29ef-452d-a9af-35abaed20751SELRES_372a7a06-b9af-434e-b3b3-c958380121a5Unity Asset StoreSELRES_372a7a06-b9af-434e-b3b3-c958380121a5SELRES_431021c7-29ef-452d-a9af-35abaed20751SELRES_1ad3ed5a-ae11-4c8d-a3de-514ef145fdc4SELRES_33efaa19-25b6-4597-a858-b1f601a443ceSELRES_6f151572-3815-4628-b422-071309bde7a9SELRES_da64acfe-5d32-4fb0-bf00-c0fe072ce9f0SELRES_f293b73c-d43f-4e06-9b9d-689d986dc5b4!
Here is an overview of what’s new:
Gizmos In Edit Mode
Originally, Dani AI was only able to render gizmos in Play Mode. While it was useful when playtesting the game, the gizmos would simply disappear, leaving the visual tools to the imagination of whoever is behind the screen.
Instead, we introduced an attribute to display gizmos whenever an AIBrain is selected in the Hierarchy. This way, you can more easily play with AI values in Edit Mode before playtesting those values.
Selecting a GameObject containing the AIBrain now shows gizmos in Edit Mode
Gizmos displaying the current changes in the field of view of the Kyle agent in Edit Mode.
Improved Editor Performance
We managed to improve editor performance by reducing its garbage collection load by around 8%. As a result, the editor is much more responsive on weaker computers. Do note that our runtime framework itself produces no garbage.
Additionally, with the introduction of UIElements in Unity 2017.1, we are currently experimenting with the new API. Early results are promising, and expect a blog post about it in the future!
Lastly, we fixed the following issues in the editor and the included Demo:
Fixed copy/paste buffer working only once per copy
Improved root-motion animation syncing with AI
Fixed a bug where restarting the demo in-game would throw errors about the HUD not existing.
We had a blast last month showcasing Modern Knights and spending time talking to you guys in Play NYC and Otakon. For us, it was about learning from others and making moves based on what was learned and what we want to do next. And we’re continuing that in Unity Developer Day in NYC this Saturday, so catch us there!
Speaking of conversations, we’ve gotten quite a few questions during the events from the curious and the veteran testers about the current state of Dani AI. Based on the current feedback and suggestions, we’re currently focusing on improving its user interface, so we took the time to fix the largest kinks in its armor:
Connecting the Dots
Dani AI is a powerful AI tool that decides which actions to take at a given situation. It does so by connecting observers, decisions, and actions (otherwise known as AI nodes)together to create a template that an agent can use to perform actions in a meaningful way. In other words, the nodes provide the information, while the connections provide the context of what is happening or will happen.
One of the first issues we tackled in the editor was the inconsistencies of creating and editing the connections. Originally, connections are only editable in the Inspector. A typical workflow for this is adjusting the conditions for the decision to activate:
Click the observer
Look in the “Connected Decisions” list
Find the correct decision that contains the condition
Edit the condition
It’s a bit odd, given that the only way to create connections is dragging the mouse in the editor to connect the nodes together. As a result, we made the connections clickable in the editor so we can jump to editing the condition in one click.
We also added a new custom inspector for connections to provide relevant information on the nodes and the conditions.
Weighing in on the Situation
When an observer is connected to a decision, it contributes to the decision’s total score by generating a sub score based on the condition. For example, if an agent wants to attack, his health should be above 50 and if so, contribute a point to the “Attack” decision.
Given that situation, its a bit odd to see percent signs when clicking on the observer or connections. Originally it was meant to show the influence an obsever has relative to other connected observers, but we kept it simple by just showing the weight instead:
When the decision is selected, the connections show both the weight and its relative influence over the decision:
Snapping into Order
Freely-moving nodes are fun to drag around, but are often quite annoying to align. One pixel may not seem like a problem, but it’s enough for our testers to waste minutes per connection just to align them properly.
As a solution, we added a really simple snapping method that rounds the positions of each node to the nearest incremental value (5 pixels by default, but is configurable in the settings). It’s most easily noticeable when moving the mouse slowly as it produces a stepper-like movement.
A stepper-like pattern for aligning nodes together.
Where are we now?
Again, big thanks to our testers who are willing to test our tool every step of the way. We’re aiming to push Dani AI to the Unity Asset Store soon, but right now we’re confident that Dani AI is in a reasonable stable state.
If you have any questions or would like to test Dani AI, please shoot us an email at email@example.com or find us on Facebook or @initialprefabs on Twitter.
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?
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.
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!
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.
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!
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.
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!