Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Vapourware Limit Theory - An Infinite, Procedural Space Game - DEAD

Executr

Cipher
Joined
Sep 24, 2014
Messages
303
Ok, so he's back on track. His absence is explained in the forums:
http://forums.ltheory.com/viewtopic.php?f=11&t=4492

Greetings beloved LT community

I'm both exceptionally pleased and...extraordinarily nervous to finally be returning to you after what must seem like ages to you all. For me, it seems more like a rather long, unpleasant dream. No doubt many, if not most of you, are pretty upset with my disappearance by now. Although I can't possibly take back or even completely explain away the 'dark months,' I really hope that shedding some light on it will help you all to understand why I've acted the way I have.

I've had a tremendous amount of difficulty figuring out how and when to tell this little story since the true cause of my disappearance was highly personal. Unfortunately, there's simply no way to explain the dark months without getting personal. It's been the most trying period of my life thus far, and to understand how I could turn my back on those whose opinions I value most, you've got to understand why. So what I've decided to do is to offer two tiers of explanation -- the first a TL;DR (with limited personal information), and the second a full-blown 'T.M.I.' that gets more personal. If the first is satisfactory to you, you needn't go on to the second.



TL;DR

In February I began having some rather serious mental health issues, likely brought on by the mounting stress and ever-escalating work habits of the previous weeks and months, as well as two years of an unhealthily-narrow lifestyle. These issues at first impaired, and then virtually destroyed my ability to do most things effectively (and with it my efficacy in building LT, although on most days I still attempted to make progress). Only after three months did I finally recognize that I required medical help -- that something was seriously wrong. After returning home to my family and being diagnosed & treated (for about 1 month now), I'm feeling much, much better -- about like I felt two years ago: inspired, creative, far less 'possessed,' far less tense about everything, and generally a lot more capable of moving forward with LT. The radio silence was due to the fact that, throughout this period, I felt totally unable to face the things that mattered most to me (LT), largely because I wasn't capable of performing at the same level that had come to be my norm.

You can read the longer version in the link posted above.
 

Drax

Arcane
Joined
Apr 6, 2013
Messages
10,986
Location
Silver City, Southern Lands
IT LIVES.
Good grief, this is good news, I was sincerely worried about this lovely freak.

Edit: Just read the longer version. Fuck YEAH this guy is still alive.
 
Last edited:

Executr

Cipher
Joined
Sep 24, 2014
Messages
303
After another 1,5 years of absence without any communication, he posted on the official forums, to say he's still working on the game.
In short, he explained in a long post (see spoiler) that he hit a wall in terms of the simulation performance and code management. It full of mumbo-jumbo programming stuff which might be of interest for those of you programmers out here.
Even if this post tries to ease some of the doubts, I think it's guaranteed we'll never see the game, or at least with all the features promised in the Kickstarter.

~ Introduction ~


  • First off, I've got to start by saying that this post is coming to you several months too late, but, as I'll discuss later, I'm taking serious steps to ensure that I change my communication habits. I'm sincerely sorry for not being on the forums for several months; I know, coming back and reading some of the intermittent posting, that it's taken a toll on many of you guys' outlook on the game. With this post, I aim to lift that outlook, but also to open up the hood and talk about why things are the way they are at the moment.

    Before we get down to it, a word about my previous updates and the community's response. If you're one of the many posters who has said something to this effect, know that I've heard you when you said "no more vagueness," "concrete details," "more than promises/empty words," etc. I got it, my previous updates were not satisfactory, but give me a chance to prove to you that I can, in fact, change
    icon_e_smile.gif
    On the other hand, a forewarning: to those who have demanded "pictures/videos or LT is kill," let me tell you up-front that you're going to be disappointed. I'll explain in detail why that's not what development is about right now, and this is the part where you all are going to have to meet me halfway in understanding that progress and pretty screenshots are NOT equivalent -- a mistake to which I've fallen prey for much of LT's development.

    The fact that development is not fun, pretty, or exciting (at least to most) is part of the very reason for which I haven't been excited to talk about it, and have even avoided doing so. For years I had beautiful things to throw up in the air and say "LOOK WOT I DID!" and receive praise for making things shiny. Man I miss those days so, so much...but the problems I'm dealing with currently are far more pressing to LT being released than more visual candy. I simply have to push through the problems I'm about to explain if you want LT to be finished. And I have every intention of LT being finished. There will be more pretties, more videos, etc., but let me be very clear: that won't happen before I get past the current roadblock.


~ Development: Where We've Been, Where We Are, Where We're Going ~


  • To understand why development has taken the bizarre course that it has, I must take you back all the way to just before the Dark Days, when the 'Road to the Beta' was in full-swing and Josh was burning his candle at 17 different ends. Things seemed to be moving quickly and beta seemed within reach. Then, all of the sudden, the Dark Days were upon us. What exactly happened, other than stress and an unhealthy lifestyle pushing me over the brink? What happened is that I was backed into a corner from which there was no easy escape. I had been backing into this corner for quite some time without realizing it.

    LT was, at that time, a massive codebase. Not massive in relation to how much it did, but still massive with respect to your average programming project. With both C++ and GLSL included, the code was pushing dangerously-close to 100,000 lines. Interestingly, 100K lines is a bit of a special number in programming. It's one of those rule-of-thumb things, but a large number of programmers, now including me, have found it to be roughly accurate: they say that a skilled programmer can manage about a hundred thousand lines of code. What do I mean by that? Think of it like RAM: your computer has a certain amount of RAM. When a program tries to use more memory than you have RAM, typically the program will still function via an OS mechanism called 'paging,' wherein hard drive space is used to effectively extend the limits of RAM. Problem is, doing so comes at a huge cost (less so with SSDs, but still a high cost): RAM accesses now may take orders of magnitude longer due to needing to page in/out memory from/to disk. Sure, your program will still run, but the moment you hit your RAM limit, a typical program will almost immediately incur a huge performance penalty. And so it is with programmers! Good programmers have a 'RAM' of about 100K lines of code. Beyond that, the difficulty of understanding and maintaining said code quickly becomes disproportionately hard, leading to a harsh dropoff in productivity.

    So, I was starting to approach the limits of my programmer RAM. My solution to this problem (as well as modding) was LTSL. LTSL made things gloriously easy to understand, and, for a while, made development gloriously fast in comparison to how C++ development had been. There was a brief period of time wherein I found myself basking in the sun and all was right with the LTverse. LTSL was making development a joy, I was able to keep everything in my mental RAM thanks to the compactness of the language...things were great. Until, one day, they weren't.

    You see, while I had successfully evaded one wall, another was sneaking up on me, and I would soon be caught between a rock and a hard place. LTSL, like all non-compiled scripting languages, was slow. Not terribly slow, but certainly slow in comparison to C++. This was the price I had to pay for offloading gameplay code to LTSL. I didn't anticipate that the price would be too much. On that point, I was quite wrong. It was a rather sudden thing, due to the nature of Limit Theory -- there's so much going on at all times...so many game entities, so many UI components, so much AI, so much physics, so much rendering -- speed degradation of only a small bit of code can cause a frightening FPS hit, since that code may be running every frame on every entity that, just for example, emits an EM signature that can be picked up via scanner. As I pushed into my beautiful new world of C++ & LTSL, I was also pushing closer to the invisible wall of performance problems, and then, one day, I hit it: FPS was down to ~20 even in situations where a relatively small amount was going on (i.e., even without LOD system simulations active, without distant AI, etc.) I knew I was in trouble, because I knew it was just the tip of the iceberg, and that performance was going to quickly go to hell in a handbasket if I continued using LTSL, my saving grace. On the other hand, my inability to mentally manage and make progress on a near-100K LOC codebase in C++ awaited me if I were to turn back. In either direction, I faced a sharp drop-off, either of productivity or performance. I was in a truly impossible situation, and for once, my Crazy-Solution-Generator-3000 failed me. Cornered and out of options, with a community expecting an imminent RTB post, my kernel crashed. And it crashed hard.

    Therein lies the rub, the truly monumental challenge at the heart of building LT (a challenge so formidable that I've given it the title of The Fundamental Problem of Limit Theory; FPLT for short): the completion of Limit Theory demands the utmost efficiency in both run-time performance (a la C++), AND development cost (a la LTSL). These two interests, as most programmers know, are in oppisition to one another in the world of development. In general you can have one, not both. But, you see, with an enormous amount of gameplay logic to crunch on an enormous number of entities, and only one programmer with one mental RAM bank on which to make that all happen, Limit Theory requires both. Voila, FPLT.


~ Solving the Fundamental Problem of Limit Theory ~


  • While I've worked on a lot of areas of LT over the past two years (since the Dark Days), >95% of my effort has been devoted to solving FPLT. This has made for a very, very frustrating two years as I've bashed my brain against the hardest problem of my programming career. I've explored numerous solutions. Each prospective solution requires a tremendous amount of effort to even get to a point where I have a simulation large enough to know whether or not said solution will be viable (i.e., I have to build a large-scale, component-based entity simulation with AI to know whether a solution is both compact and performant enough to be an answer to FPLT). So far, the answer has been 'no' to each. Despite all of my accumulated knowledge of code, performance, etc., it's still far too difficult for me to simply intuit whether the prospective solutions will be viable, hence why testing is the only option. It's been a slow, painful process of trial-and-error.

    I promised details, so let's talk about some of my concrete work over the past two years. I've seen posts implying that I haven't been working, and honestly, I can't let that rumor stand. I've been working entirely too hard to get no credit for it, so I'm finally ready and willing to pony up the gruesome details, even though it goes against my long tradition of feeding you all nothing but unicorns and cupcakes
    icon_e_smile.gif
    So here it is...the good, the bad, and of course, the ugly. Put your gloves on.

    First, naturally, there was an attempt to rescue the existing LT by amping up LTSL with a performance overhaul. A practical move at the time. It was a relatively fast failure. I optimized, I changed the way LTSL runs, I molded the memory access patterns from 'my RAM is crying' to 'it could run on punch cards!' Still, I could see that the numbers weren't going up. The gulch between the statically-compiled and intensely-optimized C++ and the runtime-compiled LTSL evaluation engine was too wide to make a dent. Despite my efforts, I'm a bit embarassed to admit that I wasn't ever able to improve LTSL's performance dramatically over baseline, even after blasting it with some of my best optimization cannons.

    With the most practical option shot down, I switched attack vectors and tried what seemed to me the next most practical: splitting the C++ into smaller bits to make it more manageable. I split up what was a 'monolithic' engine, compiled all into one library, into component pieces compiled into different libraries (libltcore, libltrender, libltui, libltai, etc.); this was an attempt to increase both runtime efficiency and my ability to keep all code in RAM. This attempt, luckily, only cost me a few months, as I quickly learned that code is code, and the programmer RAM limit applies no matter how you divvy up the lines. Another solution shot down, another lesson learned.

    I then moved on to a more dramatic change, recognizing that, clearly, the C++ core was simply too big. I was going to have to reduce. Thus ensued one of the most dramatic shifts in LT's development history, as I carefully plucked pieces from the existing codebase and brought them over to a new, 'minimal' C core library. The general idea was to do the really performance-critical stuff in C, do the rest in a still-fast but high-level language (side note: I say C because, by this point in my programming life, I had basically abandoned most C++ constructs, so moving completely to C was not a big issue -- C libraries are friendlier when it comes to linking with the outside world, which is what I was planning to do with respect to the high-level language). My language of choice? Python. It took quite some time, but I eventually engineered the salvaged 'minimal' core of LT, which was a very reasonable 20K lines, along with a cluster of (concise and easy-to-write) Python scripts that could leverage the LT core library for all of the performance-critical and gpu-related stuff. It was quite beautiful. Of course, I knew what I was getting in to: Python is slow. On the surface, it might not look too different from the old LTSL solution. But, unlike LTSL, Python has a massive ecosystem surrounding it. For performance, there's pypy, Cython, Psyco, Pyrex, etc. Much to my chagrin, none of them suited my needs (pypy looked promising, but simply didn't give a big enough speed boost). So I pursued a custom JITing solution. I wrote an intermediate-representation, an AST translator that took Python code to my IR, and an emitter that took my IR to C, which could them be JIT compiled in-memory and executed as machine code by the wonderful TCC. It was a beastly feat of code. In the end, it broke my heart when this solution also failed, not due to performance reasons, but because, as it turns out, compiling Python to a static language (or an IR intended for emission to static language) is indeed near-impossible. Too difficult for me, at least. My JIT worked for simple and moderately-complex logic, but it simply couldn't handle the 'meaty' gameplay logic of LT, as the problem of type inference and other fun things started to become intractable.

    On the bright side, not all was lost with the valiant Python attempt. I did lose quite some time (perhaps on the order of six months) to it. From it, however, I had gained the minimal core onto which I have continued to build (with minimalism!) to this day. The C core will be part of the solution to FPLT. I now have that piece of the puzzle. For the other piece, the 'driver' that will control the core, I'm still searching.

    That brings us up to the present. At this time, my current attack vector is twofold.

    I've been building a solution involving LuaJIT for several months now and am nearing the point where I can do a feasibility test. While I've learned to temper my expectations and wouldn't say that I'm confident that LuaJIT will be the answer, I can say that it's by far the fastest scripting solution I've found. My initial tests, indeed, the only reason I began pursuing a solution in Lua (which wasn't really on my radar), demonstrated that LJ achieves incredible speeds on limited-scope performance tests, even nearing the speed of my own, hand-written C. That's not terribly surprising, since LJ is a genuine JIT, meaning that it's effectively turning Lua into assembly/machine code. It seems to be darn good at doing so. That being said, we'll see how it goes with a full-blown test. I have my reservations about Lua being garbage collected, and I fear that memory access, if anything, may make LJ infeasible. Nonetheless, LJ itself is a formidable feat of engineering, and even if it doesn't end up solving the second piece of the FPLT puzzle, I have a feeling it may still contribute somehow to the final answer (this has happened with so many other 'failed' ideas throughout the course of LT that these days, I almost expect a failed attempt to end up being useful in some way in the future).

    On the other front, I've been building a solution that involves generating C++ via a meta-language based on Python. This would provide a means of performing a lot more of the game logic in ultra-fast compiled code without me having to write 100K lines. In order to get LT working in as few lines as I did previously, I had to use a HUGE amount of complex C++ trickery. While it meant far fewer lines to keep up with, it also made the code more complicated and, in a few cases, sub-optimal in terms of performance. With a meta-language, we can easily solve these problems: I don't care how much code is generated, I only care how much I have to write to generate it. So, for example, whereas setting up the component-based entities in the old C++ engine took several layers of advanced C++, making the component logic hard to understand (boy was this a nightmare with the 'market' component...), I can generate equivalent code in far fewer lines of simple Python. As a bonus, the generated code compiles and runs faster because it's not having to use trickery to reduce code size...I can get Python to spit out tens of thousands of lines in milliseconds, based on ~100 lines of my meta-language. This solution is only a few weeks old, and is sort of a 'nuclear' option in the event that the LuaJIT solution doesn't work out. I'm fairly sure that I can get this approach to work, because it's kind of brute-force. I'd rather be able to find a more elegant way, but if this is what it comes down to, so be it...above all else, I just want to get Limit Theory released at this point, and I'm willing to use whatever I have to use to get there. (By the way, this is totally differenet from the other solution involving Python. Whereas the idea there was to convert Python to machine code on-the-fly, the idea here is simply to use Python as an easier way to write / automate the writing of C++. Kind of like...writing the code...procedurally!)

    So there you have it...the past two years of my life. Has it been shiny? No. Has it been as exciting as the first two years of LT dev? No. But the hard truth is that Limit Theory is an exceptionally-ambitious project, especially considering that we can't just brute force the development with a massive team and all the standard big-budget amenities. Yes, I was young and optimistic when I called it 'easy.' My mistake
    icon_e_confused.gif
    LT is a hard problem. At the center of it all lies FPLT, which encapsulates the problem of needing to build something complex with minimal resources. It's a solveable problem; of this I'm certain. The solution? No, of this I'm not yet certain, but, as I hope to have demonstrated by laying all of my attempts out on the table in detail, I really am attacking it with everything I've got. I can't sugarcoat this situation as I've tried to do in the past, because it just leads to disappointment, so let me be perfectly honest: I don't know when I'll overcome FPLT. I sure as hell hope that it's soon, because two years is already an exceptionally-long time to be beating one's head against the same problem. What I do know is that every failure gets me closer. I learn more about what works and (perhaps mostly..) what doesn't with respect to performance in large-scale simulations. I learn more about low-level performance both of static and dynamic langauges, which helps me to evaluate future solutions. I become adept with more languages, more technologies, hence have an ever-expanding arsenal with which to blast away at development problems (FPLT can only take so much DPS before it breaks. It's a tough tank, but every month my DPS output goes up. It's only a matter of time...) In the mean time, I continue to develop the LT core C library as much as possible to ensure that when I do come to the right solution, all of the underlying machinery is in place for me to quickly and easily plop the existing LT functionality into the mold of said solution.

    Is anyone still listening?
    icon_shifty.gif
    icon_ghost.gif


~ Re-Establishing Communication with the LTVerse ~


  • Clearly, something needs to be done about my communication habits. Here's the good news: a large part of what's been causing me to not want to communicate with you all is, as mentioned above, the rather unglamorous nature of my work. I wanted to come back to you guys with guns blazing, yelling "YESSS LOOK AT THIS! AND THIS!! AND BETA IS COMING UP!" But I'm ready to accept that I can't work that way anymore. Showman Josh and Perfectionist Josh are mostly dead at this point, and I think you'll all be pleased to hear that Pragmatic Josh is now in full effect. At this point, my mentality on any given day is 'find the shortest path between where I am and LT being released. Follow it.'

    So from this point forward, I will plan to use my Sunday evenings to write a dev log -- however brief, unglamorous, or unexciting it may be -- to inform you all of my work over the past week. I'm not yet sure whether I want to do this every week or every other week, so I'll have to start with it and just go with what feels best.

    Again, I'm trying very hard to not make the same mistakes that I've been making with communication and end up disappointing you guys. To that end, I'm promising a regular but modest communication, something that will ensure you all that I'm still working to get LT in your hands without requiring as much of my time and effort as the daily dev logs, the monthly videos, RTB, etc. With FPLT I'm taking battleship-sized steps, but with communication we need to start back with fighter-sized steps
    icon_e_smile.gif


    (Oh, and yes, this does count for my first log...I'm not going to post more of my life story today
    icon_razz.gif
    )

Source: http://forums.ltheory.com/viewtopic.php?f=11&t=5659
 

Perkel

Arcane
Joined
Mar 28, 2014
Messages
15,804
Holy shit. That dude is fucking wizard with code.

Though i don't understand why he didn't went for python ==> machine code conversion instead of python ==> C++
I guess it would take more time since he would need to write his own libraries for assembly.
 

Bumvelcrow

Somewhat interesting
Patron
Dumbfuck
Joined
Nov 17, 2012
Messages
1,867,060
Location
Over the hills and far away
Codex 2013 Codex 2014 Make the Codex Great Again! Strap Yourselves In
Having read all that there are so many warning signs. Perfectionist, unwilling to share responsibility, unwilling to open himself up to (constructive) criticism, fear of negative feedback. I think I backed this game - it's so long ago it's hard to remember. But all those personality traits are poison for software development, and indeed any kind of teamworking. The fact that he's not even trying to follow what other people have been doing suggests he has a long learning curve ahead or a future working as a one-man team like Vogel or Cleve.

The posters on the forums are the usual collection of cheerleaders and apologists, with the odd pragmatic and difficult-to-hear comment thrown in. The game looks mired in development hell of the worst kind. Best thing he could do from a personal point of view is open source it and move on.
 

Bumvelcrow

Somewhat interesting
Patron
Dumbfuck
Joined
Nov 17, 2012
Messages
1,867,060
Location
Over the hills and far away
Codex 2013 Codex 2014 Make the Codex Great Again! Strap Yourselves In
Holy shit. That dude is fucking wizard with code.

Though i don't understand why he didn't went for python ==> machine code conversion instead of python ==> C++
I guess it would take more time since he would need to write his own libraries for assembly.

Common programming mistake (that I've also been guilty of until I learned my lesson) that most difficult method == best method.
 

Blaine

Cis-Het Oppressor
Patron
Joined
Oct 6, 2012
Messages
1,874,662
Location
Roanoke, VA
Grab the Codex by the pussy
I agree the guy is a wizard, and also that the game might never materialize.

Either way, I don't regret my decision to donate money to the game's development. It's better to take risks, lose sometimes, and occasionally win than to take no risks at all.

I've been saying it for the more than four years I've been posting here: Part of the reason old-school gamers have very little say in the industry is that we're notoriously stingy. It better be $10 on a Steam sale and the next coming of Fallout, or else! Meanwhile, the kiddos (and their parents) shower money on console developers.
 

DramaticPopcorn

Guest
Actually loling so hard right now at the fact that Blaine started this thread about yet another crowdfunded failed space sim, maybe he's the problem?
 

Bumvelcrow

Somewhat interesting
Patron
Dumbfuck
Joined
Nov 17, 2012
Messages
1,867,060
Location
Over the hills and far away
Codex 2013 Codex 2014 Make the Codex Great Again! Strap Yourselves In
The guy's pretty cool, not only he's a code-wizard, he's quite open and didactic about the game's development.

What? He spent two years totally out of contact, and was sporadic before that after an initial burst of enthusiasm. He comes across as somebody who is a great programmer but hopeless at planning and organisation.
 

Drax

Arcane
Joined
Apr 6, 2013
Messages
10,986
Location
Silver City, Southern Lands
The guy's pretty cool, not only he's a code-wizard, he's quite open and didactic about the game's development.

What? He spent two years totally out of contact, and was sporadic before that after an initial burst of enthusiasm. He comes across as somebody who is a great programmer but hopeless at planning and organisation.
He had an actual medical problem and a mental breakdown, I forgot to add that part, that's why I don't go too hard on the guy.
 

Bumvelcrow

Somewhat interesting
Patron
Dumbfuck
Joined
Nov 17, 2012
Messages
1,867,060
Location
Over the hills and far away
Codex 2013 Codex 2014 Make the Codex Great Again! Strap Yourselves In
He had an actual medical problem and a mental breakdown, I forgot to add that part, that's why I don't go too hard on the guy.

Yeah, I'm aware of that. But, without trying to sound too unsympathetic, he's been avoiding his customers because he's got it into his head that he's scared to disappoint them, and silence is better than truth. He desperately needs somebody to hold his hand through all this but he's determined to go it alone. He's been very open about his personal issues, but when it comes to the game he dives into technical details and avoids the harder issues.
 

Perkel

Arcane
Joined
Mar 28, 2014
Messages
15,804
Well his 1st year was like fucking lighting.
Just watch his updates where he every month accomplishes something big.
 

J1M

Arcane
Joined
May 14, 2008
Messages
14,616
Seems clear this guy would make a solid programming hire, but I wouldn't put him in charge of a project.

From his description he has made a few oversights:

1) At some point in questioning his basic approach he should have reconsidered if a component-entity model was the right choice. I know this has been used in MMOs and was in-vogue when he started, but that doesn't make the it the best choice for every project.

2) If he really does recalculate his simulation every frame that is a massive blunder. This is game-dev 101: you split the rendering loop from the game logic.

3) In a simulation like this there is no need to recompute everything at the same frequency. For example, the prices of a good at a space station don't need to be recalculated 60 times a second. Remote sensors would do fine at an interval of one second. It doesn't matter how optimized he makes his code if adding an entity on the other side of the universe creates a linear framerate hit.
 
Joined
May 5, 2014
Messages
1,677
Jul 25 2017

Limit Theory Development Summary: May & June 2017

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


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





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!


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!
 

Infinitron

I post news
Staff Member
Joined
Jan 28, 2011
Messages
97,228
Codex Year of the Donut Serpent in the Staglands Dead State Divinity: Original Sin Project: Eternity Torment: Tides of Numenera Wasteland 2 Shadorwun: Hong Kong Divinity: Original Sin 2 A Beautifully Desolate Campaign Pillars of Eternity 2: Deadfire Pathfinder: Kingmaker Pathfinder: Wrath I'm very into cock and ball torture I helped put crap in Monomyth
:dead:

https://www.kickstarter.com/project...-infinite-procedural-space-game/posts/2270873

The End

It is with a heart of lead that I write this announcement. Not in my darkest nightmares did I expect this day to ever come, but circumstances have reached a point that even my endless optimism can no longer rectify. I can not finish Limit Theory.

After six years, I am finally at the end of my means. Financially, I am beyond the initial investment and have exhausted most of my personal savings. But significantly more troubling is that I am entirely out of energy -- emotionally, mentally, even physically. Every year that passes sees me becoming more desperate to make good on the dream with which you all entrusted me, but each such year I grow less and less capable of doing so as my mindset falls further away from that bright, beautiful hope that powered me from the beginning. I am not what I once was.

Despite what felt like an incredible amount of progress in the last year alone, Limit Theory remains frighteningly far from feature completion. It is my own fault, for having underestimated at every turn the amount of work that goes into such a creation. It is my own fault, for having overestimated my own cognitive resilience and for believing that no number of setbacks would ever inhibit my ability to bring a passion project to life.

I don't know how to make this right. For years now, I've been running on pure loyalty to you all -- it has been quite a long time, if I'm honest, since I was actually working from a place of inspiration -- yet even with the purest of intentions and the deepest desire to honor my commitment, I find myself unable to bring about miracles. No matter how hard I try, it's not enough to bring LT to fruition, and this pattern of failure has evicted all self-confidence and hope from my mind, leaving only doubt, anxiety, and despair. Some days I think to myself "how absurd that a game should make me feel this way," and I realize just how unfit I have become to build a source of joy. I wanted so, so badly to make you all proud. To bring you all joy. There are no words to properly convey how sorry I am that I have failed you all.

I imagine I could go on and on with this gushing of negativity -- the years have left me with no shortage of it. But I don't think much good will come of it. Those of you who have followed the project closely, you already know how much I have put into it; how I have given 110% of myself. Trying isn't the same as doing, so I don't expect any thanks for it, but I hope you all do know just how hard I've tried. I've simply got nothing more to give.

So, what now?

Well, I will prepare the source code for release. It's not a working game, and in my frenzy to get things working I've left huge swaths of code in a half-refactored or half-complete state. But releasing it is the least I can do. I don't imagine it will be of any use to anyone, other than as a monument to a failed dream. Perhaps those who are interested in game engines will glean a thing or two from the engine, as it is a fairly solid piece of engineering, much more solid than the Lua game code.

For the moment, though, I wanted to get this off my chest as soon as possible. It has been the most painful, difficult decision of my life, and I'm sure that there will be no shortage of blowback. But I simply cannot continue to destroy myself in search of a feat of which I am not capable. When I began this project, I felt that anything was possible. Here now, at the end, I must swallow the painful reality that: I, too, am human. I am limited by time, I am limited by finances, and I am limited by mental & emotional stamina.

One last time, I would like to thank everyone who contributed. From the bottom of my heart, thank you for believing in Limit Theory. Thank you for giving me the opportunity to try for something wonderful. One last time, I am so sincerely sorry for having let you down. I hope, at the very least, that some of you have enjoyed the ride as I've pitted my brain over the years against one challenge after the next.

I'll be in touch when I have readied the source code for release.

~Josh
 

Curratum

Guest
It's been obvious for years, is all I'm saying.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom