Here’s a breakdown of my year in game dev, the challenges I faced, and the key takeaways that’ll shape my 2025 projects.
TL;DR
In 2024, I didn’t finish any games, but I learned a lot about game development. I tackled three projects: a multiplayer turn-based RPG (Kinship), a puzzle simulation game (ClarityCorp), and a co-op side-scroller shooter (no name yet). The biggest challenges included managing scope, learning multiplayer mechanics, and handling art requirements.
Key lessons: start small, focus on a solid game loop, and polish later. Despite not finishing a game, I made great strides in development and am ready to continue working in 2025.
2024 didn’t go as planned. Despite the title suggesting I “failed,” I actually learned a tremendous amount about game development last year. Looking back, I see a lot of unfinished projects, but with each one, I gained valuable lessons.
Game one - Isometric Turn-Based Multiplayer RPG (Kinship)
At the start of the year, my focus was on multiplayer—specifically, “how the hell do you make a multiplayer game?”
After diving into articles (shout out Glenn Fielder ) and studying the multiplayer quirks, I settled on a turn-based combat RPG. Games like Baldurs Gate 3 and the Divinity series are absolute classics that I would find huge inspiration from.
Kinship was designed as a 4-player, online co-op RPG. Players could choose from the classic classes—Fighter, Mage, Rogue, or Cleric—and battle through an isometric world. The combat system was simple, with basic attacks and spells, and the enemies (mostly slimes, for now) moved and attacked in turns.
Below is a screenshot of the in game combat, art is placeholder, and not final.
That’s pretty much it. Despite the lack of content, this took me many months to achieve. So, where did I go wrong?
Overambitious Scope
The classic advice is to start small, and I definitely ignored that here. Multiplayer games are complex, and Kinship needed a lot of content—multiple playable classes, levels, and assets. The sheer scope started to overwhelm me, and I found myself stuck in a cycle of not knowing where to begin.
Isometric Art
Isometric is hard. Well, not really, there are some key concepts that make it easier, but in general it means you need at least 4 versions of each asset, for each direction in the game. This means not only are you making one walk cycle, you are making 4, for each playable character, each enemy and certain moveable objects. Now your characters need to attack, thats 4 attack animations. They also have many attacks… You get the point. It’s a lot of art.
If you are anything like me (a programmer), making art is the most painful part of game development. So having to make 4 versions of everything in a perspective which is very easy to spot mistakes, I could not achieve this feat alone.
Perhaps I should have linked up with an actual artist, but without being able to pay them a fair salary, this was not an option I could pursue.
Playable classes
For this style of game to be fun and re-playable, it needed at least 4 classes, one for each player. This really multiplies out how much work you need to do to finish the game. Not only does each class need its own assets, it also needs its own behaviors, attacks, skill trees and balancing, all things required to make a really good game. Resulting in another key point that de-motivated me and stopped me making progress.
I definitely took on too much too soon, and should have focussed on nailing one class from top to bottom and ironed out all the kinks along the way.
The advice of “start small” really started to ring true here!
Learning new concepts takes time
The elephant in the room is “multiplayer”. At the start of the year I had never made a multiplayer game, I do however have extensive experience in networking having been a Backend Software engineer for over 9 years, a degree in Computer Science and founding a networking based tech company.
Lot’s of people give advice against solo-dev’s targeting multiplayer games. Whilst I do believe that advice is valid, I also believed that multiplayer is a key concept of some of the best games I play and is a way to stand out amongst the swarm of titles that hit Steam everyday. I’m also a big believer in making games that you want to play. It helps in so many ways to keep you motivated as development is fun.
Learning the quirks of multiplayer took time, however. It was apparent early on in my research that targeting a turn based system would make multiplayer slightly easier, as you do not have to deal with too many synchronization issues and lag compensation. You “just” need to make sure each action in your game is deterministic and can be replayed across clients, so they can each replicate the turns taken and synchronize state at the end of each players turn.
Ultimately the multiplayer parts of Kinship weren’t too hard to implement. Steam have an excellent library and really abstracted away some of the hard parts of the networking. The issue’s stemmed from the fact that testing multilayer games is quite a lot harder and forces a slower feedback loop. You can’t just load your game and start playing, expecting it to “just work” when you add more players. Testing meant I needed to be constantly running multiple copies of my game, sometimes across multiple devices, ensuring that interactions were smooth and there were no networking bugs. This is just harder, bugs are harder to spot, diagnose and fix.
Polishing too early
I really wanted to leverage the isometric 2.5d style to have some amazing lighting and shadow casting. In hindsight I should have spent less time on this early in development. I’m super stoked with the effect I managed to achieve, however it took many hours of bashing my head against a wall in shader hell.
Potentially this is the sort of feature that I should really focus on during the polish phase of development, once I have a game, with content and features, I can focus on making it really look and feel like a finished product.
You can see below an example screenshot of how the light and shadow casting work. I took huge inspiration from the approach that the Graveyard Keeper team used, which they outlined here . The main idea is that you simulate 3d lighting based on the vertical axis, the article really explains it better than I can!
I did really learn the nuts and bolts of how to use shaders, and this is something I can carry forward into other games that I pursue.
Game two - Puzzle simulation game (ClarityCorp)
My next game was completely different, I mean completely. Using my learnings from Kinship, I dropped multiplayer and tried to massively drop the art requirements.
The core concept was a single player experience where you are a remote worker for ClarityCorp. You log into your PC each day, are given a variety of seemingly pointless tasks, which over time you start to learn your company has a very menacing underbody. Think Papers, Please, with some heavy Matrix and Severance style inspiration.
No hook
This game however, really didn’t get further than the concept stages for me. I really struggled to nail down how to make it fun, and have a great hook.
The screenshot below shows the “login” screen you are presented with each day. You would login and be presented with a series of tasks you needed to complete for the day, to earn money and keep your family alive.
One of the tasks I started playing with, heavily inspired by Severance’s data refinement was called “Scrubbing”. You are presented with a series of words, and some criteria for words you needed to “scrub” out. You would have a time limit to remove all the words, each level getting harder and harder, and the criteria changing each time.
Despite having ideas for more mini-games, puzzles and how to progress the story, I got very demotivated as I felt this game really relied on a solid loop, which I could not nail down.
I think there is potential here for a great game, but it didn’t keep me hooked during development, so chose to park it for now. My main learning here, you need to start development with more solid ideas ahead of time. Really lock in a core game loop on paper and make that reality. Having a random list of “cool” puzzles and not knowing how to tie them together isn’t really a game.
Game three - Co-op side-scroller shooter (No name)
My third and final foray into game development of the year, took me to another multiplayer game. I haven’t yet come up with a name, however I do have the core concepts locked down.
This game involves up to 4 players, working through side scrolling levels, defeating enemies as they go. My key inspirations are:
- Celeste for the level design + platforming mechanics
- Broforce for the combat/carnage
- Remnant: From the Ashes, for the souls-like twist
Despite not being implemented the idea is that each player has the same starting point on a skill/level tree and they can take diverging paths to improve their abilities. Whether thats how fast they move, how far they jump, how often they shoot/attack, damage, health, skills etc. The players will be able to pick up different weapons, use differing skills and gain new abilities as they progress through a number of levels, ending with boss fights.
This game is hopefully a combination of the learnings from the last two games i discussed in this post. Whilst it is still multiplayer, it has a massively simplified art style, less diverse playable classes and hopefully simpler levels to design.
There are still some challenges that have and haven’t presented themselves.
Below you can see an early build of the game, featuring one player and an enemy. Again, placeholder art!
Realtime multiplayer
One key difference with this game is that the multiplayer is now realtime. Which brings up a few key new concepts I needed to learn about and solve. These are Client-side prediction and Lag compensation. Thankfully I had already learnt a lot about multiplayer game design so it was much easier to look at these to concepts in isolation and how I could solve them.
Again leaning on the amazing Glenn Fielder and other online resources it was not too hard to get an early proof of concept up and running, where multiple people can join a game and progress through a level. I can simulate lag and packet loss to test my implementations against them. I then came up with some patterns I can apply throughout the development of the game to ensure that new features do not suffer issues. We will see how well these stand.
Level assets
This time I don’t need 4 versions of each animation in a isometric perspective, but I do need a lot of tilesets for the levels I want to make. I also need to make these levels.
I feel this is much more achievable scope for me as a solo-dev, I can commission harder pieces of art out to an actual artist if need be and it will stay within budget.
For the levels themselves, I have also thought about procedurally generating certain levels to simplify the level creation process (although this does have its complexities and downsides).
Boss fights
Bosses in video games are notoriously hard to make, its hard to design them in a way that is both hard and fun. As well as this, you need to ensure that your bosses look and feel great, with complex behavior patterns and limited RNG.
This is something I do not have any experience with, so will 100% be a challenge, but one that I am willing to take on in 2025.
Play testing
Accurately testing multiplayer game experiences, well, really needs multiple people. I haven’t gotten far enough into development to make this a real problem yet, but it will approach soon. I will need a solid group of people I can keep playing with to iron out issues and properly balance the game. This is where being a solo-dev will really hinder my progress and puts doubts on my motivation. Something I need to consider going forward is how will I actually execute on this. Perhaps it is time to start building out a team…
Key Takeaways from 2024
While I didn’t finish any games in 2024, I gained invaluable experience. Here’s what I’ve learned:
- Multiplayer development is tough: But it’s worth learning, especially if you want to make games that stand out.
- Start small: Don’t dive into massive projects right away. Focus on getting something small and fun off the ground first.
- Know your limits: The art requirements for certain projects can overwhelm you, so think about how you’ll manage them.
- Solid game loops are crucial: Without a core loop that’s fun and engaging, your game can lose momentum quickly.
- Polish comes later: Focus on gameplay first, and leave polish and visual effects for when the core mechanics are solid.
Looking ahead to 2025
Even though I didn’t complete a game in 2024, I’ve made significant strides as a developer. I’m excited to continue working on “Game Three” and apply everything I’ve learned. If it doesn’t work out, that’s okay. Game development is a creative outlet, not my full-time job. But I’ll keep coming back to it because I love the challenge and putting things out for people to play!