Page 1 of 1

Week of December 21, 2014

Posted: Mon Dec 22, 2014 5:03 pm
by JoshParnell
Sunday, December 21, 2014

*Sigh* Another day, another unimpressive amount of time spent on LT. Today's excuse? Christmas shopping.

Normally I wouldn't be feeling so guilty about this, given that it's the holidays and all. But this time is different...I really need to get this next 'update' (not a typical update, mind you, so no filming process required :ghost:) out so that I can let everyone know how the dev process & beta process are going to proceed from this point. Need to get it out now :shock: But I cannot and will not come empty-handed!! :D

Well, tomorrow's another day. No Christmas shopping required. More work time? Let's hope :geek: Oh, and tomorrow (22) is the second anniversary of LT's successful KS. What a great day that was :D Woohoo :clap:

Re: Week of December 21, 2014

Posted: Tue Dec 23, 2014 6:29 pm
by JoshParnell
Monday, December 22, 2014

Scattered day, but good one! :geek:

First and foremost, I implemented per-system history buffers as well as the logic for having events automatically registered with that buffer. So we now have systems with history :) We also have LTSL-exposed code to retrieve those history buffers.

I also introduced 'Action's to the game today. What I realized is that there's a subtle problem with the way I envisioned events: they should not be thought of as driving forces of the game state, but rather, as descriptions of how the game state changed. There's a bit of a difference there, and to clarify that difference, I introduced Actions. An action is an attempt to change the game state. '<transferunit> mine <target> at <point>' is an action that will be emitted by an active transfer unit. '<transferunit> mined <quantity> units of <item> from <target>' is an event that may or may not be emitted by the aforementioned action. See the difference? Between an action and an event lies the real game logic (which may include some randomness), which determines how the attempts to change game state turn into real changes in state. Also note that a single action may cause no events, or one, or many. An attempt to mine may not yield any ore in a given tick, hence no event or state change occurs. An attempt to apply damage to an object may result in not only a damage event, but also a destruction event!

Looking toward the near future, actions are also part of the groundwork for LOD simulation. When I introduce coarse simulation, I will also introduce a mechanism whereby game objects can execute actions in different situations, depending on the level of simulation. For example, at the most-detailed-level of simulation, a Mine action can be emitted only by an active transfer unit that has verified that it's in contact with a target. At a more coarse level of simulation, though, we may allow the 'Mine' AI task to directly emit such an action for each transfer unit -- hence, we may completely skip consideration of collision or detailed asteroid geometry, and mine 'directly' for the sake of performance. Actions are a great step toward LOD simulation, without introducing any branching game logic (in other words, we can obtain LOD simulation by changing the context in which game logic is executed rather than having to change the logic itself).

Next up, I did a good bit more thinking about text generation. As embarrassingly-obvious as they sound, I did come to a few realizations about the nature of AI communications. Perhaps the biggest one is that every element of the generated text must communicate a piece of information. Wow Josh, are you telling me that language is for communicating information!?!? Incredible!! :roll: :ghost: No but seriously, it wasn't so easy finding direction in this problem. The next idea was to use the '5 Ws' to think about communication: who, what, when, where, why. This is a very succinct way to describe the information that should be conveyed by, for example, a news entry. It's also a perfect summary of the information that should be contained in every event that gets added to a system's history. I've got all of these in my events already, except for the why. As you might guess, that one's going to be trickier!

Despite having this basic understanding of the structure of communication, I'm still a long way from having a working communications generator. What I really need is a series of about five or six -- maybe seven -- amazing conceptual breakthroughs :lol: It's an exciting problem though, and the day that I'm able to pull up a communication window with an AI player and feel their personality dripping through the messages...this will be such an awesome day :D

More work required for tomorrow. I know. :crazy:

Re: Week of December 21, 2014

Posted: Wed Dec 24, 2014 4:30 pm
by JoshParnell
Tuesday, December 23, 2014

Well. That wasn't the day I was looking for :? I'll have to write it off as yet another casualty of the holiday season :ghost:

But you know, at least I had the spirit of Limit Theory in my heart all day, and was pouring forth much spacey cheer whenever relatives asked about how my project was going :roll:

Alright. Please excuse me while I get back to attempting to suppress my guilt with chocolate and Christmas cookies :shifty: But seriously. I should have more time tomorrow. Otherwise, I may explode due to the pressure of too much unused 'code potential energy' building up in my body :ghost:

In the mean time, hope you all are having an enjoyable holiday season :wave:

Re: Week of December 21, 2014

Posted: Thu Dec 25, 2014 6:52 pm
by JoshParnell
Wednesday, December 24, 2014

'Twas a special mission indeed. Every miner worth his salt knows about the legendary North Pole system. A single, mysterious wormhole links it in from the the ELF-001 sector. Thing is, unlike every other wormhole in the known universe, the NP hole is neither stable nor unstable. It's periodic. And it's the only one out there -- at least that anyone knows of. Most holes stick around, or they destabilize and are gone forever. Not ELF-001->NP. It opens up for a short period of time during a constant interval. Funny thing is, measured in the ancient calendar year of the original Limit Theorist colony, it opens for exactly one day of the 365-day year. But the interior? Far more mysterious than the gateway. A cold, crystalline world of ice lies within. Strange flakes of water ebb and flow in the vacuum of space. Ice dust collects on all that lies within. The laws of physics as we know them are bent -- no, completely broken.

But all of this is secondary to the real beauty of the NP system. Aside from the hauntingly-beautiful vistas, it offers riches worth more than all the holiday cheer in the inner-world colonies combined...for within, as rumor has it, the roids offer bounties of cold, hard, compressed Santite ore. To the right buyer, the stuff's worth about a million-and-a-half credits per kilo.

It would be cold. It would be dangerous. But I knew that, if I were to pull it off....well, it'd be one hell of a stocking stuffer to myself. After all, I had been a good boy this year, right? What with helping set up that recon station in Omicron 8 when no one else would touch the system with a ten-lightyear beam. It was time for a reward. So at 11:59 on the ancient calendar day of December 24, I found myself at the exact coordinates of the ELF-001->NP hole. By 12:01, I had journeyed into the forbidden land of ice.

(Click for full-res)

Welcome to the promised land.
Spoiler:      SHOW
My's full of ORE!! :squirrel:
Spoiler:      SHOW
Merry Christmas to me :cool:
Spoiler:      SHOW
What the...who... :shock: :o
Spoiler:      SHOW
Taking fire!!! This fool must hate Santite!!! :shock: :x
Spoiler:      SHOW
Too bad I'm faster than you, buddy ;)
Spoiler:      SHOW
Back to enjoying my prize!! :D
Spoiler:      SHOW
And so it was a successful voyage.

Merry Christmas and Happy Holidays to you all! May your cargo holds be ever-brimming with ore, may your transfer beams always strike true, and may your market orders find rapid fulfillment and bring you great prosperity!


PS ~ If you're wondering why it took so long, one contributing factor would be...I wrote this devlog directly in the you all have probably seen in the past, this is a dangerous thing to do. Sure enough, after getting to within an inch of finishing it the first time, my old nemesis the Ghost of Ctrl-W came to greet me. Wow. All I have to say is THANKS phpbb for NOT having a 'confirm navigate away from this page' feature when we're posting. Seriously. How hard would that be :x But I do think it turned out better the second time, so all is well.

PPS ~ I got a lot of Star Wars goodies for Christmas. Awesome :lol: (Yeah, so what if I'm 23, I'm still allowed to love Star Wars shirts :shifty: )

Re: Week of December 21, 2014

Posted: Fri Dec 26, 2014 4:26 pm
by JoshParnell
Thursday, December 25, 2014

Not much of a day folks, but not for the obvious reasons (Santa and such). Rather, I've been hit with another round of ye olde winter maladies. This time with extra head fuzz!! :crazy: So what's a poor young man to do on an overcast Christmas Day if his head is the site of a raging battle between cold and cold medicine? Surely there can be only one answer: watch Christmas movies! :D

No doubt, it has been a rather disappointing homestay in terms of amount of work done. I'm not sure what to make of this. But I know that, one way or another, there will be a day of reckoning -- a day of untold hours and ungodly focus -- that will pay off this nasty little debt that I seem to have picked up here during the holiday season. I can only hope that this day of reckoning will come sooner rather than later :ghost:

On the bright side, before the fuzz set in, I was able to implement a new functionality that I call widget 'gathering' for displaying custom info in the object information panel. Previously, every object had a 'GetWidget' function that could return an object-specific widget to be shown in the object information panel. This was used, for example, to implement the colony cultural traits display that you've all seen when I pull up the information on a colony. This new technique, which I call 'gathering,' simply generalizes this idea to allow objects to have many custom widgets. Rather than being implemented via a traditional virtual function, widget gathering is implemented entirely via the messaging system, which means that any component of an object that can respond to messages can also (dynamically) push custom widgets into the gathered list of widgets.

The motivating factor here is to allow scripts that are executing on an object to expose their own widgets. It's particularly critical for objects like Colonies, whose logic is almost entirely dictated by script. With widget gathering, colony logic can display information about the colony (like population, cultural items, quality-of-life, etc.) that exists only locally in a script (unlike, for example, the cultural trait vector, which is an attribute of the colony object that everyone can see). This is going to be an exceptionally-useful paradigm both for colony logic as well as for modders. Object scripts will no doubt be a weapon of choice for extending gameplay logic, and allowing said scripts to push their own widgets into the object information panel makes it tremendously-easy to display information, or even allow interaction with the script :thumbup:

It's worth noting, though, that since gathering is implemented very generally via the message system, it doesn't only apply to object scripts. Certain other components of objects are also wired into the messaging system -- most notably, tasks! So, in theory, this means that the active task can also respond to the gather message. In principle, we could use this to implement a 'control widget' for the active task directly within the object information window (i.e., a place to quickly change the details of a task that one of your assets is performing). In practice, however, task management will be handled by its own, dedicated interfaces. So I'm not sure if tasks would ever really use the gather message in practice. But it's worth noting the possibility! :)

Merry Christmas (again)! :D

Re: Week of December 21, 2014

Posted: Sat Dec 27, 2014 4:45 pm
by JoshParnell
Friday, December 26, 2014


Was supposed to leave today to head back to the coding cave. Was supposed to be heading back to the land where I can get on top of things once more. Instead? Bed, water, sleep.

You know, I think I can see a silver lining: I'll bet that life's 'server' does a major re-balancing each New Year -- which means, with any luck, it will notice that I've been struggling entirely too much recently, and that my personal life difficulty level should be lowered once more! :roll: :clap: One can hope... :shifty:

Not sure what else I can say other than...I hope you all are having a more healthy Christmas week :D Also, I would like to request that someone out there play some Skyrim on my behalf while drinking hot chocolate. That is what I wish I were doing every time I get sick. But if I can at least imagine someone else doing it for me, well, it's better than nothing :P

Re: Week of December 21, 2014

Posted: Sun Dec 28, 2014 5:01 pm
by JoshParnell
Saturday, December 27, 2014

Got tired of being sick. We all know what happens when unused code potential energy becomes greater than resistance induced by sickness :cool:

Turret Camera

While working on handling today, I remembered how cool the 'turret' cam was in Freelancer. Would sure be nice to control turrets individually when you want to, especially when you've got a big ship set on autopilot and want to have some fun while you head towards your destination. Or, you know, when the tie fighters are coming in too fast ("great kid, don't get cocky!") So I implemented a hardpoint camera. Two buttons cycle between camera positions on your ship. In the future it can be easily extended to include rear / side / top / bottom / whatever views. But right now the point is already achieved: I can "jump in" to a turret and start shooting :geek: Fun. Also fun doing this with a transfer unit ("real men mine with their gloves on the transfer unit control switches, not at some pansy ship control panel!")

Dynamic Dispatch in LTSL

Still haven't been able to push forward with text generation as I would have liked. Decided that I need to do more than just a grammar, and that I would rather structure it all using real classes as the 'objects' in the grammar rather than just strings. This way, I can have functions deciding how to produce a given element of the grammar, which answers the questions posed previously about how we will take certain things into account to make the text natural. With arbitrary functions, we can, of course, make the actual rules of the grammar as fancy as we like to provide convincing results.

The problem? Now we're getting into some heavy programming territory in LTSL. In particular, the 'right' way to handle this would be through virtual functions. Oh boy. Now listen, I've thought about it before during my usual ruminations on that which could be. I'm not afraid of base classes and virtual tables and such, and I'm sure that, given a day or two, we could have them working in LTSL. But today, I just wanted to work on my text generator, not get lost in some technical feat. That's when it occurred to me that there was another way to achieve this, one that would take me about 30 minutes to implement :geek:

30 minutes later, LTSL supports dynamic dispatch! What this means is that we can make a function call on an object that will not be resolved until run-time, because we don't know what type of object it is. In particular, using the 'Data' type in LTSL (which is a type-erased piece of data, meaning it can hold anything), we can perform a dynamic dispatch like such: (call myVar MyFunction arg1 arg2 ...). Simple! The function gets resolved based on the type of 'myVar' at run-time. Voila, we now have a way of making all this work! The 'phrases' of a grammar no longer need to have a base class, they just need to expose a common function ('ProduceText,' for example), and then we can store them in 'Data's and use dynamic dispatch to call said function. Easy!

But hold on, did we just cheat? How can we achieve the same thing that virtualism achieves without any mention of base classes or virtual functions or vtables? Well, I'll give the short answer, which comprises two pieces: first, we lose compile-time error checking. Second, we lose (some) performance. If a dynamic dispatch fails, it's likely going to fail at run-time because it can't resolve the function. Contrast this to virtual functions, for example, which can be type-checked at compile-time even though they're resolved at run-time. On the performance end, looking up the function in this type of dynamic dispatch is marginally more expensive than grabbing it out of a known offset in the vtable (as in the C++ implementation). Thing is, I'm not using this in a performance-critical piece of code. I'm using it to for one-shot text generations based on a grammar. The performance overhead is going to be completely negligible in this case :D

HUD & Reticle

That wasn't all for the day, though! I continued to work on the HUD. I replaced the left/right velocity bars of the reticle with a single velocity bar on the left, and introduced a single integrity (health) bar on the right. I've debated for a long time where health should be shown, but, ultimately, I just don't see why we wouldn't put that front-and-center as part of the reticle. It's still minimal, unobtrusive, but super-fast to check health status. In other HUD news, I have now official finished porting the HUD over from C++. The last remaining piece was handling target leading & automatic aiming. This has all been implemented in LTSL now, so the LTSL HUD is now capable of computing / drawing target leads and performing automatic aiming. Great :clap:


Anddd that's what happens when you try to keep the code suppressed! It doesn't work :ugeek:

Gotta leave now to head back to the coding cave. Looking forward to some long, long nights here soon. Please pray for me or do your tribal dances or burn incense or whatever, because I really don't want to have a flat tire when I pull in tonight (or worse, while I'm on the road :shock:)