What went well?
Diving back into Unreal was a very fun experience for me. I had not spent much time developing in Unreal Engine recently, so it was good to jump back in and relearn the basics in a fun way.
One of the most valuable things I learned during this project was how to use GameInstances and GameInstanceSubsystems effectively. Before this project, I had mainly focused on gameplay code that existed within a single level. Learning how Unreal provides persistent systems that survive level changes helped me better understand how larger projects are structured. I particularly enjoyed using these systems to manage UI, game states, and level transitions, as it made the game's architecture cleaner and easier to maintain. It was rewarding to see how central these classes are to creating a seamless player experience across the entire game.
What could have been done better?
I rushed right in with minimal planning, determined to really make a start on functionality. However, this led to several ad-hoc architectural decisions that had to be revised as the project progressed. An example was when creating objects involving player collision. In hindsight, I could have created a parent class for the Endpoint, Obstacle, Collectable, and FallBoundary classes as they ultimately do fire off differing events when overlapping with the player.
Additionally, the approach I took was one that didn't really leave a lot of room for thinking about the UX side of things. This was something that was impressed upon me by a teacher I had reconnected with from my days of studying Computing at college, where he suggested what I like to call "the UI first approach": Which was good to adopt and it helped make things easier from a dev standpoint. But it was an approach I picked up only a few days into the game jam, whereas I would have benefitted more structurally if I adopted this approach right from the start.
Because I focused heavily on implementation, I spent very little time considering the player's experience. Questions such as "How should players navigate the game?", "What information is important to them during gameplay?", and "Why would they want to keep playing?" were largely unanswered during development. While this was acceptable for a prototype, it exposed several weaknesses in my overall approach to game design.
What lessons am I taking from this?
Devtober was truly a rewarding experience. It was fun to develop a game over the course of a month and learn about what worked vs what didn't. And if I were to take any lessons away from this experience, it would be as follows.
1. Consider UX/UI: Code, UI, and features are all important, but they are only parts of the whole. The players are what bring a game to life. When I start my next project and I know what kind of game I want to make, I will be thinking heavily about how I expect/want the players to be able to navigate this game, and how best to really capitalise on that to make my next project one that a player can pick up and play very easily.
2. Take a more abstract view about coding: I still love coding and developing these awesome gameplay mechanics. But, in my next big project, I will be starting by taking a step back from the code and planning out what approach I want to take (i.e. what design patterns, what OOP approach I want to take for objects that all execute different functionality from the same source like with the collidable objects, etc). This will serve to bolster my architectural understanding of the game and further make it more robust.