Hey guys! Since I've got a bit more than usual to say today, I'm just going to hop right in
Brief Recap of the Week:
- Added physics 'sleeping' for dynamic entities -- dynamic entities at rest now take the same CPU overhead as non-movable entities; huge performance gains in a highly-dynamic scene with isolated pockets of kinematic activity
- Added attachable component for external modules like turrets, thrusters, etc.
- Implemented batched attachable updates for efficiently maintaining constraints between attachables and their parent
- Moved existing placeholder turret & thruster logic into the real framework of our batched updates
- Major improvements to the Job system (which handles the batched, per-frame logic)
- (Experimental...) Removed frame interpolation; switched (back) to variable-dt updates in favor of cleaner/simpler architecture
- Major cleanup of lots of game code due to the above!
- Ported alpha pass rendering; ported beam shader (working turrets, hurrah!)
- Extensive continued perf-testing of game logic overhead with an emphasis on scalability in high-entity + high-logic workload situations
- Implemented and used 'simulated lag' and 'simulated stutter' to test performance scaling for low-end systems (the simulated stutter is a little too good...it'll make you queasy if you crank it up all the way )
Sleepy Physics Awakens New Gameplay Opportunities!
Physics sleeping is a major and notable improvement on all of the previous incarnations of physics in LT, and guarantees that we'll be able to handle way more motion than before. I'll spare all the technical details concerning implementation, but the concept is very simple: don't spend time doing physics on things that are at rest (not moving). A decent implementation of this can actually eliminate essentially all cost of movable objects that aren't moving, meaning you can have lots more movable objects and/or lots more existing types of objects be movable. I say essentially only because movability requires extra information, extra information requires extra per-object memory, extra per-object memory induces extra cache misses when performing operations on those entities, so there's still a tiny up-front cost for being movable. But it's tiny.
One of the great results of this feature is that (subject to performance impact remaining minimal)...asteroids can be dynamic objects! I remember back in the early days when quite a few people were disappointed that asteroids would be unmovable. It seemed like a small issue to me at the time, but now that I've actually got them...it's quite nice There are several major gameplay wins at stake, including the 'big ship meets little rock' scenario (something that has caused me and, I imagine, a good many others here quite some pain and financial loss in other games... ) Previously, a large ship moving through an asteroid field was not 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. If one calculates a proper collision impulse and the resultant damage based on momenta and relative mass (as one should), then 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! Tragedy ensues as the fate of a faction goes up in flames, all thanks to some careless pirate tossing an empty beer can out the cockpit
One can, as usual, come up with various ways to work around the issue, the most immediate of which would seem to be: destroy the debris. Not bad. But it's still unclear what happens when a ship meets something, say, 10x smaller. Or 5x. Or 2x. At what threshold of relative mass do we make the collidee disappear? Isn't it going to be weird having huge rocks vanish in a cloud of dust? Can AI players troll one another by building massive-yet-cheap hollow spheres of metal and launching them in the direction of a competing faction's primary source of raw materials, soon thereafter causing the whole field to disappear in a few glorious moments of poorly-resolved collisions? It actually sounds rather cool Still, the resolution of the same situation with dynamic objects in play is even cooler: now the massive trollololosphere would drive a cylindrical hole through the field, dispersing asteroids outwardly and infuriating that one old miner who's been cutting power to his engines to get a tad more juice to the transfer beams. Returning to the more realistic game scenario, a battleship pilot need no longer worry about voyaging through an asteroid/ice/debris/cardamine field. So long as they avoid the largest obstructions, the impulses from clearing smaller obstacles will be easily handled by the shields (but please, have some respect for the poor folks who had to paint your capship -- do pack a shield generator).
It's still unclear if this will also enable mobility of large stations (the larger the scale, the larger the physics performance impact during motion; some back-of-the-prefrontal-cortex calculations tell me it's roughly-proportional to the surface area of the object, so we're dealing with superlinear slowdowns here). Frankly I don't see a whole lot of gameplay value in it. As far as I'm concerned, if you're a capital pilot and you're zipping toward Big Jiub's Quantum Armament Emporium at warp 9, you deserve whatever fate the physics engine deals out Since the issue is purely one of scale, having weapon platforms or even small outposts be movable -- and at the mercy of behemoth-class vessels -- would seem to be doable.
I've already done some really fun stress-tests with the system by spawning 1000 AI followers (running the PID algorithm discussed last time) and zipping through large (~10K) fields (at 60+ FPS!) Though the pilots aren't yet using Sean's avoidance algorithms, it's actually really neat to watch the formation as a whole either bump into (and subsequently compensate for) large obstacles, or clear smaller ones out of the way. Having everything fully-movable and collidable at the same time turns what would otherwise be a boring scenario into an entertaining one! Compare this with LTC++, where I had to (in the later days) turn off collision on NPC ships and force immobility of asteroids to maintain a reasonable framerate Suffice it to say, I remain very excited at all of the gameplay doors that are opening up thanks to so many hours spent fretting over CPU cycles
Lindsey Joins the Dev Team!
Promises "At Least 300% Reduction" in Ship Boxiness!
That's right, there's more! I know you all are already over-the-top with joy after reading the above, since, after all, physics was the #1 most-anticipated feature of Limit Theory But if you'll allow me just a few more paragraphs, I've yet another log to throw on the hype fire!
The third desk here at the office has remained unsettlingly-empty since Sean's departure. We can never hope to replace Sean's zest for flow-field-AI mechanics, nor would we dare try. But I'm very pleased and excited to announce that our third desk has found a new occupant: Lindsey Reid, technical artist extraordinaire.
Lindsey comes from an interesting mix of background experiences. Like Adam, she's worked here at the tech park in the past and been part of the game development community here in Baton Rouge, which is how we met in the first place. Some of you have already met her on IRC or the forums -- we've been dating for quite a long time now She's had the experience of working as a game programmer at a major AAA studio (making her...yes...the only one of us three to have worked in 'the big leagues'). When she approached me with a desire to work on Limit Theory, it was her knowledge of the juncture of art and code that sold me on it.
Lindsey's foremost area of interest is in improving the procedural generation algorithms, particularly for stations, ships, and artificial entities in general. Rejoice, for the time has come to retire Josh's "Ode to Box" generators and make way for a new generation of algorithms! As someone with genuine artistic talent alongside an ability to code, Lindsey can do something that I can't: she can build space stations and spaceships on paper, generating them manually with sketchpad-and-pen while simultaneously analyzing her own creative process and translating it into code. With assets in which both functional design and aesthetic form are key, this approach is more effective than my own process of rapid guess-and-check. Iterating on equations works well for asteroids and chunks of ice (and has even exceeded expectations in the case of nebulae), but doing so, as you guys have no doubt noticed, gets much harder when one turns attention to ships, stations, and the like without being able to actually draw/reason about them on paper. As I have always asserted of procedural algorithms, though, the failing is not with proceduralism itself, but rather the one doing it. We have but one person to blame for the legendary LT boxships...
The fruits of this work are already flowing. As of last week, we have a new, joint-based mechanism for procedural algorithms to leverage. Lindsey is working on creating a library of procedural building blocks along with the architectural elements to arrange those building blocks in sensible and aesthetically-pleasing ways. I was particularly pleased when she came to the joint-based solution in her second week of work, since that was an idea that I had been contemplating for the next iteration of better ships and stations. Now I need not contemplate, as the code is happening while I focus my efforts elsewhere. Lindsey will be working over the coming weeks to scale up our procedural geometry toolkit and squeeze as much quality as possible out of proceduralism in LT, especially where it remains lacking. Unlike physics, proceduralism actually is one of the most-advertised and (I like to think?) most-anticipated features
I'll leave the fun / detailed bits for her to dive into in her own logs (!!), as I'm sure she can shed more light on converting the artistic process into code.
Note: For personal reasons, Lindsey wishes to go by pseudonym (i.e., Lindsey). Yes, strange, I know...*briefly opens Facebook, sees 40 unread messages & 100+ friend requests from strangers, promptly closes browser and burns laptop*
No screenshot gallery for this log, as I don't have much that's visually new to show for the week. In terms of current work, you all now know what Lindsey is up to, but on the other side of the room, Adam is scaling our developer UI up into a full, player-facing UI, since it's currently looking as though LuaJIT may just pull through for us such that UI can remain in Lua (keep your fingers crossed...)! As for me, my focus remains on gameplay logic mechanisms and ensuring performance in the presence of real, representative gameplay logic at large scales (much of which is concerned with computationally-expensive AI that needs to happen frequently but not every frame).
With gameplay logic, UI, and procedural algorithms all getting serious brain-time simultaneously, the months ahead hold quite some promise.
See you next (/this?) week!