Big Game Project – Week 2

Yesterday I felt like I had stayed up completely too long and screwed over my sleep schedule again, it was 9 pm. This week has been so crazy that when it’s finally weekend I have too much time.

We had a deadline this week to have our first playable prototype ready by Friday. This ended up with us working until 2 AM the day before, but we got a lot of stuff done.

Teodor was sitting with most of the week with animations with Unity’s animator. This proved to be more inconvenient to use for our goals than we had imagined. We had originally intended to use it to slide all the different matching pieces with animations when the player matched them, but it ended up close to impossible to make in a good way. This added to our decision to actually scrap what we had made of the matching code, and re-do it. The majority of the reason was that it was badly optimized and would probably have to be re-done somewhat once we try to port it to tablet.

My work this week was a lot of small adjustments and optimizations to make things more dynamic. Especially the enemy spawner, which needed to be very dynamic since it’s different every wave and every level.

The biggest part of the work this week, though, was the waypoints and pathfinding for the enemies. I got the task of making the multiple paths work with the AI of the enemies, and to make a tower that you can place on the road that blocks one of the paths. This was very interesting and fun to make, although frustrating at times. I sat with this for 17 hours on the Thursday since we decided that day that we wanted it to be included in the prototype the next day.

First I thought it would be too much of a task for one day, but then I decided to give it my all and get it done no matter what. We already had waypoints on the map, at every intersection and turn of the road.

The yellow dots on the map are the waypoints, and they are added to a list that the enemies access and move towards to in the list’s order. When they’re within a certain distance of the waypoint (basically there) they move to the next position in the list. This worked well before we had multiple paths, but when we added that we couldn’t simply add 1 to their counter when they reach one. This is because they would then move across the matching field once they reached waypoint 2.

The solution I made for this was that each waypoint was a class that held on a variable saying how much of an increase in the list the next waypoint on the path was. For example waypoint 2 needed to tell the enemies to increase their count by 2 if they wanted to continue that path. This also proved a problem, since one of the waypoints had multiple paths. So I made each waypoint hold a list of integers. The size of the list would indicate how many paths the enemies could choose from, and the elements of the list would be the increase for the enemies to walk to the correct waypoint. I also later made the same but backwards, in case a path was blocked and the enemies needed to backtrack and take another path.

public class Waypoint
 {
     public GameObject wp;
     public Transform wpTransform;
     public List paths;
     public List backtrack;
     public List blockedFrom;
 }

When the player places a block the WaypointManager makes linecasts between each waypoint and it’s paths with a double loop and checks where the player placed the block. Once it finds the waypoints, it adds the previous first waypoint’s position in the list to the second’s blockedFrom list. It then also loops backwards through the waypoint list and adds block to every waypoint until it finds a branching path. Each time the enemies arrive at a waypoint they check whether or not the one they arrived at is blocked at the one they’re choosing. If it is, they remove that path from their options and randomize between their other ones (assuming there are more than two options).

A problem arrived when I noticed the enemies needed to be able to check whether or not the player placed a block between them and the next waypoint, or the one behind them. Otherwise there would be the possibility of the enemies walking straight through the block if they immediately turned back towards another path, even if they had already passed the position where the player placed the block. I thought a lot about solutions to this but didn’t find one that wouldn’t possibly impact the performance.

What I did was to add a check to every enemy moving towards a waypoint that had blocked their previous one. When the player places a block the enemies meeting that condition makes a linecast to their next waypoint and checks whether or not there’s a block between them. If there isn’t, they know it’s safe to at least move to the next one, where they will check if the next one is available anyway.

It was really fun to work with the pathfinding, even though I wasn’t too sure how it would work out in the start. I’m looking forward to next week a lot, since almost all of the basics are down now. We have an internal alpha deadline on Wednesday where we have planned to include the menus and world map as well.

Until next time!