For this project we decided that we would make the game using Unity and C#. We did this for a few reasons: 1. we were making a 2D platformer which Unity is a good game engine for, 2. the other person working on the programming for this project preferred Unity and 3. this gave me a good opportunity to learn Unity and C# which is something I wanted to do.

The first issue we had during the project was with version control. I was the only one working on the programming side of things that had worked with version control so I decided to set up the Git repository which I did using Microsoft’s Azure Devops as it gives you unlimited private git repositories and I have used it every time I have worked with Git. I then advised people to use GitHub Desktop to handle interacting with Git as it is easy to use and very widely used. I also decided to use it rather than using what I usually use, which is Git Bash a command line based interface, so that if anyone had any problems I could better help. The problem came when I let someone else create the Unity project and handle creating the initial commit.
For some reason the way that Unity handles its folders didn’t work with the provided Git ignore file so when the other person went to create an initial commit it was trying to commit the entire project and not correctly ignoring files. I managed to determine what was happening by messing around with another Unity project and Git repo. What need to be done was that the Git files needed to be moved down a folder into the Unity project files. I attempted to relay this information to the person who held the actual Unity project but they didn’t quite understand my instructions so unfortunately I had to wait until the following Monday for them to bring their laptop into lesson so I could fix the files myself. This meant for the first week I was unable to work directly on the Unity project itself.
Further problems came when I finally got hold of the Unity project after I had fixed its problems with Git. Somehow Unity had activated its own version control on the project which added a load of extra files that weren’t needed and made it impossible for me to work on the project on my own computer. To fix this I had to go into the files and manual remove Unity’s version control to get it to start working. I then final made the stable initial commit about a week and a half into the project.
In hindsight I should have created a blank Unity project and uploaded the initial commit so we at least had a stable base for the start of the Git repo. I didn’t do this then as I wasn’t going to be creating the character movement which I needed to be completed first before I could properly get started.

For managing the AI’s behaviour I found a Unity package called Behaviour which added visual behaviour trees similar to the ones in Unreal Engine which I had worked with before. This made it easier for me to layout how I wanted the AI to work and debug it when errors occurred. The first time I created the behaviour tree for the slime enemies in the game it was really cluttered and included way too many scripts which made it a mess to manage and work with. This was because for every action the AI could do I had two scripts, one in the behaviour tree that would then call another script that was attached to the AI itself. I decided to scrap everything and start again to streamline the code and optimise it. This second behaviour tree only had scripts held within the behaviour tree which greatly reduced the number of scripts I was having to work with. The problem I had with this version of the behaviour tree was that the script that was managing the sight would wait for the movement part of the behaviour tree to finish before it would run again which I didn’t want. What I wanted was for the sight script to be running constantly uninterrupted to that if the slime were to gain or lose sight of the player it would then interrupt the movement script and change its course. I had to reorganise the behaviour tree again so instead of having a repeat block going into a run in parallel block which then branched into the movement and sight I had a run parallel block which branched into the movement and sight which both started with their own repeat block. This stopped the sight from waiting for the movement to be finished and achieved the behaviour I wanted from the AI.

The first part of the slimes behaviour I wanted to get working was movement. I wanted the slime to jump similar to the slimes in Terraria. I found some code online which would allow you to input an initial angle and a destination and it would calculate the force required to launch an object to that location. I decided to look up code for this after spending a considerable amount of time trying to figure out an equation myself that would allow me to do this. The code worked perfectly after some modification that I did to get it working in a 2D space rather than a 3D space. The next thing I need to figure out was how I wanted to limit the jump so that slime couldn’t just get anywhere in one jump. I did this by limiting the force of the jump so the slime had a maximum strength rather than artificial adding a distance limit which didn’t work exactly how I wanted it to. The final thing I added was ground check and cooldown. So that the slime didn’t just jump into space I had the slime check for when it had landed on ground and then wait a time before it would jump again.

Once the slimes were able to jump I gave them a very basic sight script. Due to time constraints I didn’t want to spend the time coding a sight script that worked with raycasting to check if the AI had a unobstructed view of the player. Instead I would spawn in a 2D collider and check if it had hit the player. This gave the AI a basic sight script just based of if the player was in range. If the player was in range it would update the target location and start chasing the player.

Once I had got sight and jumping working I wanted to have the slimes patrol while they couldn’t see the player. This wasn’t too difficult, I added some empty game objects as patrol points to the scene, gave the AIs an array which would store the patrol points then wrote a script which would loop through those points and tell the AI to go to the next point in the patrol path once it had reached its destination. This worked successfully and now my slimes were able to patrol while not able to see the player and then start chasing the player once they could see them. The next thing I need to add was the ability for the slimes to be able to do something to the player.

Once again due to time constraints I didn’t want to spend the time to added a health system so that the slimes could attack the player and kill them. Instead I made it so that the slimes would bounce the player away from them if the player collided with them. This gave the slimes some ability to effect the player and the game so they weren’t just there to look pretty. One problem with this though was that the players had quite good control over their character in the air so you could use the bounce to your advantage but it still was annoying enough that it achieved what I wanted it to.

The final bug that I came across which I didn’t get to fix was the slimes being able to teleport. While in engine the slimes never teleported and I had spent a couple hours just watching and playing around with the slimes to make sure they were working correctly and they never teleported. But once I exported the game they gained the ability to teleport. They always seemed to teleport to origin so my guess is if they got an error from trying to jump they would just teleport to origin but I’m not sure. I only discovered this problem once I had set up the game ready to show everyone at the expo at the end of the game jam.

Even though the game wasn’t more than a tech demo which had teleporting slimes people enjoyed playing the game. People would keep playing the small demo level I had made to try and get to the end of it even though it was difficult and frustrating. (Video of people playing at the top of the page)

If I were to do this project again I would handle the initial commit of a clean Unity project myself rather than letting someone else manage it. That would have saved a lot of time at the beginning of this project and allowed me more time to work on the programming I needed to handle in the game. Something else I would do would be to create an export earlier and test it. This would have allowed me to discover the teleporting slimes earlier and allowed me to try and fixed it before showing off the game. I am happy with what I managed to create as the slimes worked very well in engine and this project allowed me to get more familiar with an engine and language I haven’t worked with a lot. For my next project I would be interested in working more with Unity and looking at other aspect of Unity other than just the AI.