So 17 years ago was my first full completion of an Indy game. It was a remake of the epic classic Tetris. Well, I took the base concept of falling blocks and rotating shapes, and made something of my own with it. Not unlike most games these days. Why? Well back then you didn’t have access to the amazing tools like Unreal, Unity, and other game engines. In fact you didn’t even have the online resources to draw from for libraries, API references, or QA/FAQ boards. Crafting your own game meant lots of research, reading, and trial and error… unless you were in the industry or knew someone in the industry.
Now at that point I was neither, but I had interacted with a large group of people at an Indy game developers conference out in San Francisco hosted by Andre LaMothe. So while I wasn’t completely green, I had yet to completely finish a game. Several false starts, and hundreds of pages of designs were done, but no completion. And what I learned from LaMothe, and others I met there, was that you should dream big, but start small. I had always been aiming too high for a starter’s project.
How to explain what I mean by aiming too high? For people who have never finished a major project, never managed a project, and never had to self-motivate through the hard parts, completing something as complicated and complex as a full game is beyond the capabilities of your average person. Beginners always think they can do more, better, faster, than what everyone else thinks they are capable of. The young, and the dreamers, are particularly susceptible to this delusion. I had 200 pages of designs for a single MMO style game, but I wasn’t ever going to be able to do that on my own as a first project.
So I come back from this conference and decided “I’ll make a Tetris clone.” It’s fun, engaging, has all the required elements of a full featured game, and is “Simple” as games go. Thus “Bombs” was born. The entire project took about three months and included hand drawn graphics, full UI work, mouse interaction, music background, learning DirectX (5 or 6 don’t remember which) and writing every line of code. No library, no tools, no engine to help me. That was three months of nearly full time effort when I wasn’t at my day job.
What did I learn from this? Well, nothing is ever as simple as it seems. Interactions between unrelated sections of a program are absolute nightmares to debug. And Software is frequently the easy part of the overall game design. Mostly I found my passion for making games was at its highest when you can show off the final product and share it with others. This can be expanded to help you finish larger projects. If you try to do waterfall design/development methodology you’ll be left alone with no positive reinforcement for too long. Use smaller spirals, or agile development when working as an Indy. This allows you to have partially finished and playable demos faster, and get the feedback and positive reinforcement necessary to keep plugging away at the problems.
So now I’m going to embark once again on remaking Bombs; this time using the Unity game engine. I suspect I will not take 3 months of full time effort with the tools and resources available to the Indy community. I recommend to anyone thinking of becoming an Indy game developer, or anyone with a passion for games really, to
“Dream big, but start small.”