So yesterday I had written a rather lengthy response / update to this thread trying to clarify some of the questions popping up about the old vs. new underpinnings of LT...then I had to move locations, and when I hit submit my internet was gone and, naturally, phpBB doesn't save the form state so when I hit back my response was also gone (so I gave up). Gonna try again today, using the clipboard more frequently
Here's a basic rundown of what was
and what is
, why we're in much better shape than before, etc
- Engine and most gameplay components written in C++ (~100+ source files since I like to keep things separated). Used some heavy-handed C++ constructs, adding to compile-time.
- Despite being separated in terms of files, engine components were highly-interconnected, as I wasn't good at modular structuring when I started this journey.
- LTSL implemented via compilation to expression tree (like an executable AST), scripts executed via this tree -- a fairly slow but clean approach
- High build times due to interconnectivity and 'monolithic' structure (LT engine implemented in a single DLL / dylib / .so); even making changes to an isolated feature required an annoying amount of link time
- Above problem led to higher use of LTSL for more and more features, eventually leading to exposing the performance limitations of LTSL...this ultimately backed me into a dark corner
- Minimal 'platform' written in very light C++ (basically C; no usage of the 'heavy' C++ features, no usage of C++ standard library); platform contains core graphics / audio / system functions (i.e. the microcomponents of the engine)
- Everything else, including higher-level pieces of the engine as well as gameplay, written in a specific subset of an existing high-level language (i.e., an industrial-strength one ). The platform configures, injects functionality into, and then starts up the language's environment. LT is then started in the HLL.
- Wait! Engine functionality written in a high-level language??? Sounds like another performance disaster / LTSL situation waiting to happen! -- probably what you should be thinking right about now. This is where 'magic' happens. The platform on which everything rests allows for something rather awesome -- it allows for pieces of the HLL code to be transformed into native machine code that executes as fast as anything that was pre-compiled into the platform. The awesome part is that the code can remain written in the high-level language, it just needs to adhere to a few things, and mark itself as wanting to execute 'natively,' and the platform automatically takes care of the rest.
- Ultimately, this means we have both performance-critical and non-performance-critical code written in the same language but executed in different ways. So the beauty of it all is that I don't need to guess whether or not some AI routine or PCG algo is going to be slow...if I run the game and it's slow, all I have to do is mark it (this is done in the language itself, via a mechanism I added), and next time it'll be converted to pure, optimized machine code that runs natively, just like all of the old LT used to run. There are a few drawbacks for code that wants to do this (namely, it can't use the full featureset of the HLL, otherwise it wouldn't be possible to convert it to low-level). But overall it's an awesome setup that makes development so much more tractable AND makes sure that we're ready to handle performance issues if and when they arise.
- Due to this structuring, engine and game code can be developed independently. Entities needn't be rendered in 3D just to see basic information about what they're doing, what's in their inventory, etc. The old testbed approach is just magnified 100x here, because we can play with even more minimal pieces of the game thanks to not having a monolithic engine.
Please excuse my poor articulation of that all....I'm so caught up in the code right now that I think my english is degrading
At any rate, the point is, this restructured foundation for LT solves both
the performance issue and the development complexity issue (good lord, I can't even tell you how many lines of code are saved writing entity logic in the HLL!)
Yes, details are intentionally withheld until all is ready to be revealed
For now, though, I hope some of you can take peace in knowing that the platform is finished enough to be able to work on both game and higher-level engine code. All three of these things can be worked on concurrently. And gameplay code is
being written - far more quickly than used to be possible
It is currently first priority, as I want to know as soon as possible which pieces of gameplay code will require the platform's 'magic,' and then test to verify that it does indeed remove performance bottlenecks as I expect (naturally this testing has already been done (successfully) on typical performance-benchmarking code, just not with LT gameplay code yet). Having written a good bit it already, I can tell you guys that, all this technical stuff aside, the single best part of this new approach is that building LT actually feels like building LT, not like thinking about the best way to implement each tiny piece of it.
In that respect, a HUGE burden has been lifted from both myself as well as future modders!
I told you all I was going to play it stealthy until I'm ready to show everything, but there's a little peak at the structure so that you all don't have to guess as much (although now I'm sure I've left new things to guess at...)