Overview:
The last blog post was more of an introduction into the project. This week I will be diving more into the first steps that the team and I have taken. Technically, this is the second week working on the game, however because last week was an introductory post, I will be covering work done last week as well as this week.
The Game Design Document:
In my opinion, every game, app, or large project in general, should start with a design document. A document which describes the expectations. The team and I have worked on fleshing out our design document. We do this for multiple reasons:
Before getting to deep into development, it’s crucial to ensure that all members of the team know the mechanics, art, and overall direction of the game. Miscommunication early in the development process can lead to catastrophic results.
The document can also be used to present our idea to others. The document includes a synopsis, enemy descriptions, weapon descriptions, etc. All of these components convey the story of our game to the players.
Lastly, the game design document can also help the team and I to organize our tasks. We use it as an asset list, and this allows us to essentially check off what enemies, mechanics, and other components that we have already created, or need to create to reach our goals.
Enemy AI – NavMeshComponents:
I am new to AI in Unity so I decided to challenge myself by taking charge in the enemy AI for the game. My first step for working with AI is learning to use the NavMeshComponents. These components allow me to create and AI that can traverse specific terrains, based on the classification of the enemy. I found a helpful tutorial on NavMeshComponents on the Unity Learn website here. While I am still learning to use these components, here’s what I’ve run into so far.
Problems so far:
The baked nav mesh seems to apply to all surfaces in the game. I would like to be more particular as to which surfaces my current nav mesh should apply to.
The game requires that some AI must be able to walk on the sides of walls or even the ceiling. The nav mesh in it’s current state only allows for up to 90 degrees of slope, thus preventing all ceiling movement.
Solutions so far:
The nav mesh can be controlled by using specific layers, possibly allowing me to bake on only certain surfaces. I believe this may become a bit messy to manage later.
I believe that by baking a mesh, and then moving a component that has the mesh baked to it, I can change the orientation and the mesh will act normally. This would solve the problem of not being able to run on walls. However, if I ever need to re-bake, then I would have to completely reconstruct the walls after baking. This is extremely inefficient.
Enemy AI – Behavior Trees (BTs):
As I’ve stated before, I am fairly new to using AI in Unity. With the help of my teammates, I have begun laying down the ground work for using behavior trees for the AI as opposed to a Finite State Machine (FSM), which I had originally intended to use. The problem with using a FSM for the AI is as follows:
Maintainability: States are highly coupled. This means that changes to a state will have to propagate to any other states that use it. This high level of coupling decreases the efficiency of refactoring states, or even adding new ones in certain cases.
Portability: Because the states are so coupled, they can rarely be used outside of the conditions given to them. This means that they cannot be transferred between projects, whereas behavior trees can be somewhat future proofed.
After choosing to work with BTs, we decided that the simplest way to implement AI and check that our system is working, is to create a simple walking AI. The AI will simply move back and forth over a nav mesh on a standard plane. This is a movement that will later become the standard patrol behavior needed in all of the different enemy AIs.
Moving Forward:
My task now is to focus on creating the behavior tree’s for the enemy AI. The first enemy being developed is the Grunt. The two behaviors I want to focus on are patrol, and attacking the enemy. Once those are completed, I plan to work on either starting a patrol on another enemy type, or working on a fleeing behavior in the Grunt. In the next post I will dive into more specifics with the behavior tree implementation.