Making a game

Hi, I’m Lang. I work as a software engineer at a very normal company in New Zealand.

I’ve been exploring game dev for the past month and, being the uninspired individual I am, decided to make a Breakout clone. After all, a simple game like this should be quick and easy to develop, right?

This blog post is probably a repeat of a million others already made, so I’ll keep it short, like how my project should’ve been.

Scope

Adding mechanics to any game increases its development complexity, regardless of perceived gameplay simplicity. Even rock-paper-scissors might get complex if you decide to add roguelike elements to it.

A lot of my ideas went unimplemented because I just wanted to finish the project. Creativity is limitless, but motivation and time are not.

Project planning and tracking

Following from the above, I should plan what features to implement before starting the project.

I wasn’t aware of Game Design Documents (GDD) before starting the project. They make a lot more sense than the random sticky note I was using as a to-do list.

Time estimates

The game should’ve been quick to make, assuming you already know the basics of game development, the tools you’re using, what features to make, and can perfectly avoid any and all issues during development.

Code quality

The player doesn’t care about how organized the codebase is, or how difficult it was to make sure the ball doesn’t fly at mach 10 when collision physics get weird. Only programmers care about that stuff, sometimes.

Next time

Games are pretty cool, and I want to get better at making them.