On the Nature of Rebirth
Often I seem to return to the legendary creature, The Phoenix. Much like the Orobouros, the phoenix is a representation of the philosophical concept of rebirth.
The project has often been a process about experimentation, trial, failure, and success. It is iterative, evolutionary, and in some way breathes seasons. Recently I happened across very old, very early code from playing around in the Unity Engine editor. It was nothing more than a couple C# files which allowed for experimenting conceptual features. Looking back, these were obviously a start to where things are now, but it’s difficult to say what the launching point was.
I recall distinctly, in a project following the Cube(d)Quest demo, that I had replaced most of the Unity Engine’s solutions with my own. I realized that it would not be outside the realm of possibility to follow through. And thus I am here. Unsurprisingly, it has taken me a while to catch up in terms of where I need to be. But I believe it has been more than worth it. I have learned much that I otherwise would not had I stayed in premade-engine land. Memory management, allocation, shader logic.
A lot of underlying systems in commercial game engines are opaque. This is not necesarily a bad thing, as it doesn’t overwhelm the developer with things they oughtn’t worry about. However, it also means that developer may never understand that he or she is doing something incorrectly. It also means that as soon as you step out of the playland and attempt to replace a system which otherwise cannot do what you need, you fall a long way to the bottom. There are other downsides to this approach that I could foresee being an issue, especially with portability.
Rather, this foray into engine development has opened my eyes to a truth that I now know, that I otherwise would not have seen. Specifically: Specialized engines may allow for greater dedicated range at lower cost to an end user. This is important, as I want as many people to be able to play this as possible. I don’t want to wall anyone off by way of hardware restrictions. There are untold amount of people out there who live day to day, looking for momentary escapes into games. These people don’t have a bunch of money, and that which they do is spent on family and household. They have one computer they keep as the family computer, and they play whatever they can in their downtime. I have known these people in my life.
When developing DOOM, John Carmack aimed to target people’s work computers as a viable target platform. I see no reason why I shouldn’t at least attempt the same. It is a driving factor to keep hardware reqs as low as I possibly can so as many people as possibly can enjoy it. Ultimately I’m hoping the end product of the engine and game uses >250MB VRAM, >2GB RAM, >6GB Disk space, and single threadability. To that end I have planned to (at some point) implement a software model which avoids the gpu entirely. I do not yet know if those hardware targets are achievable, but I am working towards those goals regardless.