Week 3 and 4: Basic Enemy AI and a different perspective

It’s been a busy couple of weeks, so I haven’t found an awful lot of time to work on the game. However, I did manage to complete a couple of bits and pieces that get me a little closer to having a very basic playable game.

Enemy AI

Since this is a puzzle game, I want my enemy AI to be predictable by the player but still interesting enough that some thought is required to solve the puzzle. Therefore, I thought a combination between a basic patrolling enemy (walking up and down a line) and an enemy that spots you and comes after you might be a good mix. I think some interesting puzzles could arise from luring enemies around.

To begin with, I simply implemented the patrolling enemy. They act as if blind, not reacting to the player’s presence in any way – they simply follow a path up and down or around in a circle. This will be enough I think to implement a few basic puzzles and get me to that first playable iteration of the game.

Camera perspective

After thinking about it, I have decided to scrap the camera that follows the player and allows navigation using mouse look. There are two main reasons for this. Firstly, I mentioned in a previous post that not having access to the full information for the puzzle might frustrate players, and I think that having a camera angle positioned above the world makes it easier for the player to make informed decisions. Secondly, although the camera may have provided a different feel for the game (more like an adventure than a puzzle game), I think that the aesthetic of mouse look counterbalances this. For me, the sharp movements of the camera when using the mouse break the immersion, and are probably only suited to games where high precision is necessary (such as FPS games).

To implement the new perspective seen in the image for this post, I had to make a few changes to how my movement code worked. The code now fires a ray from the camera to the point clicked by the mouse, and if it finds a waypoint that is adjacent to the current waypoint it will tell the character to move there.

Introducing the new perspective has highlighted a possible problem with my NavMesh-based approach. Even though I disable clicking on other waypoints until the character is nearby the waypoint he is heading to, clicking another seems to allow the character to get too much momentum and kind of spiral around the next waypoint. I think I can remedy this by making sure the character has stopped (or is at least very close) to the current destination waypoint before accepting new destinations.

Next week

As I have mentioned a couple of times in this post, I think it is important to aim for the most basic playable game I can first of all. I can then iterate on this and grow it into a full game. Although I need to fix the character movement slightly, I think I’m happy that the movement and AI is ready otherwise. I think there are a few things still to do before I can say the first iteration is complete:

  • Undo and restart functionality
  • Implement failure and success – the player should not be allowed to make further moves after collision with an enemy. Only undo should be available. Similarly, the game should detect when a puzzle is complete and move to the next puzzle.
  • Collectibles and unlocking – I want there to be some kind of collectible in the levels that the player must collect in order to finish the level or unlock more levels.
  • Design some puzzles – design 10-20 puzzles using only the basic mechanics implemented so far.
  • Implement puzzles – drag and drop assets into Unity to implement the puzzles.
  • Simple UI – both HUD elements and menu.

I think focusing on the puzzle design in the next week would be a good place to start as the puzzle design may make me realise I want to implement some of the mechanics slightly differently to make things more interesting.