Yes, those were back in the days when I was simply pumping out C++ as fast as I could. And there's nothing wrong with that. I could resume that approach today and have a much lesser form (and non-moddable) of Limit Theory out in a very reasonable timespan (and that's only because I've re-architectured the engine and now know how to prevent monoliths). But that's not going to happen, because, as my conception of Limit Theory matured, modding became something that I simply had to have. I want you all to be a part of Limit Theory's development. I want to see what people can do with this technology over which I have slaved for years. I want to play insane variations of my game that blow my mind. And it's all very much possible. I'm fine with dropping other content (especially content that has crept in since the original design doc) -- it can be appended later via modding. But I'm no longer fine with a non-moddable LT, and this is where the real challenge lies.
About LTSL -- the need for LTSL originally arose from a feeling of uncleanliness that I was getting from the LT codebase. It was taking me longer and longer to make trivial changes and recompile / view the outcome, it was getting harder and harder to figure out what was affecting what, and debugging was becoming more and more challenging. All of these problems were scaling linearly with the size of the codebase, meaning the difficulty of development was, effectively, scaling quadratically with time. This is, perhaps, responsible for how 'suddenly' things seemed to change. Hitting the wall was not a linear-time process, unfortunately. LTSL was nowhere near a mistake, and it did cause a fairly significant explosion in my eyes. A lot of it was UI, but that's because UI is one of the most annoying things in existence to hard-code. Remember the latest market interface? The assets interface with holographic views of each asset? There was also a working ship builder UI that was to be revealed in RTB 3.0, which never happened. Warp rails and their graphics effects, HUD, radar, target information UI, scanner UI, custom AI maneuvers, new station algorithms, new ship algorithms -- all LTSL. LTSL did the job. But it was a temporary 'escape' from the real problem: that the engine had grown too difficult to deal with, hence the need to 'escape' into a lightweight scripting engine.
But, as nothing is perfect, LTSL began to show its own problem -- performance. Towards the end of LTE (the Limit Theory Engine), much of the functionality was offloaded to LTSL in an attempt to fix the 'monolithic' problem. But LTSL struck back with performance limitations. It couldn't handle the intensity of true engine work. We were stuck. I could keep pushing and pushing and pushing in an engine that was becoming increasingly difficult to maintain, I could suck it up and accept the (fairly drastic) negative performance implications of engine work in LTSL, or I could use everything I had learned from both experiences and do something better. Anyone who knows me knows immediately which option I chose.
Here is what I would like everyone to fundamentally understand about Limit Theory:
It has ALWAYS been about working smart -- it has ALWAYS been about creating a beautiful technology in order to enable the creation of a beautiful game.
In the beginning, plenty of people said "no way, not gonna happen with a one-man dev team." And then guess what happened? I developed technology that allowed me to show the progress of a game at quite an impressive rate.
Despite the paradigm to which so many have become accustomed -- "shiny new content!" -- Limit Theory development has always been fundamentally about THINKING and finding the smart way to do things. That's the only way it can happen.
And that's exactly what's happening now. Yes, it has taken time, but I now have an elegant technical solution to both the monolithic engine problem AND the scripting performance problem. That much I will divulge. When this solution has been built up to the point of supporting all of LT's existing content, the content algorithms will simply be transferred over -- no work will have been in vain (not even LTE or LTSL, because they were important milestones for my coming to understand the right way). This time, I can guarantee that there will be no circularity, simply because there is nothing more that I could possibly do, technically, to energize LT's development than what I am doing now (to explain what I mean would be both too divulging and too technical). There will be plenty of back-and-forth in finessing the game, but not technology. One can either choose to believe or not believe me in this regard...it doesn't really matter, as LT will come in time and all of this will be over when the release drops.
^ This is the last time I will provide a justification of my current direction, I'll be keeping this link handy for the future.
And about that 'finding an entry point' thing that someone recently expressed (imagine my joy in being reminded of this dev log) -- it was never actually an issue. It was never about Limit Theory. What I was expressing in that log was a projection of my mental state onto my current task. The reality is that I was degenerating mentally to the point of being unable to see a big picture, to find a coherent strand of thinking to follow, to see LT as the beautiful concatenation of interesting subsystems that don't have an entry point. It is entirely possible to develop each independently, and to perform incremental testing by joining them as they are ready to be joined. I no longer have the problem that was being expressed in this log, because it was not a problem with Limit Theory -- it was a problem with me, and, as you all know, I've been working to fix 'me' since the end of the dark days.
