I’ve been programming since I was in middle school, with the intention of being a game programmer. At the time of writing this, I am 22 years old and I’m fairly confident in my ability to develop a presentable game in something like Unity. Except engines like Unity aren’t where I learned how to code.
Back in 2009, there weren’t quite as many helpful resources for an 11 year old kid to learn about game programming. There were some pretty cool engines like Blitz and GameMaker, but I didn’t want to make those kinds of games. I wanted to make the real stuff, I wanted to make games that could compete with the likes of Oblivion and Half-Life 2! Most of the resources I found lead me to study C++, and I gave up as soon as my attempt to build a “Hello World!” application failed. I managed to take a deep breath and consider starting small, first with GameMaker. Then I built my very first game, Ball Fighter.
This game can be beaten in 10 seconds and took me about 3 weeks to make. I had no programming knowledge at the time and even back then I wasn’t quite satisfied with how it turned out. Neither was the YoYoGames community; in fact one person very strongly voiced his opinion that it was probably the worst game he had ever played. I promised everyone a sequel with more effort put into it within a year, but I got distracted by other things.
Fast forward a few years, after familiarizing myself with more programming concepts in easier languages, I decide to actually pick up a book on C++. From there, I programmed a few short “choose your own adventure” text games that I was fairly proud of at the time, but never published. After a couple more years of switching between premade engines and working from scratch, I finally managed to find a good resource for creating a game framework from scratch in SFML2. I followed the book and then started going my own way so I could experiment with things like the update loop and rendering order. It was good to know how these things actually worked, but I just could never manage to finish a project.
Finally, I decided to go back to the basics with the knowledge I have now. I’m a C++ programmer, I knew how the update loop in a game works and what goes on under the hood, I was aware of common game programming patterns. I thought, “Why not make that sequel to Ball Fighter, the way I originally wanted it to be?”
First I had to familiarize myself with the engine. And hey, what a lucky coincidence that Ball Fighter was originally intended to be a roll-a-ball game, while the most basic Unity tutorial was for roll-a-ball? 😉 After finishing the tutorial, I customized things for my own needs and turned the game into what 11 year old me was trying to make: A game where you roll around as a ball and fight bosses. Except with my developed sensibilities of challenge and level design structure. And my developed understanding of how game engines work.
Which brings me to talk about another issue. How many gamers first boot up an indie game and then sigh when they first see this, knowing that the game is probably going to run at 24 FPS and be full of unnecessary post-processing effects?
Unfortunately, while game development has gotten a lot more accessible, we have not yet removed the necessity to understand how games operate on a technical level. Many aspiring game developers these days will start with either Unity or Unreal Engine 4, completely unrestrained by their lack of knowledge. Which means that they do things that are extremely performance costly, or follow really convoluted programming patterns that are helpful in the long run.
And it’s unfortunate because these are actually some very powerful engines in the hands of people who know what they are doing. The problem is you can’t really know what you’re doing until you know what the engine is doing. I’m not proud that it took me so long to become a competent programmer, but I’m glad that I experienced low-level development before sticking with the higher level stuff. I think everyone programming potentially resource-intensive applications should take some time to create things from scratch before trying to use somebody else’ tools. Think of it like learning to ride a bike without training wheels, but then you install training wheels that make your bike go even faster. (Also, pretend like there’s no social stigma around using training wheels)
Overall, I think as a developer, it’s your responsibility to master the toolset you’re working with. The toolset shouldn’t master you. I believe most people learn best with hands-on experience and there’s nothing more hands on than trying to recreate something you’re working with. Even if it’s not anything presentable, I’d encourage you to make your own engine before sticking with Unity; it never hurts to be overpowered.
Oh, hey. Some physicist condensed my entire blogpost into a single quote about 50 years ago.
“What I Cannot Create, I Do Not Understand”
Richard Feynman
Just goes to show you that Computer Science is still science.
Gavyn Bryan - Programming Blog 