Post mortem

This week I participated in the BlackThornProd Game jam with my brother Jack Algera. This game jam gave us 1 week to create a game from scratch based on a given theme. The theme this week was “Game development”. The game was made using Unity and visuals were made using Photoshop.

I will be talking about the game, what we did for the different systems, how we implemented them and some problems we encountered. Then I will talk about what I will be trying to do better in the future. What I need to change and what I learned through this experience.

The beginning:

We started the game jam with a long brainstorming session to get the creative juices flowing and get some ideas to work with. We separated the game development theme into 4 different themes, Story, programming, art and sound talking about each to try and find ideas. We created a mind map and noted all the ideas we found. One of the ideas that we liked was creating spells with code. We would have an interface to code the spells that we used by telling it what the spells would look like and their damage, type and size. The game would then be played in a top-down view. We also wanted to create a character creation part to teach the player how to use the programming to create spells, but we never got around to doing it.

The story:

The short story that we came up with was that you, a Squaron mage knight, have been tasked to kill Trianglons who have been menacing the land. The king frames the Trianglons as being really evil and they have to be killed as soon as possible! Wiped out! As you progress through the game, you realise that the Trianglons aren’t that evil. They are a peaceful race having lived in this region for centuries. The Trianglons try and figure out why you have decided to attack them, but you wipe them out before they can understand anything. In the smouldering ruins of the village, you find a book describing the real history of the people and you realise that it was not them that were evil but the Squaron King! You wiped out a peaceful race of people because your king did not like them. History is written by the strongest...

Now that we had our idea, it was time to start coding the game. We started by separating the work between us. I started work on the spell interpreter and Jack started working on the player and some visuals. I will mostly talk about the parts that I did but will include some stuff that Jack worked on as well.

Working on spells:

Firstly, what is the spell interpreter? The goal of the interpreter was very simple. Take the code that the player wrote and convert it into a spell in-game. My first idea was to convert the spell directly into a spell GameObject and save that somewhere but that didn’t seem possible, so I moved on to another system. I decided to convert my spell first to JSON and then create an object that will read that JSON file and generate the spell. Because the spells are quite small, it didn’t take long at all so at the level start a spell could be loaded. The interpreter worked by cutting up the code from the user and looking at what was written and converting it to steps in a spell

A spell consisted of 2 things, spell shapes and spells phases. Spell shapes are what defines the shape, position, duration, damage, etc of the spell. A spell phase is what defines the spell in time. A spell is launched in multiple phases with each phase lasting a certain time before the next. It is akin to launching multiple spells one after another.

The spell class is made up of up top having the spell class, which had the mana cost of the spell, the written code of the spell that the player wrote to create it and a list of phases. For each phase, we have the time to wait till the next phase and a list of shapes for that phase. Each shape has, like I said earlier, mana cost, position, duration, etc. The spell class is converted to and from JSON using Unity’s built-in JSON converter and JSON files stored in the resources file. What I did not know and only realised at the end when we tested the game was that the resource files aren’t created on export and so when we tried to save the JSON files, it didn’t work and we couldn’t use spells. This is one of the 2 things that made the game unplayable when we pushed it online.

When I want to cast a spell in-game, each step of the class creation creates the parts coming under it. By separating the spells like this, it was relatively easy to implement. I instantiate the Spell generator and launched the spell generation. It would then create the phases which would, in turn, create the shapes.

While the player codes the spell, he can preview his spells on the screen. He also has a console showing him any errors in his code. Finally, he can save his spells to the 2 different spell slots that he has.

I continued working on this feature during the whole jam making sure the feature continued working as the code base continued to change.

The rest of the game:

We didn’t include a main menu but rather decided to go with a hub world that the player is directly thrown into. From this place, the player can go to the level selector and spell creation station.

To make the player see that they can interact with certain parts of the screen, we used 2 techniques. The first technique was to create a beam of light that points on the interactable objects. This makes it stand out from the background and signals to the player that this object might be useful. The second thing we did was adding effects to the different objects. The map lights up, the computer turns on and the door opens to leave the game. This makes the area feel real and interactive and not just like a piece of art that we are looking at.

The map selector was quite simple, we used a simple system where we had the player walk on a map and trigger markers that can be activated to start a level. The level markers animate when the player walks over it to make it, like the main screen, seem more interactive. The player must realise that something had to happen when he interacts with the marker.

The gameplay is quite simple as well. The player is spawned in the middle of the level with some enemies spawned around it. The player can walk around with the WASD keys and use his spells with H and J. The levels are made with prefabs of trees, rocks and grasses. For spellcasting, we made a system where when the user presses a direction button, a GameObject would be rotated so to be facing the right direction. We then connected this to a visible target reticle so that the player knows where it was aiming. When we spawned the spells, we could rotate the spell generator which gave us a semblance of aiming.

The AI side of things:

Enemies were meant to be simple, I don’t know what I did for them to become so complicated. The enemies have 3 states. Idle, the enemies walk around randomly. WalkTo, the enemies walk to a certain target and Attack, the enemies attack the player. I created the state machine using the animator for the enemies and adding behaviours to the states. I found it very helpful to be able to control things in this way, but I found it limiting as well. We can’t use Gizmos to debug, coroutines aren’t usable either. I need to work a bit more with the system to really get a hang for it but I should try and combine the animator with MonoBehaviours on the Object. This might give me more freedom and make organising the code easier. I need to try.

The Good, the Bad and the Okay

Now that you know how the game works, I will be talking about different things that we could have done better, what I learned and what I will keep doing in future game jams and game development in the future.

For the moment, I have participated in only 2 Game Jams. I will be doing many more in the future as they are an amazing experience to learn new techniques, try new ideas and just make a game! This experience, as always, has been very interesting.

The first thing I want to talk about is Git and Unity. It was a pain to work with the 2 in the beginning. If you aren’t careful when creating your metafiles, you could have problems during the whole development cycle. We struggled for a long time with prefabs going missing and sprites going missing. We sorted it out later by just pushing everything, deleting our local repos and recloning everything. We didn’t have any problems after that. We will have to be careful next time.

Another thing that we struggled with was merge conflicts on Unity .scene files and .meta files. They aren’t very easy to understand so when you must merge a conflict, it takes a while to figure out what had changed. A workaround is to be sure to never work on the same scene but it is inevitable that it will happen sometimes. Communication is vital when trying to fix these kinds of errors because it can be must easier to find the conflict if we know what had changed exactly.

Something I am really happy about is the brainstorming we did in the beginning. It was very thorough, and we got most of the ideas down straight from the start. We threw around a lot of ideas to get where we were, so we were sure that we at least had the most interesting idea that we could think of. It is very important to write down everything that we think of to really try and get as many ideas as possible. It is also very important to clearly define everything we need to work on for the game to be finished.

In the same line of thought, prototype! Prototype a lot! Export the game and test it. Have working prototypes of the game as soon as possible. We only exported our game for the first time just before uploading and we had a problem with our game. We worked more on the different mechanics than on the actual game and so by the end, we only had some mechanics and no real video game.

When working with a hard deadline like a game jam, try and get your game to a releasable state a day before the deadline. This is very hard to do but not having to rush your game like we had to do before the deadline is just great. This will allow you to test your game before putting it online and make sure that it works. You won’t be as stressed, won’t have to rush anything and if there is a bandwidth problem with the servers where you are uploading, you will have the time to get your game online.

Something that I found useful was having organised work from the start. I made sure to have the folders that I would need when we started the process, organising everything while we were working. Making my code organised and working with design patterns is great too because adding things later becomes easier.

Lastly, I want to talk about something very important, Scope! When you are designing your game, you must be aware of the scope of your game. What I mean by that is how much you want to do with your game. This is even truer when you are doing a 48h jam where you can’t go too big. We made a game that was way too ambitious for the time that we could sink into it. Aim for something smaller in the beginning and add more later if you have the time. You can always add something but take something away is really hard.

I hope you enjoyed the post-mortem of “Attack on the Squarons” as much as I enjoyed writing it. If you have any questions, I would love to discuss it with you. I will add a link to the game after we fixed the game breaking bugs.