A young, aspiring game developer is one of the most admirable human specimens you will ever encounter. Eager, hopeful of the future and with a insaciable hunger for knowledge, he strives to learn by experience anything he can lay his hands on. In this respect a young game developer is like a sponge and no dissimilar to a 2 year old toddler. Knowledge is a precious jewel to be acquired and guarded at all costs. During the early phases of learning a game developer has no focus since everything could be potentially useful – algorithms, design patterns, optimization, data structures, game engine fundamentals, graphics programming, rudimentary AI concepts, Newtonian Physics, etc. The list goes on an on, but during those stages everything is interesting and non-trivial – as each of these topics has the potential of building on the foundation necessary to become a well-rounded game developer.
Many of us recall those early phases – deep-diving on graphics programming concepts, contemplating on the differences between 2D and 3D graphics programming, understanding (or more accurately attempting to understand in vain) Binary Space Partition (BSP), texture mapping, software rendering, shadowing, the different kind of shading (flat vs Gouraud vs Phong vs whatever else became industry-standard these days). Those are just a subset of topics, but we all recall the countless prototypes we put our hearts and souls in – written in old Microsoft DirectDraw interfaces or OpenGL. Little algorithms that we feel so proud of, that satisfied intellectual and problem-solving longings but more than that strengthened our foundations in game development. These little programs served their purpose at the time – we needed to understand these concepts well and we felt a fascination in understanding the complex, interwoven puzzles that make up what we see on the screen – from the pixel drawn on the screen to the shadow cast by a game character in a simulated ground.
Our first prototype of a pixelated blur resembling a spaceship blasting away more pixelated bullets was one of the most gratifying moments of our professional or amateur careers. We understood why those pixels move and how the algorithms we wrote organize the bullets to be shot. The academic and intellectual goal reached, we moved on to more ambitious prototypes in the search of testing newer and more complex ideas. At the time, the more we read and the more the dug inside the game engine trenches the more intriguing the whole experience became. Today we learn how a pixel is drawn on screen, tomorrow we could learn how to perform full object culling with algorithms written with our bare hands. The possibilities seemed limitless.
The desire and the hunger for dwelling to such granular levels in our conquest of every game programming is also rooted by the stories we read as well – real or romanticized. We read how highly motivated duos, trios, quartets or even lone wolves lock themselves up in a basement or a lake house and by the sheer momentum of ambition pull off a feat unmatched by today’s standards. These are the Carmacks, Romeros, Sweeneys and the Ken Silvermans that we both admire and to some degree despise. Admire because of their monumental accomplishments that we so highly covet. But we also hate them because they accomplished so much with so little at their disposal at the time. In turn today we have so many resources at our disposal that this comparison seems both unfair and shameful. John Carmack and Tim Sweeney both developed game engines from scratch on their own. Carmack single-handedly developed software and hardware-rendered graphic engines for multiple blockbuster titles with the rapidity of an industrial assembly line. Sweeney performed a similar feat. Ken Silverman is honored now with a more memorable task given a shorter timeframe – this one man army surpassed the technical accomplishments of id Tech 1 (Doom Engine) and produced the Build Engine now used by several games that are household names in the PC gaming community. He was 17 at the time. We need not pay homage to Romero here. This self-proclaimed “Project Specialist” did everything that was necessary to ship a game out the door – game design, game programming, graphics programming, tools programming, level design and even PR to name a few.
I believe that the stories we read in books such as Masters of Doom both inspire and set the wrong expectations for aspiring game developers in 2016. Inspiration is most welcome, but truly speaking the dangers of setting wrong expectations (or standards) as game developers far outweigh the benefits of short-term inspiration. After reading such books we want to be heroes like the ancient legends of the 80s and 90s and feel the need to become jack of all trades like them. We want to be able to write gameplay code, draw digital art ourselves as well and similarly be able to re-create Carmack’s Reverse Shadow Volume Algorithm by memory. This is what developers did back then so why should we be deprived of similar honors?
Our egos are already hurt because we are now one Google keyword away from finding that solution in StackOverflow that has eluded us for days on end. However we now live in a highly-specialized environment. We are no longer in the nostalgic era of the 90s. Highly dedicated garage duos are now seldom producing and releasing blockbuster titles in Steam, Google Play or the iOS App Store. In the same vein there are no such things as prodigious hermits living in grandma’s basements developing every single granular component of a game (graphics, physics, AI, network, etc.) themselves. This myth is both dangerous and irresponsible to believe. The current environment is forcing us to become more specialized in the skill sets we can offer to the game industry.
To be a game developer 25-30 years ago meant many things. Nowadays it has a very different meaning.
In this series of articles I will be discussing one of the conundrums that has been a heavy burden for Helldorado Team (for many years actually) regarding Game Engine Development: to build or not to build your own game engine. I will discuss the wonders, perils and what to take into consideration when attempting to tackle this dilemma. Stay tuned!