This post will be taking a slightly different approach than my others. Most of the things I write are about experiments, bugs, and tools I’ve done. However, I think it’s just as important to appreciate the failures we’ve had as it is our successes. Today, I will be taking you through some “cold readings” of projects that will never see the light of day.
All developers have these, projects that fail for some reason. I am still only a few years into the professional world, but I’ve been writing bad scripts for almost half my life, and each of these prototypes has taught me valuable lessons. Without further Ado,
Thankfully, I have a version of this project hosted on github. This project was a game that someone offhandedly commented was “similar to Galaga”. After having played Galaga, I realize that’s not the case at all. It was simple, but awesome:
The game had wave bosses every 50 kills, which were by far my favorite part of the project. I really enjoy boss design.
I suppose this may not count as “unpublished”, as I did give it to classmates, but I never really got close to my original plan with it. A friend of mine also did some of the sprites for this. Great job, buddy. I remember a student I thought of as a bully came up to approached me after creating this project, and said something like, “I got to a score of 300 in your game, I played it all night last night, I’m hooked”. That was enough to make this project worth it.
- Games can be a medium to connect with people
- Simple concepts can still be fun
- Boss design is really interesting
- I was (and am still) bad at pixel art
At some point in time, I decided that everything was best done myself, so I could learn how it works (I still believe this, honestly). This lead to a lot of interest in 3D projection. It took me a while, but I eventually found some information on how this worked in a way I could understand here.
I took this logic, ported it to Java, and added systems for drawing lines between the points. Then, I added code for filling those shapes with color. Despite a fairly messy implementation, I am still quite proud of how this turned out.
- Leaning on libraries can be good, especially for performance-intensive tasks
- There’s many problems (rendering, movement, physics) that become more complex in 3D
- Math is a valuable skill for improving performance, rendering objects, and general programming
Another project I built that year was a simple platformer about a pig who couldn’t fly. I never wrote any of the story for this, but that’s what it was about.
Playing through this, I really do appreciate how inconsistent and unfair it was. There are invisible tiles that are required to solve both levels after the tutorial, so unless you know thatt, the game is practically unwinnable. I also enlisted two classmates, one to make the sprites (thanks again bud), and another to design the levels, which were encoded in big text files, a simple but effective visual editor.
- Game design that’s overly clever is going to lead to confusion
- Incorporating story is challenging in prototypes
- Good collision is important for platformers (this game had buggy collision)
For several years after this, I became deeply involved in the Minecraft modding community, and didn’t build many side projects outside of that. The projects I did build were mostly brief prototypes that never got developed much. Here’s some screenshots of those prototypes:
There’s one last project I want to talk about. This is probably one of my favorites. The concept was a tower defense game focused on building and upgrading towers. It focused on using different tower components to change properties of fire rate, turret health, and even projectile motion. Different parts of the path of a projectile could be influenced by the pieces used.
I spent a lot of time focusing on using quadtrees for reducing the search space for projectiles. I was able to get around 8,000 “smart” projectiles rendering, all with specific pathfinding logic. In retrospect, this still wouldn’t have worked for weaker computers. The final state of this project was fairly far along. It was the fatal mistake of deciding I should port it to multiplayer that eventually killed it. This lead to a massive rewrite, and the codebase becoming mostly illegible to me, as well as several nasty bugs.
Multiplayer did work though. I was able to connect with friends, kill enemies, upgrade turrets, and eventually die. Sadly, the state of the code and the game were broken enough I lost interest and abandoned the project. I used version control, but I built several features around multiplayer and lost a lot of my direction for the project.
- Changing scope is dangerous and leads to dead projects
- Multiplayer isn’t important for all games
- Test on less powerful machines
Originally I felt this was probably not something worth doing. After considering it and writing it, I have realized a few things I would not have expected. Outside of the technical lessons learned, I have learned two very important things from looking back on these projects.
These are more than my personal projects When I began writing this, I realized that I felt a strange attachment to these long-dead projects. I found that they were important pieces of how I became who I am today. In 2012, I was a bored kid, stuck in a middle school I hated, dreaming of leaving and going on to great things. My life has changed so much since then, and each of these projects were milestones between everything else in my life.
This has been a valuable reflection for me. For better or worse, I’m only just realizing how much my hobby, passion, and eventual career has shaped me as a person.
Collaboration is important Out of all of my projects, the best ones were done with friends. Even if unfinished, I consider all of those to be successes. I think the best strategy for good projects is working together with friends who have complimentary skills. Thank you to everyone for the roles you’ve played. I look forward to the next project.