Creating an engine is, of course, an exhaustive process, and demands on my part all the planning, assembling, refining, and (unconditional) loving it deserves. An engine is the concert put forth by an innumerable mass of moving parts, all working in tandem. It is the motor that drives a solid game.
There is an art to designing a program, and when done well, it can be beautiful. If medieval cathedrals were to have a contemporary counterpart in modern software, engine architecture would surely be it. Algorithms, design patterns, and class compositions are the vaults, arches, and buttresses of the intricate software system called an engine.
I have christened the graphics engine I am developing “Clairvoyance” – the ability to perceive matters beyond the range of ordinary perception. It is appropriate, then, because the software will be responsible for bringing to life the surreal imagination of its users.
There are several requirements I have laid out for this project, describing how this software should be developed and maintained. A high level view can generalize these specifics into a few architectural strategies; they are scalability, portability, and extensibility.
The engine is designed to accommodate a variety of user-defined requirements, and some of the components and methods involved in meeting these requirements will overlap. It is necessary to design a granular system whose parts can be used and reused in varying contexts. This system will be designed to accommodate the different proportions of its features gracefully: identifying common components and designing them to be general yet flexible enough to fit specific needs creates a modular system where scale is a nonissue. Having these reusable components makes production easier, cleaner, and more robust. Granularity is a key concept, and a thorough understanding of its uses will be imperative to designing this software optimally.
The engine will be available on multiple platforms and it is important that its source be portable at a developmental level. Designing to a specific platform will be avoided as much as possible, if not all together. Source will be able to be brought between different development environments seamlessly when needed. This is necessary for quick development that will maintain a common design throughout each OS specific application version. Accomplishing portability will be done by designing the architecture around a minimal number of external dependencies, and accommodating platform specific libraries where necessary.
Clairvoyance is built to handle future growth. It is necessary to take into consideration future extensions at all development stages since we must be willing and ready to adopt feedback. Future iterations of the software must take on modification and additions with low levels of effort to ensure quick updates are possible. Making large updates to software will not require an overhaul each time, and will instead fit alongside with already existing code.
There are some concepts specific to the production of a graphics engine that I try to keep in mind. Namely, I want to make sure that Clairvoyance is built around the latest revisions of the graphics APIs it uses. Keeping it compliant with the most recent APIs is important to ensure I can design efficient code, communicate optimally with the graphics hardware, and avoid deprecated code. Currently, Clairvoyance supports the architectural paradigms introduced in OpenGL 3.0 and 4.0, deliberately avoiding the less efficient deprecations of previous versions. Future iterations of the engine will ideally incorporate D3D.