2 min. read
A few days ago, I released version 0.1.0 of my CmdFX video game engine. I previously wrote about how it aims to operate as a video game engine inside your terminal.
The initial release didn’t really do a lot of game engine-y things. This post is to kind of document the next future updates for cmdfx, and hopefully highlight everything I want to do when beta is over and I fully release it in v1.0.0.
I definetly want to introduce key events in v0.1.1. Mouse events are more tricky, since those will definetly need to be os-specific and not just a divide between Windows and POSIX.
I’ve also been thinking about other kinds of events, namely draw events. Terminals don’t usually keep track of what characters are on the screen, that’s kind of just something that I would need to keep track of. It is something I am considering, though it would be a bit of a hassle if resizing because a big issue.
Speaking of resizing, I was also thinking about broader events regarding the terminal environment itself. One (and currently the only) event is when the terminal itself resizes. I’ve been thinking about maybe creating a new event when it gets to be fullscreen.
You can kind of already mimick a 3D environment with darker ANSI colors. However, I was moreso referring to the idea of implementing this natively and without hassle. Cubes, Prisms, and all of the other sorts with their own specified dimensions.
Not necessarily a v0.1.1 release, but something to consider in the early days of the engine. I want to natively implement a physics engine that can be enabled, specifically for Sprites. This would include collisions, gravity, and all of the other normal things that physics engines usually have.
As a Kotlin super-fan, I couldn’t leave it out of the toolchain. It may be a bit difficult to integrate with a CMake project, but I’ll figure out how to merge both Gradle and CMake in order to generate Kotlin/Native bindings for cmdfx. May also include some handy Kotlin-only features, since C isn’t really an OOP language, but I’d want the bindings to heavily use it.
I’ve mostly been stealing(?) some features from the KorGE game engine. Even though its documentation is (widely) outdated, it still serves useful. I’ve been working with it less as I’ve migrated towards native languages, which is why I’m also considering making Kotlin/Native bindings for this engine, and other future game engines as well.
Also, If you’re concerned about the naming scheme, do whatever feels comfortable. As a proper noun, CmdFX in its capital form will be used in most official documentation and when referring to it in of itself. cmdfx in its full lowercase form will be used in programming documentation and releases, as well as whenever I refer to it in a technical context.