It is with a heart of lead that I write this announcement. Not in my darkest nightmares did I expect this day to ever come, but circumstances have reached a point that even my endless optimism can no longer rectify. I can not finish Limit Theory.
After six years, I am finally at the end of my means. Financially, I am beyond the initial investment and have exhausted most of my personal savings. But significantly more troubling is that I am entirely out of energy -- emotionally, mentally, even physically. Every year that passes sees me becoming more desperate to make good on the dream with which you all entrusted me, but each such year I grow less and less capable of doing so as my mindset falls further away from that bright, beautiful hope that powered me from the beginning. I am not what I once was.
Despite what felt like an incredible amount of progress in the last year alone, Limit Theory remains frighteningly far from feature completion. It is my own fault, for having underestimated at every turn the amount of work that goes into such a creation. It is my own fault, for having overestimated my own cognitive resilience and for believing that no number of setbacks would ever inhibit my ability to bring a passion project to life.
I don't know how to make this right. For years now, I've been running on pure loyalty to you all -- it has been quite a long time, if I'm honest, since I was actually working from a place of inspiration -- yet even with the purest of intentions and the deepest desire to honor my commitment, I find myself unable to bring about miracles. No matter how hard I try, it's not enough to bring LT to fruition, and this pattern of failure has evicted all self-confidence and hope from my mind, leaving only doubt, anxiety, and despair. Some days I think to myself "how absurd that a game should make me feel this way," and I realize just how unfit I have become to build a source of joy. I wanted so, so badly to make you all proud. To bring you all joy. There are no words to properly convey how sorry I am that I have failed you all.
I imagine I could go on and on with this gushing of negativity -- the years have left me with no shortage of it. But I don't think much good will come of it. Those of you who have followed the project closely, you already know how much I have put into it; how I have given 110% of myself. Trying isn't the same as doing, so I don't expect any thanks for it, but I hope you all do know just how hard I've tried. I've simply got nothing more to give.
So, what now?
Well, I will prepare the source code for release. It's not a working game, and in my frenzy to get things working I've left huge swaths of code in a half-refactored or half-complete state. But releasing it is the least I can do. I don't imagine it will be of any use to anyone, other than as a monument to a failed dream. Perhaps those who are interested in game engines will glean a thing or two from the engine, as it is a fairly solid piece of engineering, much more solid than the Lua game code.
For the moment, though, I wanted to get this off my chest as soon as possible. It has been the most painful, difficult decision of my life, and I'm sure that there will be no shortage of blowback. But I simply cannot continue to destroy myself in search of a feat of which I am not capable. When I began this project, I felt that anything was possible. Here now, at the end, I must swallow the painful reality that: I, too, am human. I am limited by time, I am limited by finances, and I am limited by mental & emotional stamina.
One last time, I would like to thank everyone who contributed. From the bottom of my heart, thank you for believing in Limit Theory. Thank you for giving me the opportunity to try for something wonderful. One last time, I am so sincerely sorry for having let you down. I hope, at the very least, that some of you have enjoyed the ride as I've pitted my brain over the years against one challenge after the next.
I'll be in touch when I have readied the source code for release.
Looking at the last update, I'm quite intimidated to post another one -- that's a tough act to follow. I'm afraid I don't have quite as many pretty screenshots for you today, but I certainly did not come empty-handed :) Over the past few months, we've been busy acting on the lessons learned from the PAX Demo sprint as well as pushing into new gameplay territory. In particular, we have seen a great deal of progress on the high-level dynamics of the game, as I'll detail shortly!
Before we get to the excitement, though, I would like to announce an unfortunate bit of news: Lindsey has left the team. Rest assured that there are no hard feelings nor burnt bridges; she left of her own volition due to changes in her work availability. During her time here, Lindsey built up an impressive procedural geometry library that I'll be able to leverage in finishing up the remaining algorithms. And, of course, we still have the ridiculously-good fighter algorithms that she devised! Despite her time with us being too short, I am nevertheless grateful for all that she accomplished while here. Thanks, Lindsey! o7
Now, back to the good news.
Content Creation with The LT Editor
One of the lessons I took away from our PAX sprint was a lesson that I had already learned (in an unfortunate manner) during the era of LTC++ and LTSL: the ability to add content in a flexible, granular fashion tends to run directly counter to the ability to maintain a big-picture view of that content.
In response to the dilemma, I spent a bit of time prototyping a tool to help. With the power of Lua and a UI library known as Dear ImGui in-hand, I came up with an "LT Editor" that fundamentally solves the aforementioned problem. The editor allows us to maintain full visibility of everything going on in the game while simultaneously making changes maximally-modular, since each change to the game content is encoded as atomic 'deltas' in a generated, Lua-based LT mod file, and these mod files can be merged cleanly in nearly all cases. Ultimately, all of this boils down to avoiding the same tractability problems that I've run into in the past as we scale the game up with more and more content.
There's quite a lot going on in the editor; if you're interested in reading about the details, check out my March 9 devlog.
When I revealed my work on the editor, some of the community voiced understandable concerns about the relevance of such a tool to shipping LT 1.0. While I still feel that the editor will play an important role in avoiding past mistakes, I have shifted my attention to raw, unquestionably-relevant-to-release gameplay for the moment to dispel any misconceptions that LT is not going anywhere, which, as my last devlog in particular demonstrates, is quite false :)
Dynamic Economy, High-Level AI, Colonies
Speaking of gameplay, the past few weeks have brought a real explosion of work on the big-picture dynamics of LT. I've resumed both theory and implementation work on markets, trading, projects, colonies, and the AI that ties them all together into a dynamic macroeconomy. My efforts thus far have yielded a tremendous amount of fruit, bringing our current implementation of these dynamics to a quality level far beyond that which was demonstrated in the old update videos.
To ensure total dedication to the work itself and zero distractions (like...shiny graphics..), I used an 'economy sandbox' application for this work. As such, the images are rather ugly -- but it's the contents that matter! To explain everything going on in this sandbox would require several devlogs worth of text, so I recommend glancing through the two relevant logs -- April 20 and April 30 -- if you're interested in learning more about all the details. Perhaps the most important breakthrough in this work was the development of a novel, 'flow-based' model that enables the AI to make remarkably-sensible choices that lead to interesting, efficient, and stable economies.
For those not interested in the details, it suffices to say that Limit Theory is shaping up to be every bit the rich, dynamic experience that I outlined in the beginning. We have real market economies, colony dynamics, AI with free will to do as it pleases (and high-quality algorithms that make sure these choices result in rational behavior), emergent global phenomena that result from changing economic conditions, and so on. This is no lonely, unresponsive single player experience we're talking about...this universe is alive!
Exploration, Discovery, and Information
With the global economy simulation humming along better than ever before, I wanted to press even further into new code and flesh out the exploration mechanic, both in design and AI implementation. The latter, in particular, yielded some really exciting work in the economy sandbox.
Once again, I'm afraid that to explain this work fully is beyond the scope of a summary, so I will refer interested parties to the "Information, Discovery, and Non-Omniscient AI" subsection of my April 30 devlog. The short story here is that we have a game world whose activity can be completely reshaped by discoveries and the spread of new information. Explorers rejoice, for here, youactually matter!
Gameplay development continues at a steady pace. The economy, high-level simulation, and AI are all in really good shape. Information & discovery mechanics are now well-explored territory (teehee). Although a fair bit of UI work remains to be done in order for all of these implemented mechanics to be usable by players, having the underlying theory and AI algorithms worked out for these features is a huge relief considering that we're talking about fairly brain-taxing work. On his end, Adam is working to implement the interfaces for much of this gameplay, and already has a command interface up-and-running!
The coming months should be relatively unsurprising: with no real blockers or distractions in sight, Adam and I will continue powering through that which remains between us and feature completion. Personally, I am looking forward to a continued focus on the 'big picture': bringing mechanics together to produce a vibrant universe.
One last note: I've been working hard to bump up my devlog frequency over the past month, so for anyone unsatisfied with the relative infrequency of the Kickstarter updates, please do drop in on the "Dev Logs" sub-forums where you can follow development at a faster pace and in (vastly) more detail! In fact, Adam has posted a rather hefty log just earlier today!
Another year of LT development has come to a close and 2018 is upon us. It is with enormous joy and relief that I say "2017 was excellent!" Especially the latter half.
2017 opened with me returning alone from PAX South 2017, having shown a demo of 'BoxShipWars 3000,' feeling tentatively good about a candidate solution to the great performance crisis & ensuing meltdown of 2015. It closed with a team of three of us returning from PAX South 2018, having shown a demo of what actually looks a good deal like Limit Theory combat, running on tech that we have now proven can handle the demands of LT. Between the two endpoints, development has come to life and the feeling of an infinite, procedural universe of possibility looms on the horizon stronger than ever before :)
Limit Theory @ PAX South Recap
We spent the weekend of January 12-14th at PAX South in San Antonio showing off an LT combat demo. Although we had planned it as a bit more of a serious experience, by the end of the weekend, we had refined our demo into what seemed to work best for the five-minute-sampler PAX experience: pure chaos! A faction vs. faction all-out war, one-hundred units on each side, each respawning in small squads as they fell. The player ship had infinite health, infinite energy, and the ability to summon ever-more allies from nowhere ad-infinitum. The demo even included a ship editor that allowed players to tweak and explore the parameters used by Lindsey's procedural algorithms (note: not representative of the full-featured LT ship/station editor workflow.)
Here's a quick video capture we did afterward to showcase a bit of the demo. Note that there's no audio!
The player response to LT at PAX was really encouraging. We had numerous players express their amazement at the sheer amount of 'stuff' going on -- especially impressed were those who tried to crash the game by spawning 10k+ AI escorts, only to find a very gradual FPS degradation after they hit 2,000 ships. We compliments on the beautiful visual style, the smooth and responsive feeling of it all, the joy of being able to issue orders to a fleet, and the quality of the procedural assets. The ship generator was a bit hit, and folks were especially impressed upon learning that the ships were procedural down to the very vertex rather than lego-style recombinations of prefab assets.
If I were to boot up the old LTC++ and try to push it to do what our current setup did at PAX, it would have been a spectacular display of tears and molten lava -- the former pouring from me, the latter pouring from my laptop. We are easily capable of pushing 10x the amount of activity LTC++ was capable of, and at an extremely high framerate. All the while, we're not only putting more entities in the world, but the amount of dynamism is starkly superior to LTC++. Our demo was running full collision on all entities -- NPC ships collided with one another and with every asteroid in the scene; ramming small asteroids sends them flying off into the abyss; slowly pushing a large asteroid is even feasible with a large enough fleet. The AI drove thousands of turrets across hundreds of ships, each computing viable firing solutions. Tens of thousands of projectiles collided with everything in the scene. All those little details added up quickly into an experience that felt genuine, deep, and rich with opportunity.
All-in-all, what we had going on is exactly what LT promised to provide, and what I've thrashed my neurons for so many years to make possible: a universe alive with activity. Imagine this same scale of activity expanded beyond combat -- thousands of ships trading, exploring, mining, patrolling, constructing, researching, so on and so forth -- and you are left with the vision of a vibrant, living universe that captured the enthusiasm of so many (including myself) at the outset of LT: a single player experience in which you are far from alone!
Personally, I walked away from the experience with a wonderful (and rare) sense of comfort -- comfort that the unspeakable hours put into solving FPLT ever since the fall of LTC++ have truly been worth the pain that they all-too-frequently caused.
The State of the Limit Theory, January 2018
At this point, we've essentially got all of our core support and modding systems working. Where there was once a wild-west of Lua trickery, there is now a solid set of production-ready, battle-tested systems. It's rather scary how quickly we're able to implement vast swaths of functionality now!
In the past two months, we've ported and improved AI architecture from LTC++, as well as re-implemented a vast list of features: escort/formation flying, dogfighting, AI squad management, ownership and asset tracking, flying mechanics such as energy capacitors and boosters, and more. We've also ported things from the old LTC++ code such as muzzle flashes, dust clouds, engine trails, explosions, planets, and atmospheres, along with a slew of other small features - some of which we didn't showcase during the demo, like a basic manufacturing component with blueprints.
There's lots more, but for full details, I'll refer you to the devlog subforum. I'd like to call attention to how much of this functionality is, at long last, gameplay-centric or at least gameplay-adjacent! This, my friends, is the shape of things to come :)
Procedural Assets on the Rise
On the ship generation front, Lindsey's progress is really starting to show: we've got a solid library of component shapes, deformations, and geometric operations like bevels, tessellations, and greebling. Even basic usage of this library is capable of creating quite complex and interesting outputs, as those who explored the ship generator in the PAX demo quickly found out!
Lindsey's posted many-a-devlog and many-a-gallery on the topic, so for comprehensive treatment of the subject I'll refer you specifically to her recent devlogs:
With all that PAX excitement behind us, we'll be spending the next week or two doing a mini postmortem and taking some time while we have it to deal with any blockers discovered during the demo sprint that affected our development efficiency. Lindsey, on her end, is looking to move on to capital ship algorithms.
I'm really looking forward to the next few weeks / months, as I think it's going to continue to be a lot of fun writing new gameplay, listening closely to see what the code is telling us about our architecture, and iterating until we're doing bigger and bigger things with less and less effort. PAX was truly a reinvigorating experience.
2018 is going to be a big year for Limit Theory. We can feel it in the air :) Thank you all for making it possible.
Hey there! How 'bout some space goodness to brighten up that Monday?
Yes? Well then, I've good news on the space goodness front: Octember was big. We're getting ever-nearer the event horizon of total-gameplay-focus, hastened by major improvements to supporting systems, and we've even picked up a new team member who's in the process of overhauling some of the procedural generation algorithms! I feel it's going to be an exciting recap :)
Promises "At Least 300% Reduction in Ship Boxiness!"
Sean's departure left a noticeable emptiness in the office. For a while, it's been home to only Adam and I in our quest to bring LT to life. The abandoned corner desk brought to mind warm memories of AI sandboxes and colony mechanics. While we can never hope to replace Sean's zeal for flow-field AI, I'm very pleased to announce that this desk has found a new occupant: Lindsey Reid, technical artist extraordinaire!
Lindsey is a hybrid programmer/artist who comes to us from a major AAA studio at which she worked as a software engineer (making her, indeed, the only one of us to have worked in 'the big leagues'). When she approached me with a desire to help craft better generation algorithms for stations and ships, it was hardly a difficult choice...especially in light of recent 'concerns' about the so-called 'boxiness' of certain PCG algorithms for which I may or may not be to blame :S
When it comes to working on procedural algos, Lindsey can do something I can't: she can build spaceships and stations on paper, generating them manually while simultaneously analyzing her own creative process and translating it into code. I, much to my chagrin, can only draw very simple, boxy ships on paper. Perhaps we have found the root of the aforementioned concerns... At any rate, I have always asserted that, when it comes to procedural algorithms, failing to produce great results is never the failure of proceduralism itself, but rather of the one doing it. Lindsey, having been with us for little more than a month, is already showing this to be true with the highly-interesting shapes stemming from her foundational work.
Personally, I'm overjoyed to have someone with artistic capability working on generation in LT. Proceduralism is such a major part of LT's aesthetic and feel; I'm glad it's getting the dedicated attention it deserves as I focus mine elsewhere. Lindsey has already posted two devlogs detailing her progress and thoughts, so do check them out if you're interested in meeting her and seeing some truly-otherworldly geometries!
AI Maneuvering & Handling High Volumes of Gameplay Logic
You've all heard plenty by now about entities, components, data, and so on. 'ECS' we called it. 'CTypes' we called it. In the end, we were left with the most powerful tool currently at our disposal for building game data. Yet, what of the other side of that coin? If data is on one side...function must surely be on the other. Logic. Code.
Over the past two months I've been working to build, test, and profile different mechanisms for handling 'gameplay logic' -- the bread-and-butter code that underlies everything from how a piece of ore gets transferred to a miner's cargo hold, to how a pilot aims a ship turret to hit a moving target, to how an AI player in a high position makes difficult choices about starting or stopping economic projects, to how a colony's economy produces and consumes goods, to...you get the picture. Everything that you would call 'true gameplay code.' In the same way that entity data requires something to make it work easily and performantly, so does all of this gameplay code require a supporting system to make it easy to hook and unhook vast numbers of bits of logic to/from loads of different entities in the game -- and to ensure that everything gets done quickly enough to maintain that silky-smooth 60+ FPS feel.
Truly, once this system is finalized, we will have blown away every last obstacle to jamming on the fun stuff :) Good news: we've already got a working prototype that has withstood quite some demanding stress-tests. I've written a non-trivial bit of AI maneuvering logic that uses the prototype script manager to keep track of and intelligently organize the way in which said logic runs when 10K+ ships are all trying to stay in formation with me. Thus far, the tests have been successful for both the underlying script manager as well as for the new AI maneuvering algorithm! As usual, many, many more details are available in the dev logs for those who find their interest piqued.
Dynamic Asteroids Confirmed Thanks to Faster Physics
Previously (as in, back in LTC++), guiding capital ships through asteroid fields wasn't just dangerous, it was a nearly-suicidal proposition. A carrier-sized ship hitting a static object 1000x smaller than it is an inherently-problematic scenario. Since an unmovable object has effectively-infinite mass, it can apply an effectively-infinite impulse to colliding objects. All of the kinetic energy of a hulking ship creeping through space can end up being reflected right back on it as kinetic damage at the hands of the tiniest fleck of unmovable space trash! Such was a limitation imposed by previous performance constraints.
Over the past month, I've implemented enough major optimizations in our physics engine to entirely remove those constraints. As a result, we can afford to make virtually everything dynamic (movable)! In particular, the contents of asteroid/ice/debris fields can be made dynamic without fear of your machine starting a fire! The gameplay implications are vast and certainly not yet fully-explored. But at least one immediate consequence is that battleship captains need no longer worry about voyaging through asteroid/ice/debris/cardamine fields. So long as they avoid the largest obstructions, the impulses from clearing smaller obstacles will be effortlessly negated by shields. Large ships will simply 'tunnel' their way through debris, pushing it aside. This is a very cool thing to see in action :)
I've done some fun stress-tests with the system by spawning 1000 NPC followers and zipping through large (~10K) asteroid fields at 60+ FPS! It's *really* cool to watch the formation as a whole either bump into (and subsequently compensate for) large obstacles, or clear smaller ones out of the way. With everything being movable and collidable at the same time, what would otherwise be a mundane scenario turns into an entertaining one!
I'll be keenly interested to see what opportunities this opens up in the future. For now, I look upon it as yet another system that's "ready to go" with respect to supporting LT at-scale.
On top of all that, Adam is in the midst of a major push to convert what started as a 'dev UI' into a full-featured system that we can use for game UIs, since performance seems to be holding steady. No doubt there's more to come on that front in the near future.
From a big-picture standpoint, each of us is sailing toward the same goal: architectural lock of everything that's not gameplay. It's a goal that's eluded me time and time again in my previous lonesome journey to the center of the Limit Theory. But now, with three brains homing in at the same time, well...I hope you all feel as I do that the progress speaks for itself :)
From now until the end, thank you all once more for making LT possible.
Happy Friday all ye (future) fellow explorers of the infinite!
In the last update, I spoke of super-fast new code for powering our game objects, the push toward release-quality code with Lil'T, and, of course, the dawn of the 'multi-programmer' era of LT development. I'm really pleased to be able to report back with great progress on all fronts over the past months.
At this point, we're working *almost* exclusively in Lua -- meaning we're dedicating nearly all of our time to game code rather than engine code. Exciting times, to be sure.
A great deal of effort over the past two months was put into setting up the scaffolding surrounding gameplay code, and, as a continuation of the work referenced in the last update, pressing further into 'real game code' territory, stepping back to see if the scaffolding held in place, and repeating.
Concretely, we began using our much-touted ECS (which, having come of age, now goes by the name 'CTypes') to create some basic game entities, run basic logic on said entities, and analyze the resulting LuaJIT output & performance to ensure that everything was behaving as expected (-- which is to say, blazingly-fast). CTypes is a really, really exciting system, because it allows us to use fast and size-efficient native C memory layouts (backed by custom allocators just to push it over-the-top!), while being able to write logic in Lua, all the while retaining the benefit of having it dynamically compile down to good-quality assembly thanks to LuaJIT and our architecture. Moreover, it's not just a toy anymore -- CTypes is battle-tested and has benched some really impressive numbers, notably, the ability to perform physics calculations on tens of thousands of asteroids at 60 FPS! I claimed last time that the performance problems inherent in a game like Limit Theory had been solved, and the tests are continuing to back me up on that! Speaking of physics...
Getting Physical with Newton
In implementing game logic, one of the most basic first steps is, of course, having objects that can move and respond to forces and torques. Newtonian dynamics. Previously (and I'll be honest here since it's now fixed...), physics has been fudged in LT pretty badly. Especially angular dynamics (torques, angular momentum, rotating objects). Thankfully, I finally took the time to learn the real math behind said dynamics, and our basic motion engine is running beautifully! We set up a sandbox where we could use the mouse to apply forces to asteroids, and proceeded to hurl massive rocks aimlessly across the stars.
Perhaps it's also worth mentioning that I made a very simple multiplayer version of that particular sandbox, so that we could all fight for control of the same asteroids, and we played it over LAN in the office. This served as a nice little test that the basic networking functionality I promised to include in LT (so as to make a 3rd-party multiplayer mod feasible) is indeed working, and such a thing is indeed feasible!
More Procedural Power
Way back in July, I set Adam to the task of studying distance field surface extraction techniques and finding out if there were any good, open-source implementations out there that would allow us to upgrade our distance-field-based mesh pipeline. I'm sure I could find at least a dozen mentions in past devlogs of 'what ifs' with respect to having a really good surface extraction algorithm, and how everything would be golden if we did. Thanks to Adam's work, it's no longer a 'what if' situation!
Adam succeeded in finding an open-source library that has the functionality we need, and also went through the struggle of figuring out how to build, test, use, and evaluate the quality of the code therein. He was able to show concrete timings and outputs that proved the library capable of performing adaptive, high-quality surface extraction with great speed. At the end of the day, it basically boils down to both a lot of dev time saved, a substantial performance gain, and way more flexibility for our PCG.
Here's a shot of a simple test CSG meshes, demonstrating how well the algorithm works (notice the really nice adaptivity!):
Although I haven't yet gotten around to taking another crack at the ship algorithm with this power in-hand, it's really only a matter of time!
Adam and the Magical BSP Trees
Several times over the past two months I've had to turn around and tell Adam that his BSPs are just grossly over-performant. In our current LT sandbox, we can click objects to select them, view data about them, orbit them with the camera, etc. Selection requires raycasting the scene, which, in turn, requires raycasts against the BSP trees that provide the acceleration structures for meshes. Currently, we're literally raycasting against every single asteroid / ship at once. Really, it shouldn't even work. It's disgustingly inefficient. It should outright melt the computer when you have thousands of complex objects in the scene. But it doesn't. In fact, the fps hit is so low on my machine that I forget how negligent I'm being.
Ultimately, what this means is that we'll probably be able to support like 10000000 million projectiles in the world at once. Or something like that. Basically, REALLY BIG BATTLES. 100 ships is going to be a cakewalk, apparently! We've already established that CTypes can handle massive data/logic throughput with ease, and now we've got these magical BSPs that can handle stupid numbers of queries per frame without batting an eye...yeah, I'm looking forward to seeing 'new LT' battles ._.
In August, Adam began spearheading the campaign to improve our debugging & development efficiency with an in-game developer UI. We decided that the real UI should be one of the last things we do (this was guided by the realization of how much time I've sunk into UI that later became useless when underlying game mechanics changed). Until then, though, we've got some nice, programmer-artsy widgets to see what's going on.
Nebula Algorithm v. N+1
I spent some time after-hours one night making the nebula generator roughly 10x faster while also improving the visual fidelity. I'm mentioning this because nebula generation was one of the most expensive parts of system generation (by quite a lot). It's now much more reasonable, especially on less-powerful GPUs. And more beautiful. Win-win-win.
I put some eye candy shots in an album for the end-of-August devlog. Nothing you haven't seen before, but as you can see I'm trying to be more proactive about pursuing the whole "we want screenshots, it can be of anything!" sentiment that seems to be the prevailing one.
Sadly, Friday, August 11th was Sean's final day here as an intern, as he's now off at college studying CS and no doubt becoming an unstoppable force of programming. We'll miss him for sure...his time here seemed way too short.
In the weeks before he left, Sean set up a combat sandbox that can run really fast combat simulations, provide us with information about the performance of different combat AIs, and rapidly simulate entire 'faction vs. faction' battles. At one point, Sean simulated a 100-faction battle with thousands of ships. It was entertaining but terribly slow since his sandbox isn't using our optimized engine as a backend.
In his final act of glory, Sean finished implementing a fully-generic, hierarchical, fleet-based AI maneuvering system, capable of representing fleets with any number of sub-fleets, and intelligently directing their motion. To demonstrate it, he showed us a group of several fleets flying together in a V formation, with each fleet comprised of squadrons in a V formation, each of which was comprised of fighters in a V formation...you get the idea! All of the math required to make it happen is rather difficult due to this arbitrary nesting requiring scale-invariance. Sean got it all hammered out and now we have proper, hierarchical fleets.
I'm really eager to get Sean's work integrated into the main LT project and have it run under our performance-crazed systems. I look forward to watching hundreds of ships fly in recursively-nested formations :D
In the latter part of August, Adam and I have cumulatively had more of those 'wooohoo!' excitement moments than I can remember having in the past year. It's undeniable. LT development is finally where it needs to be: on a rock-solid foundation and headed steadily toward the finish line. Of course, between here and there we've still got a lot of progress to see. But it's progress of a different nature -- a significantly more enjoyable one!
As always, but perhaps more now than ever, I look forward to the coming months and sharing the results thereof :)
Thank you all again for giving us the opportunity to build Limit Theory.
PS ~ Expect another double-rolled update in Octember (hey, remember from back in the day? That was a thing!) -- 2 months is turning out to be the natural KS update stride for our dev pace.