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: May & June 2017

44 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

Limit Theory Development Summary: February 2017

75 likes

Hey everyone!

Since the response to 'how should I handle KS updates?' from the last one was overwhelmingly in favor of monthly summaries of my weekly development logs, that's what we're going with. Here's the first one. I'd like to note that this summary was actually compiled from my logs by the new Limit Theory Community Manager, Nathan (known as 'Talvieno' around the forums). You can read more about that exciting development below!

---

In the first half of February, I explored the performance characteristics, and, ultimately, the feasibility of the current LuaJIT solution. LuaJIT has been a roller coaster of emotions for me. At first, I was cautiously hoping it would be the solution, and became very hopeful when I saw that it ran more efficiently than any other solution I've tried... only to become extremely worried whether it would actually be performant enough in the long run. This caused me to look into other related solutions (which didn't work out so well!). Fortunately, I didn't give up there. I continued to put some more work into it using LuaJIT's built-in profiler, which was helpful in weeding out the worst areas of performance. At the end of it all, my heavy-duty laptop was able to run a 1000-ship battle at 60fps. Remember, of course, that not all of the logic is implemented, so this isn't representative of what you'll be able to do in LT. The goal for me has always been to allow ~100-ship-battles at decent framerates, and at this rate, I believe we'll be able to do that.

What I've seen has allowed 'Practical Josh' to conclude that we will be able to (tentatively) proceed with LuaJIT. This is also taking into consideration that, if things start to get too heavy, I'll likely be able to make enough little scale cuts here and there to push out a still-high-quality LT 1.0. I'm keeping practicality in mind and am open to, for example, having to slightly lower the scale of system economies or out-of-system simulations, etc, if it means the difference between 60 and 10 fps. I'm also devoting some relatively-small amount of time to researching other potential solutions guaranteed to be more robust than LuaJIT, just in case LuaJIT doesn't work out.  All-in-all, this is great news since it means that FPLT will not be holding up development any longer!

I spent the latter half of the month getting more content brought over to the new system and sanitized. PlateMeshes (stations, ships, turrets and the like) are 90% back now, and I've spent some time making them more robust and performant than in the past, since they turned out to be the cornerstone of many of my procedural algorithms. Planets are back and at 100%, including atmospheric scattering. Asteroids will be back as soon as I figure out scalar field extraction in the C core.

In summary, a LOT of stuff is coming back very quickly, as I promised it would, since the real work of thinking through problems is already done in many cases. It feels so nice to get to focus on putting content back in! This time around, I'm not going to make the mistake of going for long periods without a playable version of LT. I intend to keep the PAX demo in working shape and updated with relatively-recent content, both so that I can continue to feel the inspiration of being able to actually play LT, and because I'll be pushing myself to go to more local tech events where I can continue to demo the game (I'll give you all a better heads-up from now on as well).

As long as we're talking about the community, it's also worth mentioning that I have appointed LT's forum admin, Talvieno, as my official community manager. His new role as CM will ensure that the amount of non-coding LT-time I spend in the future is kept to a minimum! I'm really happy to have Talvieno on board. You can see the full post about it here. I’ve also kept my promise of delivering weekly textual devlog updates. They're viewable here, and go into much more technical detail on my recent developments. If you're not pleased with this summary, do have a look!

And in a rather unexpected note: part of my time over the past week was dedicated to developing a networking and remote 'control panel' system for LT. It's a technology investment that I'm sure will pay dividends. Specifically, in an attempt to gain better control over LT's procedural generation algorithms, I implemented a multi-platform TCP & UDP socket API, then used it from LuaJIT to spin up a very simple HTTP server run in the background by the engine that serves up a simple control panel webpage when connected to via a browser. It can change internal engine variables automatically in response to controls like sliders or buttons being changed in the panel. This makes it fantastically easy for me to work with large amounts of parameters and see results in real-time (which is exactly what's needed for building good procgen code). As a bonus, since it's based on sockets & HTTP, I can connect remotely and use another machine like my tablet to control parameters while I develop on my main box. There are a whole lot of other ways I can envision using this to boost my productivity! Also, the tools are now there for anyone who wants to give an LT multiplayer mod a shot at release. (May the force be with you...)

Finally, I experienced one of the happiest development moments in memory when I got to see my universes in VR for the first time! VR support had always been planned, but I had never gotten around to adding it until a couple of weeks ago. Playing the PAX demo on my HTC Vive blew me away! It reminded me of why I became a graphics programmer: I wanted to build worlds. I always dreamed of getting to explore the worlds I'd built. Eight years ago, when I started learning 3D programming, I also looked into VR, but the hardware just wasn't around back then. I saw how I might be able to build worlds with enough learning, but I didn't see how on earth I could learn enough to build the technology that would let me experience those worlds. Fast-forward less than a decade, and a bunch of really smart people have done exactly that. I never dreamed it would happen so soon...if you had told me back then that in eight years I'd be able to code nebulae, planets, stars, and ships, AND that I'd have access to hardware that would let me SEE them (almost) as I see objects in reality...there's no way I would have believed it. But there I was this very month, floating above a planet, staring at nebulae and stars, and watching the occasional pulse-laser fly by my face. Even the most trivial experiences in LT were made absolutely thrilling :) I'm planning to do a lot more visualization and testing in VR, simply for the inspiration factor. After two years of relatively-uninspiring work, I'll take all the motivational boosts I can get.

---

Again, if you're really interested in details (all of the developments of February can't possibly be packed into a neat summary), dive into the logs!  In March I hope to see completion of the porting process for most content (actually, that's the goal for the end of this week, not the whole of March...!)  With all my toys back, it'll be time to resume the process of assembling them into a universe.  Full steam ahead.  I look forward to being able to post new visuals again :)

~ Josh & Nathan (Talvieno)

PS ~ This format is a work-in-progress.  Please let us know if you have thoughts about the format of the KS monthly summary (too much text? need bullet points? rather just have tiny per-week summaries with links to the full log?)

The State of Limit Theory Development, 2017!

109 likes

Hi everyone!

So, we've got quite a bit of catching up to do.  I know that those of you who don't keep up with the forums have been in the dark for quite a long time now, and I hope you'll accept my sincerest apology.  It's been a rather rough time for LT development over the past two years, and that situation has made me less than keen to communicate, since I've grown all too fond of communicating good news over the course of LT's dev cycle.  That being said, it was a very poor choice to leave so many in the dark for so long, one that I now regret deeply.  As of last week, I've launched a serious campaign to rectify my communication habits, bring everyone up to speed, and ensure all who care about Limit Theory that, despite roadblocks, it's coming :)

For those who want the full, gritty story on development over the past two years (and why it's not been nearly as fun as usual), I'm going to refer you over to the forum announcement that I made last week.  Though I don't wish to trivialize that beast of a post with a summary, I understand that not all of you want to read another Josh Novella, so a rough summary is: LT development has run into a very difficult technical problem with no clear/easy solution (in particular, achieving high run-time performance while also being maintainable by one programmer).  The result is that I've had to spend a great deal of time exploring solutions, all of which have thus far failed (although the latest one is currently looking more promising than any before it).  Quite honestly, it's been a rather bleak period for me -- where once I got to have fun building things freely, I've had to shift to the much less fun problem of figuring out how to do so 'sustainably,' so-to-speak.  Anywho, I won't ramble on about it, if you want more details, please do have a look at the post.

Second on the agenda, as some of you may already know, I attended PAX South this past weekend with a small LT combat demo!  I should have announced my attendance beforehand, as I'm sure some people would have wanted to come -- unfortunately it snuck up on me and I was absolutely swamped with work getting ready for it by that time.  I did get to meet a few forum members, a few backers, and a few general lurkers, which was a great deal of fun!  Although the demo was very simple (being built quite hastily on top of the current 'attempt' at solving the aforementioned problem), it's quite fun if I do say so myself, and should also serve as a bit of comfort to anyone who's genuinely concerned that I've quit working on LT or am not making progress (really, if you read the posts I link, you'll know how far that is from the truth).  For more details on the demo and PAX experience, you can read the recent devlog that I posted, which summarizes the past week.  Or, if you're only interested in the screenshots, you can have a look at the LT @ PAX South 2017 album I made, which contains some shots of the demo as well as a few bad pictures from my phone of people playing it.  If you're wondering why the ships are rounded boxes, you'll have to read the devlog :)

Since I can't resist popping something shiny into this post, here are some of my favorites from the album:

 

 

 

Speaking of dev logs!  As I mention in the first forum post, I'm going to resume a regular development log series, albeit at a reduced frequency.  I understand that I can't keep doing this irregular, unpredictable communication style.  It doesn't work, it's hurting the community's trust in me, and it makes me feel bad on top of it all.  So, the current plan is weekly or bi-weekly (I'll have to feel out which is best) 'low-pressure' logs.  The idea is that, in an effort to make sure that I communicate regularly, the understanding with these logs will be that I'm going to summarize development whether it be positive, negative, shiny, unglamorous, etc.  The fact of the matter is that a lot of weeks aren't going to be glamorous, but you guys have made it clear to me that communication of news, even if it's not unicorns and rainbow nebulae, is far preferred to no communication.  Got it!  The first such log is already up and is, again, mostly about building the combat demo and the PAX experience.

Finally, in terms of Kickstarter updates, I'm not quite sure what to do, so I'm open to suggestions on this matter.  I don't really want to flood you guys with a weekly / bi-weekly KS post just for a dev log that may or may not be of interest to anyone.  Typically I reserve KS posts for 'bigger' matters.  Perhaps, then, I should do a sort of 'monthly aggregate,' wherein I take all the logs for a single month and pull them together so that you guys get a monthly digest?  Or something else entirely?  Please let me know what you, personally, would like in terms of KS updates -- it'd really help me get a sense of what to do!

Really happy to be back in communication with you all, I've missed it.  We all knew LT was an ambitious project from the beginning.  Some knew from the start that it would be..errr...'slightly' more difficult than my youthful optimism led me to believe.  Nonetheless, we have come entirely too far to throw in the towel at this point.  I'm 25 now (can you believe I was 20 when I started LT??) and the world isn't as rose-colored as it used to be, but I still see so much beauty in Limit Theory.  It's a beauty for which I'd happily wrestle issue after issue.  Many days when I sit down at my desk to start work, I imagine the day that LT is released.  I imagine all the happy people around the world creating their stories in a limitless universe.  It's enough to keep a guy going no matter the difficulties :)

~Josh