For various reasons, I’ve spent some time away from LxEngine coding over the last several weeks. I’ve decided to intentionally use this time away from the code to attempt to distinguish the forest from the trees and ramble about where LxEngine should be headed…

Script + Engine Driven

I believe I’d like to modify lxengine.lib into lxengine.exe. Instead of a library to build applications on, it should be an executable that is driven by a configuration file, scripts, and native plug-ins. A new app should be writable without any native C++ code. This mindset fits better with the original goals of rapid development as a priority. I’ve envisioning a manifest file suppling a list of shared and custom plug-ins (which are in turn a series of configuration files, scripts files, DLLs, and resource files) and a “main” script file to control execution. This seems like a better architecture for my goals.

Smaller Core, More Plug-ins

Physics, Sound, and many other utilities should be separate dynamically loaded DLLs. Lots of small DLLs is less efficient at runtime, but again – the goal of the project is easy, intuitive development rather than bleeding-edge performance. I need to constantly remind myself of this. I need to break out the non-core services into a set of plug-ins per the architecture described above.

It’s likely that Javascript and JSON support will be built into the core, as these will be the primary platform upon which further extensions can be built.

More but Smaller Samples

With a “no native code required” engine setup, I’d like to throw together a lot more minimalist examples. This fits better for testing purposes – not to mention it fits better with my erratic coding schedule.

Concurrent Architecture

I’d also like the LxEngine architecture to support a few high-level constructs more “natively” than directly coding in C++ or Javascript would. I want LxEngine to be different enough from a collection of standard libraries that the advantages (or disadvantages) of it are immediately apparent. I want it to heavily assume a concurrent, event-driven model.

The first-class concepts I’d like to include are:

States both in the form of sequences (context-dependent behaviors) and stacks (inherited and overridden behaviors). Concurrency, i.e. in the form of good threading support. Task support in the form of elegant coding mechanisms for large sets of small functional units. Coroutines, i.e. interruptible and resumable functions for spreading behaviors over a non-sequential time-period (useful for animation and AI scripts). Events – i.e. the engine should be almost entirely event-driven rather than sequential to better fit with the concurrency model.

Resource Manager

I’d follow the same “manifest file” approach with individual resources. A model, texture, script, etc. _cannot_ be loaded unless it provides a manifest file with licensing and other use / authorship metadata. I’d like to have part of the engine itself be a service to enumerate the proper credits and licensing information for any set of resources. Sure, this would be trivial to circumvent, but that’s not the goal; the goal is to make it easy for those developers who want to use open resources to automatically properly credit them.

Still a Development Platform

I still want LxEngine to be both an engine itself as well as a easy to use development environment / platform. Even if Bullet (for example) is no longer linked into the core engine, I want to retain LxEngine’s current scripts for pulling down the source release and building Bullet locally as part of the environment. I still want to support the use case where the third-party “auto-build” and configuration can still be used even if the lxengine core code itself is not used. Build and configuration is too much of a hassle on Windows. It shouldn’t be.

NaCL and the Web

Not sure exactly where I need to head in this direction. After some fruitful time working with Javascript in a purely web-based environment, I see a lot of advantages to immediately web-deployable work…but at the same time, I have not forgotten that C++ has some serious advantages. I don’t have a conclusion for where the native code base and the web code base should merge and if the answer is Google’s NaCl – but it’s an inevitably lingering question.