Another year, another Brackey’s Game Jam. For anyone unfamiliar with it, you’ve got a week to make any type of game, from any game engine. The only limitation was that the game had to not contain any NSFW (“Not Safe for Work”) and offensive/discriminatory content. The game also had to incorporate a particular theme voted by the Itch.io community. This jam’s theme was “An End is a New Beginning”.

Before the jam had officially begun, I had written done some ideas for each just in case my desired theme didn’t come up. Fortunately for me, “An End is a New Beginning” was one that I had been coming up with plenty of ideas for.

To me, the theme seemed kind of cyclic. My idea was to make an endless runner, a game that continues forever and usually ends when the player runs into an obstacle of some kind. To keep the player engaged, they would accumulate a score based on the amount of time they stayed alive for. Their score would grow until they ran into any of the obstacles placed around the level. The scenery was also randomly generated and would change as the player continued to move through the level. Upon death, the player would begin at the end screen but when they went to try another game, they would see that they were in fact playing their previous run, as though this would continue forever.

If anyone has had a chance to play “I Forgot the Bus Again”, they would find that while it may have looked like the player was moving around a spherical object, it was in fact the environment that moved underneath the main character’s feet.

The player was limited to left and right movements, as well as vertical movements when they jumped. This created the illusion of movement when there was none.

Like any game jam, there were plenty of problems to solve, some were related to the game, others were personal matters that came up during development.

Early in the project, I had decided that I would use assets that I had recently purchased to save time. One of the assets, Quibli, an anime-style renderer for Unity, was the asset I was using to achieve a particular style for my game. I believed that the renderer didn’t have any way of creating materials with pre-made textures, so I ended up discarding my old level design because I didn’t think I would be able to make a material for the ground and props that properly fitted my rather atrocious UVs. It turns out there was a way, and I just didn’t look hard enough into Quibli. My level ended up being made of objects from the Quibli asset pack, which came with many problems. Firstly, to make a new road, I had to connect many prefabs together, end-to-end, which made for a very long list of Game Objects. In the end, there were seventy-two (72) road segments prefabs all within one giant prefab.

This turned the level into something very blocky and was noticed by at least one person who commented on the project. It also added to the number of draw calls which exacerbated the problems I had with framerate on the WebGL build of the game. I’ve come to realise that Quibli is better suited for creating stylized environments with the occasional moving part. With its largely modular prefabs, Quibli can be extremely heavy on draw calls, something that troublesome when working with limited resources on a WebGL build of the game.

As well as dealing with a looming deadline, I also had to deal with a theft at work, more specifically, the theft of my phone. Long story short, I never got the phone back but thankfully, after one long night of resetting passwords, I was ready to get back into game development. It turns out that the stolen phone was not too much of a setback because I was able to finish my game with a few hours to spare.

Even though the game jam was now officially over, and the voting period had now begun, I still had some challenges to get through. From comments people had left on my submission, I knew there were improvements that I could make. I collated all the feedback and got to work on version two of the game.

 This time around, I wasn’t too concerned about the gameplay mechanics since it didn’t get brought up and what I wanted to focus on were the issues that people were able to notice the most. Because of the “blockiness” that one commenter noticed about the level design, I opted to switching back to the original design for my road environment, removing some unnecessary geometry and reimplementing the old method of scattering spawn points using Blender’s Geometry nodes system and Instancing of objects.

I found that the method of scattering empties in Blender and exporting to Unity was very easy, but it did have its own set of problems. The rotation of each empty object had to be correct on export, otherwise the rotation would be incorrect in Unity. Setting up an axis for each spawn point helped show the current angle without needing to look at rotation values. It also made me realise that when I had mirrored the objects on one side, that is when the problem occurred.

Another commenter said that the main character was too simple looking considering the style of the rest of the game. With the help of Mixamo, a website with some great animations and characters, I was able to create a good-looking character that fit the style better. I did have some issues working with bones and Unity’s Avatar system having conflicts with the names of other bones, but this issue was easy to overcome by simply ignoring the problem and using a different method that got similar results.

One issue that couldn’t be ignored, was the issues I was having with collisions. It turns out that fast-moving objects had a hard time colliding with each other in Unity. I could have spent too much time coming up with a system that could have kept track of positions between frames and determine collisions that way, or I could have just increased the size of each obstacles collider until the physics system had enough space to detect a collision. The obvious answer was to do the easier one.

Speaking of easy problems to solve, this next problem was so easy, I was confused as to why I hadn’t implemented it sooner.

Plenty of commenters had suggested that I make the intro cutscene skippable. From numerous playtests, I had never considered making the cutscene skippable, even though I remember getting quite annoyed at all the times I had to wait watching a cutscene to then be able to test out a new feature. This quality-of-life improvement didn’t pose any significant issues. Saving and loading, on the other hand, wasn’t so forgiving.

While working on this feature, I hadn’t realised that the “Resources” folder in Unity was load-only. Numerous tests in the editor showed that files could be saved there, it wasn’t until I built the games that I realised that the folder became unusable for saving after everything had been complied. Some quick Googling led me to a Stack Overflow page that suggested using the “Application.persistentDataPata” for saving information. I must thank the Stack Overflow user, “TEEBQNE” for the simple saving and loading script that they had posted in that thread, it was extremely useful. Thank you.

Game Jams are not easy. Even when everything is going to plan, something comes in to disrupt it, pulling attention away from what is needed to be done. It’s whether those disruptions detract the project beyond recovery or become a minor annoyance is what will determine a project's success or fail. As someone who knows what those distractions look like, I know it can be hard to get back into a project after being distracted for so long. Try to push through the disruptions and continue creating and I know something will come of it.

Have fun.

James