Bradley Jones - Crate Corruption

Crate corruption is a homage to the Crash Bandicoot series. It takes the crate breaking puzzle platforming of Crash and adds a few twists and interesting mechanics. You are tasked with simply reaching the end of the level but there are multiple ways to perform well in each level.

Crate corruption was a solo developed game made for an assignment in my second year of university. Everything in game (barring some free to use music) is made completely by myself, including the engine! I decided that I'd like to push myself out of my comfort zone for the sake of this assignment and wrote the game entirely in Java. I really enjoyed the process and felt that it taught me so much about what I was actually doing when using engines like Unity. I had about a month of consistent development time and I'm quite proud of the end result as the framework I had set up left the project really open and easy to expand upon.

While building my game, I started using a tool called Tiled to handle level design. At first, I was just hardcoding object positions—placing the player at (0,0), looping over blocks to spawn them manually, that sort of thing. It worked, but I knew it wasn’t sustainable. Tiled output a big XML file, but I honed in on the tile data and wrote a basic Level Loader that checked tile IDs and spawned prefabs based on hardcoded values. That quickly got messy, especially when editing the tile set changed the IDs. Eventually, I learned I could add custom properties to each tile and give them names tied to prefabs. From there, I built a system that reads the tile set, maps IDs to prefab names, and spawns everything based on that. I also used Tiled’s object layers to place unique NPCs with custom dialogue and freeform positioning. The final thing I got working was autotiling, which let me quickly build more natural-looking terrain instead of relying on indestructible crates as filler. Over time, I ended up using more and more of what Tiled had to offer, and it became a core part of my level-building pipeline.

One of the systems I set up that I was quite happy with was my asset loading class. Before the first prototype submission of my assignment I decided I wanted to use a bunch of the crate textures I had made to make a rudementary background behind my level with a bit of parallax scrolling. It was as easy as inserting a bunch of randomised sprites with no colliders in the background but when it came to loading the game, there was a noticable delay in the game starting up. I realized this was because each sprite was searching for it's image inside the files. To get around this, I centralized the logic for loading assets such as images, audio clips, and json data into one class called AssetLoader. I made it cache each image it loaded so that if another object was requesting to load that file, it could just return the data from the cache rather than reading the file again. This allowed me to have a tiled background texture that I could edit very easily during development rather than having to create an image that could be loaded as the background. Pictured is an example of the function I would call when trying to access an image. It could also request and cache sliced sections of images to allow me to introduce sprite sheets to the game. I also made one class that contained all the file paths for images, prefabs, audio clips etc. so that I didn't have to mix string file paths into my code base and go hunting for them when I moved files around my project folder or made a typo.