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

Limit Theory Development Summary: March 2017

73 likes

Happy early Saturday to all!

Seemed like last month's format worked out well for you guys, so we've kept the same format this month.  Except that we have eye candy this time :)

---

'Twas a long month. So much happened that it's hard to remember everything, but that's definitely better than the alternative. This month was all about big pushes toward the completion of big systems: assets, entities, and the physics engine. Major progress was made on all fronts.

I said last month that I'd be a happy camper if I had my primary assets 100% back, and I'm pleased to announce that I am indeed a happy camper! All my old mesh tech is back and accessible from Lua. Some of it even got upgraded; BoxMeshes (previously PlateMeshes) can take on cylindrical and other anisotropic shapes that weren’t possible previously, lending more power to ship & station algorithms. With all of this functionality re-packed into the LT Core library, I’ve ported the PCG algorithms for asteroids, planets, ships and stations. Seeing the ship and station algorithms again reminds me that I still need to put more time into them, but it was still glorious to have my assets back!

Oh how I missed you, bizarre procedural ships!
Oh how I missed you, bizarre procedural ships!

 

I uploaded a full gallery of screenshots for that week, so have a look:

Limit Theory Devlog Gallery ~ March 8, 2017

Sadly, while trying to delve into some gameplay programming in Lua, I ran into the same old problem...you guessed it: performance. Turns out I underestimated how badly LuaJIT has been hurting me (that is, in comparison to native C or C++ code). It became more evident once I had my assets back and was trying to push gameplay logic into fully-populated systems. Achieving the classic LT silky-smooth 60FPS was quickly becoming an uphill battle.

After much thought, a cascade of obvious insights befell me.  Moving some of the entity logic into C wouldn’t be the end of the world; some things modders will never need to touch. That line of thinking led me to more critical realizations: bottlenecks are always in the computations that happen every frame (especially if the computations happen across a large number of objects). Motion calculations and physics in general are obvious culprits. In fact, I realized that the most expensive, frequent computations are in the low-level logic...much of which need not be accessible in Lua. Most gameplay logic is far higher-level and need not run every frame. I knew this previously -- that costly code should be moved into C -- but never realized how well it could be done without hampering the ability to write gameplay quickly and elegantly in script. To make the high-level logic as fast as possible, I’m now working on an ultra-fast, event-driven entity system that will ensure per-frame processing is cut to the bare minimum.

Running performance tests for the first time even with only some of the above implemented shocked me. Moving low-level entity logic into C yielded absurd gains over Lua, but, perhaps even more surprising, it yielded gains over the old C++ engine. This I can only attribute to the fact that I've done a better job of structuring my entity code for performance! Suffice it to say, as of this month, I am completely convinced that our performance problems can be overcome with the right mixture of C and LuaJIT. 50K moving asteroids will back me up on that:

Spool up the FTL...something has gone seriously wrong in this system....
Spool up the FTL...something has gone seriously wrong in this system....

 

Once more, I couldn't resist and uploaded another full gallery of eye-candy for the week's work.

Limit Theory Devlog Gallery ~ March 17, 2017

 

Physics (collision detection, in particular) was the secondary focus of the month’s work. LT’s collision detection used to break down quite badly in cases that are traditionally ‘difficult’...unfortunately, with the scale of entities in LT, such cases are not at all infrequent. A complex ship navigating in close proximity to a complex station that’s 1000x larger in scale is, for example, a difficult case that occurs all the time. With several new collision detection structures implemented in the core this month, I’m well on my way to obliterating this bottleneck. Initial tests are showing great performance, although I've yet to finish the whole system. No big gallery for this work, but a little gratuitous ocular edification:

My God, it's full of...boxes!
My God, it's full of...boxes!

 

Toward the end of the month, I began implementing a full-blown entity component system (ECS) in the C core. The ECS is 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-view of the would-be LT modder (as well as Gameplay Josh), it's the most important part of the engine. I'm excited to see where this work takes me, since I believe that the new ECS along with an event system is going to simplify gameplay constructs dramatically, while providing superior performance to anything we saw in previous incarnations of LT!

On a side note, I got an opportunity this month to exhibit LT in New Orleans at the 'New Orleans Entrepreneurship Week' event. Since it was less amenable to interaction than previous events, I wrote a quick 'cinematic camera' that flies around a system, smoothly moving and panning while hunting for interesting things to look at. My demo was, essentially, 'Limit Theory Screensaver' :P It was quite lovely and I got very positive feedback. One guy even mentioned that he used to love playing Freelancer, and was excited because LT looked like a modern version of it. Naturally this made my day :) I made yet another gallery for the event, although this one is smaller and has less variety since not much was different, content-wise:

LT @ New Orleans Entrepreneurship Weekend, 2017

---

Big thanks to Nathan for managing to summarize what apparently added up to 7K words worth of devlog this month! Remember to hop on over to the forums if you're up for digging into the details, and be sure to check out the three screenshot galleries linked above!

I don’t think I can stress how big of a month it’s been for cold, hard progress. I’ve got assets back, I’m well on the way to defeating the performance issues that ended up killing the old LT, and, most importantly, I've got my eye on the gameplay ball. April should prove to be very interesting indeed.

Thank you all for caring :)

~Josh & Nathan