This is a bit overdue, but at long last, I’m finally getting around to it. Here is the 2018 development roadmap for the ÔÇô Engine.
…or in other words, a less trivial “Hello World” application. This involves
creating rendering contexts for the various operating systems, and being able
to print a cool image to them that shows they’re functional. It also means
we’re dropping most every upstream dependency currently used in the
master branch of ÔÇô.
It also means, as I eluded to
By “various operating systems”, for now that only means Windows, macOS, and Linux, because windowed mode isn’t really a thing on mobile and we don’t yet have an iPhone to test it with anyway. Don’t worry though, I’m sure we will soon enough! 😅
This is the first substantial series of abstractions for ÔÇô, and probably my favourite because of the colourful history it has had in various projects in mine, in name at least.
In some rather forgettable precursors to ÔÇô, there existed a new reimagining of the object system used by Game Freak, which has carried forth into today. The idea—on the surface, at least—is simple: OAMs provide powerful extensibility in two-dimensional games. They provide mechanisms for scaling, rotation, millisecond-precision animations, and Photoshop-like real-time graphical adjustments, all together in a modular, stackable grouping system that allows one to stick together graphics in countless ways and at any level of complexity. Put simply, it’s a live and programmable Photoshop doc for video games.
…or well, that’s the end goal. OAMs and other facilities will be the first nontrivial things added into ÔÇô, and only to the ends of a Minimum Viable Product. Rather than get carried away, we’d like to develop some other niceties as MVPs too.
Up until this point, pretty much everything will have been implemented in a quick-and-dirty fashion – naturally, some things will have been done lazily on the CPU just to get them working and out the door. However, at this point everything that ought to be parallelised by the GPU, will be put on the same sheet of music and consume a lot fewer resources. This is where Vulkan will begin to shine, because unlike OpenGL and earlier versions of DirectX, it provides a lot of muscle for GPU usage outside of graphics workloads.
Alongside this, support for Android and iOS will be fleshed out to fall in line with what is given on desktop builds, more or less. The challenge with these will entail getting D code compiled for mobile, using the LLVM-based LDC.
With the engine bearing a rendering context, sophisticated tools for runtime abstraction, and a modicum of sensibility towards the hardware it’s running on, well all would seem to be just peachy. There’s just one thing missing: an editor!
Developing this also entails developing a scripting runtime for use by designers, which we’ll go into more detail on later. (No, we’re not jacking Lua or something ridiculous like that.) For designers, there will be good support across Windows, macOS and Linux in the editor suite we’ll build, unlike Unity and (somewhat) Unreal. We also want to stress that we will be taking a different approach for scripting than both Unity and Unreal do: it will most closely resemble Godot’s “GDScript”, but with some differences still.
Beyond these things, it’s pretty tough to imagine much besides our embarking on 3D feature development, and the general things that entails. We don’t want to get in over our heads with plans, so until we reach these upper echelons we won’t be worrying about it too much. 🙂