Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

In my LAST POST, I talked mostly about some of the pathfinding options that I came up with. One of these solutions involved relying on raycasting to determine a path to my player, which was a fun exercise and yielded some really entertaining gifs. However, I decided to scrap that system in favor of using Unity’s built-in pathfinding system via the NavMesh and NavMeshAgent components.

However, because my game uses grid-based movement, I wasn’t going to be able to use said system out of the box.

My first solution to making Unity’s pathfinding play nicely with my game was to have the NavMeshAgent generate a path, and then overwrite that path by normalizing each of its points to align with my grid (whose cells are 3x3x4).

This would have been fine, but I soon realized that would have had to account for inserting points along lengthy straight paths, as the NavMeshAgent only calculates the corners, or turning points, along the path.

I could have done this, but after a bit more thought, I realized this would require unnecessarily complex logic, and that I could accomplish the exact same end result with a simpler, but similar solution.

Basically, I just decided that, each time my enemies move, I would have the NavMeshAgent generate a new path. Then, instead of normalizing the entire path, I would just look at the first point in the path and normalize that. Why bother normalizing the whole path if I’m only ever going to be moving to the first point in the path anyway?

After I did this and added a bit of extra logic to account for the locations and movements of other enemies, I was able to successfully have relatively large mobs moving in ways that (more or less) seem to make sense.

Check out this video of some menacing cubes following my player around:

After I got all of that mostly working, I decided that, although the game is still in a super early state, I owed it to myself to add a bit of polish and replace my cubes with one of the assets I acquired.

Check out the difference a couple of textures, 2 models and some animation configuration can make:

So there’s a lot going on in this video, so let me explain.

Firstly, here’s a list of the key features that you can see in the video:

  1. Grid based player movement and turning (thanks to the awesome iTween library for all of my grid movement and rotation animations)
  2. Mouse Look with rotational snapping (this was actually kind of fun to do)
  3. Dissolving enemies (I’m still experimenting with different effects as you can see. Let me know which one you like).

Secondly, here’s an explanation of what you’re seeing in the video:

The game view is on the left. This is what the player sees.

On the right we have a bird’s eye view courtesy of Unity’s Scene View.

Note that the game uses a true turn-based system. Enemies won’t perform an action until the player does. In the video it appears that the enemies sometimes take multiple turns, but I’m actually skipping my turn via keypresses in those cases. I guess I should also mention that if an enemy turns to face a new direction, it ends their turn, but the player can turn as many times as they want for free. I might change this in the future, depending on whether or not this becomes an ‘unfair’ thing to be able to do and tilts the odds too much in the player’s favor.

The blue overlay you see is the walkable area of Unity’s NavMesh. You’ll notice that when an enemy enters an attack state, it will carve out the square that it occupies, making it non-walkable so that other enemies avoid that cell appropriately. I had to do it this way because, although Unity’s NavMeshAgents will avoid one another if they’re in control of movement, they don’t actually take into account other NavMeshAgents when they calculate the path, and since I’m manually moving my enemies, I needed a bit more customization.

You’ll also probably notice that some of the skeleton’s animations are a bit off–the attack in particular. Unfortunately, I couldn’t allow the animations to apply root motion as it interfered with my grid based movement, and as a result, some of the animations are a bit wonky. This was a purchased asset, which I’m still happy with, but if everything goes according to plan, hopefully I’ll be able to spend some money to have the animations updated to align with my grid.

Anyhow–that’s pretty much it for now.

I think my next focus will be on starting my inventory system. Looting, buying and selling are going to be a core gameplay component, so I’m going to have to get it right.

Deleted post

Thanks :)

Since I made this post, I modified how I handle pathfinding. I still use pretty much the same approach, but, since I'm manually moving my characters along the calculated path, I found that I was having to fight with the NavMeshAgent component attached to each enemy (since they also try to move whatever they're attached to).

Now, I don't even use NavMeshAgents. Instead, I just make a call to  the static function NavMesh.CalculatePath(Vector3 sourcePosition, Vector3 targetPosition, int areaMask, NavMeshPath path);

Deleted post