The Coding Sheep

[thecodingsheep]

Near The End!

Introduction

SpudLiminal, formally known as Hilbert’s House, is the physics-based puzzler that came to life the way my team and I foresaw it to be at its current stage 10 weeks ago when the concept got pitched. We regarded this idea as a joke since we needed another game idea. At the time (10 weeks ago), we were deadset on making a stealth-based mushroom-themed game, but SpudLiminal, where the player plays as a potato, quickly grew on us. My team and I consistently meet each sprint cycle to help empower our vision of SpudLiminal. We also meet outside of working hours to get to know each other and build relationships outside of a role on the team. so far, we never once encountered any issues of miscommunication or malicious intent from another. We are fond of one another's company; we habitually confide with each other when presented with roadblocks.

Core Idea’s Clarity

After sprint six of SpudLiminal, my team and I proudly closed our gameloop (enter room, encounter puzzle, solve the puzzle, acquire new ability, escape room). Players were now able, for the first time, to complete puzzles and unlock a newly acquired ability; which assists them in their escape with a dialogue system to support them with puzzle completion; it provided context to their environment. Utilizing that system, we want future puzzles and scenarios to enhance and showcase SpudLiminal's overarching narrative. Proceeding sprint six to sprint 9 (week 12 of the semester), we began refining and polishing SpudLiminal by encompassing multiple puzzle solutions and ways for the player to escape the room to ensure our gameloop is closed. Subsequently, through game testing, we were able to observe pathways players took in completing our current puzzle (analytics system), and it allowed us as a team to assemble new changes to either suffice more transparency or locate any unexpecting loopholes. Some of these discovered loopholes were patched or turned into an achievement to reward players in exploration (one SpudLiminal's design pillars) for using the game as a playground, sandbox-esque experience.

The Team Being a Team!

Everyone in Spud Studios (the team name) is working well together. Many team members assess their risk for current features they want to implement and any interdependencies it may require and tackle them with appropriate priority; While also communicating their struggles and components needed for a functioning game. At this moment, all that is essential to hone the homestretch is ways to facilitate visual feedback for grabbable objects in an immersive manner, sound triggers for the already implemented sound effects, and smoothing the player's third-person camera. My only worry for Greenlight last minute changes/merges into the final build. What if a critical gameplay object is left out, causing something in the room to look unfinished or potentially break SpudLiminal into an unrecoverable state? Despite my concern, my team is already taking action to mitigate my fears; the final build is one day before Greenlight (which gives us more time to find any lingering issues.

[thecodingsheep]

Building out Spudliminal’s Production

Introduction

Over the past eight weeks, my production team of seven has been working on our game, "Spudliminal,"  formally known as "Hilbert's House." Players open their eyes as a limbless potato in a mysterious house where the rules of nature cease to exist. When exiting a room, you seem to reenter the same room but through another entrance. Although players return to the same room, entities within the space shift and bestow a new stumbling block the player must overcome to hopefully once in for all escape the room. The main objective is to escape the locked room using any of the provided tools given, either through completing various puzzles, pure will, or luck. 

Team Makeup

As a generalist programmer, my role on Spudliminal has been working on assorted physics mechanics, particle effects, and shaders to appeal to one of the game's core pillars, absurdity. Some features I worked on were: smoke shader & VFX, water shader, buoyancy, mesh deformation via the squish mechanic, liquid in containers shader, etc. Like myself, my preoccupied team is aspiring to complete Spudliminal's minimal viable product (MVP) for the Greenlight showcase, with each discipline specializing in one unique role on the team. My current team buildup is:

One 3D-Environment Artist

One Character Artist

One Producer

One Narrative/Level Design Designer

One Sound Designer

One Systems & Tools Programmer

One Generalist Programmer (Me)

With my team's current makeup, build status, and project scope, we are on track to meet the standards of a minimal viable product within two weeks from today.

Challenges

Some of the challenges my team and I encountered: 

Integrating mechanics into puzzles and core gameloop

Balancing physics systems

Balancing frustration with puzzles

Balancing narrative elements in a sandbox-esque game

The player's third-person camera

Redefining scope

To tackle integrating mechanics into puzzles and the core gameloop, the player acquires an ability they unlock through solving one of the room's various puzzles. That unlocked ability allows them to escape the room. In our second level, the player will have to utilize the unlocked ability in level one to complete various steps in that variation of the room's puzzles. Physics systems are difficult to balance; The core challenge Spudliminal carries is playing as a potato (so limited movement and control). To counter frustration, we allowed players to have some air control while moving through air and water. Smoothing out physics mechanics allows puzzle completion to go smoother, along with the introduction of the narrative system implemented during sprint 5, to give context to the world and hints on how to solve puzzles. Although, Spudliminal has a narrative through a non-playable character existing within the room, making dialogue options keeps the game's sandbox-esque aesthetic intact and appeals to story game players. One of the biggest challenges is getting the third-person camera that follows and looks at the player to feel right and yet not annoying to play. Game testers often comment the camera, at first, is satisfying as it bumps with the player, but after a while of playing, the moving camera gets unfun and irritating.

Going Forward

To ensure that my production team and I are satisfied with the product we are presenting during Greenlight, I will do the following:

Communicate any struggles encountered earlier during sprints focused on feature development. Discussion issues earlier on during a sprint helps the team redesign future sprint formats for an accurate portrayal of the current state of progress.

Establish boundaries for any possible workarounds for features out of scope for an individual but essential to the completion of the minimal viable product; Partaking in-studio collaboration "help" sessions are an example of workarounds that I could utilize.

Lastly, continue working on features in my personal set production work session. Finishing the work I promised my team keeps everyone on track for the sprint goal and is one step closer to completing the minimal viable product.

[thecodingsheep]

Reflecting on Hilbert's House

Introduction

During the first four weeks of my senior capstone, my production team and I had two achievable and amusing game concepts, Amanita's Talismans Shop and Hilbert's House. My team and I cherished those concepts and would love to work on them throughout the entire semester if we had the opportunity. Regardless, we had to part ways with one of our concepts so that we could devote a respectable amount of time to developing our chosen game idea into a cake pop-style proof of concept. We decided to select Hilbert's House, the sandbox puzzle escape physics based-game, over Amanita's Talismans Shop, the stealth heist-themed game. We saw the value of choosing a game with a more straightforward closed game loop of solving rooms' puzzles to escape and rinse and repeat for the next level. Compared to Amanita's Talismans Shop's game loop of sneaking past enemies operating various trap-making devices at the player's disposal to accomplish the goal of reaching the level door and rinse-and-repeat. Despite that, the main reason Hilbert's House was the concept my team and I decided to pursue was how silly, unique, and fun the game could become with the added bonus of having intriguing core mechanics like "Squish," eyeball arms for grabbing, etc.

What is Hilbert's House?

Have you ever exited a room only to reappear in the same room you just left but at a new entrance, and you are a potato? On a planet shaped like a lotus flower, where every time a star dies, something on the planet shift! Threatened by outside forces on that planet's petals, Hilbert, a genius and passionate magic researcher, built a safe house of sorts to hide in and trap intruders who sought to ruin him. Caught in the crossfire, players open their eyes as an ordinary potato on one of the shelves inside Hilbert's kitchen. When they try to leave, they suddenly seem to renter the same room but at a new entrance. Determine to escape, the player must interact with characters and objects to solve room-based puzzles for one step closer to freedom from the maze-like prison, Hilberts House. After communicating the game idea with many friends and family outside of Champlain's Game Studio, they all seemed fascinated by how such a mundane character set in a magic's only struggle is traversing the environment. They enjoy how original Hilbert's House was as the lore explains gameplay as to why rooms seem to repeat themselves. Since the concept's game loop appeals to the escape room theme games, it opens the player demographic to a wide-range audience, making the game concept, not niche. The only qualms they had were what other methodologies the lore is conveyed outside of character narration and the room repeating itself with minor changes! However, the environmental artist expressed how they were going to incorporate strange lotus-themed plants to convey how Hilbert's House takes place far from earth. The team wants Hilbert's house mechanics, systems, lore, narrative, environment, and characters to feel and make sense of how we want the concept to become.

Learning Experience

Even though Hilbert's House game loop is more straightforward, and has low ceiling scope, it provided us a safe space to ensure that we can achieve a minimum viable product while slowly challenging ourselves with new features in our respective disciplines. I have been slowly incorporating shaders and other forms of visual effects into Hilbert's House to help immerse the player into the environment, with my bubbles and smoke shader. We furthermore frequently divert work responsibilities each sprint to stay on track with our road map. During the earlier stages of the project, any jokingly made side conversations became features in the game, like the thought of making the potatoes physical being like mashed potatoes to get under the door to exit the room. That idea became the first core mechanic the player acquires to "escape" the kitchen during its first iteration, the squish mechanic. That cycle became full team meetings discussing the room puzzle's minimal requirements and what each discipline can do to execute it to a functional state. If the puzzle requirements seem too over scope, not fun, or distracting to the overarching storyline, then we inform the designer to rework the puzzle. In conclusion, my production team is challenging ourselves while keeping the core gameplay simplistic, which so far has kept our enjoyment in what this game concept can become!

[thecodingsheep]

Reflecting on New Capstone Team

Introduction

Before Capstone (a senior-level class focused on the discipline relating to one's field of study), my team and I created an informal Jamboard, labeling each member of the team's game preferences and loathings. These "likes and dislikes" varied from aesthetics, themes, features, engine choices, etc. My team and I regularly articulated skills and experiences they sustained in their particular disciplines, like my experience with AI, during our in-depth discussions about potential concepts we wanted to take into Capstone. During our first sprint of Capstone, we utilized that unrefined informal Jamboard document as a reference guide to constitute the types of game concepts we as a team wanted to create and present during Greenlight, which is a showcase event near the end of the semester, where each Capstone team introduces their game concept and prototype to faculty, staff, friends, family, and other Capstone teams. My team and I established a work agreement contract, which explicitly sets the work expectations to allow room for natural life circumstances and the necessity of providing self-care; mental or physical breaks are critical to increase productivity and deter burnout!

Opportunities & Challenges

During my team's sprint planning meetings, I accrue more opportunities to attempt new systems or mechanics in the fields of programming I am either skilled in or feed my curiosity. In one instance, my team and I's first game concept was a 3D stealth game centered on a small-puppet-sized talisman of creativity mushroom cap maker protagonist escape from their creator's cottage. To escape the cottage, the protagonist would have to sneak around other hostiles, determined to prevent its creator's most prized possession. Subsequently, most talismans despise each other, so the player could utilize other talismans' dislike for each other to get access to areas they could not enter before. The player can achieve that feat by aggroing one group of opposing talismans and escorting them to their conflicting group of talismans. On a technical end, to simulate that particular interaction, that game would need an ecosystem-based AI. so that the world outside of the player's control feels lively. On paper, this system sounds like a notable opportunity to expand my technical ability and tickle my interest, but I know I can dedicate an overloading amount of time to a single complete feature with inadequate code architecture, a technical weakness I am striving to improve. Imagine a system encompassing multiple AI interactions. Although I am excited about ecosystem AI, it can cause potential challenges in later sprints if my team and I proceed with this game concept for our Greenlight showcase. 

Contributions & Work-Life Balance

I aspire to remain a valuable asset to my team with my skills in AI, Physics, and Gameplay programming. Understanding that, my team and I set clear boundaries in work that we believe are accomplishable with the one-week sprint cycle. To partake in that culture and to respect boundaries, I have been communicating more often (than I typically did in the past) about technical feats puzzling me instead of spending hours independently debugging issues. I have also limited myself from working more than six hours maximum per day to maintain my mental energy and respect myself since I am human as well; we all need rest!

[thecodingsheep]

Hierarchical Task Networking in a Turn-Based Combat Simulation!

Introduction

Hierarchical Task Networking (HTN) is a static-traditional planning method that enables AI to predict future in-game situations; the AI can then execute a responsive action (task). For instance, if a player is charging up a powerful attack, the enemy will attempt to interrupt the player before they can cast the spell by either knocking the player down or stunning them. The enemy can even execute distractive measures like throwing a smoke bomb to reduce the player's accuracy, as mentioned in the 2021 "AI Summit: Advanced Real-Time Hierarchical Task Networks: A New Approach" GDC talk by Tomohiro Mori and Kousuke Namiki. These actions or tasks the AI can pursue can come in two types: primitive and compound. Primitive tasks are the direct singular action the AI will conduct. While compound tasks are multiple primitive tasks, the AI can perform as a response (EX: the AI ducking and reloading from player fire). Hierarchical Task Networking is remarkable as it has the ability to further breakdown compound tasks into individual sub-primitive tasks to accomplish the minuscule of details in a responsive action in a game (EX: the AI in a boxing game can block the player's attack in a specific area of there body instead of only executing a face block for all player attacks). 

Hierarchical Task Network

Hierarchical Task Networking is a static planning method, which means it thrives in a non-dynamic (static) environment. The AI generates a "chain" of responsive tasks to perform to adapt to the in-game situation. After the AI performs a task, that task can be deleted or stored at the end of the chain for later reuse. Chain of tasks order matters! So if an action the AI wants to execute exists within a chain, but that task is not the first task of that HTN chain, the AI will have to create an entirely new chain with that wanted task first. Highly dynamic environments with HTN utilized can cause performance issues, as the AI will most likely generate a new chain based on every environmental change. Static environments provide "a breathing space" for the AI to recycle and reuse previously created chains with the wanted action first instead of the constant chain generation. The more frequent an agent has to re-plan, the less predictable the agent will be, thus turning the AI into a reactive agent with limited/narrow long-term prediction. To effectively perform Hierarchical Task Networking, one must perform these following actions: 

Recycle chain with wanted task first if present.

Create a chain with the wanted task first if a chain was not recycled.

Delete oldest least utilized chain(s) if  reached maximum chain list capacity.

Execute chain’s first task.

Recycle Chain

When the agent wants to respond to an in-game situation, HTN checks if there is a valid chain (a chain with the wanted task at the beginning of the chain list) present in the network. If the valid chain is found, every chain is shifted downwards until the wanted chain is the first element of the network, the last element is the oldest and least utilized chain in the network. To optimize chain recycling, instead of checking through a list of all chains, one can classify what type of action that chain can belong to based on the environment. For instance, hiking and jumping over obstacles tasks should most likely not belong to a chain list for a flat-plain-like environment.

Chain Recycling function. I passed in a wantedTaskID as a parameter to compare the agent's wanted task id with the first task in the agent’s HTN chain list (network).

A sort algorithm that shifts the wanted chain to the front of the chain list (network).

Create Chain

If a chain with the agent's wanted task first could not be recycled, a new chain with the wanted task is created with the wanted task as its first element is created. After the wanted task is created, another task that the AI might want to undergo next (based on the in-game situation) is added to that chain until the chain length reaches its max capacity.

I created a new chain with the wanted task and added it to the AI’s chain list (network). I then recycle that chain so that it can be the first element in the network.

When adding a non-agent-wanted task to a chain, I check if the task condition function is true, which takes into account all the situations in the environment. In my case, if the target were to have charged up their attack last turn, the AI may want to add the block task to the chain, to prevent a massive amount of damage in the near future. If the task has been added to the list, decrease the amount of task to make until it reaches zero. (mTaskToMake = the chain length at start)

Delete Chain

For optimization purposes, the delete chain function removes the oldest and least utilized chains in the network only once the network has reached its maximum chain capacity. If one opts to delete executed tasks, then the delete chain function will also delete chains with zero tasks in them as they serve no purpose.

Execute Chain

After recycling or creating a chain with the wanted task first and deleting old leased utilized chains, the agent can then perform their desired action. The desired action (task) is the first element of the chain list (network) and the first element of the chain's task list. After completing the desired action, one could decide to delete the task from the executed chain's task list or move it to the end of that chain's task list for later reuse.

Applications & Conclusion

There are many static-environment-game applications in which Hierarchical Task Networking thrives, one game genre being turn-based strategy. I tried to simulate a combat simulation between a user-controlled player character versus a computer AI, who will utilize in-game situations, like having low health, being de-buffed, or being stunned on the previous turn, to conduct a "smart" responsive action. Overall, with some small feats that I need more time cleaning, the AI delivers a medium balance of re-planning (creating new chains) and reusing previously created tasks to provide a not a low-to-normal level opponent experience. In turn-based games, if the AI's attack pattern is foreseeable, it is most likely continually reusing its HTN chain. If the opponent is less predictable, it may have created new chains to respond to the in-game actions; thus increasing the level of challenge. 

The player’s attack options. The player and the opponent AI utilizes the same actions to:

Increase damage (charge).

Avoid damage (block).

Recover health (heal), health percentage based.

Harms the other party (attack).

Forces the other party to lose their turn (stun).

Reduce healing and attack damage (Debuff).

Video Demonstration Link:

With more development time, I would make attacks look more turn-based. There is an initiative value that determines which party will act first, but it is not visually displayed. As a result, the combat looks as if everything is happening at once. Also I would love to add visual effects to the performed actions to display more visual feedback to give more life to my turn-based combat simulation. For example, it would be funny to see a flying red boxing fist hit the blue player!

References

AI Summit. (2022). Ai Summit: Advanced Real-Time Hierarchical Task Networks: A New Approach. GDC Vault. Retrieved April 18, 2022, from https://www.gdcvault.com/browse/?track_category=1402.

[thecodingsheep]

Development Blog Pumpkin Pals Postmortem

Introduction 

For all the work my team and I put into Pumpkin Pals for Ten weeks, we have done relatively great at managing and re-scoping the game to a more sandbox-esque game with missions serving to guide the main gameloop and breaking up repetitive gameplay. Before Greenlight (a concept proposing event), Pumpkin Pals was supposed to be a collect them all styled game, similar to Pokémon, where the player has to encounter all types of Pals of a unique species, trait, and emotion. However, around week four of development, the development team realized that we needed to invest more time into core systems so that the programmers could utilize those systems to complete the Pal Journal (the method of storing all unique Pal encounters). To combat overworking and or rushed/ unpolished core systems, my development team decided to change the main gameloop: where the player has to evolve one out of the three evolution lines to the max level.

Pumpkin Pals Postmortem

As one of the programming developers of Pumpkin Pals, I have learned the benefits of utilizing and integrating my team's other programmers' systems. Meshing systems save time for the following reasons: you do not have to create something entirely from scratch, and the other programmer (the author of the system) can assist you with the system integration. Some examples are my clock system (which tracks the in-game: seconds, minutes, hours, days, weeks, months, and years) is utilized in the Mission System, Pal Seed Growth, Interaction System, Alarm System, Collectible Spawning System, etc. During development, I realized how awful I am at estimating how long it will take to complete a system. During week five, I estimated that the Interaction, Pal Trait, and Pal Evolution systems integration would take around six hours; however, that task took roughly twenty hours to complete bug-free. I utilized polymorphism, object-oriented programming's inheritance, to integrate the systems which was the only way, at the time, I saw to help me combine those core systems for the gameloop. During the next week, at one of my development scrum team meetings, a team member told me I could have utilized a data-oriented approach, which could have saved a vast amount of time creating sub-classes and parent-classes. Despite that, I am more comfortable with object-oriented programming's inheritance: virtual and override function use and can always fall back on that approach when in doubt. I have also learned the importance of communication through my code and verbally. I have been too comfortable with being the only one who would read and see my code! After receiving feedback that my code is not readable, I try to incorporate more comments and headers in my code to explain the purpose of each function and where to call it. Also, I try to expose more private constant variables as public so that they can be easily modified by the team's designer for gameplay tweaks. Subsequently, as the team's lead programmer, I have had to improve my verbal communication. I sometimes have a hard time articulating my thoughts verbally and sharing my thoughts on a matter. I have had to quickly adjust to the feeling of becoming uncomfortable and sharing my thoughts and concerns on particular features and systems, as my programming peers would often ask me questions on approaches they should take in completing a system or game feature.

Final Words

Overall, I am tremendously proud of the work and hours my development team and I have put in to achieve our playable considerably ambitious pre-alpha game, Pumpkin Pals; This project and game is something I will look back on, and treasure. Who wouldn't want to work on a game where you are raising pumpkin monsters!

[thecodingsheep]

Influence Maps

Introduction

Influence maps are a well-known tool for handling tactical pathfinding for agents, particularly best in large outdoor environments. These maps are evoked from spatial logic through propagators, who carry a base scalar field of influence, positive or negative. Influence maps provide these components to make the AI make better or believable decisions based on the influence value at the given agent's current world position. Influence values can also drop off, so it is critical to update the influence buffer, which handles influence within the world space to appropriately decay when propagators are no longer in range of a particular area.

The formula for an Influence Map:

Influence Map = Update Propagators + Update Propagation + Update Influence Buffer

This Influence Map displays the influence value for each cell on the grid. Cells with yellow hue text have positive influence values, while cells with a blue hue value have negative influence values. Cells with a black text hue have an influence value of zero. 

Propagators

To update propagators, you would first have to obtain your propagators by assigning the base scalar influence values for that propagator. In a war game scenario, you would set allying forces and structures with the same influence value, positive or negative. The enemy force needs to have the opposite signed influence value from the ally team. Any natural agents or forces have an influence value of zero. After assigning the influence value for the propagators, add them to a list so that you can iterate through each propagator and reset the cell that the propagator is currently on (the cell's and the propagator's world position is equivalent) influence and influence buffer variables to of the propagator's base influence value.

foreach (Propagator propagator in mPropagatorList)

{

    if (propagator == null)

    {

         removePropagator(propagator); // remove propagator from the list

         Return; // exit iteration because the list size has changed

    }

Cell currentCell = getCellFromWorldPosition(propagator.getPosition());

currentCell.mInfluenceValue = propagator.InfluenceValue;

currentCell.mInfluenceBuffer = propagator.InfluenceValue;

 }

Propagation

To update propagation, cycle through each cell in your grid; Inside the loop, create a local float min and max influence variable, which initially equals zero. Then create a sub-loop that cycles through the list of neighboring cells of the current cell on the grid. In the neighboring cell, the sub-loop use this formula or one like it to create the influence spread:

influence = currentNeighbor.mInfluenceBuffer * Mathf.Exp (-mDecayRate * decayScalar) 

With the influence of that current neighbor cell calculated, you want to set the min and max value of that cell. Then check if the absolute value of the minimum influence is less than the max influence. Lerp that cell's influence value with the new min or max influence value that was just previously calculated.

foreach (Cell currentCell in mGrid)

{

    float maxInfluence = 0.0f;

    float minInfluence = 0.0f;

    List<Cell> currentNeighbors = getNeighborCells(currentCell.mGridIndex, GridDirection.AllDirections);

    foreach (Cell currentNeighbor in currentNeighbors)

    {

         float influence = currentNeighbor.mInfluenceBuffer * Mathf.Exp (-mDecayRate * decayScalar); 

         maxInfluence = Mathf.Max(influence, maxInfluence);

         minInfluence = Mathf.Min(influence, minInfluence);

         if (Mathf.Abs(minInfluence) > maxInfluence)

              currentCell.mInfluenceValue = Mathf.Lerp(currentCell.mInfluenceBuffer, minInfluence, mMomentum);

         else

              currentCell.mInfluenceValue = Mathf.Lerp(currentCell.mInfluenceBuffer, maxInfluence, mMomentum);

    }

}

InfluenceBuffer

Lastly, to update the influence buffer, iterate through each cell of the grid and set the cell's influence buffer equal to the current cell's influence value.

foreach (Cell currentCell in mGrid)

{

    currentCell.mInfluenceBuffer = currentCell.mInfluenceValue;

}

Influence Map

As a result of Update Propagators + Update Propagation + Update Influence Buffer, you now have an influence map. Those three functions are known as propagating, which updates the influence on the grid.

Agents with blue hues have negative influence and those with positive influence have yellow hues.

Influence Map Application

Some interesting things you could do with influence maps allow agents to path find towards opposing forces and set influence towards detection ranges, as shown below with my turrets.

I made my agents choose a random location on the grid and compare that location with other locations’ influence values. If the influence value is of the opposing force’s influence then, that agent will path find towards that location.

// the agent's base influence is positive

if (mPropagatorInfluenceValue > 0)

{

    // prioritize another cell that has less influence that was initially wanted

    if (currentCell.mInfluenceValue < wantedCell.mInfluenceValue)

         wantedCell = currentCell;

    // stop the search early if found negative influence (an enemy was spotted)

    if (wantedCell.mInfluenceValue < 0)

         return wantedCell.mWorldPosition;

}

// the agent's base influence is negative

else if (mPropagatorInfluenceValue < 0)

{

    // prioritize another cell that has more influence that was initially wanted

    if (currentCell.mInfluenceValue > wantedCell.mInfluenceValue)

         wantedCell = currentCell;

    // stop the search early if found positive influence (an enemy was spotted)

    if (wantedCell.mInfluenceValue > 0)

         return wantedCell.mWorldPosition;

}

I applied influence on turret neighboring cells (Cardinal and Intercardinal Directions) that were within its detection radius.

Video Demonstration Link:

References

laurentlavigne. “AI Influence Maps.” uBibliorum, Dec 9, 2016. https://forum.unity.com/threads/ai-influence-maps.145368/

[thecodingsheep]

Development Blog on The Most Challenging Week

Introduction 

The first week after gaining new members in my studio was one of the most challenging weeks I have encountered this semester. After Greenlight, there was a week of downtime dedicated to non-development tasks to allow the recruits to the team that extra time to inform themselves on the documentation, game loop, art style, and back-end logic. As the sprint pace slowed down, it affected my workflow pace the following week, my most challenging week. That week I wanted to work on something relatively simple in the abstract but a crucial feature that integrates well into other systems, the Pumpkin Pal's State Machine with a few movement-related states and transitions: circular movement, follow a target, idle, interaction, linear path, random movement confined to a square perimeter, and wander. With these seven states and transitions, singular-functionality was not a difficult feat but setting up the initial State Machine for each creature and properly setting each transition for each state so the states can transition to each other. Subsequently, storing each state into a list to be later referenced to allow that state-transitioning to occur turned my estimated six-hour task into a ten-hour-plus one.

A Pumpkin Pal in the Wander State.

The Outcome

The outcome was not nearly terrible as one would infer. The night before the end of the sprint, after about four hours of effort each night, I was able to correctly utilize Polymorphism, a programming technique where an object or an inherited class derives properties from its parent object or class while having individual or special properties relating to that class's specialty. In my case, I created a state class, which solved my problem of storing each of the states in a list as now each state had the same data type, which they inherited from the parent state class. To handle each state having access to its correct transitions was resolved by utilizing the state machine having each initial state made with nulled state transitions. In the same function but on the following line, the program will check the AI's state list and add all the required transitions to the nulled state transitions. I was able to solve that particular problem with the help of my AI professor, as he informed me each transition should have some sort of reference to each state that they need to transition to, either by holding the next state itself or its ID. 

The line of Code I mentioned.

Reflection

If I had a time machine, I would have asked for help earlier to save time. I find it most frustrating to be stuck on the same task that one started at the beginning of the week; In my case, I started the state machine and all its components on that Sunday but did not finish the feature until that week's Thursday night, the night before the end of the sprint. Despite that, It was a great learning experience as I am now 100% confident working on any system that requires Polymorphism, like the traits, evolutions, and treats system in Pumpkin Pals.

The state and transition diagram. The diagram showcases all the states and its possible transitions.

[thecodingsheep]

Development Blog on The Future of Pumpkin Pals

Introduction 

Greenlight (game prototype showcasing event) feels like ages ago but helped me valuable experience to simulate for next semester's senior capstone team presentations. My team showcased our game prototype "Pumpkin Pals," and we practiced and reworked our presentation for it numerous times in preparation for the event. We changed the order of the slides to make it appear as no one is not dominating the presentation. Our transition from one person to the next felt smooth and purposely clear! Also, We stuck to the rule of three, no more than three items a part of a particular category. For example, when listing the system mechanics of our game Pumpkin Pals, my team only listed the: growing, decorating, and interaction mechanics. I had had to cover two of the mechanics, and I was extremely nervous presenting my part. I felt my arms and face twitch from unrestful nerves. Despite that, for the most part, I was able to successfully recall my part of the presentation from memory; Which will be great practice for any presentation in the future. I did "mess up" the order in which I wanted to initial say for one of my mechanics slides but was able to recover. After numerous conversations with audience members, they seemed to enjoy Pumpkin Pals as a game concept and would enjoy seeing it move forward into further development for the remainder of the semester. 

After Greenlight Experiences

Luckily for me, Pumpkin Pals as a game concept went forward and will be one of the two games worked on with a larger team for the remainder of the semester. The decision for this game to move forward was not easy as it came down to a tie three times with Lanternbound (another game showcased at the event). The following Production class after Greenlight was utilized to recruit new team members that would help my team in the future development of Pumpkin Pals. My team recruited an additional creature artist, a systems programmer, a gameplay programmer, a narrative designer, and a producer. So far, my team has had numerous meetings to help these new hands adjust to Pumpkin Pals after two full weeks of development. Documentation about Pumpkin Pals was created and updated to help solidify our game loop and narrative to allow the new members to get input on how they would like to see the game concept evolve. For example, on March 8th, The team had two meetings: One for tightening the game loop; Which will help the team establish how some of the shallow appearing systems on the systems list document integrate into the game's win state (giving them more value). The meeting helped showcase how the Day and Night Cycle system influences gameplay by allowing some NPCs and shops to only appear or open at specific times of the day. Collectible items have a chance of growing at certain times of day and can be collected after a certain time duration or time of day has been achieved. Two for the narrative direction. I was not a part of that meeting, but I do know that the narrative team established the reason as to why our main protagonist has to acquire/unlock all the emotions in the game from growing and collecting Pumpkin Pal creatures (the win state). Also, our team established discipline meetings to help make sure that each discipline is on the same page by adjusting to the right art style and making sure that completed systems get correctly pushed into the build as examples. Overall, the new larger team seems to work well together.

Reflection

From this whole overall experience, I learned that sticking to a rigid script during a presentation can backfire and should leave room to include quirky personalized speech to add a bit more flair into whatever the presenter is saying. Also, becoming a leader in a discipline is a lot of responsibility in terms of keeping meetings documented, and if someone wants to deviate and include a new system or mechanics, that person has to run it by me; Which is not something I am not well accustomed. Lastly, I learned the value of making sure that programmers on the team have to work on systems that are dependent on each other because working on a very dependent system without having the independent system already implemented is a hard struggle. So I will keep that in mind during my team's next sprint!

[thecodingsheep]

Flow Field Pathfinding

Introduction

Flow field pathfinding is a grid-based pathfinding method, where hundreds or even thousands of agents can steer towards a single location, and that destination can dynamically change without a huge performance loss. Two fields are required to help generate a flow field: A cost field and an integration field. 

Cost Field

The cost field stores information regarding the terrain type and associates a cost value for that particular terrain. As the developer, you can set any value for how the terrain cost will affect gameplay; The lower the terrain cost, the more desirable that type of terrain is to agents. The only rule is the terrain cost can not be greater than 255 or less than or equal to 0. Any impassible terrain cost value will be 255, the max value of a byte data type. A terrain cost of 0 is the destination node, which is calculated in the integration field.

My grass terrain has a cost of 1. My dirt terrain has a cost of 4. Lastly, my stone terrain has a cost of 255. My agents will prefer to path find on the grass terrain and will attempt to path find around stone and dirt terrains. They will never path find through stone terrain as it has the impassible terrain value of 255 (only on special cases, as you will see in the video demonstration).

Integration Field

The integration field calculates the cost for each cell towards the destination cell, whose cell cost value is set to 0. Cells closer to the destination cell are smaller compared to those further away. The idea is that agents will want to path find on the shortest cost path so each cell will carry a directional vector to the best cost path (the lowest cost path) when flow fields are utilizing the integration field. Each cell on the grid (besides cells with a cost value of 255) will check its neighbor cells and add its cost terrain cost value to its own to help achieve low costing pathways on the grid.

Since the grass has a terrain value of 1, every grass terrain cell on the vertical and horizontal will cumulatively increment with a value of one away from the destination cell. The diagonals will increment with a value of 2 away from the destination. 

Flow Field

Finally, utilizing the integration field's newly set cost for each cell away from the destination cell, 8 directional vectors (the 4 cardinal directions and the 4 bi-cardinal directions) are created on the grid that all point to that destination cell. Numerous shortest pathways are created, which allow agents to path find on low costing pathways (shortest paths). In the agent controller class, modify the agent’s velocity by taking the directional vector (created by the flow field) that the unit is currently on and multiplying that vector by the unit’s speed, and setting the result as the agent’s velocity. As the agent moves to another cell, that directional vector will replace the previous cell's direction vector in the velocity calculation to ensure the agent steers towards the destination cell, whose direction vector has a magnitude of 0. 

Red X Icon: Impassable terrain (255 cost cell).

White Arrow Icon: Cell direction to goal cell.

Orange Circle Icon: Goal cell (0 cost cell).

Yellow Circle: Unit pathing towards goal cell.

Video Demonstration Link:

[thecodingsheep]

Development Blog on Game Concepts

Introduction 

Over the last several weeks, my production team and I have been prototyping three game concepts. We hope that our cohesive and most well-scoped prototype will pass through an event known as Greenlight (a showcase of one prototype per 3rd-year production team). 

Concept #1

My team and I's first game concept was Man-made Horrors: Macabre Metropolis; Which is a horror city-building simulation-esque game where the player must balance the amount of fear they instill in their human inhabitants through building placement and the monster populations. The higher the fear, the more monsters move to the city. However, the human population may flee town with the new influx of monster residents. Initially, my team was dead set on this game concept as we had a clear vision of the game loop closing with the remaining eight weeks of the semester. Regardless, this game concept was not the one we selected as investing a lot of resources in fine-tuning numbers could quickly get out of scope, and our team loved another concept a bit more!

Concept #2

The second game prototype was Templum Umbrae Daemonium, a stealth game. The player takes on a persona of a shadow demon who recently got liberated from their stone prison within a dark temple. However, the ancient origami-themed guardians of the temple feel the shadow's lively-active presence and have awakened to cast the demon into eternal sleep once again. The shadow must avoid light sources and utilize their abilities to escape the temple. The closer the player is to the exit, the more lit areas; thus, the more treats the shadow will encounter. We rejected the game concept because the team foresaw the game loop closing way before the end of the semester. The only new gameplay elements to add were new player or guardian abilities, puzzles, and levels which was not evoking our team's passion in further developing the concept, even though the art direction was unique and compelling.

Concept #3

The last game concept my team and I selected and thought was the most cohesive and well-scoped was Pumpkin Pals, a creature-collector ranching simulation game. The player takes on the persona of Fred Gourdon, a retired headless horseman who decided to settle down to grow his own. The player can interact with pumpkin head-themed creatures known as Pumpkin Pals, where through particular interactions like hugging, the player can manipulate these creatures' emotions. The player must help Fred discover Pals' preferred interactions to unlock heightened versions of their emotions, like from happy Pal to glee Pal. Fred can demonstrate his creature's emotions at the weekly social at the town square for extra cash and rewards on the side. While at the town square, Fred can purchase and sell decor items, treats, and seeds to help the player add their personal flair to the game. The game concept is ambitious, which is great because it has a well-defined and achievable scope in closing the game loop for the remainder of the semester. As a bonus, my team incorporated elements from prototype one (Man-made Horrors) like decorating Fred Ranch and some returning NPCs to help add a little something to make everyone satisfied in developing this game. Combining well liked elements from one prototype to another that is manageable is what helped us formed in our decision.

Pumpkin Pals title screen!

Personal Contributions

As the team's programmer, I allotted most of my time developing the first iteration of the emotion and interaction system. I vividly recalled having numerous mini-meetings with the team's lead designer in inquiring how each of the three interactions (hug, yell, and talk) at that stage of the build affects Pals of particular personality traits. There are four personality traits: sweet, bitter, homely, and erratic. Pals with the sweet trait strongly dislike mean interactions (yell) but prefer friendly interactions (hug). Bitter pals prefer solitude (no interaction) but hate when their personal space is invaded (hug). Homely pals prefer talking and are not strongly affected by any interaction. Lastly, erratic pals are a wild card regarding interactions, so any interaction will have a random chance of being liked or disliked; Setting the foundation of how interactions and emotions will play helped the team formulate how the game loop regarding that system will function. Subsequently, I questioned how the lore of the prototype intertwines with game systems and mechanics. If the lore and mechanics cohesively mesh together, it not only strengthens Pumpkin Pals as a game concept but solidifies the game loop; Which provides additional evidence that this game concept is feasible and strong.

Some in-game footage.

Reflection

When initially programming Pumpkin Pals, I had doubts about my ability to program the mechanics and systems needed for the game. I adore simulation and rancher-esque games and would dislike seeing it fail because of my inability. However, my pessimistic thought shifted as Pumpkin Pals' concept scope narrowed to familiar territory but also still maintained some level of challenge; Which I can adequately adapt to and learn from. Along with my team, making necessary edits: the explorer mode moved to future plans and having 2D pumpkin pal creatures in the 3D environment to accommodate our 2D-character artist. From this experience, I discovered that having team members always clarifying the scope of the project and making sure that each member is working with some level of familiarity was refreshing but valuable.

[thecodingsheep]

Flocking With Obstacle Avoidance

Introduction

The Flocking steering behavior is a blended steering technique that utilizes the group alignment, cohesion, and separation steering to simulate agents maneuvering together like birds in a flock. Group alignment is responsible for agents matching their nearby neighbors' velocity (the group's average velocity). Cohesion allows agents to clump together with their nearby neighbors' position (the group's average position). Lastly, separation steering is somewhat the opposite of cohesion; It lets the neighboring agents steer away from the group's average position. With flocking, separation acts as an offset for cohesion steering so that the agents do not pile on top of each other when steering to the flock's average position, and group alignment allows the group to move together at the same pace.

Flocking + Obstacle avoidance

There are several ways to combine obstacle avoidance with flocking: blending the obstacle avoidance as a weight in the flocking steering, running obstacle avoidance independently, etc. In my implementation of the algorithms, I found running obstacle avoidance independently from the flocking steering worked the best. Instead of modifying the velocity of the agent when approaching nearby obstacles, I directly changed its position and applied the necessary avoidance force according to what the agent's numerous rays detect; Utilizing these formulas:

AvoidanceForce = (Ray - Obstcale.position).normalized() * MAX_AVOIDANCE_FORCE;

Agent.position +=  AvoidanceForce * MAX_SPEED * deltaTime;

There are 5-6 groups of agents in a flock.

Flocking Demonstration Link 

The pink agent in the demonstration does not run the flocking algorithm but is wandering. That agent was utilized for the sole purpose of allowing my other agents to start moving and see the flocking algorithm in effect since the starting velocity and acceleration for each unit have a magnitude of zero. Also, utilizing partitioning methods like quadtrees, grid, etc., is an efficient way for you to have a lot of agents running flocking all at once. The algorithm can get expensive quickly when checking through a list of all agents in the scene, is nearby that agent every frame. An alternative to partitioning is storing a list of neighboring agents (if it is close to a specific radius to that particular agent). In my demonstration, I used the grid method as it was easier to implement and is not memory intrusive on this small-scale assignment.

[thecodingsheep]

Obstacle Avoidance

Introduction

Obstacle avoidance behavior is a technique utilized to provide an agent's steering AI the ability to maneuver in a crowded scene by swerving around or avoiding obstacles. This technique is necessary to make agent AI movement in the environment look believable. One would not want townsfolk in an RPG game to attempt to walk through a wall, trees, or other non-playable characters. One way to achieve obstacle avoidance is raycasting.

Raycasting Obstacle Detection

Obstacle  raycast from a circular agent, one would need to take any point on the agent's surface position in relation to a point outside of the agent (this point could be infinite). These two points create a ray. Any obstacle that intersects these rays are potential objects that can cause the player to crash; So it is up to the rays from the agent to detect collision and pass this information to the agent so that the agent can steer accordingly.

When the ray detects an obstacle it will turn red and move in its respective direction. In this case the agent will move downwards.

Avoidance

Rays transmit their collisions with obstacles to the agent, for instance, through a boolean function. If false, the agent continues to steer in the direction they were initially moving. If true, the agent will steer in another direction to avoid the impending obstacle collision ahead of the ray. In my demonstration, I account for these ray collisions, and the agent maneuvers accordingly:

Top Ray:

The agent steers downward

Bottom Ray:

The agent steers upward

Middle Ray:

If above the obstacle’s center point

The agent steers upwards

If below the obstacle's center point

The agent steers downward

Top Ray & Middle Ray:

The agent steers downward

Bottom & Middle Ray:

The agent steers upward

Top Ray & Bottom Ray:

The continues normally

Top Ray & Bottom Ray & Middle Ray: (although rare in my program)

The Agent Crashes

Obstacle Avoidance Demonstration Link

The more rays surrounding the agent, the better it is at avoiding obstacles as seen in the clip. In practice, for a small scaled simulation like in my video demonstration, three rays would be enough. For a larger project dealing with numerous objects with different sizes and forms, more rays are essential as the agent will not successfully avoid close-knit or concave objects.

References

Reynolds, Craig W. “Steering Behaviors for Autonomous Characters - red3d.Com.” Accessed January 30, 2022. https://www.red3d.com/cwr/papers/1999/gdc99steer.pdf. 

Wood, Tyler. “Obstacle Avoidance.” Tyler Wood, 2015. https://tyskwo.com/work/89_obstacle-avoidance/.

[thecodingsheep]

Development Blog on Pernicious Plotting

Introduction 

As a junior at Champlain College, I have acquired some of the fundamental skills and knowledge it takes to be a game developer who aspires to work in the industry after graduation. During this semester, spring semester, I am taking Game Studio 2; Which is a class that builds on these fundamental skills, teamwork, and production skills, to simulate a fully designed, documented, and tested digital proof of concept suitable for portfolio inclusion along with a complete game “pitch.”  Currently, my team and I were tasked to construct three unique game ideas, and each week, one concept will be prototyped and demonstrated to the entire class. At the end of the three weeks, one concept will move onto the next round, where it will be a fully-fleshed-out fun working game. My team and I are designing elements needed to fit the theme for our first concept,  “A Horror City Building Sandbox-Type game." Presently, our placeholder name for the game is "Pernicious Plotting." The goal of Pernicious Plotting is to fill up the fear meter so that the player can unlock more buildings to place and for new residents to want to move into town. The game challenges the player's creativity and resource management skills as too much of one building or resident will cause residents to abandon the city. If all residents move out of the town, the town becomes abandoned, and the player will lose the game. If the player has placed down all the buildings from the build menu at least once, moved in all types of residents at least once as well, and reached the maximum capacity throughout their entire playthrough, then the player will win the game.

Current State of The Prototype

As the team’s programmer, I was tasked with developing the prototype for Pernicious Plotting’s main game mechanics and systems: the grid plot, lots, buildings, residents, and the fear system. So far, I have only programmed the functionality of grid plots, lots, buildings, and the fear system. Later this week, before the prototype presentation, I should have the core functionality of the residents programmed and ready for the prototype demonstration.

Grid Graphs: In my past computer science and game programming classes, I have familiarized myself with the concept of a grid graph; A graph that contains nodes and connections. The nodes store information such as position on the graph and neighboring nodes. I utilized my understanding of grid graphs and created a grid plot that allows the player to place buildings and lots from a build and lots menu onto the grid plot/map. Any nodes that are occupying the space the lot or building is taking up are stored into that respective node and later used for identification needed for later deletion or the ability to add a building on top of it (for lots case).

Lots: Lots are plots of land that the player can place onto the grid map from the Lots Menu. Lots come in five unique sizes: 3x3, 3x4, 4x4, 4x5, and 5x5. Larger lots can reserve more buildings and largely sized buildings compared to smaller lot sizes. The rendering color of Lots will change to reflect if the lot can or cannot be placed down onto the grid map. A more red hue will display if a lot is on the border of the grid map; Also when a previously placed lot is already occupying the space of the grid map as well. Once a lot is implanted in a valid location on the grid map, the nodes confined with the lot’s shape will update and become a lot node. 

Buildings: Buildings are shelters and attractions for residents that the player can place upon lots from the Building Menu. Buildings come in three distinct sizes: 2x2, 3x3, and 4x4. Largely sized buildings require more extensive lots compared to smaller ones. Buildings rendering color will change to reflect if the building can or cannot be placed down on ta lot. A more red hue will display if a previously placed building is on that location on the lot and if a building is off a lot. Once a building is placed on a valid unoccupied space on the grid map, the nodes confined within the building’s shape will update and become a building node. Each building has a pre-set fear value which contributes to the fear system.

Fear System: The Fear System determines the win and loses condition for the game. Placing buildings contributes to the town’s total fear rating. The higher the rating, the more buildings are unlocked. Presently, the fear meters will only reflect the impact each fear value the buildings contribute to the town, but later this week, I will add more resident integration to contribute to the win and lose state for a more dynamic fear system.

Picture of grid map that lots and buildings can be placed upon (Note: not the actual art of the prototype)

Picture of lots (in green) placed on the grid map and a building placed on a lot. One building was attempted to be placed on the grid map, so the hue turned red. (Note: not the actual art of the prototype)

Picture of the fear meter increasing as more buildings are placed in the town. (Note: not the actual art of the prototype)

Personal Strengths and Weakness

While working on Pernicious Plotting, I am noticing particular areas that I am breezing through during prototyping. Particularly anything to do with node information, storing, connections, etc. The grid map is the most fleshed-out and most-complete feature in the prototype; Which should be the case as I have had previous experience with nodes and graphs in my prior computer science and game programming courses. On the flip side, I do encounter that I am having minor issues with the small collision detection system for detecting the mouse’s world position in relation to the particular object the mouse is close to in the scene. This type of collision detection is critical to determine which object the player can delete (if they so choose to). I am currently in the process of reading up on documentation and detection algorithms I can plausibly utilize to aid me in this issue.

Growth and Takeaways

During Game Studio 2, I aim to prioritize setting realistic goals and boundaries for developing game prototypes. In the past, I usually overwork or overdo more than what is required to contribute to my game development team, and these expectations should not be standard practice but a spur-of-the-moment opportunity to do passion work. Setting boundaries like not working on game development tasks after 10 pm has been relatively helpful for my programming creativity and mental health. Setting realistic goals, like taking on two small tasks and one medium one, is a small step in avoiding burnout; Which is something crucial to avoid in this industry. 

[thecodingsheep]

Tactical Pathfinding

Introduction

Tactical pathfinding has a reputation for being more intricate or complex compared to other pathfinding algorithms. Despite that, tactical pathfinding is quite similar to those algorithms; the only difference is the cost incorporates tactical information in addition to the typical distance and time cost (Millington 2019). Along with a weight multiplied by the tactical information, the product is added to the distance and time cost to create the new cost for the connection; This can cause intricacies as tactical information is commonly stored on a per-location basis.

Application In Games

You can utilize tactical pathfinding in virtually any game involving complex strategic gameplay. For instance, stealth games and military combat would incorporate this technique to allow AI-controlled enemies to take additional actions such as fleeing, calling in reinforcements when outnumbered, taking cover, hiding, reloading, etc. (Cifelli 2016). All those actions deliver a slightly more immersive experience to the player than the standard shortest path pathfinder. 

At first thought, Real-Time Strategy (RTS) games' AI may seem to benefit from incorporating elements of tactics; however, since the player is manipulating their pawns' actions, this method is used. RTS games that involve non-player-controlled squads could possibly work; It would just require intelligent game level design; to prevent the player's team from poor pathfinding, such as accidentally subverting from the player's preferred path. The squad can then evaluate the game situation correctly to perform actions: seeking cover if the enemy is shooting, squatting if the player is crouching, jumping over a ledge after the player has jumped, covering the player while they are flanking, etc. (Millington 2019).

Influence Maps for Pathfinding

Influence maps are great for handling tactical pathfinding, particularly for large outdoor environments. These maps are evoked from spatial logic through propagators, which are constructed by scalar fields of influence, carrying positive or negative influence. Influence maps provide these components to make the AI make better decisions based on the influence value at the given AI's location (Adaixo 2014):

Situation Summary - Summarize the active details in the world, allowing data retrieve easier (quick response time)

Historical Statistics -  store the current world's information for a limited amount of time

Future Predictions - Influence maps anticipate upcoming events.

If a red unit were to enter a blue area, the influence map would predict that the blue units would attack, so the red units would stand guard and prepare to call for reinforcements.

Basic Influence Map Demo

Multi-Tier AI

With Multi-Tier AI, each unit has its own AI while partaking in a group and there are tiers for how decisions are made collectively and individually; There are two common types of decision trees in this technique top-down approach and bottom-up (Millington 2019). .

The top-down approach is where the highest level AI makes a decision for the group and passes the information down each tier to the lowest level. There is usually a strategic reasoning system like state-machines, tactical analysis, or influence maps. The highest decision is the player in this approach. The characters will respond to the player's presence and input. For instance, if the player decided to enter a nearby river to "quickly" get across the other side, the AI would follow the player in this approach to match the player's preferred path. 

The bottom-up approach is where the lowest level AI accesses the game situation and acts on them. Systems on lower tiers would allow units to stay together while avoiding local obstacles and storing new information from their surroundings (from influence maps as an example (Millington 2019). In the river example, in a game where group members have different attributes like swim speed or walk speed, a group member with a faster swim speed would follow the player's preferred path. If there was a nearby bridge, other group members may opt to walk across the bridge and wait for the player to reach the other side (with influence-map-based future predictions).

An example of a Multi-Tier AI hierarchy

References

Adaixo, Michael Carlos Gonçalves. “Influence Map-Based Pathfinding Algorithms in Video Games.” uBibliorum, June 20, 2014. https://ubibliorum.ubi.pt/handle/10400.6/5517?locale=en. 

Cifelli, Tyler. “Tactical Waypoints and Tactical Pathfinding.” Tyler Cifelli, April 25, 2016. https://tylercifelli.com/2013/12/07/tactical-waypoints-and-tactical-pathfinding/. 

Millington, Ian. “Tactical Pathfinding.” Chapter. In AI for Games, 548–73. CRC Press, 2019.