Lets talk about: Future project(s)

So, the other night, I was watching a DemoDisk video by Funhaus, and I saw them featuring a Shadow the Hedgehog trailer. After watching a short 4 - 5 seconds clip of the trailer, I thought to myself, why not give the Sonic universe, a good name. I mean, I've always heard that Mario was a big hit, and that he was so much better than Sonic. But I thought differently, I always preferred Sonic. And then, it occurred to me, why not make a free-roam Sonic game? Where you can customize your own characters, it follows the lore of the Sonic universe. Imagine The Witcher 3: Wild Hunt, but the Sonic universe. I conferred with my friends and colleagues, and most, if not, all of them said that it would be a good idea. And they were all really familiar with the lore and the whole universe. 

Some of you, who are reading this post who knows and likes the Sonic universe, would like to see a game where you can play as Sonic, where you don't have to run in a linear path just to collect coins and to destroy Dr. Eggman and his evil contraptions. Imagine a game like Shadow the Hedgehog but instead of expecting linear game play and story telling, there would be a more elaborate story line, and a bigger map where you can conduct your missions and whatnot. It would be great, right? Reasons like these give me the inspiration to be a game developer, where I can develop a game where I think people would enjoy. Bringing something new in the industry or the indie market.

Some of you are wondering or saying that I might be a bit too ambitious with this idea in my head. I mean, making a game this big would take years and years of development. Not only that, but I will have to buy the license of Sonic, off of SEGA or whoever owns Sonic and anything else which is affiliated with him and the lore. But then again, it is just an idea, a future project, or maybe even a little side project after I graduate or in-between my trimesters, who knows? But what I do know is that I have some people who are willing to give it a try, and it won't hurt to give it a try, am I right? 

Lets talk about: Loot crates and its new label

As most of you may or may not have heard, loot crates and anything which involves the players to open up something with some sort of probability, is now considered as gambling. Games such as Overwatch and CSGO have their loot crates/cases. 

How do I feel about this? Well, I don't feel affected in any way, shape or form. I believe that spending real money on virtual items is useless, because this items do nothing but add aesthetics into the game. Like CSGO weapon and glove skins. It doesn't give you any combat superiority or gain, like what Revolver "Shalashaska" Ocelot from Metal Gear Solid V: The Phantom Pain once said, "Engravings, give you no tactical advantage", and I couldn't agree more. Weapon skins, character skins or anything that can have a skin, are just meant for bragging rights:

"Oh look, I have a rare skin!"

"Oh look, I have an epic skin!"

"Oh look, I have a legendary skin!"

"You won't believe what I spent with my $300 Chirstmas/birthday money! A knife which gives me no value or benefit whatsoever!" :D

Things like these makes my blood boil! Where some games just lives off of micro-transactions, which is sort of like ripping off or stealing from your consumers. A prime example of this, are mobile games, Clash of Clans and Candy Crush to be precise. These games have little-to-no gameplay, they're free, but what better way to make our game fun and put some cash in our pockets? Just trick them to buy golden lollypop bars so that it can give them unlimited lives, tries, moves and whatnot. (And yes, I'm aware that I'm going off topic but I just had to get it out of my system)

Some people might say that I'm "salty" for not having a $300 - $1000 knife or skin in my Steam inventory and that I have to "git gud" but its annoying. You're burning your wallet for things that give you no advantage, no gain, no superiority, whatsoever in battle or in-game. Its like how Xbox Live insults work. Its annoying, and its just there. You can't avoid them. (You know what I'm talking about). But I have come to accept the fact that they're burning their own money on these things, and I won't fall victim to this "skin insanity". 

Hopefully with this new label, things will change. 

Project Renegade

For this unit, or trimester, I have been tasked in making a game with a group, the group consists of 7 people, 2 programmers (including myself) and 5 animators. Our game/project is called Renegade, a 3rd person and isometric stealth game, where the player will have to sneak around the map, and make their way to the escape point. The game will feature a simple AI which would have these behaviors:

Patrol - Following a set of points around the map

Chase - Chases the player if they are within a certain distance

Attack - If the enemy is really close to the player, the enemy will attack

Search - If the player chooses to use a noisemaker to lure the enemy, the enemy will "search" for the source of the noise

Stun - If the player chooses to use an EMP dart on the enemy, the enemies will be disabled for a few seconds

Judging from the behaviors Stun and Search, you may or may not realize that we have two bullet types, a noisemaker and an EMP dart which works much like a tranquilizer dart from the Metal Gear series.

For the behaviors or the enemy AI, we are using the composite design pattern for the the behavior tree. If you haven't read my previous post on behavior trees, I mentioned there how a composite design pattern behavior tree is used. For re-cap purposes, a composite design pattern includes a composite node class, which mainly features 2 other classes inheriting from it, the selector and sequencer class. These 2 classes will determine how the AI will behave. The sequencer class will check all of its children. If all of the children returns a success state, then the sequencer will return as success. The selector class will check its children in priority, on by one. If any one of its children returns a success state, the selector class will return as success. More on this topic on the behavior tree post.

In this post, I will also be mentioning the progress update for the project.

The progress so far:
1 -  We almost have our behavior tree working, with the chase, patrol and stun behavior working. I have tasked my partner with the attack and search behavior. Progress is coming along for those two behaviors, and I hope to see it done by the end of this week.

2 - The UI is almost done, and the main menu is finished, with working buttons, and a main menu music at the back to complement the menu. The UI needs images for the bullet types and updated ammo counter. Once that's done, the UI will be complete.

3 - In terms of the animators' side, the map layout has finally been textured completely. The only thing left is to add some lights on the walls to give the vibrant, neon TRON: Legacy aesthetic. Character models are finished, but they have not been implemented yet. Animations are underway, and progress looks very good. My animators inform me that they will be done by this week.

Progress to be complete:
1 - As mentioned above, we need the attack and search behavior integrated, in order for us to have a complete behavior tree.

2 - Integrating character models and animations within the game

3 - Finish the UI with ammo counter

4 - Cleaning up the map

5 - Check scripts for bugs and errors to ensure smooth gameplay

Steering Behaviors

Steering behaviors is something used to make your AI move in your game look a lot more human. For example, in Unity, you can make a patrol pattern which gives the user a somewhat good feel to the game. However, when the enemy reaches a point, they will move at full speed towards their target, and stop perfectly. It makes them look too much like a robot! Steering behaviors allows your AI to make them move and behave more human.

Whilst we're on the topic of patrolling, there is a steering behavior called Arrival. This behavior will allow your enemy to arrive at a target position much like a human. We never move to our target area as fast as we can and stop. We slow down towards our target and come to a nice and smooth stop. This is what this steering behavior does. It makes an invisible circle around each point, and the closer the enemy gets to its point, the lower their speed. 

Other steering behaviors include:

Pursuit - This steering behavior will calculate where their target will go to in x frames, much like a leading target. If you've ever played War Thunder or the new Battlefront's starship mechanic, you can see a lead target, where you will hit the target. This is what this steering behavior does.

Evade - This steering behavior will allow the enemy to evade a target object within the game scene. Much like a prey, running away from its predator.

Wander - This steering behavior will allow NPCs or enemies to wander around your game scene. This is made by making an invisible circle infront of the NPC or enemies. Within this circle lies the steering direction/force which will allow them to move towards that direction. This steering behavior will never invert on itself, much like a person forgetting something in a room. 

Seek - This steering behavior allows your enemy to seek out a target.

You can see many more by using this link: https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732

Pathfinding

Pathfinding is an algorithm AI uses to find the closest distance to a target. So in our case, a game, pathfinding is made to allow the AI to find the closest distance to the player. Some of you might ask, why would we need such an algorithm if we can write a few lines of code to chase the player. If we didn't have a pathfinder, the AI will not be able to chase the player, if there was an obstacle in the way. For example, if the player and the enemy was at opposite sides of a table, the enemy will not be able to chase the player, as there is something blocking its way.

How does it work? 

When making a pathfinding manager, you should make a singleton for it. For those who don't know what a singleton is, a singleton is a way of making sure that there are no duplicates of a script. For instance, there should only be ONE GameManager script throughout the whole game. A singleton is made to ensure that this is true. However, for a pathfinging manager, we don't want to destroy the manager as soon as we load into a new scene, we want to keep the manager and the algorithm itself so we can use it for multiple levels, when needed. Once the singleton is done, there are 3 problems you should take care of:

1 - Building the Graph - The graph consists of the nodes (or waypoints) positions and the distances between each and every one of them. The graph also contains information of which nodes are connected to each other, and which ones aren't. The graph (for visual aid) is like the multiplication table. But in this case, instead of putting the total, you put in the distances and -1 for any nodes which aren't connected.

2 - Making the algorithm - The algorithm I used is the Dijkstra algorithm, where it will keep track of the accumulated shortest distance, if the node has been visited or not, from which node did it arrive from and a queue list which will check each node it arrives. This algorithm will go through each node, between the enemy and the player's position. It will then check which nodes have the closest distance to the player. 

3 - Backtracking - Once the closest distance has been calculated, the algorithm will now need to backtrack, from the player, to the enemy. Once the backtracking process is complete, the AI will then start to follow the points, given by the data/information given by the algorithm itself. 

Behavior Trees and Finite State Machines (FSMs)

Ever wondered how AIs in games work? Well, the structure is pretty simple. The AI will have to make a decision on what to do when they meet an enemy, an ally, a normal NPC or the player. In order to do this, they will have to make a structure which allows the AI to make decisions, both complex and simple. Developers and/or programmers can use either a Finite State Machine, or a Behavior Tree. In games, we use Behavior Trees really often, as it allows the developer to change an add new behaviors at any time, and any where within the tree. Its dynamic. The tree can be used for a really complex AI or a really simple AI.

Behavior Trees

Behavior Trees allows the AI to make complex decisions and actions when encountering the player or any other objects within the game. The decision structure is much like a tree, as shown above. The tree is made up of the behaviors (Actions) and the composite nodes, the selector and the sequencer nodes. Before I explain what each composite nodes do, I need to cover how the tree works. 

How the tree works:

Within the tree, there is a class called Node, or TreeNode, whichever one suits you for that particular behavior tree. Inside this class, there is an enumerator variable, which keeps track of the behavior tree's results (Success, Failed, Running, Ready). 

Success: It means that the AI has completed executing this behavior

Failed: It means that the AI has encountered something which prevented it from executing this behavior

Running: It means that the AI is currently running this behavior

Ready: It means that this behavior is ready to be executed.

Composite Nodes:

Selector: The selector node will check all its children in priority. If one of the children returns a result as success, the selector node will return success, and will run that behavior. 

Sequencer: The sequencer node will check all its children in priority. If ALL of the children returns success, the sequencer node will return success.

How the tree works, related to the image above:

So with the explanations above, I will explain how the image works. The head, or root, of the tree is a selector node. If we were to follow the numbers next to each node within the tree, it shows the flow of how this tree works. 

0 - It will check if any of the children nodes returns success

1 - It will check if any of the children nodes returns success

2 - Plays/checks behavior

3 - It will check if ALL of the children nodes returns success

4 - Plays/checks behavior

5 - Plays/checks behavior

6 - Plays/checks behavior

7 - Plays/checks behavior

8 - Plays/checks behavior

Lets put it into perspective. Lets say we had our own behavior tree. This tree would have:

1 - Selector

1.i - Sequencer

1.ii - Patrol

1.i.i - Chase

1.i.ii - Attack 

So the children of the selector will be the sequencer and the Patrol behavior. The children of the sequencer will be the Chase and Attack behavior. 

The tree will check if the sequencer has returned a result type success. It will check the children, both the Chase and Attack behaviors. If both of them return failed, then the selector node will check the Patrol behavior. If this behavior returns success, the patrol behavior will be executed. The patrol behavior is the default behavior of the AI.