It'll go down in history as the first week that Limit Theory had more than one programmer working on it! And I'm coming to learn just what a fine thing that is. It's remarkable how different it feels to have help (I mean, on the programming side), especially help that's sitting a few feet away. So without further delay, let me introduce the new names that will appear on the LT credits under 'programming' (well, no last names yet because I don't want you guys stalking them...not that you would ever do such a thing... *glances at startlingly-high unread facebook message count from unknown people + neverending friend request list* )
Adam - In the last log I mentioned the fantastic coincidence of a highly-talented game programmer walking into my office and subtely inquiring about a job. His name is Adam, and you will all come to know him as the other guy on the team who gets excited thinking about spatial partitioning schemes, memory layouts of component systems, and C without the ++. Last week we did a 'trial run.' Monday through Friday of last week, he came in and we tested the waters with respect to whether he would enjoy LT work, whether I would enjoy having someone else in my office / be able to give him things to do, etc. Come Friday it was basically a no-brainer. We both knew how the week had gone. At the end of Friday, I made him an offer and he accepted. Welcome, Adam.
Sean - I also mentioned a potential intern with such an acute talent for learning quickly that it more than offsets his lack of years at the grindstone. He came in and toured the office last Wednesday. We had a chat about some of the things he could work on here -- especially AI-related. I asked him, to get a sense of how much I needed to "sell him" on the internship, what his thoughts were on a scale from 1 to sold. He immediately responded with "sold." Welcome, Sean.
So, last week we were at (unknown%, ~95%), respectively. This week we are at (100%, 100%). They both officially started on Monday. Hard to believe it's only Thursday.
We'll work on getting Adam & Sean on the forums, since I know you guys would enjoy flooding them with enthusiasm and the 'occasional' off-topic meme...
Now, let's see how this week is going thus far!
Project Organization - It's worth mentioning, since LT has thus far existed, at various points in time, as: stacks of notebooks brimming with frantically-scribbled ideas, code files spanning dropbox, google drive, 5ish different dev machines (throughout the years, that is), and, at one point, that silly USB-drive chain that I wore around my neck, and of course, countless various patterns of neural firings that have been etched into my brain. Oh, and countless Trello Boards. And sticky notes. And...you get the idea. Not exactly centralized. A team necessitated a change, so Adam and I worked hard on setting up some organization. Version control that isn't Dropbox's version history feature (hey, don't hate, it's an amazing feature), project management tools that aren't just lists of cards. We actually have milestones with dates, task allocation, analytics...you know, all that stuff that fancy folk use. Now, boring stuff aside....
Entity Component System - HA!!! And you thought you had heard the last of it. Come now, you should know better But seriously, we had to come back to this. Once Adam got LT building and running on his machine, I was rather horrified at the performance. Granted, I haven't been overly-focused on optimization. Granted, he's not running the most powerful GPU ever (760M IIRC). Still, it was pretty clear that we needed to rein in the Lua and bring more over to C, as I said would happen if perf declined.
To that end, we've been collaborating on an industrial-strength ECS for which we've set a pretty harsh architectural-lock deadline. The great news is that, having someone else with the skill to design such a system, the task is asymptotically faster. I'm starting to realize just how much time was lost to my own self-doubt and falling into the same loop of bouncing between A, B, C, and back again. I suppose that's how it goes when you have one brain anchored to nothing. But with Adam and I bouncing the design and implementation back and forth, we've already got what we both feel is a really good architecture. As of tomorrow we should have enough done to begin verifying that it's as good as it looks on the whiteboard. It should provide very significant gains, and negligible (or no) loss in moddability.
Universe Creation, Planet & Colony Dynamics, Research, High-Level AI: Yeah, ok, that's kind of unfair. I feel like you guys, from here on out, are probably going to be mostly interested in Sean's work. Maybe I'll make him write the logs Since Sean is still comparatively fresh with Lua, C (and programming), it seemed best to allocate him more towards using that brain for pure thought. Of course, he's not just thinking about gameplay, he's also learning Lua at the same time and getting a feel for what the high-level will look like in Lua.
I've taken several hours over the course of the week to explain some of the high-level mechanics to Sean as he has encountered the need to understand them. At this point, we've been over a lot of territory: how the high-level AI works and reasons, projects, details of the economy and the market/mission board, AI traits, colonies and their spawning of AI + culture vectors, universe generation, research mechanics, and so on. At this point I'd say he's got a pretty good handle on the big picture of LT, and his task is basically: explore it, detail it, make Lua out of it, and generally continue filling in the framework that I laid out for the LT large-scale dynamics. Ultimately I hope to have him doing large-scale, long-time-scale sims on generated universes and doing data-driven balancing and tuning to ensure that we have a dynamic-yet-stable (as in, doesn't blow up after 10 hours of game time) simulation going on in the game that affords maximal fun for players.
As the so-called 'root'/anchor of the game simulation, colonies were a natural place to start, and that's exactly where Sean started his exploration. This exploration naturally led him to the exploration of...basically everything, so it's probably easier to flat-out list the things he's been working on:
- The nature of the colony culture vector and its influence beyond just the spawning of AI
- Planet types and the way in which different types of planets modify the economic processes executed by the colony
- Star types and the way in which different types of stars influence planet generation
- Distributions and evolutions of stellar masses in a galaxy and the way in which physical formulae dictate the evolution of a galaxy / the distribution of stars (it brought me joy to see him exploring some of these things with real-time graphs he created )
- Bringing it all back to mass distributions, and going forward from there to temperature, color, planet distributions, etc.
- Colony-to-Colony interaction mechanics (something that's never been explored before!), including cultural diffusion
- The exact formulas and mechanics that dictate the creation, growth, and death of colonies
- AI spawning mechanics, especially with respect to how the birth and lifetime of an AI player affects the colony on which it was born and vice-versa
- The influence of colonies on planets (! not the other way around! I have never considered this before)
- Probably a lot of other things....
Physics: As I mentioned, Adam and I are essentially trading off the baton on ECS work so as to get the best of both of our brains. His task, while I have the baton, is currently the implementation of the fastest-possible structures for physics. I've talked about my work on various spatial hierarchies for physics pretty recently, and I'm effectively giving him the task of seeing that work through to completion. Interesting side-note: Adam was studying physics in grad school when he decided that game programming was more interesting
Asset Compression: I'd be remiss if I didn't mention the work that Adam pulled off last week in just two days. I tasked him with implementing compression in the engine for binary data, to be used primarily for asset compression (notably, to make sure that procedural stuff like nebulae, planet surfaces, ship/station meshes, etc. don't eat up your whole hard drive when I cache them to disk). I was very impressed when, instead of just integrating zlib like I suggested in passing, he took the time to run actual performance benchmarks on several algorithms, which, in the end, landed us at LZ4. I was totally unaware of LZ4 and how incredibly fast it is. Speed is of the essence here, since we're going to be compressing and decompressing at run-time as we trade certain things off to a disk cache when the player leaves the system. LZ4 blew zlib out of the water with respect to speed, and still maintained quite an acceptable compression ratio. It's now integrated in the engine. As I told Adam, "you've just saved countless man-hours" -- had I done it myself, I would have dropped zlib in and never thought twice about it. And the engine would be a good bit slower at loading / saving. This man respects your time as a player! Only one of several impressive feature completions that made it easy for me to see the value in bringing him on!
Everything: As for me, other than continued ECS work as noted above, the week has consisted of not much less than everything. With two others working on dedicated tasks, I've been somewhat freed up to nail a lot of residuals that have lingered in the to-do list for far too long. Another list seems in order:
- Added 'OpenGL debug mode' to the engine that automatically checks for and reports non-critical GL errors after every call. These can significantly hurt perf on older drivers or less-powerful cards; we saw a nice boost on Adam's machine when I eliminated all of them
- Significant cleaning of engine API so that it's easy and fast for us all to use (not just me), and...
- Automatic LuaJIT bindings to the engine generated via a script (so that the bindings are never out-of-date, which has caused several headaches thus far). Combined with the previous item, these two ensure clean and complete access to the engine from Lua
- Stack-based render state
- GPU hinting for machines with both integrated and dedicated cards. Adam's machine was running the engine with integrated graphics by default; turns out applications can do certain things to 'hint' to NV / AMD drivers that they need high-perf. The engine now does so, and automatically runs on the dedicated card for machines that can choose.
- Minimizing the build process accross Linux & Windows. Since Adam is running Windows and I usually work in Linux, the result is that we get to constantly test LT on both. It's also a headache to keep the build process simple, especially when we want to add test applications. I'm close to having all such headaches totally wiped out (in a simpler way than CMake / Scons / name-your-overly-complex-build-system)
- Planning tasks and generally learning how to make us the most effective team we can be + getting everybody ramped-up logistically
- Everything else
Well, I'm exhausted just from typing that; I'm sure you all must be exhausted from reading! (Talvieno: I'm so sorry. The TL;DR will no doubt be a pain... ) But I wouldn't want to miss the chance to convey to you all just how fast we're ramping up the development.
I've been saying it for 4.5 years and I'll keep saying it for whatever (comparatively) little time we have left: LT is coming. You can't stop the train.
See you all soon!