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: November 2017 - January 2018

63 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!

 

Limit Theory Development Summary: April 2017

39 likes

I was hoping to post this on May 4th (...surely you know this reference if you're excited for LT!), sadly it didn't come to pass. But...May the 9th be with you??

This month was full of progress in, shall we say, a diverse set of areas. Nathan aka Talvieno (our Community Manager who writes these summaries; I believe some people were confused about that last month) put it like this in his email to me: "[The summary] took me a while to pare down because, honestly, you were EVERYWHERE this month." Heh. He's not wrong!

From the architecture of core systems underlying gameplay to ship generating algorithms to a teensy bit of graphics work to factions and their implementation...it would be rather hard to identify a central theme for the month other than "get this thing done." I'm OK with that!

---

You may remember the ECS (Entity Component System) I was working on at the end of last month. As a quick refresher, it’s the part of the engine that controls how the data that underpins objects like ships, stations, colonies, asteroids, etc. is defined, managed, and altered over time in response to gameplay. From the point of gameplay, it’s the most important part of the engine. For half of the month, I gave myself 'full permission to do nothing but ECS work.' And boy did I take that permission and run with it.

After MANY hours of banging my head against the problem, I made what I consider to be a very practical decision: I said 'screw it; I'll design for the rule, not the exception.' I'm sure someone has said that before, but now I'm saying it again. I banged out an ECS that covers the majority and gave myself permission to worry about the rest later. CPU-heavy information lives in C, and the components live in Lua, since I decided that these are, in the 90% of cases, lightweight enough to be handled by Lua without issue. And so it will be until something starts causing major issues. I'm more than ready to put this kind of infrastructure work to bed and build game.

The ECS work, despite being a pain, did bring about several big new advancements outside of just entities. One was the implementation of the 'RenderQueue,' an engine-level construct (that I've never had in previous versions of the LT engine) that allows me to encode graphics operations as objects that can later be submitted to the fast part of the engine to be executed at blistering speeds. The upshot is that we can define how to render certain objects, or even special effects, in Lua, but not have to pay the cost of actually executing them in Lua. This is exactly the best-of-both-worlds type situation for which I'm always hunting: being able to build and iterate quickly in Lua, while maintaining high performance by putting the C engine to work.

Another product of the ECS work was a mod loader along with a preliminary mod format. I'm actually using this for prototyping new gameplay systems. Writing gameplay as 'mods' means that I can easily plug and unplug them as needed while I develop. It also means that I'm breaking in the modding system, so it'll be well-worn before you guys get your hands on it! The current mod format is a lot like a 'data description,' which makes things clean and easy to reason about (without any sacrifice in flexibility). Lua is a beautiful language for describing data. Making LT modding easy and powerful has been a big goal of mine for a long time, and it's looking like I'll achieve that goal (and without the game-breaking performance penalty of the old Limit Theory Scripting Language).

After weeks of waging the ECS war, I needed a break, so I gave a few days to Graphics Josh. I implemented the 'blind-you-with-all-the-things' style of HDR bloom that seems so characteristic of high-end engines these days. It looks impressive, but if I use it in LT I'll be sure to turn it down...a lot :P I also ported some of the physically-based rendering code back from LTC++, including GGX environment map generation (with faster and more accurate math, which means that everything looks...just a bit better). I also brought back the per-system, procedurally-generated color grading. Nice boost in shininess; but I must reiterate for the sake of those who would be concerned: I was working on graphics purely as a break from more important things...as I've expressed before, I'm done putting a lot of time into the graphics, which are perfectly-suitable for release in my opinion!

Speaking of graphics, I did put together a small album of shots from this month for your ocular pleasure. Have at it!

Limit Theory Devlog Gallery ~ May 5, 2017 

Color Grading & Atmospheric Scattering make a lovely combination
Color Grading & Atmospheric Scattering make a lovely combination

 

Really like the colors in this system...algorithms did a good job!
Really like the colors in this system...algorithms did a good job!

 

Toward the end of the month, I gave another public LT demo at an LSU game industry event. Like the rest of the events I've attended, it gave me a fantastic excuse to get some fun things pumped out quickly! Annoyed by how similar all my ships look currently, I sketched out a basic 'fighter' generating algorithm. Although simple, it's an important step in the generating algorithms: it's the first to use sub-generators for coherence. As I move toward more coherent ship generation, I expect more and more of my generating will be factored out into 'component' sub-generators. Cargo bay generator. Engine generator. Cockpit generator. Solar panel array generator (station). This has always been the plan, it's just the first time I'm actually working on it (and the first time I've worked on ship algorithms in...a long time)!

I'm not the sexiest fighter ever, but I'm clearly a fighter >:3
I'm not the sexiest fighter ever, but I'm clearly a fighter >:3

 

If you checked the album above, you may have noticed beam weapons - something that's been missing from LT for a long time. Finally having a nice visual distinction between capital ships and fighters for the demo, I wanted capital ships to be more fearsome, so I banged out some beam weapon code and a new shader. It turned out nicely :) The initial balancing, though was…quite poor. It was NOT a fun time to be a fighter pilot, despite your fancy new fighter ship design...partly because I forgot to put a range cap on the beams.  Whoops...

"The Red Beam of Doom"
"The Red Beam of Doom"

 

A fitting system color for capital ships blowing everything to pieces...
A fitting system color for capital ships blowing everything to pieces...

 

In addition to all this, I implemented factions so that I could start working on some more interesting gameplay in the new engine. Factions are first-class objects now and, thus far, have unique ship designs, their own credit accounts, a tech level and more. NPC AI now (more) intelligently selects enemy targets based on various factors. Combat AI was split up into several distinct sections and generally improved.

Finally, we've upgraded the website! This one was actually all Nathan, to whom I gave the task of 'modernizing' the LT homepage a bit, by replacing the pictures with more recent ones. He did that and much more. As usual, Nathan has gone above and beyond :) Check out our new homepage! (Force refresh with Ctrl-F5 or Shift-F5 if you don't see the changes. We're still working on caching issues.)

---

Another month, another step closer to release. Work is getting more and more oriented toward Limit Theory the game rather than Limit Theory the engine, a result of my painful journey toward pragmatism. For that reason, I'm keenly interested to see what May's development has in store for us!

Reminders: don't forget to check out the screenshot gallery, check out Nathan's redesign of LTheory.com, and, for the brave among you, check out the full dev logs.

As usual, thank you all for joining me on this journey toward the completion of a beautiful, living, procedural universe.

~Josh & Nathan