AftGangAglay

Rationale

In the 7 months (at time of writing) since AGA (AftGangAglay) began - it has transformed from a testing ground not intended for eyes beyond my own, for an OpenGL abstraction which no longer exists. As it now stands I would be confident in calling it a "game engine".

Applications are consolidated binary "blobs" of multimedia assets which are presented as visuals, sound and behaviour to the user. In my mind, this is the platonic ideal of a game applicaton engine: eat data, excrete experiences.

I often find myself confronted with the arbitrary nature of the restriction to the technology of the early 1990s - especially when faced with neccesary exemptions such as WGL support for modern sensibilities. Ultimately, my final judgement is one of reasonable restriction and "interesting" versus "boring" work.

The goal of AGA has never been to simply "have a gimmick" - it was born out of a genuine interest in this important transitional period of computing. The web is just on the verge of changing the world, 3D graphics hardware is just about to enter the consumer sphere and CD distribution of multimedia experiences is about to become the standard to supplant sequenced audio with PCM in games. This poses what is, to me, a very "interesting" series of problems: how were these technologies used at the time of their inception? It is not that we have to reinvent the wheel - the goal is not to simply write the future again - but rather we get to bring our modern understanding of how these technologies "turned out" and take things on a different path. We get to learn where the foundational software of our modern ecosystem started and how the concept of a cohesive ecosystem evolved out of the web.

On the other side of things, the "boring" problems I alluded to are those where we have no room to innovate or diverge - creating our own arbitrary model transmission format and the associated tooling by which to use it is, in my opinion, a "boring" problem; We would simply be reinventing the wheel. This is largely a space subject to debate - and I really do try to engage with those who contest whether a given restriction or lenience is in the spirit of the project.

At the end of the day - game engines facilitate games, and the player doesn't care what technology was used to create the experience so long as it is fun. Asking the player to install an unsigned SoundBlaster driver for our own measure of "authenticity" is getting in the way of the fun for our own ideals, which would be at odds with our identity as a game engine. On the other end of things - if we simply conceded to modern technologies in the name of modernisation for our own convenience; We risk losing our identity as a project and becoming "yet another" engine with an outdated foundation.

Moving forward - my personal focus has been set on gamedev driving engine development by-neccesity. However, wider architectural work is not placed on hiatus - I am only human, and the "call of the void" to address our ever-growing list of "TODO"s will still win over and lead to sweeping changes as architecturally significant changes are enacted.