Transitioning to DOTS: Part 2 Proxy and Components

Disclaimer: This information presented uses Unity 2019.1.0f2 and Entities Preview Package 30-0.0.12. Since Unity is regularly adding to and depreciating the API, I cannot guarantee the methods I use will work beyond previous mention versions. If change to API break any parts of my code, please comment on it and I will try to address it as soon as possible. In addition, my intent is to use “Hybrid ECS”. It is also important to note, I will be using Hybrid ECS since a lot of Unity Built-In system are not support in Pure DOTS at this time.

The first step in creating in transition to DOTS, at least for me, is to develop the components.  Since this implement will use Hybrid ECS, GameObjects will have to be convert into Entities.  Currently, the Unity Entities package comes with a handle pre-written script to handle this. All that is required of the user to write the IComponentData Struct and Transfer Proxy script.

At this time, the focus is on recreating the Example Video from part on and will only have two influence map Proximity and Threat. Since I am using Hybrid ECS, We have to create a Proxy Mono Behavior using the IConverGameObjectToEntity interface. This allows a Monobehavior to be convert to entity at the Loading of Scene, when using the ConvertToEntity script. If you plan to use “Pure ECS” for your project, you will select convert and delete for the Conversion Mode. Also, note “Pure ECS” requires the use of Hybrid Renderer package.

Now that we have an entity, we have to access it and do something with it. For that, we need a ComponentSystem and a Job. Before start coding, let us think about how the influence system will work. An NPC will request to know the Influence at given location. In order to determine that it need to know all entities with an Influence Component in the scene. From there, the list of entities needs to be reduce to only the entities close enough to affect the influence of the sampling location.  With a condensed list of entity, the influence can be calculated and outputted.

Transitioning to DOTS: Part 1

From the moment Unity ECS announce, I immediately took interest in it. I downloaded the beta and started playing around with the tools and sample codes in the Project GIT. After playing with samples and trying to integrate into my project, I quickly learned ECS was not ready for self-taught Indie Dev. A lot of the API was not standardized. Unity had not decided between “Pure” and “Hybrid” ECS. The Jobs system and Burst compiler were just in development only. Even with the release of the Job system in play, Physics API still had to be ran in the Main Thread. Even though, Unity DOTS, Data-Oriented Technology Stack, is still in beta, with the release of Unity Physics, now seems like a good time to start learning the new system.

Using DOTS requires a complete paradigm shift in coding logic. Simply put, using DOTS requires you to forget everything you know about Object Oriented Programming. Coupled with lack of complex tutorials and source to study, DOTS implementation can be a serious challenge. What I am looking to try to do is document my process of creating a DOTS based AI System for Project Rebirth.

The first system I am looking to create using DOTS is the Infinite Resolution Influence Mapping. If you are unfamiliar with Influence Maps, you can check out this GDC Talk “Building a Better Centaur: AI at Massive Scale” or read the white paper from Game AI Pro.  In addition, here is video demo and explanation of 2D Influence Map system.

So now that a primer on Influence Maps has been given, what am I trying to achieve? I goal is to make a point based Influence. Rather than creating grid of influence, AI agent will set a query of a location and determine the influence based on AI agent and obstacles in the areas. This allow of influence to emit in three dimensions. On top of that, I want to us ray casts and NavMesh to determine if influence should effect a given area based on the AI agent able to get there. If an AI agent is unable to see or get to the query point, it will reflected in it influence.

Dev Log 007: The Constant State of Change

Talk to anyone who’s worked in development of any type of product and they will tell you one thing, change is inevitable. The only thing that’s constant doing the entire development period that changes are going to occur. Sometimes they’re for the better and sometimes there for the worst.

Starting this month there are some major changes coming to project rebirth’s AI system. If you have read previous blog post, you would see that I have scratch that behavior tree system I was previously using and switched to a  Utility AI system. Utility AI systems allow for complex simplicity. Instead of having to an order of states for the NPC to cover through, I can allow the NPC to determine the best state based on what is happening in the Game World. While Utility has been helpful, I still been struggling with how enemy NPCs engaged with the player. Engagement is key in action RPGs. The players need to feel overwhelmed and surrounded but still be in control and able to win. I’ve been working on codes battle circles, which allow a group of NPCs to the player character and coordinate attacks. However this system is very very rigid and any gamer who plays the game for more than 2 hours. A few days ago, Blake posted a video on modular tactical influence Maps. And immediately I said I got to have this. Starting today and I am scraping the battle Circle system in favor of modular tactical influence Maps. For those of you who aren’t familiar with the concept, please look at the video below.

 

 

Dev Log 006

Since the last update, social media has launch a new trendy challenge, the 10 Year Challenge. This challenge has users post posting current picture and one from 10 year prior in hopes spark reflects on the life one lead. While I will not be partaking it this challenge on a personal level, it did influence me to go back into the hard drive archives of yesteryear look at previous game project I have worked on.  All I can say, I have been a long journey and are still many miles to go.

Updates

For the last couple of weeks, I have been focus on the development of my own Utility AI System. While there is need for improvements, I can say Utility AI is better system than FSM and Behavior trees for my projects. The next step for the system is to add an Editor Window for easy debug and looking to whether or not this system would benefit from Unity ECS integration.

 

Optimization Tips: Does It Have Be Updated Every Frame?

One topic does not get enough coverage in my eyes is Game Optimization. As self-taught developer, it has been difficult to learn how to effectively optimize games.  I feel as if most article on optimization should be title “Don’t Make These 10 Rookie Mistake”. These articles generally cover things like reducing draws; combining textures, Object Occlusion, and, my favorite, do this instead.  This is not bad information; however, it barely scratches the surface of optimization. Many things can cause the CPU to have too much work to do. Examples could include demanding rendering code, overly complex physics simulations or too many animation callbacks. In this series of articles, I want to discuss way to improved performance beyond the traditional methods.

Stop Running Code Every Frame

One of the questions programmers should always ask is does function need to run frame.  A function called in the Update method is called once frame. On a project targeting 60 FPS, each function in Update is ran every 16.667 milliseconds.  With the exception of physics and rendering functions, most code does not need to be run every frame. An example of code that does not need to evaluate every frame is AI detection logic. A player does not move enough in a single frame to affect the outcome of the function.

So how does one go about making a function run once every X frames? In this example code, an expensive function runs once per frame.

In fact, it would be sufficient for our needs to run this code once every third frame. In the following code, we use the modulus operator to ensure that the expensive function runs only on every third frame.

An additional benefit of this technique is that it is very easy to spread costly code out across separate frames, avoiding spikes. In the following example, each of the functions is called once every three frames and never on the same frame.

 

Switching To Utility Based AI

Writing game code, in general, is difficult. While there are plenty of assets in the Unity and Unreal asset store to ease a lot of the burden, being

an unheard of solo Indie Dev with student loans means disposable income is rare luxury. This means every asset I use is either Open Source or something that I have made myself. While there are a lot of nice 3D models and animations, available online, good code is hard to find. Most of the code assets starts as Open Source and either they die due lack of interest or they get pull down and made into paid assets.  Over the last few years, I have tried to find and make an AI system for my hack and slash project with little to no success.

My first attempt at AI was using a Finite State Machine, FSM. While FSM are good for simple AI Systems, they start to get a bit cumbersome for large system with multiple states. FSMs are great because they are so simple and intuitive. When they get big, however, they become so complicated. It got to a point where I am afraid to change the configuration of the FSM because the working AI easily breaks. From there, I move to Behavior Trees.  I have used a number of free open source assets. Unfortunately, not of them have functioned quite the ways I liked. In addition, behavior trees are not necessarily any better, either. They also have a major disadvantage: steep learning curve. You have to think like a compiler when working with BTs. You have to know what its elements mean like Sequence, Selector, Parallel, Decorator, etc.

After listening to GDC talk from 2010, I decide to try a Utility AI approach. Goal oriented action planning is an artificial intelligence system for agents that allows them to plan a sequence of actions to satisfy a particular goal. The particular sequence of actions depends not only on the goal but also on the current state of the world and the agent. This means that if the same goal is supplied for different agents or world states, you can get a completely different sequence of actions, which makes the AI more dynamic and realistic. For my usage, the GOAP fits perfectly.

For anyone who is trying to develop their own AI, I will release my code once I have completed, simplified, and optimized it for in game usage. For those of you unable to wait for that day, here is a look into how I developed the basis for my system. I started with a FSM system based on Chapter 3.1 of Game Programming Gems 1 by Eric Dybsand and written by Roberto Cezar Bianchini. That code can be found here.  I replace all the code regarding the Transition with what I am calling EvaluationState.  EvaluationState is an abstract class which contains the logic and scoring for determine what state to run. An EvaluationStates can be used on multiple states.

 

Please stay tuned for future update. There ae a lot of quality of life and performance changes include Unity ECS integration.

 

 

 

Dev Log 5: Holiday’s Post

I am going to try something a little different in this dev log.  This is mainly because I have been swamped with work these last few weeks and have not had time to do much beyond general code improvements in the realm of building the game. The one thing I have had is plenty of time to theorize how certain systems should work in the game. So instead of talking about the minor changes that no one care about and will never notice (unless they go into the source code), I am going to start theorize the next system to be program. That system will be the Enemy and Companion AI System.

In previous iterations of this project, I have struggle with AI systems.  Most of the difficulties I have are because of general inexperience and not having clear goals for this project. So this time, I am going to follow the “7 Habits of Highly Successful People” by beginning with the end in mind.  So in this post, I am going to lay out what I intend for the final AI system.

• Enemy and Companion AI System
  • Modular design
  • Designer Oriented
  • Driven By Unity ECS

The first and possible most important goal is to have a modular AI system.  The intent is to have one system to control all NPC in the game. From NPCs simple walking down the street to the Dungeon Boss, every NPC will use one set of global code. This allows for the use of higher-level code since subsystem are used to create a complete AI. Some of these subsystems are navigation, interactions, and combat. By combining, different subsystems together unique AIs are created.

The second focus is on being designed to be use by Game Designer instead of a programmer.  By having a modular AI system, where sections of code are used for multiple AIs, having a system that can be modified in the editor is essential. Any change that happens in the code is passed throughout the game. Designers need to be able to modify and change the way subsystem function without altering the code.

The ending product will use the Unity ECS Structure. While I do believe that Unity ECS should be avoided in the prototyping phase of game development, it is a powerful tool that definitely be integrated in the final product.

Seeing as this will be the final post before New Year, I guess it would be fitting to go over the goals for 2019. My biggest goal is to increase the number of hours I spend working on the project. I am love gaming  too a point that could be consider obsessive. Unfortunately, due to the financial risk take by AAA Dev, the games I love to play are slowly becoming fewer. With AAA Devs not able to take as many risk with potential IPs, I believe it is up to Indie to take chance. My second goal is, once again, to start blogging more regularly and marketing Project Rebirth. And my third goal is to start doing some RnR streaming.

Dev Log 004: Back Online

After three long and torturous weeks, my mine system is finally back online. While travelling for work, there was a heavy storm around my place, which cause several sequential blackouts in the course of a few hours. The storm shorted out my Ryzen & 1800x and a PCI slot on my MSI x370 motherboard. After spending $100 in parts to do diagnostics, two and half week of being in RMA/Tech Support Limbo, and one small fight with FedEx, I have my new CPU install. I am currently in the process of running stress test to verify system integrity.  I hope that weekend I can do a proper Dev Log.

Lesson Learned: Always use a proper Surge Protector or UPS.

The Required Daily Grind

Today, while search through the forum, looking for help with an issue I am having with Particle System in Unity, I came across a Kickstart promotional post for Indie game called Zeal. What caught my eye is the developer’s bold claim to be an Action RPG that is grind free. In this day of grind fest game like Assassin Creed Odyssey and Battlefront II, there is great appeal in a “Grind Free” game. However, a game like that just cannot exist.

In competitive gaming, grinding is unavoidable. Aside from the story, grind is the driver of the game. Game presents the player with set of challenges; player overcomes those challenges and is rewarded with some item or enhancement and new set of challenges.  The problem comes when balance of challenge to reward is disproportionate in either direction. If the game rewards player too frequently or the challenge is too easy, players will become bored and quit. When challenges become too difficult or rewards are not equal to challenge, the game becomes a time sink and players tend to rage quit. An old USA TV show, Leverage, did an excellent episode on purpose of balance game and game theory called “The Gold Job”.

No matter what game you play, from card to video game, grinding will always occur. What differs is the type of grind the player will experience. As Video game developer, we have two types of grind to choose from, Level up or Get Good.  The biggest responsibility we have is to balance the grind, make it enjoyable as possible and not a pointless chore.

 

Is RTX Here to Stay or Just Another PhysiX?

With Hurricanes Florence and Michael devastating the east coast, I have been busy with helping with recovery efforts and unable to keep up with game dev work and tech news. NVidia’s RTX GPU release has been a topic I have wanted to do an article on since its announcement. By now most of you have read or watched multiple reviews about how the RTX 2080 and 2080 TI are a bad buy when looking at the dollars to performance comparisons and that is without Realtime Raytracing turned on. Currently the only thing available that support Realtime Raytracing is FFXV benchmarks commissioned by NVidia.

While I have seen plenty of reasons on why you should not buy an RTX GPU, I have yet to see anyone address the elephant in the room. No matter how much better performance you get on a gaming PC, consoles drive game development. We rather ignore an ugly truth. Developers always target the widest reach audience with least amount of required work. In the case of video games, it is the console gamer. Having only two hardware configurations to develop and optimize for saves time and money. GTV was launched on PC 17 months after the console launch. While Red Dead Redemption has yet to make it to PC and no word if the much anticipate sequel will come.

Now what does any of this have to so with the success or failure of RTX GPUs? In essence, everything. With the next gen of consoles already in development and the premium cost of cost of Tensor cores, I find it highly unlike we will be see Realtime Raytracing on a console anytime soon. On top of that, NVidia have already confirmed the RTX 2070 as the lowest card capable of supporting Realtime Raytracing. Now, according to Steam’s Hardware and software survey for September 2018, majority of pc gamers are using a GTX 1060. Therefore, it is possible that Realtime Raytracing is a feature that only a small subsection of gamers can use. As a developer spending additional and resources to integrate and optimized for feature that only 10% of the market can use does not sound like rational business choice. With this in mind, I predict that support for Realtime Raytracing will be a post launch release.

I know that rebuttal on Developers using RTX will be marketing point that Realtime Raytracing is easy to implement in games and engine. To that I say, where are the RTX On patches?

The second is I see with RTX GPU is that, even If hypothetically we get 60 fps at a respectable 1440p, will anyone actually notice? Follow is a list of all the game to support RTX on in the near future.

• Assetto Corsa Competizione from Kunos Simulazioni/505 Games
• Atomic Heart from Mundfish
• Battlefield V from EA/DICE
• Control from Remedy Entertainment/505 Games
• Enlisted from Gaijin Entertainment/Darkflow Software
• Justice from NetEase
• JX3 from Kingsoft
• MechWarrior 5: Mercenaries from Piranha Games
• Metro Exodus from 4A Games
• ProjectDH from Nexon’s devCAT Studio
• Shadow of the Tomb Raider from Square Enix/Eidos-Montréal/Crystal Dynamics/Nixxes

Six shooters, four RPG/MMORPG, and one racing simulator are list games. Eight out of eleven game seem to be fast pace games. I only wonder noticeable will real reflections be when actually playing these games. In the mid of a firefight, who is the person who will notice flames reflecting off the car?