Sunday, October 12, 2014

Not much to report today, unfortunately, probably because I'm trying to work on too many pieces of content at once Nothing complete yet, but so many things in progress Plenty of time to bring them all to completion by the end of the month, though

Wait for me folks, I'm going to try to focus a little more on one element tomorrow (the overhead testbed) so that I can get a little completion going on.

In the background, though, I'm getting more and more excited as I shift my thought patterns towards content and away from tech. I've always thought it's more fun to think about tech (since I'm a developer)...but with the tech in line, it's starting to get more and more fun to think about gameplay I think that's a real good sign. The next few months are going to be shaped a lot by gamer Josh, and for that I'm thankful. After all, it's he who wanted this whole Limit Theory thing in the first place

PS ~ I tried, for a brief moment, to work outside today...and nearly got blown away by the wind Fall is coming quickly upon us here in Tennessee...hopefully it won't take the house with it

PPS ~ Been thinking today about a new testbed: a simple player vs. AI dogfight scenario where I can work on making player-side combat as gripping as possible. That kind of thing should be super easy to set up! Oh the possibilities...

Monday, October 13, 2014

Nope, still didn't get that focus Couldn't resist. As I worked in my overhead testbed today, I just kept thinking, man, it really sucks that there's no "Open Trade Market" option in that right-click radial menu when I click on a station. Naturally, I was once again distracted by this mysterious trade interface work (which I have kept tightly under wraps in the last video, as you probably noticed )

At this rate, I'm fairly sure that the trade interface is going to make an appearance in October's video. But what looks like some seemingly-innocent interface work actually brings up a host of deeper questions pertaining to trade in LT. Today I thought a lot about the accessibility of trade with other entities. I'd like to open up two of the bigger questions for discussion:

Can transactions be made remotely? If so, at what 'distance'? I think the coarse answer here is pretty easy: yes, it makes sense that we can open markets and buy / sell without having to dock -- but it also makes sense that the transactions are made using on-site storage. So buying something remotely means you now have it in your storage locker at the location of the transaction. But the details are more interesting. How close do I need to be to make transactions? Do I need to just be in-system? Or do I need to be within visible range?

Can transactions be made directly through owned ships? In other words, if I own a ship in another system and that ship is in such a state that it can perform a transaction with an entity in that system...do I have the ability to actually directly manage that transaction? Can I pull up a far-away station's trade interface if one of my fleets is docked there? Or must I perform the transaction 'indirectly' by giving orders to the AI pilots ('attempt to buy X in system Y for <= Z price')

Yes indeed, we're getting to that point where a lot of the abstract notions start to come down to concrete details, and with the concrete comes questions. Luckily, since 'details' are implemented in script, there's never too much pressure to get the answer right the first time, as iteration will no doubt take its due course

Another day, another trade. Look forward to it

Tuesday, October 14, 2014

Can't help but continue yesterday's trade work I like where it's taking me.

Today I dove back into the existing AI trade structure that already exists internally, but has not been externally visible for a while -- that is, the mechanism whereby AI players set up projects and manage the inputs and outputs by buying / selling at markets. As a first step to getting back into this work, I'm pulling the 'detailed' commodity market interface back into the game via the new LTSL interface. I haven't finished yet, but I'm really loving how easy it feels to re-work inside the new interface. There was quite a bit of odd space usage in the node UI, especially for things like lists (for example, buy / sell orders), where nodality just felt awkward. With our newborn LTSL interface structures, everything feels a lot better I also continued yesterday's work on the basic trade view, and am dangerously close to having the searchable list-and-or-tile-view container that I always wanted to have in the node UI but never quite managed to pull off.

With both the (simple) market view along with the detailed commodity both coming back into the game, it's looking like October is going to be a great month for trade, which is fantastic, because the commodity market is perhaps one of the most fundamental backbones of the game.

I wish I had more to say today, but I don't, so I'm going to leave it at that Looking forward to yet another day of enjoying the thrills of all my powertool toys It's already been such a fun week

PS ~ Yes, we've really got to do something about that devlog deficit Gonna try to work on that...

Wednesday, October 15, 2014

Today is a tremendously-exciting day. Why, you ask? Because today, my friends...today, the first LT mod was born. His name is Luke...a tribute to the one who restored balance to the force. He sits humbly in the LT 'mod' directory. He's not much of a mod, to be perfectly honest. All he does is change the primary interface color, and tweak the background stars in the LT skies to be a bit brighter. Odd combination of functionality for a mod

But the important thing is not what Luke does. It's how he does it. As of today, the mechanism to support mods actually exists and is fully-functional in LT, and Luke is just a demonstration of that. In principle, he can override any of the numerous pieces of the game that live as external resources rather than hard code. He can override specific scripts, add new ones, or even get fancy -- override or extend any of the shader code, sound effects, fonts, etc.

The mechanism behind modding is fairly simple: instead of loading resources directly by file path, the LT engine now creates a 'map' of resources that takes into account mods. It first populates the map with all of the default resources, but then loads all mods in the 'mod' directory, which may add new resources to the map or override the paths of existing ones (e.g., replacing the default LT resources with new, modded ones). Then, whenever the engine needs to access a resource, the access is routed through the resource map, which means whoever asked for a resource will get the newest, most overridden version of it.

It's simple, really, and only took a day to implement. But the power is pretty obvious: there's not really anything that you can't do with this scheme. What more do you need than to add resources or replace existing ones? I'm sure this is how mods for most games work. But still, I'm proud to have it in LT now

An interesting thought occurred to me after I had finished the work: this is actually a really cool way to test out 'big changes' that I might want to make to game functionality without touching the vanilla code. It could work a bit like version control, which I already have, but which is much more complex than this simple little modding scheme. If I want to test-drive a total rewrite of the AI planning algorithm, no need to go in and mess with all the vanilla code -- why not just override the corresponding task script with a mod? If it works well, then great...we can replace the vanilla code. If not, just delete the mod (or place it in a directory of 'failed experiments') and move on with life.

Very, very happy to have all of this working already

Thursday, October 16, 2014

Catch-up day!

Yes indeed, sometimes they just have to happen. I've spoken about these mysterious entities before: beasts that arise from my natural tendency to neglect all that is not code during the usual, LT-all-day-every-day regimen. On the off day, of course, I neglect everything that isn't purely fun. This leaves a rather large volume of elements that lie awkwardly between code and fun that just...don't get any love

Today I nailed them all at once The primary element was a tire change, the necessity of which became apparent to me on the last drive home from the supermarket, during which I had the pleasure of feeling my car lose contact with the road for a fractional second during a rather intense turn Heh. Not something one should neglect, I think

Other than that, my day consisted of a haircut, buying office supplies, and...cleaning up a rather large, mysterious puddle of water that appeared in the middle of one of the downstairs rooms in the quiet of the night. Quite frankly I'm not sure where it came from, nor how long it's been there But a basket of towels later it departed me. Anyone who reads the devlogs regularly will know that this has been a shockingly-bad year for me and water I now live in fear of this winter's snow

So. All caught up on life. Or at least, adequately so. With the hair now out of my face, my tires safely hugging the road again, my pens and notebooks re-stocked, and the house once more clean and free of standing water (for now...), I am prepared to take up the mighty sword of coding and continue the battle against time.

Tomorrow, the code flows once more

PS ~ Seriously...prayers, voodoo, wiccan rituals, or whatever else you might be able to use to keep water out of my house would be welcomed with open arms

Friday, October 17, 2014

Rawr. One of those days

So today, I decided it was finally time to man up and embark on the quest to fix a very mysterious error in LTSL compilation. For quite some time, I've been experiencing a rather scary thing: about 1 in every 40 or 50 LTSL script compilations would fail. Programmers typically live in fear of these kinds of errors -- the kind where the same thing works almost all of the time but will fail every once in a while. Generally, in my experience, these problems either come down to threading issues or memory initialization issues. These are the only two places (at least that I have experienced) where we regularly see indeterminism (the exact same code with the exact same inputs executes in a different way). Since LTSL compilation is not multithreaded, one would deduce that the problem lies in memory initialization.

The issue, however, brings up a bigger one: that the compiler needs better error reporting. During normal coding, it's fine to see "expression (blah blah blah) failed to compile" and the few other errors that the compiler generates, because I know that I've made a mistake and I'm familiar enough with the language to be able to fix it quickly. But when I see "expression (blah blah blah) failed to compile" and I know that (blah blah blah) is actually a correct expression...that's when I really need more information. In general, the compiler needs to not only say what failed, but also explain why.

This led me back through augmentation of all the compiler code to add optional error outputting. This means that when something fails to compile, the compiler can flip a switch to turn on error reporting, and then re-run the compilation to generate a detailed picture of what went wrong. Doing so took...quite some time.

Here's the good news: the LTSL compiler is now a thorough error reporter The other good news is that, thanks to this, I know exactly where and how the compilation is failing on these strange 1-in-50 problematic runs. The bad news? Well, I haven't actually had enough time yet to dive in and fix what's failing (I only just got the detailed error reporting working).

I imagine, since I now have all the right information, I will be blowing out the candle on this error within the next few hours Yes, a bit of an annoying distraction from our content push, but nonetheless something that absolutely must be fixed before release I'm anxious to get back to the 'fun' devlogs as well



PS ~ If you're wondering whether I still think LTSL was 'worth the trouble,' given the dev time + debug time...my answer would still be an unequivocal, resounding "YES!!!"

PPS ~ A strange idea for 'unified math' using neural computation popped into my head today. Yet another reason why I'm anxious to wrap up LT -- it's getting hard to ignore all the other ideas that my work is spawning

Saturday, October 18, 2014

Yes, one of those days! But the opposite kind from yesterday!

Actually, it's one of those days where I think we need to do the list...

• Continued work on system layout generator, finally delving back into multi-planet systems. This is great news! Sadly, these systems really need...
• Continued work on warp tunnels, but not as much as I would have liked (see below!) I need these things this month. I need them now so that we can move back into massive, many-zone systems without using that little 'jump to object' dev tool cheat.
• Finished bringing detailed commodity view into the new interface (with LTSL)! Like all things, I look forward to rapid iteration on this little gem of a widget (I am a big fan of LT's detailed commodity view ).
• Started work on unified asset caching. I've spoken about this several times before, and I'm starting to get impatient for it, as it impairs the loading time of my HUD, colony, and overhead testbeds. I need for all procedural assets to have a unified mechanism for saving to / loading from a disk cache. I've spoken about how I plan to implement this as generalized LTSL function caching, and that's what I'm working toward now! Honestly, though, it's a bit hairier than I expected. The problem has roots that go fairly deep in the engine. Still, once we rip that bit of inefficiency out, we're going to see yet another major drop in loading times. In fact, this is probably the only major bottleneck that remains in terms of loading.

The only thing I want to talk about in more detail is warp tunnels. They're progressing too slowly for my liking. Part of the problem is that I can't isolate them in a testbed yet, as I don't have the ability to render arbitrary models in a widget. That must change! As I said on my planning day, one of my goals for the month is to have a model viewer widget (note: a related, but much easier goal, is to have a texture viewer widget). Perhaps more than anything, warp tunnels just need this widget to progress. Iteration is too slow right now and it's frustrating trying to bring them to match the visual fidelity of the rest of the world when I can't tweak and reload quickly. This widget needs to happen soon -- and warp tunnels aren't the only thing that will benefit (fast iteration on models means we may finally see gas giants, the return of ice, and of course, faster improvements to the ship / station / planet generators!)

PS ~ Oh yes, of course, about that bug from yesterday -- we killed it Memory initialization issues indeed. Rawr.