Thursday, April 13, 2017
Rawr. I had almost finished this log when I accidentally closed it before having saved. Why hadn't I been aggressively saving after every few keystrokes like I usually do when I'm in vim? We will never know the answer
Please forgive me if I'm more terse this second time around...
Last week I gave myself "full permission to do nothing but ECS work." And boy did I take that permission and run with it. Frustratingly, I'm not yet able to come back with a happy 'I GOT IT YAYYY!' like I wanted to.
---Entity Component System
: What can I say? I am finding that building this thing requires taking into account a massive number of factors at all times, making it slow and mentally-taxing. I showed last week how I've been writing gameplay pseudocode to help guide me as I architect this thing. In a continued spirit of practicality, I did more of that this week, but additionally went so far as to write down a detailed list of every entity that I anticipate being in LT 1.0, along with every 'component' / piece of data and functionality that I anticipate said entities to need. At least this moves some of the factors I must consider onto the screen and out of my brain.
Doing so was quite revealling: it reinforced in my mind that very few components require 'special treatment' for performance. Virtually everything that does
require special treatment can be grouped under a broad interpretation of 'related to physics.' Thrusters are the odd-man-out, as they require special treatment for rendering purposes. Whether I can gerrymander said special treatment into the realm of Lua via some magic or another (I do have ideas) is still unknown. Basically, I'd like to be able to fence off all such special treatment and shrink it to the minimal viable subset. I'd then like to draw a big line in the sand between C and Lua that makes said special treatment 'not the concern' of the gameplay programmer (aka me + mod writers). This is a Really Hard™ problem that I've tried attacking from a million different angles and will continue to attack from a million more until one angle finally prevails.
The TL;DR of the technical details is: they haven't been solidified. The technique to which I alluded in my last log (as well as the long post I made in that thread, in which some details of that ECS architecture were revealed as the 'first level' of the mod API) has been put aside after further consideration as being over-engineered. If it comes down to it, I'll come back to that one. But my review of the actual needs
of LT gameplay showed me that it's probably overkill to use Lua to give metacode-style definitions of ECS-related data to the engine, which then JIT compiles them to native code. I now believe a less 'heavy-handed' approach is feasible by drawing the aforementioned line in the sand carefully enough. I'm currently working on such an approach.Mod Loader / Hooks / Environment
: Believe it or not, one of the easiest ways for me to audition ECS ideas is to treat them like mods. All it really does is force me to write highly-compartmentalized logic and to think in terms of events and event hooks (which I need to be doing). The end result is that I can swap out different ECS ideas (at least on the Lua front) without breaking other things.
To get this all working, I of course had to write a basic mod loader (which is very, very easy in Lua), define some initial engine-level event hooks, and hammer down a format for mods. It was all quite rewarding. Mods, at least those that operate only on code (rather than adding or replacing new non-code assets) already work, because I'm implementing my ECS ideas that way, which makes prototyping very quick!
I developed several neat facilities for the mod system. Sandboxing was a big one (mods can't access arbitrary stuff from the outside world), and Lua again makes this very easy. It's easy to make sure that mods don't, for example, plug into the filesystem and start deleting your C drive. The way it works currently is that mods have to explicitly
request access to the APIs that they need. Without an API request, mods have virtually no power (they can't even use basic (unsafe) Lua statements like require!) So if I want to use the function 'Draw.Rect' anywhere in my mod's code, I need to add 'Draw' to the list of APIs that is requests usage of (which is done by adding to a list in an 'info' table that every mod defines which contains name, description, version, dependencies, apis, and more). If I don't, the engine won't inject the API into my mod's environment, so my mod will simply cause a crash when it tries to use a function from the Draw API. This is very cool, because it allows the game tight control over what mods do, and can provide modders and users alike with detailed information. No hidden network access attempts
It also makes it easy for me to reason about my own code dependencies while I develop. And for one more bonus, it makes debugging easier, because I can see exactly what 'mod' (remember that I'm using them right now to prototype things) caused a crash or even issued a print statement.Physically-Based Rendering Stuff
: Ok, so I admit that, after more than a week of waging ECS war, I needed a break yesterday evening. I gave the evening to graphics Josh
I implemented the 'blind-you-with-all-the-things' style of HDR boom that seems so characteristic of high-end engines these days. It does look impressive. I'll turn it down a lot though...with it fully-enabled, the lighting in LT is literally blindingly-gorgeous
I also ported some of the PBR stuff from LTC++. I don't have the stamina since this is my second go at writing the log to talk details, so I'll just spew words this time. GGX environment map generation, better math this time (so arctangent, very sqrt, much spherical coordinates...wooww), faster as well; lighting just looks better with PBR yayy; combine it with above bloom tech and wowww beautiful reflections, eyes bleeding in all the right places. There you have it.
Guess what I'm (still) giving myself full permission to do in the coming week? Yes. ECS. Send your mental clarity vibes, I need them.
Hello again everyone! Talvieno here with a non-technical summary of this week's devlog.
Since our last update, Josh has been trying to figure out the ECS (Entity Component System) - the thing that makes ships, stations, asteroids, and more. It's a tough problem to work out. He wants modders to be able to access the bits they need (in Lua), while still keeping the slower portions in the faster C code (the LT core). Figuring out which bits go where (and how to make them all work together) is kind of tricky, but he's working on it.
Part of working on it is actually making "mods" to test it out. Josh can now load "mods" into the game, which is helping him figure out how to structure the ECS. As an added bonus, he's fixed the modloading process so that you can't make mods that do things they're not supposed to - like deleting everything on your hard drive or connecting to the Internet and downloading things. This is pretty much a necessity anyway, but he's come up with a clever way of doing it that he's proud of.
Finally - he made the game shinier. The graphics monkey has escaped, ladies and gentlemen - can we ever put it back into its cage now that it's released?
(It was only an evening's worth of graphic monkey, though, so we should be fine.
) He implemented HDR bloom - a shiny glow you typically see from particularly bright light sources like sunlight. He's also ported some of his PBR code from the old LT version, so LT looks very pretty. (PBR is a lighting model that attempts to make materials model the flow of light the same way as you would see in the real world. This means more realistic-looking textures.)
tl;dr: Josh is working on the whole ship/station/asteroid problem and it's more difficult than he expected. He also added in some pretty graphics additions yesterday.