AdamByrd wrote: ↑

Tue Aug 15, 2017 9:59 am

Guys! Gals! Hey. I'm just popping on to check in with a super ultra tiny mini update.

Things are starting to move fast. Lil'T is alive and kicking. And producing pixels. Actual pixels! (Seriously, I've spent so much time staring at text books and data dumps these last three months I almost forgot we're making a game. With nebulas and rocks and space pirates.) I've been working to nail down how we're going to be writing actual gameplay code. That means fleshing out how Lua talks to C to keep heavy bits and allocations in fast code land, how to make that Lua feel 'normal' and not like C grafted onto Lua (metatables are really nice!), making sure LuaJIT actually jits to assembly, iterating on the engine API to remove friction, and building a prototype solar system. I'm insanely excited about the progress we've been making. All the mountainous unknowns are now small piles of exploded rubble. We're moving faster by the day.

The GIF floodgates are opening soon, my friends.

What a time to be alive.

• Finished implementing zero-cost Lua wrappers for engine functionality (mentioned in last devlog; means we're getting superb performance when interacting with the LT Core)
• Implemented enough of the foundational Lua code that we can all work on LT in Lua at the same time
• Continued careful analysis of LuaJIT debug output; continued to ensure 100% JITing to assembly; continued to learn more about the trace compiler and how to beat it into submission
• Hooked up our ECS to Lua + wrote the convenience wrappers that allow it to be used really easily (note: we now call it the 'CType' system instead of 'ECS', reason being that it is actually more general and flexible than an entity component system, although it can and does serve as one -- I'll explain more below!)
• Ported Lua deferred renderer; modified to take advantage of all high-performance constructs
• Made major improvements to our logarithmic z-buffer code while doing the above (this is the code that allows us to render objects at massive scales & distances without issue)
• Implemented a work-in-progress event system in Lua for use in gameplay code
• Implemented Lua wrappers for efficiently dealing with SDFs and OpenVDB (the library mentioned in the last log that we now use for extracting meshes from distance fields)
• Implemented CSG functions on SDFs that are roughly 10x faster than OpenVDB's defaults, allowing complex, detailed meshes to be built very quickly (read: better procedural mesh algorithms coming soon!)
• Wrote a simple pathtracer for fun since graphics Josh has been repressed Not totally irrelevant to LT, though, as we could perhaps use it for nice renders of procedural assets or for having a 'ground truth' reference for our physically-based rendering code
• Built several Lua 'template' applications that allow us to easily various, specific pieces of functionality really quickly (just like the old LTSL sandboxes!)
• Loads of other things that I'm forgetting

• Started working in the Lua side of the LT codebase!
• Put in the time to learn about all of LuaJIT's lovely 'idiosyncrasies'; Adam is now 100% capable of helping me deal with the technical side of LJ
• Used LuaJIT magic to implement the first parametric type in our CType system -- the arraylist! This means that not only can we define and use new, native datatypes in Lua, but we can also have what amounts to native std::vector<T> and so forth of them. I know I've beat this horse to the ground, but seriously, the power we now have to create and use types that are as fast as compiled code simply can't be overstated! Memory management is by far the weakest spot in Lua's performance, and we are almost entirely side-stepping it.
• Hooked up BSP code to Lua and used it to implement picking (being able to click on an object in the world and do something in response -- a seemingly-trivial task that is not at all trivial for large scenes and complex meshes, since it requires casting a ray through acceleration structures)
• Got our first star system set up and working using CTypes and all the new high-perf Lua stuff!
• Made a lot of improvements to our geometry code (BSPs, triangles, rays, etc.)
• Implemented really fast BSP-Sphere intersection tests
• Loads of other things that I'm forgetting (again)

• Native memory types can be defined on-the-fly in Lua; behind the scenes they are 100% as compact as the equivalent type would be in statically-compiled C; accessing the memory is extremely fast due to fancy, custom memory-pool allocation magic done automatically by the engine. All of this complexity is hidden from the user, so code remains very easy to read and write.
• Types can be nested in other types, enabling 'component-based' design, as demonstrated with Health and Weapon. Of course, since this is a full-blown type system rather than an ECS alone, we can do things like have multiple health components, which ends up being useful sometimes!
• 'Member functions' can be attached to these types and called in the idiomatic Lua manner; convenience + performance = winning!
• Generic functions like 'Weapon:damage' can be written without concern for the type of the target object and still 'just work,' despite the fact that we're using direct field access instead of table lookups like most dynamic languages (if you're a programmer and understand what I mean, that should blow your mind a bit )
• (Here's the even-more-mind-blowing magic) Functions that can operate on different types of objects (like Weapon:damage, which could be used to damage stations, hardpoints, etc) will be traced by LuaJIT and end up running as fast as equivalent statically-compiled constructs (in C this would require a switch statement or function pointer, in C++ this would require a template or virtual tables; here it requires nothing extra!!); this is a HUGE win for both performance and simplicity!
• Although I didn't show it above, types can be built in a piece-meal fashion rather than defined all at once. In particular, mods have access to type definitions and can inject their own fields and methods as required to support extra, mod-related data and functionality (I showed something like this in a devlog a while back). As always, giving modders the ability to add just about anything conceivable to vanilla LT is really important to me!

AdamByrd wrote: ↑

Mon Oct 02, 2017 11:31 am

Hey guys. I'm going to try something new for a bit and see how it goes. In between Josh's bigger updates I'm going to start posting smaller updates. These mini-updates will focus on the specific problem I'm solving at the moment. The goal is to go deeper into detail than the bigger updates normally do and is often going to be centered around code architecture since I've been spending a lot of time there lately. They will also be more informal: I'm going to write them without much revision and without the flair that generally comes with Josh's writing. This is mostly just laziness that I'm selling as time savings and pragmatism. I also imagine this being a little more interactive than the usual updates, so feel free to ask specific questions or tell me what you'd like to hear more about and I'll do my best. Off topic stuff is fine as well as I realize you guys don't know a whole lot about me yet. What I won't be covering is what Josh is currently working on. For one I don't want to steal his thunder and two I want to ensure there's still new information in the regular updates. Onward!

---

Recap
First a bit of history. My primary goal since teaming up with Josh has been to get to gameplay as soon as possible. In a particularly productive team meeting early on this lead to the birth of Lil'T. The original goal was to have a single, playable system in a week. Something basic with player controls, a nebula, and some asteroids. This was back when I had just finished the BSP implementation. We had been working solely in the engine and didn't even have a separate (code) project for LT. I didn't know any LUA or how to start writing gameplay that leveraged the engine so this was a good motivator to start knocking down those barriers. I think it ended up being about 2 weeks before we really got to the point we wanted to be. I have to say, hooking up the BSPs for the first time and being able to click things in the scene felt really damn good.

Now, as much as I want to get to gameplay, the second major goal is making sure the code we write is shippable. It can't be prototype stuff that's going to need to be re-written. It doesn't have to 100% perfect and complete either, but it needs to be written in a way that can expanded without needing to be refactored. In getting the first phase of Lil'T running it became obvious that the infrastructure to support LUA needed to be in before going further. That took another few weeks and you've likely read about some of that in the past couple of updates. During that work we spent a lot of time profiling, testing, and tweaking things and it became pretty obvious that being able to do some of that while the game was running would save us a bunch of time so I set to task on the debug UI.

With the dev UI in a good spot we're shifting back to gameplay again. We're likely going to do this 1-2 combo of sprinting on gameplay for a bit then stepping back to improve the infrastructure supporting it a few more times. Often we can't really tell what the scaffolding needs to look like until we have concrete gameplay as a guide. We spent a couple of days talking through how we wanted to simulate entities. Since they have one-to-many parent-child relationships (a ship is the parent of it's turrets), the game objects form a tree structure. We compared hierarchical updates using depth first and breadth first traversal. We compared job-based (run on all entities) and event-based (build a list of entities that need to be updated). Ultimately we settled on event-based updates with the ability to create jobs within that framework.

Input vs Simulation
Once we nailed down how we wanted updates to be processed, input became the next target. We ended up with a lot of code that looks like this:

Code: Select all

function onUpdate (dt, hasFocus)
  if hasFocus then
    if PHX.Mouse.Pressed(PHX.MouseButton.Left) then
      self:fire()
    end
    if PHX.Mouse.Pressed(PHX.MouseButton.Right) then
      self.camera:setTarget(self:getPick())
    end
  end
end

(Note that I'm being loose with the term 'update' in the text (but not the code). The core game loop is essentially simulate, update, draw. Simulate is the fixed interval simulation step. Update happens right before draw and is for things like animation and interpolation. Draw is for, well, drawing. Also note that handling input in the update step is wrong and will be changed eventually. We aren't currently buffering input and since the simulation rate is much lower than the update rate we miss a lot of input when handling it in update at the moment.)

This isn't great. Having to manually track, pass, and handle focus in every single location that processes input is going to lead to a lot of mistakes and unnecessarily obtuse code flow. We knew this wasn't going to last long as it was being written and it needed to be addressed soon, before enough incorrect code built up that refactoring it would be a big task.

Josh and I talked through this quite a bit and his idea was to treat the game window as a fairly standard UI. The GameView would just be a UI widget that displays the final, rendered view of the simulation. The simulation becomes an autonomous thing that marches through time, updating its own state without any concept of a camera, a player, or input. UI widgets will provide visible controls and input handling that inform the simulation of requested state changes. The GameView decides how it should render the view of the simulation.

It took me a bit of time to understand the implications of this approach. It sounded a bit odd at first, but the more I worked through it, the more I was able to see the large number of subtle benefits.

• The GameView gets the full benefit of the automatic layout functionality of the UI. Debug and gameplay UI elements can push the GameView out of the way in addition to just overlapping it. If you've noticed how the debug UI overlaps gameplay that's actually quite annoying. It's nicer if the debug window is able to make the gameplay view narrower and slide it to the right so they are side by side instead. In general it means we can allow the game view to be resized, moved, snapped, etc very easily and naturally. We can iterate on UI layout faster, allow players to customize their UI easily, and handle window resizes without any added work.
• Multiple GameViews can exist (think radar, scanning, minimap, whole-system views, etc).
• Input focus is already handled cleanly. The UI tracks what your mouse is over, which widget has focus, is being dragged, etc. It's trivial to extend this to have separate mouse and keyboard focus, hard and soft focus, separate onInput functions for letting only the focused widget handle input, and whatever else might be needed.
• The amount of branching in gameplay code drops significantly. We don't have to check for focus or input because that gets hoisted to the highest level and doesn't need to be repeated all over the place. Even with our tiny system, the amount of code and complexity immediately dropped.
• The simulation takes on more of a client-server model. Input is handled in the 'client' which then requests state changes on the 'server'. Validation in the simulation all happens in one place. We end up being forced to build a clean API in some sense.
• Concepts like control schemes become much easier to think about and implement. Since each form of input is going to be a separate UI widget completely changing how the game controls just means creating a new widget and adding it to the UI hierarchy.

There's probably a lot more nuance that I'm leaving out. Anyway, we're currently using the dev UI to handle this. We didn't originally intend for the dev UI to be the final UI system but the performance is good enough that it's actually a possibility. It's powerful and easy to use. However, if the dev UI is swapped out in the future it's not going to affect the way the gameplay code is written so it's natural to move forward with it for now.

Of course, making this change meant a decent amount of refactoring. I had to pull all of our input handling out, decide where it went and reimplement it in the new system. I ended up with 3 new widgets: GameView, DebugWindow, and DebugPicker. I also reimplemented the data inspectors Josh added a while back so we can actually walk through the entire game state from UI windows. I also took the time to add a bit more UI polish: added stretch weights to grid columns/rows, fixed subtle positioning errors in labels, added alignment to labels.

This is mostly under-the-hood work, but I figure I can at least drop a gif of the GameView being animated smoothly: https://i.imgur.com/EkASTsN.mp4

---

This update is a bit higher level than I'm aiming for in general, but it's not a very involved or probably interesting topic and it's only a few days worth of work. Let me know what you guys want to hear more/less about so I know where to focus in the future posts.

Cheers

• Implemented several new components for entities, most of which are in preparation for / in service to implementing gameplay logic
• Implemented a mod-loading system that performs validation and loading of isolated mod files, which of course means that I also...
• Defined a mod file format and started writing logic in mod form; ideally, most if not all of our actual gameplay logic will be written like this, both for our own convenience in being able to easily plug/unplug pieces of gameplay, as well as to ensure uniformity with respect to 'built-in' content vs. mod-added content
• Implemented an event-handler architecture for effortlessly broadcasting events as well as hooking listeners to respond to said events
• Worked with Adam to implement first pass of 'job' system, which is, essentially, the 'code' analogue of an ECS
• Implemented several jobs / pulled much of the existing LT logic out into jobs, resulting in isolated, efficient, and easy-to-reason-about logic
• Implemented (naive) collision detection and resolution (as a job) -- had lots of fun with large quantities of asteroids bashing into one another
• Tackled many, many performance optimizations accross the board, attempting to ensure that we stay lean-and-mean as we push more content into the game; some examples are LOD meshes & automatic generation thereof, fast font glyph caching, fast vertex AO computation for SDFs, and more...
• Explored building a simple editor program for expediting the process of adding components, entities, and logic + rolling those changes into a mod file and testing it in-game (heavily-inspired by the TES games and the legendary 'TES Construction Set' from back in my Morrowind modding days)
• Began work on version 2 of the jobs system, which will, hopefully, unify how we write the heavy, running-almost-all-the-time gameplay logic and the sparse, happens-only-under-specific-conditions gameplay logic
• Got the 64-bit Windows version of LT built & running

• Implemented a spatial hash grid structure similar but far superior in performance to what LT C++ used to use for physics
• Added xxHash to the engine; replaced several internal hash function usages with xxHash to reap the performance benefits; did some performance benchmarking to confirm how awesome it is (thanks to Adam for bringing its existence to my attention)
• Used the aforementioned spatial hgrid to implement broadphase collision detection; despite being in Lua and still being quite non-clever (other than hgrid usage), it performs remarkably well
• Implemented a generic C-style hash map with open addressing and lossy hashing for ultra-fast lookups (profiled @ roughly 5x the GCC 4.8 libstdc++ unordered_map impl; not that it matters); will be used in the near future for gameplay-related code
• Unified parent/child relationships in CType components
• Introduced and experimented with a new pattern of 'components as functions' -- since the CTypes system has 'type descriptors,' we can add fields and methods via normal functions that operate on type descriptors (a very dynamic-language-esque thing to do); doing so may simplify component logic -- we'll see!
• Implemented powerful new mechanisms in the CTypes core to support automatic constructors, destructors, initializers (with arbitrary arguments), and automatic reference-counting
• Used said mechanisms to simplify a lot of code
• Used said mechanisms to help implement the Item and Blueprint classes in CTypes (I'm itching to get rolling on gameplay, so I've started working on adding some of the gameplay-related datatypes and such!)
• Implemented two (very) different types of script manager to explore options for writing gameplay logic
• Wrote a simple AI test script in each script format to explore usability, performance, concision
• Took some time, while I was at it, to implement a new AI maneuvering algorithm that uses the PID (proportional-integral-derivative) controller algorithm to robustly achieve a desired position and orientation with minimal stupidity; results are really encouraging...the AI is better than ever before at piloting! (That is, in terms of the basic stuff like adjusting course and thrust. We still need to pull over Sean's work to get real formations and collision avoidance and so forth!)

• 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 )

• Researched & drew very, very basic concept art for stations
• Wrote foundations of Shape library for basic building blocks of procedural geometry, including:
  • Prism (with arbitrary # of sides to the 'base face' & radius, height)
  • Irregular Prism (same as above, but with unequal side length & radius for each side of the 'base face')
  • Ellipsoid (like spheres, but with arbitrary w, l, h)
  • Torus (with arbitrary functions for the inner and outer rings & radius of each)
  • Box (arbitrary w, l, h)
  • Scaffolding (arbitrary w, l, h)
• Began foundations of Warp library for making those Shapes interesting
• Wrote foundations of Joint system for combining Shapes along Joints
• Wrote Piece object for storing combined Shapes
• Experienced awe and terror at the nebulous challenge ahead of me
• Pulled art theory out of my butt and made cool shapes with it I guess

Spoiler:      SHOW

Pictured below: concept doodles for whole stations & for shapes & patterns to build those stations out of. Also, random ideas scribbled on sticky notes, and at the very bottom, art books indexed with sticky tabs for quickly finding my favorite space station concepts.

• Prism
  • Spoiler:      SHOW

    
  • Just imagine the big shape without all of the little rectangles around it, and that's a prism :p it allows for arbitrary side #, radius, and height. The rectangles are actually a demonstration of the Joint system working!!! (which is explained below.)
• Irregular Prism
  • Spoiler:      SHOW

    
  • The code to generate this is actually quite similar to the prism, but the radius and angle for each vertex on the base face is random.
• Ellipsoid
  • Spoiler:      SHOW

    
  • Ellipsoid is just a fancy word for a sphere with arbitrary width, length, and height.
• Torus
  • Spoiler:      SHOW

    
  • I included tori as a primary shape because 1) they're hecking cool and 2) SO many space stations have rings. also, it was fun to code. As you can see in the full Imgur gallery, both the inner and outer ring of the torus use parametric functions to make customizable shapes.
• Box
  • A box is a box. You know what boxes look like. also i forgot to take a screenshot
• Scaffolding
  • Spoiler:      SHOW

    
  • Scaffolding is kind of an odd one out because it defines a very specific shape. It's one of the first clusters of shapes that I made, and it's really here more just to demonstration that my mesh rotation & translation was working than anything else. I do expect to use it, since scaffolding is such a common shape on many space stations, but it may or may not be one of the 'primary' shapes.

• Moved all heavy physics code (kinematics, collision, attachments/parenting, sleeping) to C (HUGE gains)
• Added lots of new instrumentation & utilities for profiling; we have a much better handle on CPU time now
• Major improvements to HDR tonemapping to prevent color desaturation, especially in bright regions
• Added time acceleration (for testing purposes...)
• Ported dust-flecks from LTC++; dust clouds to follow shortly
• Had a lot of fun with Lindsey's new extrusion & stellation functions in our PCG library
• Added AI aiming / turret control to existing gameplay logic test
• Stress-tested gameplay script scheduler with great results
• Loads and loads and loads of fixes, optimizations, cleanups
• Scripting scripting scripting gameplay logic gameplay logic gameplay logic and such

  other code other code other code
    other other other
    ...
    <--  I am here :'[  -->
    ...
  ...

  my code my code my code
  ...
  <-- yield; everyone ELSE is here >:] -->
  ...
  mine mine mine mine mine

• Logic is never scheduled before requested, but may be scheduled after. For this reason, sleep returns 'delta time' -- the actual amount of time elapsed since the script yielded. AI uses this, for example, in the PID algorithm, which requires knowing elapsed time. The manufacturing script has no need for the true dt, though it does operate under the assumption that at least job.batchTime time will have elapsed when it is awoken (our scheduler, like most, guarantees an 'at least' relationship with respect to sleeping)
• The entirety of script execution can be bounded such that total script time is never allowed to take, for example, more than 10ms per frame. Doing so allows maintaining performance -- but our scheduling algorithm also ensures that each script will still be called with an importance that is proportional to how long it's been since the script should have awoke
• Due to the above 'fairness' policy, dt becomes 'larger than expected' for each script at roughly the same rate,
  meaning that each script's temporal accuracy degrades at roughly the same rate, so the simulation accuracy degrades smoothly and fairly in the face of too much work
• Since the scheduler is deeply concerned with time, it is very easy to profile the total CPU time of each script! This allows much more insightful information than just 'Ship.onUpdate' or 'AI.onUpdate,' as it was in LTC++ profilers. Now we will actually see accurate time consumption for each piece of logic, aggregated over all entities on which that logic is running!
• Speaking of which, even in its infancy, scheduler has been profiled with tens-of-thousands of scripts running at the same time with no degradation
• The future of gameplay logic is BRIGHT!

• Added more data to Joints
  • Added up vector
  • Added scale
  • Added function to generate a JointField from a Shape
• Added AABB function to Shape
• Cleaned up all basic Shape functions
  • Ensured all shapes are manifold
  • Ensured no basic shape functions create bad polys
• NEW SHAPE: 5-faced pyramid
• NEW WARP: Bevel
• NEW WARP: Smarter tessellation
  • Refactored tessellate() to tesselate quads INTO quads
  • Refactored tessellate() to produce 0 duplicate verticies
• NEW WARP: Greeble!!!
• Implemented a policy for protecting against crashes & bad geometry as a result of trying to apply a warp on a bad poly.
• Began work on Style

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

• A fan-shaped triangulation, which creates 0 new verticies. This doesn't preserve the angles of the original poly, and thus is currently only applied at the last step of shape creation, right before the shape is converted into an engine-level mesh, which is used for rendering.
• A centroid-based triangulation, which doesn't preserve angles, and is used to break up polys with >3 indicies.
• A triforce-shaped triangulation, which preserves the angles of the original poly. Currently, it can only be applied to tris, so right now a centroid-based triangulation is applied to any polys with >3 indicies before applying the triforce triangulation. This is great for creating detail is meshes before applying warps like greeble().
• A tesselation for quads that splits them into smaller quads. A quad is a poly with 4 indicies- basically a rectangle or square. Tessellating quads into more quads preserves the original intention of the poly better than splitting it into tris. It's used in our shape:tessellate() algorithm in conjuction with the triforce-shaped triangulation to create more detail on shapes before applying ceratin warps.

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

Spoiler:      SHOW

• Major breakthrough with being able to use Lua data & functions from our C subsystems
• Used the above to implement a C-side scheduler that schedules Lua logic for execution; significantly faster than previous implementation
• Ported planets & atmospheres
• Integrated Loom for advanced inspection of LuaJIT traces and assembly
• Implemented several new algorithms for procedural geometry library, touched on in Lindsey's latest log
• Loads of quality-of-life improvements to how 'game-level' Lua is written
• First-pass design of mod format taking into account all existing support systems

Spoiler:      SHOW

Many of my technical expositions, and even the less-technical ones, are ridden with talk of moddability and concern that a given system will not hinder the extensibility of LT. I feel that it might be a good time to step back and look at the big-picture of LT development for a moment; to express what modding means to me, what it has meant for Limit Theory's development process, and how it has impacted both to the utmost degree. To open, I'm going to make a daring assertion: I believe that Limit Theory would already have been released by this point had I chosen to stick with my original vision of 'no modding.' Take it as you will, perhaps noting that I do have a patently lackluster track record of timeline judgement (:oops:) Still, I feel that there is quite some truth to the statement. After all, we had the solid beginnings of a game with the release of the LT Prototype all the way back in April 2013 (!!)

Sometime in 2014, the tides began to change. I began to recognize the need for an external data format in which to place 'arbitrary' constants like those relating to high-level balancing (how much energy is required to negate one unit of damage compared to dealing one unit of damage? How much energy is required to extract one energy unit's worth of raw material from an asteroid? etc..) Naturally, it wasn't long before a similar need for 'arbitrary' code was recognized. The solution at the time was LTSL, and, as we all know, thus began the march toward the dark days, FPLT, and some of the hardest months of my life.

Looking back, it's clear that my solutions, from that point on, were guided by an unspoken requirement: LT had to be moddable, on that point I was no longer willing to yield -- else I would surely have eventually come back to C/C++, learned to write a more modular engine with faster compile times, and found a way to iterate on gameplay code without needing a separate language. It's hard to admit. But it's the truth. Hence, today, we are in a world where great sacrifices in development time and effort have been spent on Limit Theory's touted modding capabilities. Personally, I'm OK with that. And here's why.

When others ask about LT, moddability often comes up. Invariably, I bring up Limit Theory's suggestions sub-forums at some point, typically bragging on it as being "surely on of the best places on the internet to find inspiring, space-game/sci-fi ideas of remarkable breadth and depth, elaborated on by people of singular imagination and intellect." Since the KS closed at the end of 2012, there have been >1,000 topics and >20,000 posts in this subforum alone. It is a remarkable place -- one that I wish I had the time to read front-to-back. But that's just it: I don't. I don't even have enough time to read all of the beautiful, elaborately-thought-out gameplay suggestions generated by you all, much less implement them.

What I can do? What I'm really good at doing, as this whole process has taught me, and perhaps, what it is that I love doing above all else: it's probably not game design, it's probably not even procedural nebula algorithms ...no...building things that allow other people to realize creation with ease, simplicity, and power...now that is the kind of thing that can get me out of bed in the morning. And that's exactly what I/we have done. We've built something that can take a high-level, simple description of a new gameplay mechanism, and do everything that needs to be done behind-the-scenes to let that mechanism play nicely with a thousand others, in the presences of tens of thousands of entities stretched accross a boundless universe. We've built something that renders many of your suggestions doable in a few hundred lines of Lua or less. And THAT...I'm proud of that

Everyone knows that Morrowind was one of my favorite games of all time. And it still is. It's still cranking, 15 years after release (in 2002). People still play it, people still buy it, people still love it. All because Bethesda decided they would build their game with a Construction Set rather than pure code, thereby enabling others to add to their original vision (which was already fantastic) via that tool. And the result is that today, some of us are still talking about how stunning Morrowind looks with graphics overhaul 3.0 et al; some of us are still in awe that Tamriel Rebuilt is alive-and-kicking, expanding the vanilla game's playable area by god-only-knows how many square miles.

And this is my dream for Limit Theory: that it ships as the vision you all supported in 2012 + the modding capabilities that have since become a core feature, and that, in 10 years' time, it has become something utterly and totally beyond that which I could have done myself or with our small team in the same amount of time. I really can't wait

LindseyReid wrote: ↑

Fri Dec 01, 2017 7:41 pm

My plan moving forward is quite exciting: between now and the new year, I want to jam on generating a complete bomber-sized ship.

Spoiler:      SHOW

JoshParnell wrote: ↑

Wed Dec 20, 2017 12:57 pm

Limit Theory @ PAX South 2018

Hey everyone!

I'm going to be hopping on the devlog train in a moment here, but before I do, I want to get this information out ASAP so that anyone interested can make arrangements sooner rather than later. And the big news is...already spoiled by the title of this post!

We'll be demoing LT again at PAX South this year! When I say we, I mean all three of us from the office here will be going, so if you'd like to praise Adam for his stupidly-fast BSPs, or Lindsey for her stupidly-fast progress on great-looking ships, or me on my stupidly-lackluster ability to meet deadlines ...you can do any or all of the above!

PAX South will be held in San Antonio, TX and will run from Friday, January 12 to Sunday, January 14. We'll be there with an LT demo all three days, although at the moment, it appears that we may be closing up early on Sunday. I'm waiting for some clarification from the Tech Park on our Sunday schedule, and will update this post & thread as soon as I know for sure. So, if you're interested/able to come, pick whichever is most convenient for you, but don't bank on us being around after ~12ish on Sunday. The cost is $40 USD for a one-day pass. Unfortunately, it appears that the three-day passes are already sold out.

Official PAX South Site Links:
Registration & Purchasing a Pass
Full Schedule

As with last year, we're going as a group with the Louisiana Tech Park, so to find us you should look for some kind of signage related to "Louisiana Tech Park," "Baton Rouge Game Developers," or possibly "New Orleans Game Developers"...and of course, we will have a smaller sign with "Limit Theory" on it. Our setup will likely be a mounted HD TV with a gamepad, since we'll be pressed for space.

---

The Demo

As of this week we've started planning out and sprinting on features for the LT PAX demo. Naturally, since LT isn't ready to play yet (nor would the full game make for a compelling five-minute demo experience), our demo will aim to give 'a taste' of Limit Theory in a format that's more amenable to picking up a gamepad for a few minutes and having some fun. It will be unequivocally superior to last year's "war of the box 'ships' demo."

If all goes according to plan, we'll be showing off a combat demo wherein you must defend against progressively-more-difficult waves of attacking ships. Successful defense rewards the player with credits that can be used to purchase upgrades to weaponry, consumable items, full-ship upgrades, new AI teammates, and possibly more All of this will, of course, be happening in procedurally-generated systems with procedural asteroid fields, planets, nebulae, and (possibly) stations (although they may be of the 'old' variety since Lindsey is focused on ships at the moment).

Additionally, since Lindsey has made great progress with ships, we'll be integrating a 'ship generator UI' that allows for customization of the generating parameters, so that you can play around with customizing your ship and seeing the PCG work in real-time! She's got some great ideas concerning how we might even save the best user-generated ships so that they continue to pop up throughout the day (you may come back to find someone piloting or fighting a ship that you custom-generated!)

If you've got reasonable ideas/feature requests for the demo that you think would be fun for people to see, please post in the official LT PAX Demo Suggestions thread, but please read the first post before doing so!

---

If you're able to make it, then we look forward to meeting you! Otherwise, fret not, for there will surely be an abundance of shinies from the ordeal, including an endless fountain of screenies, some real-life pictures so you can see just how photogenic we programmers are, and hopefully some video capture of user play sessions.

• Nailed 3 ship types: classic, surreal, and tie.
• Made & then discarded a few other ship types- vertical, radial, for example.
• Pulled apart all ship generated algorithms into resuable parts - wings, hulls, engine, and gun all come in different algorithms than can be reusable by new ship types.
• Started adding customization properties for all of the ship generation types.
  • Added a new UI value type for enums to allow UI selection of which ship type to generate.
  • Put a few of the randomness properties (for ex, wing length) into the UI for customization
  • Leaving alone for now; waiting for new UI scheme to be done so that I can build the ship customization tool for PAX demo.

• Ellipsoid
• Torus
• Block (rectangular prism) (image is made of many blocks lol)
• Pyramid (currently only square pyramid)
• Icosahedron
• Prism
• Irregular prism (prism w/ random angles between each vertex on the base face)

• Greeble
• Stellate (per-poly and all over)
• Extrude (per-poly and all over)
• Bevel
• Bell-curve warps (applied as an all-over warp to make the ship have a subtle curve)

• Shapes, for storing polys & tris
• Joints & JointFields, for connecting Shapes

LindseyReid wrote: ↑

Thu Jan 18, 2018 3:47 pm

Limit Theory @ PAX South 2018 Recap

---

Hey everyone! If you didn't know already, we spent last weekend at PAX South showing off a Limit Theory demo at a booth on the expo floor. Since many of you couldn't make it, this post will recap what was in the demo and how PAX went. There are a few goofy developer photos and a demo video for you to enjoy

Here's a 3-minute clip of us playing with the demo! (there's no sound on purpose )

---

What Was In the Demo

The demo had two parts:
1, a small slice of combat in the form of a dogfighter, and
2, a small demo of the ship customizer.

At first, we designed the combat to have a goal, with the player needing to dodge bullets to retain health and earn credits from kills in order to buy ship upgrades. However, after just a few hours at PAX, we decided that making the player invulnerable and removing the goals was WAY more fun. Our idea of how big the demo needed to be for PAX was overestimated; people would drop by for a couple of minutes and really just want to fly around and shoot stuff. Dying wasn't so fun, and earning credits to upgrade parts was definitely out of the scope of what a short demo needed.

So, what we ended up with was a super simple dogfighter! The player had a certain amount of friendlies and an equal amount of enemies that would constantly respawn, and there was no final goal. Players could fly around and shoot the enemies, with a couple extra fun controls: pushing down the right stick would allow the player to spawn new friendlies and enemies, and the up and down buttons on the D-Pad allowed controlling friendlies. Up would tell the friendlies to go kill whatever enemy the player was locked on to, then return to the player; down would tell friendlies to find any random target, kill it, and then return to the player. Friendlies spawned with the right stick would follow the player in sphereical formation.

In addition, the game had a small ship customizer demo. The customizer allowed you to pick from the three fighter classes I've written so far (surreal, classic, and tie-like) and customize the shape and size of the wings and hull of the ship, as well as a couple of details like the surface detailing and overall warps. The full version will allow you to do much more, but this demo was in the small scope of what people would play with during their short stop at our PAX booth. Josh also added the ability to randomize a color pattern on the ship, which was cool and well-received.

---

How It Went

In short: really well! We had a constant stream of visitors to the booth with almost no downtime, and virtually everybody who played enjoyed it. We ran out of the 300 business cards we printed. People really enjoyed the dogfighting, and while fewer people used the ship customizer, those that did deeply enjoyed it and said things like "I could play with this all day!"

Josh made small tweaks to the code throughout PAX, sometimes to implement or change a feature (like when we made players invulnerable), to fix a small bug (of which we had very few), or to make a change a player asked for. One of our biggest requests, for example, was to make the control axes inverted, which we're certainly going to take note of.

Players also had a TON of fun with the 'spawn' button. We had several groups of people attempt to spawn as many NPCs as they could, with the goal of crashing the game. (Un?)fortunately, the game didn't crash from excessive NPC spawning, even when we had 10,000+ ships on screen. It did, however, start to slow down the framerate... after around 2000 ships. Thousands of ships flying in various formations, hundreds-of-thousands of pulse lasers, and all of it rendered with 2x supersampling (meaning rendered @ 4K and downsampled to 1080p) -- our work on performance optimization seems to have paid off. Players frequently expressed surprise at how smooth the game ran despite having loads of stuff going on

Here's one group of players who spawned 4000+ ships, with Josh smiling in the back, probably at our performance:

Spoiler:      SHOW

And here's Josh deep in the code, looking super exstatic about me (Lindsey) taking a coding selfie with him:

Spoiler:      SHOW

---

Fin

Overall, PAX was a great experience for us, both in marketing and for testing the game. We made real connections with fans old and new, from backers, to people who had heard about the game a couple of years ago, to people who were learning about it for the first time. The demo was also great test of our workflow for writing gameplay code and of our performance. We found a few things to clean up with regards to architecture that Josh and Adam are now working on. We're very, very close to going full-force on gameplay code, and the PAX demo was a great milestone for that.

Here are a couple of photos of the team in front of our booth.

Josh (left), Lindsey (middle), Adam (right):

Spoiler:      SHOW

Lindsey (left), Josh (middle), Adam (right):

Spoiler:      SHOW

That's all, folks! I hope this has satiated your curiosity about what went on at PAX. Here's the link to the demo video again. Feel free to ask more questions about what was in the demo and such, and thank you always for your continued support.

- The LT Team

JoshParnell wrote: ↑

Thu Jan 18, 2018 5:37 pm

Thursday, January 18, 2018

Greets everyone and Happy New Years / Merry Christmas (a bit late)! I had, as usual, intended to post before now, but the time since my last log has been absolutely jam-packed with pumping out work for our PAX Demo. Now that it's over, I'm excited to come back and add my own thoughts on how it went, as well as update you all on the progress that's been made leading up the the release.

Of course, I recommend reading the official PAX recap posted by Lindsey earlier today for a general overview of the event.

---

Progress Since Last Time...

It's going to be difficult for me to remember everything. It's rather scary how quickly we're able to implement vast swaths of functionality now that we're sitting pretty with respect to our supporting engine & lower-level systems! You'll have to excuse the wall-of-bullet points and the scatterbrained parenthetical thoughts accompanying them.

• Added working pulse laser turrets, muzzle flashes, thrusters with engine trails, explosions, and several other effects (some ported from LTC++, some brand-new)
• Ported & improved AI architecture from LTC++; implemented escort, formation flying, dogfighting, and a few other AI actions
• Added AI squad management & hierarchical formation (WIP -- currently the squad disbands into individual units if the leader is destroyed, although this was actually a neat feature for the demo)
• Added ownership and asset tracking; all relevant objects now belong to an ownership hierarchy (in the demo, assets are owned by either the human player or an AI player who is controlling the actions of enemy squads)
• Added thruster overloading ('boosting'); added AI ability to use boost (still need to generalize to all ship hardpoints to have generic 'hardpoint overclocking')
• Added energy grid / capacitor component for 'real' energy mechanics (like in LTP); note that we had infinite energy enabled in the demo for fun (hence why the left capacitor bar never depletes when firing or boosting)
• Added basic manufacturing component; the home base station in the demo is actually capable of manufacturing ships using a build queue and pseudo-blueprints, although we ended up not using this functionality due to reasons given by Lindsey in the recap (complex game mechanics ended up being less approachable for a play-for-a-few-minutes demo)
• Added basic HUD with working soft and hard target locking, forward reticles ('lead indicators'), capacitor and health meters, and optional auto-targetting (turned off for most of the demo)
• Added disposition tracking to allow dynamic inter-person / inter-faction relations (the enemies in the demo are shown as enemies not because they are in any special 'enemy' list, but because the human player and the AI player controlling them are set to have maximally-hostile standing with one other)
• Enabled & extended a proof-of-concept paint shader on metal assets to allow per-ship/per-station coloring
• Added dust clouds (still need work to be more subtle at high velocities -- a problem numerous people pointed out in LTC++ ); improved dust flecks to be more subtle
• Added several post-processing effects for use with alternative view modes like the ship editor / slow-time action camera
• Added velocity-dependent radial blur (currently a bit too aggressive?)
• Major optimizations to rendering architecture, especially with respect to supersampling -- we ran the demo at 100+ FPS with 2x supersampling on my laptop
• Made everything work on gamepads + improved engine-level support for joysticks, gamepads, HOTAS, etc.
• Partially-implemented an active deflector shield (for fun) that reflects energy weapons -- didn't finish in time for PAX, but may keep the idea of an 'active' shield mechanic on top of passive shields
• Improved chase camera dynamics for more 'classic Freelancer' feeling (still perfecting it, but we're definitely getting somewhere!)

Indeed, quite a lot of quality functionality came about thanks to our PAX sprint! Note, in particular, how this list, in contrast to so many of my recent lists, is very much brimming with gameplay and immediately-related-to-gameplay features

---

Takeaways from PAX

Naturally there was a lot to be gleaned from publicly demoing a slice of the game for the first time since last year, but I think, if I had to put my finger on something concrete (other than just 'people are really going to enjoy this labor of love'), it would be the comfort with which I walked away from the experience. Comfort that the tireless, seemingly-never-ending Royal Crusade Against the Excessive Usage of Milliseconds (aka 'performance optimization') has genuinely paid off. Perhaps even more broadly, comfort that the unspeakable hours that have been put into solving FPLT ever since the fall of LTC++ have truly been worth the pain that they all-to-frequently caused.

If I were to boot up the old LTC++ and try to push it to do what our current setup did at the PAX, it would have been a spectacular display of tears and molten lava -- the former pouring from me, the latter pouring from my laptop. We are easily pushing 10x the amount of activity with extremely high, consistent framerate. We can push 100x the activity almost as easily, although there are a few choice places to which I must make small tweaks before 1000+ ship battles will be as buttery-smooth as the 100+ battles are currently. All the while, we're not only putting more entities in the world, but the amount of dynamism is starkly superior to LTC++. That demo is running full collision on all entities -- NPC ships collide with one another and with every asteroid in the scene; ramming small asteroids sends them flying off into the abyss; slowly pushing a large asteroid is even feasible with a large enough fleet. The AI is driving thousands of turrets accross hundreds of ships, each computing viable firing solutions. Friendly-fire is turned off for the demo, but projectiles still collide with everything in the scene. The collision is still slightly coarse (you will 'bounce' off of asteroids slightly sooner than expected), but this will be remedied with the help of Adam's InsaneBSPs. All those little details add up quickly into an experience that feels genuine, deep, and rich with opportunity.

All-in-all, what we have going on is exactly what LT promised to provide, and what I've thrashed my neurons for so many years to make possible: a universe alive with activity. In the demo, that activity is a bit boring, what with the AI only thinking about shooting things. But imagine the same scale of activity applied to a diversity of gameplay mechanics -- trading, exploring, mining, patrolling, constructing, researching, so on and so forth -- and you are left with the vision of a vibrant, living universe that captured the enthusiasm of so many (including myself) at the outset of LT. A single player experience in which you are far from alone

Working on the demo reinvigorated me in so many ways. Seeing even the simplest of gameplay mechanics come together to create moments of fun; having new gameplay ideas that required only an hour or two to bring to life; falling back in love with writing AI...it was all very therapeutic

The icing on the cake, of course, was player response. As mentioned by Lindsey in the PAX recap, we had numerous players express their amazement at the sheer amount of 'stuff' going on (especially those who spawned hundreds/thousands of AI escorts, expecting a crash but instead finding only a very gradual FPS degradation). We received plenty of compliments about the beautiful visual style, the smooth and responsive feeling of it all, the joy of being able to issue orders to a fleet, the quality of the procedural assets (Lindsey's ship generator amazed more than a few people, especially once she had made clear that the ships were procedural down to the very vertex, not simply lego-style recombinations of prefab assets). Even with such a small taste of the full Limit Theory experience, people responded really positively. Yet again, it brings me comfort and excitement -- for if just a tiny morsel of the cake is enjoyable, surely the full experience that awaits you all at launch will satisfy

---

Going Forward

The sprint to PAX functionality gave us a chance to see how our various systems and architectures performed not just with respect to runtime, but with respect to developer time -- the second half of FPLT is, after all, making this raw engine power easy to harness and sculpt into something that matters. For the most part, I'd say we succeeded there as well. However, as was to be expected, pushing content into the demo in such a short time gave us critical insights into where things are too complex or less-than-intuitive.

Adam and I are going to spend the rest of the month doing a sort of PAX-postmortem, taking some time while we have it to deal with those hitches that affected our PAX demo development efficiency (and will, by extension, impact our dev efficiency going forward toward release.)

On my side, perhaps the biggest challenge remaining is moving our PAX demo into mod format. As you may recall from my last log, the mod format was well-underway at the time. As it stands today, it's more-or-less complete, but yet again, moving over representative gameplay snippets like some of those developed for the demo will reveal the true efficacy of a system that looks fantastic on paper.

I'm really looking forward to the next few weeks, as I think it's going to continue to be a lot of fun writing new gameplay, listening closely to see what the code is telling us about our architecture, and iterating until we're doing bigger and bigger things with less and less effort. The PAX demo marked the true start of the ramp-up into gameplay code. The rest of the month will be an outward spiral of ramp-up and ramping-up the ramp-up (you know, d2G/dt2, where G(t) is gameplay ).

Thanks for listening

---

I put together a small album of some of the screenshots I took during PAX (and a few after). Mostly of people doing absurd things :V Please note that the radial blur & horizontal screen effects were just a little PAX polish for making the camera modes look distinct. LT does not have the outer portion of the screen blurred out most of the time

Limit Theory Devlog Gallery ~ January 18, 2018

interface IButton
{
  bool IsPressed  { get; }
  bool IsHeld     { get; }
  bool IsReleased { get; }

  void Update();
}

interface IAxis
{
  float Value      { get; }
  float Deadzone   { get; }
  bool  IsInverted { get; }

  void Update();
}

class ButtonToAxis : IAxis
{
  private IButton button;
  // ...
}

class AxisToButton : IButton
{
  private IAxis axis;
  // ...
}

Spoiler:      SHOW

• Integrated FMOD for audio support.
• Attached very quiet cantina music to asteroids and watched Lindsey go slightly insane trying to figure out why she has Star Wars stuck in her brain.
• Sniped revisions 1000 and 1024 from Josh and made really boring commits.
• Played around with tooling for merging / viewing / debugging mods.
• Moved in with my girlfriend.
• Got a puppy!
• Gave said puppy a trial run as head of the Office Happiness Enhancement Department
  (she'll be back for a second round of trials in March).

Spoiler:      SHOW

• A finished mod format that's functional, granular, and generally awesome
• Support in the mod format for whatever 'categories' of game content we want to add in the future, for example, Item Types, AI Behaviors, Procedural Generators, Settings, and so on (if you look carefully you can see that the mod format handles these all in the same, unified way)
• Ability to create new mods (that can have any number of dependencies, or none -- Core is built the same as any other mod, it just doesn't depend on anything!), load & save them, automatic backups, visual highlights on changes made by the active mod, arbitrarily-deep undo & redo (which is actually tightly-related to the mod format), ...and so much more
• All of the above written in Lua, making it super-fast for me to add functionality; ImGui functions are bound & injected into Lua automatically
• In-editor OpenGL integration and Lua bindings for OpenGL, making it possible for us to create development visualization & simulation tools limited only by our imaginations (procedural algorithm rapid iteration, material editors, historical simulation sandboxes, dynamic economy simulations, you name it! As a bonus, since it's in Lua, we can run pieces of the game code directly in the editor, no extra work required!)
• An engine-side loader & compiler that takes in an 'active mod list' and compiles the merged data down to code that interfaces with all of our existing tech (ECS/CTypes, engine-side functions, Lua utility libraries, etc.)
• An inspiring workflow!!
• A 'Core' mod representing Vanilla LT that is already well-underway
• A dramatically-nicer workflow and a happier Josh