A look into what goes on when writing a small game from scratch.
I first started thinking about the idea for my game, Byte, a year and a half or so ago when I started my first job as a web developer. The basic idea is that you are a byte in a phone defending the user against harmful texts. At first, there was going to be power-ups, cut-scenes, an entire story, and a hub world with NPCs. All of these ideas were good, but I ended up not implementing them because you should start small when developing your first game. I realized that I wasn’t trying to make the next big game, or even sell it somewhere. I was making a game to learn more about game and software development, to learn a new coding language (Python), and to make something for myself.
Deciding what tools you want to use for game development can be a daunting task. There are so many out there that are complex such as Unreal Engine, Unity, and Godot, to smaller frameworks like PyGame, DragonRuby, and Renpy. Figuring out what kind of game you want to make and what you’re making it for is crucial to picking game dev tools. I ended up choosing PyGame because it is more of a library than a framework. I wanted to learn how to make a game from scratch and PyGame really helped me do just that.
Using PyGame was fairly straightforward after figuring out the headache that can sometimes be Python and PIP versions. Once everything was set up, I started working with a simple script. I used guides online to start making things appear on screen, and eventually made my own sprites with Aseprite and my own music with LMMS. I remember getting it to the point where I could control the character and I had a small animation of him blinking. I was so happy with my progress…but eventually understood how large of a task I had set up for myself.
I had worked for hours, just to get a simple animation in. I still had to work in the enemies, shooting, more animations, more music, and all of the other ideas I had. That’s when I decided to cut some of those ideas out so I could finish the game. I realized that projects like this take time, but I hadn’t approached it that way. I wanted to make a quick game so I could move on from that idea. It started to bore me, so I worked on it as much as I could to finish it and get it out.
This is not the way you handle things you care about. I should’ve understood how I was feeling about the game and either 1. dropped it, 2. taken a long break from it, or, 3. fully understood that development takes time, and accepted that that’s okay. Instead, I rushed it out and shipped an unfinished idea of mine.
I learned so much from working on this project. I not only learned technical skills by learning Python and working with PyGame, but I also gained essential experience in software development. After that project, I started slowing down. I take my time developing now - it’s better for my mental and emotional health and it allows me to write better code and tests.
I encourage everyone to go make a game of any kind. It’s such a different part of software development and learning more about it will help you to excel in other aspects of your career and / or personal projects.