Build Environment

This was a very unique project as we were given 1 month and tasked with not only creating a game in Swift for iOS, but then to port and refactor our game to a different engine of our choice (we chose Unity with C#).

This was our first time using Swift so it was very interesting to learn a language with the pretense of being able to mentally make that knowledge backwards-compatible with what we already knew about Unity and how we might implement these same systems there.

How It Went

Dev

As Gavin is more interested in the architecture side of things, he handled building the core systems that would interact with each other within the engine to orchestrate our limited scope of features. I was tasked with finalizing each of these systems, as well as informing him from a user-perspective how these features needed to function and how to bring that experience to the player.

Combat was fairly static and boring, but we did implement all the necessary inputs and hitboxes to make it play as expected. If we had time I had plans for a rogue-lite system for randomizing floors and unlocking powerups and new weapons. Together we built a very dynamic collision system for dealing with the tile-based levels with multiple layers like environment, walls, dynamic collisions (doors, interactables), and decoration. This allowed for quick and easy prototyping of levels with unique layouts and interesting silhouettes.

While Gavin handled things like the state machine for the player and enemies, I built the input and animation systems, and hooked them all up to their respective parts of his framework including debugging and optimizing. I also handled all UI interactions/animations, scene changes, and menus.

If I have learned anything from all the projects I did over my 2 year course, it is that I really want to practice making things more modular and reusable. Because we were always changing languages and game engines, we never built anything sustainably, and it can be a daunting task always starting games from scratch and having to consider every single small system in your timeline. Being able to compartmentalize things like player input, combo systems, ui systems, etc could save a lot of time and headache when making new prototypes and just wanting to slap together some basic systems to test a hypothesis.

Design

The goal with this project was to focus on an aesthetic and game feel as a complete package so that we had a baseline to compare after the porting/refactoring exercise. I really enjoyed the process of finding a tileset, deciding how we can use it, and letting it inspire some game mechanics along the way (oftentimes pointing out things that are missing from it as well). What I found interesting was the process of finding a sprite sheet for the player character. I went through dozens thinking none of them would fit the style of the tile set I just found.

In the end I just imported all the 16 characters that I gathered and realized that almost half of them fit just fine and only needed small palette changes to really mesh with the art style. In the end the one I chose didn’t need a palette change but that was just coincidence that it had the best animations for our plans.

The main character and base tile sheet were purchased from itch.io and trimmed and optimized for our purposes. I also added about 10% custom tiles to the set using the original as reference, to suit our specific gameplay goals.

A free UI pack from itch.io was used as the baseline inspiration for the UI but ultimately many of the icons are hand-made and the colour palette is completely custom to bring it in line with our other two texture atlases. I also designed the layout and functionality of this UI keeping in mind that the project required the game to be designed for the mobile experience.