Project retrospective

After I starting work on Slingshot Wizard in March of 2021, it's finally complete! Development went on hold around April as I was starting a new internship which took my focus away from most personal projects for its duration, with it concluding at the end of October. Now I've had time to start looking at my own projects and this seemed like a perfect candidate to wrap up and put out into the world.

While I'm happy with the result, I definitely would have done things differently if I were to do this project again. Not to absolve myself of responsibility but a big part of that is thanks to my internship, where I learned a lot of good Unity practices (as well as un-learned some of my self-taught ones).

Code

For whatever reason I had the idea using Unity's built-in tools like dragging/dropping references in the inspector wasn't the "proper" way to do things, and it was somehow better to be getting all my components in the awake method. Obviously, this is way harder to keep track of AND worse on performance, so once I came back to the project I started looking for things like this to fix.

Furthermore, I used to have a habit of using GameObject.Find() whenever I needed to get a reference to an object in the scene (related to my irrational fear of the inspector), so I also started looking for ways to avoid doing string lookups, both for keeping track of code and also for performance. The solution to this would either be an inspector field or in some cases making use of the singleton pattern.

I created a few singletons for things that want to be kept track of during regular gameplay (i.e. the music player, pause menu and in-game timer), though I think any more would have been too much. It may have been possible to avoid the singleton pattern altogether, possibly by having these components exist on the player object.

The main reason I avoided doing this is it would involve going through a 6-month-old code base from before I started coding to a standard, and also before I understood the importance of making code readable (instead of trying to jam as much as possible into a single line because it looks complicated, therefore cooler and more code-ier). In this case, singletons were a simple and fast way to implement these new features without having to interact too much with the existing codebase. 

In subsequent projects, I've tried to restrict singleton usage to things that are truly global, like game manager scripts. The singleton pattern is useful but I don't want to become dependent on it, I've heard the cautionary tales of it causing unnecessary amounts of dependency and generally getting out of control, with a ton of global static classes floating around.

Sprites/Graphics

For a while, I insisted on using strict pixel-art for my graphics. It seemed like a very simple art style that would shorten the time needed to create sprites. However, this wasn't exactly the case.

My overall sprite size was 8 pixels to a unit. In hindsight I think maybe something like 8 pixels to 2-4 units would have been better, primarily for the tilesets.

The sprites themselves look ok, however when they're applied to a repeating tileset they can be a bit hard to look at, especially when moving at high speed. I think it's ok since the sprite colours are dark or have low contrast, but they would benefit from an overhaul. It might be making the tiles bigger, using fewer pixels per tile, or forgoing the tileset entirely for a set of prefab building blocks to create levels. These would then use simple hand-drawn sprites without a rigid pixel art style (like the menu buttons I ended up using). I found creating assets in this style is a HUGE time saver, and will likely be using it for these smaller 2D projects in the future if I need to start prototyping graphics (and am ok with a colourful/cartoony art style).

Overall I think the pixel-art style was more restrictive than helpful, and while I do want to try it again in the future, I'll be more skeptical of it on a project-to-project basis.

Gameplay

My initial idea for the game involved a lot of high-speed movement and even more mechanics. I was hoping to implement stuff like wall jumping and for sliding to be more prominent of a movement technique. While that stuff would be fun and could probably be implemented, I think the final game shows those ideas are harder to add in a 2D game.

Moving too fast without the context of what's further in front of you leads to complications. There were draft levels where the player had to do a lot of manoeuvres in quick succession. While I as the developer knew the level layout I had designed and could complete them fairly consistently, I decided to cut them. It seemed very easy for levels like that to get frustrating and the limitations of 2D just don't lend themselves particularly well to that type of level design. Back when I realised this it made me want to branch out into 3D more to see what kinds of new mechanics would be possible with an added dimension.

I like to think the final product is quite user-friendly, but it wouldn't shock me for players to find certain levels excessively difficult or frustrating.

One thing that took me a bit by surprise was level design. It was fun to draft out and create new levels. I made new levels by sketching out a path I wanted the player to follow and constructing a level that allowed them to follow that path as close as possible. Some weren't possible as they involved diagonal movement, which meant players had to make incredibly precise launches with a high chance of getting stuck on a corner and losing all their speed, which got tedious very fast.

Conclusion

Overall I'm happy with the final product. If I was to make this game again I would definitely try and tone down the speed to allow more compact, detailed levels. While the speeds in this version can be fun, it might be offputting to some players and is restrictive in what other mechanics can reasonable be implemented. For example, there are only a few instances in the game where you even have to walk for more than a few steps outside the tutorial level. Having slower-paced levels could lead to more puzzle-like elements and therefore more varied gameplay.

Finally, I think this game gave me a lot of useful experience with pixel art and the tileset package. I'll likely steer clear of them for now until I have better pixel art knowledge and a game that really benefits from the fast prototyping of a tileset.