One way of comprehending the software side of the real-time image is to divide it roughly into two basic components or layers. The first layer can be seen consisting of art assets, such as 3D models, textures, sprites, and so forth that populate the virtual space. The second, perhaps more fundamental, or even metaphysical, layer covers the collection of algorithms, popularly referred to as the graphics/game engine, which deals with simulation of space, light, and motion, and in the end, puts everything together. Put differently, the former layer deals with the static, and the latter with the dynamic.
The above dualism comes actually down to the earlier post regarding the dichotomy of algorithm vs. design, which was about the idea that algorithms cannot produce genuine design structures in and of themselves, but that dictated by a set of rules. For instance, a physics engine does produce an unlimited number of different outcomes, which is the beauty of it, but which all are deterministic and thus predictable in nature. The same goes with everything else produced algorithmically, like shading, perspective, post processing, or even fractals. Therefore, sure, an engine can provide a solid foundation upon which to build a modern high-end video game, but overplaying a specific engine in marketing as a certification for quality is usually just that: marketing.
Still, I believe the relative importance of engines in general has exponentially increased over the time as the technology behind the games has become more sophisticated. If we look at the dawn of the real-time image, such as Pong (1972), there wasn’t that much either design or complex algorithms involved. It was the era of Commodore 64 and the likes, when we really started to see actual art direction emerging in games, such as Andrew Braybrook’s Paradroid (1985) and Uridium (1986), which both had a distinct visual style to them.
However, if we scrutinize the said games merely through still images, the engine being used really contributed nothing to the ultimate look of the games. The art assets, such as sprites and background elements, appeared on the screen just like they were initially designed pixel by pixel in a paint program or what have you. Here, the visual impact of the engine came to play only after the piece like Uridum started to move and became dynamic. And, like said, in the end it’s the engine what makes things dynamic in the realm of real-time imagery, which meant in the C64’s case basically little more than moving art assets along the x- and y-axis.
In the C64 era no one talked about graphics engines. It was only after the art assets started to traverse along the z-axis in a massive scale in games like Wolfenstein 3D (1992) and Doom (1993) when the serious engine-discourse started to take place, I believe. Now the engine did contribute fundamentally to the overall outcome of the real-time image, which came across even through still images. Indeed, art assets no longer displayed on the screen as is, but went through algorithmic processes, like simulation of perspective (i.e. space) and/or illumination, before hitting the player’s retina.
Now marketing departments and people in general started to evangelize all of a sudden about the Doom engine, Build engine, and let alone Quake engine(s), which led to a plethora of derivate games coming to existence through engine licensing. The more sophisticated technology behind the games became, the more it made sense to license it instead of developing one’s own from the ground up, it seemed.
Yet, the most relevant developers today generally don’t use off-the-self graphics engines, but propriety engines instead, or at least heavily modified licensed ones. I guess it’s fitting here to adapt the famous saying of Alan Kay: People who are really serious about their games should make their own engine.
Except for the physics engine, that is. There’s still no better physics engine than Euphoria in the market.
Pixel Counterrr 