Author: cedricbrownewell

Flow Fields in Unity Engine

Uncategorized

Flow Fields are a version of pathfinding that don’t construct a single path from the agent’s current location to a target location, but instead creates a path across an entire grid. Flow Fields are broken down into three parts. The first part is is the cost field. The second part is the integrations field and the third part is the titular flow field.

The Cost Field holds the values of all the tiles in the grid. Typical these are held in some sort of 2D array, map or other data structure that have a key and a value. Having a key value pair allows for easy access of values based on a tile ID or some other kind identifying value. These values will be used in the calculations in the Integration step.

The integration field is where the most pathfinding happens. Here the algorithm becomes very similar to searching algorithms like Dijkstra’s and A*. We have an open list and a closed list which are used to keep track of the grid tiles. The open list is used to keep track of which tiles we have to visit and the closed list is kept to tell which tiles we’ve already visited.

Before the Integration process starts all tile’s cost is set to a large number. My examples uses 100, but as long the number is big enough that the costs will not add up to it you should be fine. Then the endpoint tile’s cost is set to zero so that it will always be the center. Once the Integration process starts the endpoint tile is is added to the open list. The algorithm then grabs the top of the open list (the endpoint tile) and looks at its neighbors while also removing it from the list. Each neighbor tile then has the original tile’s cost and its Cost Field Cost added together to create a new cost. This can be done using the tile’s cardinal (with diagonals) neighbors or using the tile’s orthogonal(no diagonals) neighbors. If the new cost is less than the neighbor’s current cost (the large number we set it to at the beginning) then it is added to the open list if it is not on the closed list. After all the neighbors have been looked at then the original tile is added to the closed list so that we don’t look at it again. This process continues until the open list is empty signifying that there are no more tiles left.

Once the Integration is done we then go to the Flow Field process. The Flow Field then iterates through all tiles and looks at all their neighbors to find the one with the lowest cost. Once it has found the lowest cost neighbor it computes a directional vector that points from the origin of that to its lowest cost neighbor. My example stores this directional vector in the tile itself, but you could also store it in another grid of vector values so long at it is the same size as the original grid. Once the this part is done the Flow Field is complete and units can read directional vectors in order to path find to the target location.

Senior Production Blog Post #3

Senior Production

It’s about a week until Greenlight and the game is really coming together.  Weapons are becoming more stable, we have better reference directions for levels and all around increased the quality of our production.  We did get some helpful advice from our production teachers about the scope of what we were trying to accomplish and upon reflection our leads thought we might be doing too much in such a short amount of time so we brought back the scope.  We had originally wanted two game modes, a regular deathmatch (possibly team deathmatch too) and a custom gamemode called Breakdown where instead of just trying to get as many kills as possible the player gains points by getting kills in unique ways.

This change has altered my work a little bit, but not too much.  With the reduced gamemode scope our programmers are working on making sure the networking and its related systems are up to date.  I took on the work of bug fixing the weapons we currently have.  It’s a job I’m happy doing since it lets me build my expertise in blueprinting.  Additionally bug fixing the weapons takes less pressure from the other programmers who already have a lot on their plates trying to get things ready for Greenlight.

The weapons are fine at the moment except for one, which is the Supercell (formerly the Derecho).  The Supercell currently has two core issues: the projectile damages the person who fired it and the movement is jerky.  The former problem is caused by something in the projectile code, however I have yet to verify this.  I have tasks set out for investigation of the problem and tasks for the actual solving of the problem.  I have it split up this way so that in case the problem isn’t easily solved.  The issue might not be what I thought it would be and if that’s the case then I have a task that doesn’t accurately cover what I am doing and spending more time on a task then predicated isn’t inherently bad, but does signal poor planning if extra time is significant.

The weapon projectile speed stuttering is most likely an issue with the server calculating the movement.  It will be a small tweak I imagine, but I have the same task structure as the damage bug just in case something goes awry during the bug fixing process.

Testing has started in earnest as well.  We had some good results so far with testing sessions, both external and internal.  I am trying to push for more data on the weapons such as their range, how often they are used, etc.  Our team has not yet had any formal meetings for QA, but after having a meeting with my design discipline advisor, he made it apparent that I need to be involved in the QA process.  I can’t just be there to get the data earlier I should be part of the process guiding how some of the questions should be shaped alongside our QA Lead.

Senior Production Blog Post #2

Senior Production

It’s about four weeks into the project now and things have started to pick up in the project.  Balancing is still not on the forefront of my work, however I’ve still been able to help the team.  Since we don’t have quite enough data to effectively balance at this point I’ve had plenty of time to get familiar with the weapons code.  I’ve been implementing some of the weapons.  One feature our leads wanted to add were weapon alternate fires.  I was assigned to implement the alternate fire for both of the guns that were already created, the Volt45 and the Derecho.

Implementing those alternate fires was tricky in the beginning.  I had very little knowledge of how the Unreal Engine’s Blueprint system works so this was very enlightening.  Fortunately for me the weapon’s were set up in a C++ inheritance structure, a version of polymorphism I am very familiar with.  The hardest part of the process was becoming familiar with the Unreal syntax.  With time and effort I managed to get the two weapon’s alt fires to work properly.  In addition to learning how to code blueprints I was also introduced to code reviews.  Code reviews are something I had heard about in my periphery, but never got to experience until now.  I am going to try and do more in future to get better acquainted with the programmers on my team and to also help build up how code reviews should be done.

I was also assigned to fully implement a new weapon in the game.  The weapon is a sniper rifle-esque weapon that can attack from far away, but the fire rate is low.  I’m still in the process of putting it together, but it will be my first full implementation.  As previously mentioned I’m getting more used to blueprint coding I have not spent as much time exploring the inspector and other parts of getting the  weapon to appear in game.  I’ll need to apply a mesh and test to make sure all functions of the weapon work as indented.  I’ve made a note to set up a meeting with the design leads so I can show them the weapon.  If they don’t like something about the weapon I can make notes and readjust the weapon based on that feedback.

Testing has started which means things should start picking up for me in terms of balancing work.  We had a few bumps in the road with our networking, but they were quickly fixed after testing so the next QA session should prove more fruitful for balancing information.  We also have more levels being grey-boxed so I will be taking a look at them in the next sprint (or earlier if time permits).  Looking at the grey-boxed level should help me establish a better rapport with the level designers.  We will be working together very closely once balancing starts in earnest so becoming familiar with them will prove advantageous in making changes to levels or systems.

One last thing I worked on these past weeks was to help develop a new game mode.  It’s called Breakdown and is a take on traditional deathmatch.  Instead of score being entirely dependent on the number of kills.  In the Breakdown game mode, players are granted points based on how many kills they get, but are rewarded with points multiplier if they do cool things before, after or during the kill.  Some examples of cool things are kills in motion, successfully navigating the map without running into anything and multiple kills in a short time frame.  Testing should provide more ideas for cool actions to perform, but for now we think we have a solid start on the game mode.

Senior Production Blog Post #1

Senior Production

Cedric Brownewell
2/6/2021

It has been about two weeks since the start of the semester and the project.  It has been great to get to know the team.  I was on-boarded to help with systems design and balancing the game.  Because of those reasons I was also put onto the backend team.  Our current team structure is divided into a front end and a backend team.  The backend team is in charge of things the player won’t directly be interacting with such as networking, developer tools, and mechanics, while the front end team will work on aspects such as level design, environment art and UI.

The backend team’s biggest project right now is getting networked play up and running.  While a great goal, this unfortunately means there isn’t much balancing work for me to do in the game’s build.  In order to be productive I have been trying to help the programmers on the backend team.  I offered because in addition to my Game Design degree I also am working towards a Game Programming degree.  Since in build balancing is feasible at this moment my role in the team is to help design the developer tools that I will be using to balance the build.  It’s a good job for me to have as it will help me familiarize myself with the tools I will be using in the future to gather data and make changes.

I have also been putting together a plan for when I can actually get into the build to start balancing it.  I’ve been keeping track of who I should be in contact when I start balancing the game.  Some of the areas I’ve identified so far are the weapons designers, level designers, and systems programmers.  The weapon designers and systems programmers would be needed in case a major change had to be made to a weapon. The changes that would require that level of collaboration would have to go beyond just simply adjusting the weapon’s values. Adjusting values such a damage and clip size is something I should be able to do with in the engine editor.  Level Designers would need to be brought into the loop incase of any tweaks in the weapons or game modes. These changes might change how the level needs to be laid out so they should be included in the process.

I expect to participate in QA for a majority of the project duration.  Having the results and making sure the tests collect good information makes my job easier and more efficient. Good data means clearer results and well informed decisions.  One of the tools the backend team wants to develop is an admin spectator tool so that developers can watch the games in action. It would be a useful tool to help supplement the other data we’ll be collecting with context to the decisions we see.

Goal Oriented Action Planning (GOAP)

Game AI
by Cedric Brownewell

The technique this blog post is going to cover is Goal Oriented Action Planning (GOAP).  GOAP is a version of Finite State Machine (FSM) that aims to decouple and simplify the predefined loop in the FSM.  When applying GOAP to a FSM the FSM should only have about three to four states it cycles through.  These states are Idle, Move and Perform (sometimes Animation is its own state or is done in the same step as Move).  With this limited selection of states you might be wondering how you actually get the agent to do anything, well that’s because in GOAP you define the actions the agent might take separately.  The actions are not part of the FSM for a very good reason, having them decoupled from the FSM allows them to be used in any order.  This is where another part of GOAP comes into play, the planner.

The GOAP planner’s goal is to iterate through all available actions for the agent it is assigned to and find the best set of actions to allow it to reach its goal.  Actions are normally given to each agent individually and on a need to know basis to help with organization and memory consumption.  For instance say you had a Fight_Enemy action and a Harvest_Wheat action defined.  You would assign the Fight_Enemy action to the soldier agent and not the Harvest_Wheat action since if the soldiers goal is to kill enemies the Harvest_Wheat action would never be used, but still considered slowing down the planning time and consuming memory that shouldn’t be needed in the first place.  Proper action assignment sees each agent have a list of actions specific to their function in your game.

Once you have a list of actions the GOAP planner will create a decision tree that will take into account all actions available to the agent it’s attached to.  It will iterate through all actions linking them together until it has reached the goal that is supplied to the agent.  The next question you might ask is how does the planner know which actions link together if the actions know nothing about each other?  GOAPs solution to this problem is that it uses a centralized World State to help determine how to reach the goal.  The World State is simply an easily accessible script or data structure that holds onto all of the information in the game.  The scope of this World State can change though depending on the context of the implementation.  Sometimes it can refer to the entire game or it can refer to only the state of the assigned agent.  Regardless of the scope it is very helpful to make the World State simple and easily copied.  The planner will create a copy of the World State to help determine how each action would affect the world in order to help string together a sequence of actions to the goal.  In addition to the World state each action will have a set of preconditions and effects.  Preconditions are conditions that need to be met before this action can be used in the planner’s action sequence.  Effects are what happens after the sanction has been performed and are essential to finding the goal since they mutate the World State, allowing other action’s preconditions to be fulfilled.

Once the planner has created a list of actions they are put into a queue (to help preserve the order) and then passed to the agent.  This is where the FSM comes back into play.  The planner activates and runs during the Idle state, then the Move state moves the agent within range of the action, then performs the top action from the queue.  The FMS will then switch between Move and Perform until the queue is empty.  When the queue is empty the FSM will return to the idle state and search for a way to find the goal it’s been assigned.  In this case the previous goal would be searched for and repeated until a new goal is supplied.

GOAP can be used on console and PC, but would most likely be too memory and processor intensive to be used on a mobile platform due to its dynamic nature.  Additionally this technique works best when you need a variety of agents or agents that need to be able to adapt to many different scenarios.  This could prove to be a point of complication on platforms with limited processor and memory.

As said previously this technique is best suited for games that require a variety of agents to perform multiple tasks with a level of automation.  Game genres such as Supply Chain management games are one such genre where the functionality of GOAP could be useful for worker AI.  Strategy games in general are a great place to use GOAP since the user doesn’t need to micromanage everything all the time.  The user mostly issues orders and the units do their best to fulfill those orders.  Another place where GOAP would be useful is in games where adaptable enemies are needed/wanted.  First Person Shooters are one such game genre.  GOAP has already been used in games such as F.E.A.R. First Encounter Assault Recon.  All of the enemies in that game use some form of GOAP in order to make the enemies more unpredictable and dangerous.

Resources Used during this Project:

Chaudhari, Vedant. Goal Oriented Action Planning. medium.com, December 12th 2017. https://medium.com/@vedantchaudhari/goal-oriented-action-planning-34035ed40d0b

A great article that explains the GOAP technique. Was used in conjunction with an article written by Brent Owen’s to help my understanding of GOAP’s implementation. Chaudhari’s article helped fill in some of the code gaps in Owen’s article such as an explicate way to define goals. Chaudhari talked about more about the methods application in some games. In fact Chaudhari cited Owen’s article in his sources.

Bevilacqua, Fernando. Finite State Machines: Theory and Implementation. gamedevelopment.tutsplus.com, October 24th 2013. https://gamedevelopment.tutsplus.com/tutorials/finite-state-machines-theory-and-implementation–gamedev-11867

This resource was linked in Brent Owen’s article. I was having trouble understanding Owen’s implementation of the Finite State Machine and this was a link that he said was a good refresher/starting point for the FSM. The article had some good concepts that I could see in Owen’s example project, but uses Flash as its code examples. Overall it’s concepts helped me get farther in interpreting Owen’s methodology for GOAP.

Nystrom, Robert. State. gameprogrammingpatterns.com, 2009-2014. https://gameprogrammingpatterns.com/state.html

This is a site I’ve used in the past during my time in a Game Architecture class and was very insightful. I used to as a refresher on many of the base Finite State Machine systems as it had been awhile since I had implemented one from scratch and in the Unity Engine so less.

Owens, Brent. Goal Oriented Action Planning for a Smarter AI. gamedevelopment.tutsplus.com, April 23rd 2014. https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai–cms-20793

Brent Owens article was very helpful on explaining the overall method with some code examples. The examples were given in Unity C# which helped me with my implementation of the technique in Unity. Owens also included a link to their own repository with an example project for those who wanted to see a full implementation of GOAP. Some parts of the article were a little abstract, but with the inclusion of the link to the repository it was very helpful in understanding the GOAP technique.

Thompson, Tommy. Building the AI of F.E.A.R with Goal Oriented Action Planning. www.gamasutra.com, May 7th 2020. https://www.gamasutra.com/blogs/TommyThompson/20200507/362417/Building_the_AI_of_FEAR_with_Goal_Oriented_Action_Planning.php

This article breaks down how GOAP was used in the F.E.A.R game. The breakdown allows me to get a better understanding of the circumstances in which this technique would be useful in when you need an AI. It also briefly convers it methodology, but not as in depth as some of the other articles I found. The value of this article is in the description of how its used in gameplay and the reasons it was used as an AI.