Share this project

Done

Share this project

Done
An RPG, RTS, and sandbox space exploration game all-in-one.  Explore, trade, build, and fight in a beautiful, procedural universe.
An RPG, RTS, and sandbox space exploration game all-in-one.  Explore, trade, build, and fight in a beautiful, procedural universe.
An RPG, RTS, and sandbox space exploration game all-in-one. Explore, trade, build, and fight in a beautiful, procedural universe.
5,449 backers pledged $187,865 to help bring this project to life.

Limit Theory Development Summary: February - April 2018

60 likes

Hey everyone!

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.

The LT Editor makes understanding and manipulating game content effortless
The LT Editor makes understanding and manipulating game content effortless
It's also a fair bit more inspiring than my usual code editor...
It's also a fair bit more inspiring than my usual code editor...

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.

Interesting structure (such as certain planets being trade hubs) arises naturally in systems thanks to smart AI and a dynamic economy
Interesting structure (such as certain planets being trade hubs) arises naturally in systems thanks to smart AI and a dynamic economy
Things continue to work even with as many as 50,000+ NPCs forging their own destinies in the same system!
Things continue to work even with as many as 50,000+ NPCs forging their own destinies in the same system!

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.

Trade routes are unnecessarily-long in this system due to four ice fields remaining undiscovered
Trade routes are unnecessarily-long in this system due to four ice fields remaining undiscovered
Upon discovery of the other fields, an entirely new economic equilibrium arises!
Upon discovery of the other fields, an entirely new economic equilibrium arises!

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, you actually matter!

Conclusion

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!

Oh, and Adam pumped out a (functional) command interface :D
Oh, and Adam pumped out a (functional) command interface :D

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!

Until next time,

~Josh

Limit Theory Development Summary: November 2017 - January 2018

64 likes

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:

  And a few shots from her galleries:

 

 

   

Onward and Upward!

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.

<3 The LT Team

Us @ PAX! Left ~ Lindsey; Middle ~ Josh; Right ~ Adam
Us @ PAX! Left ~ Lindsey; Middle ~ Josh; Right ~ Adam

 

Limit Theory Development Summary: September & October 2017

52 likes

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 :)

-------------------------------------------------------------------------------------------

Lindsey Joins The Team

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!

Related Logs:

Lindsey's Geometry Library in Action
Lindsey's Geometry Library in Action

 

 

Alien Geometry formed with Lindsey's Stellation & Extrusion Algorithms
Alien Geometry formed with Lindsey's Stellation & Extrusion Algorithms

 

Icosahedra now a part of the PCG Library
Icosahedra now a part of the PCG Library

 

You Shall Not Pass.
You Shall Not Pass.

 

 

 

------------------------------------------------------------------------------------------- 

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.

Related Logs:

1000-Fighter Loose Ball Formation -- Don't Mess With Us.
1000-Fighter Loose Ball Formation -- Don't Mess With Us.

 

Hoard vs. Asteroids
Hoard vs. Asteroids

 

 

 

-------------------------------------------------------------------------------------------

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.

Related Logs:

100K Dynamic Asteroids @ 45 FPS, Only 2% of Frame Time is Physics
100K Dynamic Asteroids @ 45 FPS, Only 2% of Frame Time is Physics

 

Contrived Example: Plowing a Hole Through an Asteroid Field with a Massive, Spherical Ship
Contrived Example: Plowing a Hole Through an Asteroid Field with a Massive, Spherical Ship

 


-------------------------------------------------------------------------------------------

Screenshot Galleries

Octember was unusually-abundant in screenshot galleries, so for those who aren't keen on diving into the logs but would still enjoy some visuals, have a look:

-------------------------------------------------------------------------------------------

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.

~ The LT Team

Limit Theory Development Summary: July & August 2017

54 likes

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. 

------------------------------------------------------------------------------------------- 

Building the 'Real Stuff' 

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! 

Kerrrrr...boom.
Kerrrrr...boom.

 

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 ._. 

 

DevUI 

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. 

Data Data Data Data Data ALL THE DATA Data Data Data
Data Data Data Data Data ALL THE DATA Data Data Data

 

 

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.

Limit Theory Devlog Gallery ~ August 31, 2017


  

 

 

Sean?? Seannn!!! 

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.

Simulated AI pilots...beating the bantha poodoo out of one-another!
Simulated AI pilots...beating the bantha poodoo out of one-another!

 

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. 

<3 LTeam 

 

 

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.

Limit Theory Development Summary: May & June 2017

46 likes

Hey everyone!

May and June were uniquely busy months for LT, with some major and unprecedented changes to development that I’m excited to reveal to those who haven’t kept up with the dev logs :) Unfortunately, since they’ve been so busy, I fell a bit behind on the KS updates and devlogs, but am here to rectify that at once!

---

May saw the biggest change to LT’s development since the beginning: the team of LT programmers tripled in size! Yes indeed, where once there was but a lone coder, now there are three. This came about through a series of exceptional little coincidences. I used to think it impossible that I would find other developers who would be both capable of contributing and willing to work with a ‘doing it for the love of it’ budget. Turns out I was wrong...allow me to introduce the new team members!

[ Adam ]

Early in May, a highly-talented game/engine programmer who also works in the Louisiana Tech Park walked into my office and subtly inquired about a job. You will all come to know him as the other guy on the team who gets excited about spatial partitioning schemes, memory layouts of component systems, and C without the ++. We did a trial run to test the waters with respect to whether it would work, and within a week it was basically a no-brainer. I made him an offer (thankfully, like me, Adam’s primary concern is not money), and he accepted.

[ Sean ]

Over the past school year, I taught a programming class for high-schoolers at LSU every Sunday. During that time, I encountered a senior with a talent for learning quickly and ‘just getting it.' His performance in the competitions in which we participated was so impressive that when the class came to an end in May, I had a chat with him about interning with me and working on Limit Theory. Since he’s got a particularly-keen interest in AI, it was...an easy sell ;)

Old Roadblocks Meet New Weapons

Now, as for what this super-sized development team has been up to! For the most part, Adam and I have been collaborating on engine-level features in an attempt to lock the code on which LT rests once and for all. When we first got LT running on his machine, I was a bit horrified with the performance. Granted, I’ve let optimization slip out of focus lately, and he's not running the most powerful machine ever. Still, coming off of two years of trying to solve ‘FPLT,’ it wasn’t exactly comforting. It was clear that we needed to rein in the Lua and bring more of the code over to C.

To that end, we revisited many of the old performance bottlenecks and collaborated on new solutions to them. Our work yielded more than a little success, including an industrial-strength ECS, new battle-tested physics acceleration structures, and a LOT of features pulled over from Lua to C that have resulted in significant speed gains. I’m particularly excited about the ECS. I know I’ve belabored that point in the past, and we’re all getting tired of hearing those letters. Here’s the great news: our new ECS design seems to be the nail in the coffin! It’s multiple orders of magnitude faster than I thought possible. It blew my expectations clear out of the water (some reference: 10K objects being created and deleted per frame is absolutely no problem; managing 100K component-based objects whose memory layouts are specified at run-time is no problem…! Can you say…massive battles??). Honestly, it wouldn’t have been possible without Adam, as having two brain iterating on architectural ideas was the only way it happened. Expanding the team has already paid major dividends.

Let me emphasize how much our work paid off by stating clearly: FPLT is solved. We have successfully obtained tremendous performance with very high numbers of dynamic, non-hard-coded entities whose logic is defined in a high-level, easy-to-write language. C & LuaJIT was the winning lottery ticket. It’s an incredible relief to me! I can write gameplay code with the assurance that it won't be thrown away later. Major LTdev obstacle down!

Fast BSP Raycasts. Maybe a Little Too Fast...
Fast BSP Raycasts. Maybe a Little Too Fast...

 

The Birth of Lil'T

With our success in the performance department, we set out on a new task: a mini LT -- or, as Adam ingeniously dubbed it -- "Lil'T." Our goal is to take all the work we've done up to this point and build a small LT out of it, the central idea being that we do everything the way we will do it for release, which means, theoretically, no throw-away code. We're using the actual ECS, the actual physics, the actual AI, the actual modding system, and so on, locking in code as we go to ensure that irrevocable progress toward release is accrued at a steady rate.

Sean's Supremely-Satisfying Secret (AI) Sandbox

As for Sean, I’ve been working with him to get his obviously-powerful brain thinking about and solving the AI problems that need solved. To allow him to do so as effectively as possible, I built a small visualization program that’s driven by Lua, allowing him (or any of us) to quickly see the results of Lua code when we don’t need complex rendering. Since starting, Sean has already covered a lot of territory: the high-level LOD simulation, colony dynamics, universe/system/planet generation dynamics (and their relationship to colonies), colony market dynamics, etc. With the birth of the visualization program, he has moved into ‘low-level’ AI code, working on algorithms for path-finding, obstacle avoidance, formation cohesion, and more.

Visualization of Sean's Flow Fields, Used in AI Maneuvering
Visualization of Sean's Flow Fields, Used in AI Maneuvering

 

 

 Real Team, Real Tools

It’s worth mentioning that LT's general organization and development ecosystem have seen total overhauls, since my old one-man-dev setup wasn’t tractable for more than one dev. We have real version control, better project management tools, milestones with dates, task allocation, analytics…you know, all that stuff that fancy folk use!

All three of us have done more in the past two months than I can possibly squeeze into a KS update, so do check out the dev logs if you want more (oh, and enjoy the shiny new forum upgrade while you’re there! Nathan aka Talvieno and I spent quite some time on that...)

Shiny New Forum Upgrade is Shiny!
Shiny New Forum Upgrade is Shiny!

 

Featured: Nathan's Full-Featured LT Feature List

As a final note, Nathan and I have collaborated on a feature list that gives a rough, line-item overview of LT 1.0’s feature status. I’d like to bring attention to one element in particular, since it’s the sole element on the list that was promised during the KS but is unlikely to ship at release: the OS X build. For the moment, I'm going to have to postpone an OS X port until after LT 1.0 releases on PC and Linux. Several factors drove the decision, but ultimately it came down to time consumption. The OS X build became by far the most cumbersome to support, up to the point that day-one Mac support no longer made sense. This doesn't mean that there won't be an OS X port at all, just that it will come later. (Day-one Linux support is still very much guaranteed.)

---

Sean and I both just finished volunteering at a three-week-long summer camp that teaches code to high-schoolers (it’s part of the same program through which I discovered Sean!) The reason for this update’s lateness is, in fact, the remarkable lack of time induced by having to prepare lessons and coding projects for the students. As of this morning, however, we’re both back in the office and pumping out LT code.

Thank you all for your patience in waiting for this update; I hope the news is as exciting to you all as it has been for me. Since July will be comparatively light on such news, I’m going to plan on rolling July and August together into one update as I did with June and July, after which we’ll resume the usual monthly schedule.

Thanks :)

~The LTeam

PS ~ Although not as visually exciting as usual, you can find a gallery of a few more screenshots of the physics and AI work here!

Gratuitous Cool Screenshot, Demonstrating that Adam is as OCD About Performance as I Am!
Gratuitous Cool Screenshot, Demonstrating that Adam is as OCD About Performance as I Am!