Sunday, November 2, 2014

Warp rails.

New name-changing gimmick, or new game-changing nimmick? No, that one didn't quite make as much sense as one would like. But the answer is: the latter. Finally, I had all the inspiration I need on the 'highway' infrastructure. I've got it. Warp nodes connected by warp rails.

Warp Rails: Because Tunnels Belong in the Past!™ Seriously folks. Tunnels are so retro. Rails are the new tunnel.

Here's how it works. Warp nodes are like big transformers that connect the power lines -- the warp rails -- together. A warp node essentially creates a large 'warp potential difference' between itself and its neighbor (or two neighbors, in the case of a non-endpoint node). That potential difference induces a 'rail' -- a thin, extremely-energetic 'power line' that connects two nodes, almost like a constantly-arcing bolt of electricity.

To move using the warp infrastructure, ship's don't enter a boring tunnel -- no, they latch on to a rail, riding the energy current to the other end. It's like a massive, futuristic zipline in space. Ships can tether and untether at any point along the rail, which means you can, as you would expect, 'break out' of the rail to reach a destination that's partway between two nodes. Of course, you'll break out at an extremely high velocity, so you'd better know what you're doing. Warp nodes can be temporarily disabled by damage, which causes automatic untethering when the broken rail is reached.

Now, the idea doesn't stop there. There's also a very interesting, very neat notion of what happens with 'traffic' as a result of the way warp rails work. You might ask how are collisions prevented? The answer is that, like an expandable-lane highway, the warp nodes expand and contract the equilibrium radius of tethering to accommodate the traffic. When lots of ships are using the same rail at once, they'll be tethered at a larger radius than normal, so as to accommodate all ships without risking collision. While you're riding on the rail, you've essentially been allocated an angular 'slice' of that rail -- the rail will ensure that no other ships come into your angular slice, which prevents collisions. Big ships require larger angular slices, which means the rail must push the tether radius further out to accommodate capital ships.

But! It gets better. Keep in mind that the rail is providing energy to all tethered ships. When multiple ships are tethered, less energy is provided to each ship. Another natural explanation for this is that: the energy field created by warp rails falls off with the radius from the rail. So when the rail pushes the tether distance further out to accommodate more / larger traffic, you're essentially getting less energy because you're further from the rail. The math is negotiable, but simplicity is always preferred: energy falls off as 1 / radius. Circumference increases proportional to radius. The implication is that energy provided is directly reciprocal to the total size of ships using the rail. 1 small fighter going 3km/s, another fighter of the same size jumps in, they're now both going 1.5km/s. Make sense? Again, the exact math is negotiable.

Busier systems need larger rails for obvious reasons: traffic is going to get too heavy for the rails to be useful to anyone if busy systems have rails of equal power to desolate systems. It also provides a natural explanation for why it's really difficult to knock out a major 'backbone' rail. They're massive, because they support tremendous amounts of traffic. You're not going to be able to disable a backbone of a busy system with one fighter. Piracy becomes about choosing locations wisely. Knock out smaller rails to isolated mineral fields.

There are three components to the graphics: the warp node graphics, the rail graphics, and the tethering / using-the-rail effects. The first two are already well-underway in our favorite little 3D testbed, and I'm already substantially pleased with the warp node graphics. Rails still have a way to go, but all in time.

Very, very excited to finally have this system designed and nailed down in a way that feels elegant, logical, and rich with gameplay opportunity.

Woohoo

PS ~ Here's the kicker: it came to me in a dream! Well, half-dream, that is. I've been working hard to explore lucid dreaming lately. Although I'm not there yet, I'm at least at a point where I'm able to go partially into a dream state while hanging on to consciousness. This is great, because it turns out my subconscious is a whole lot more creative than my waking mind. I asked it about warp tunnels today, and in five minutes it had shown me a whole new way of looking at everything -- the nodes, the rails, the tethering, the traffic mechanic. It laughed at my paltry little struggle with warp tunnels. Thanks, brain! Guess I should half-sleep more often.

PPS ~ Oh! Forgot to mention. The graphics for nodes and rails are both...heavy on the particle effects So today I had to expose particles and particle systems to LTSL. I wrote all of the particle effects for nodes and rails in their respective LTSL scripts...which, of course, meant many, many F5s and huge amounts of fun with particles

Monday, November 3, 2014

Quick one (hopefully..) today, as yesterday's was quite a hefty log

I'm now in the thick of the implementation of what I hope and believe will be the end-all-be-all of intra-system fast-travel in LT. Graphics are still baking and coming along nicely. But logic is the real challenge now, because we want to see these things working!

The angular allocation system of rails is proving to be really interesting. Instead of simply 'pushing out the radius,' as per yesterday's devlog, I've decided to go with a slightly-more-complex but also more effective 'cylindrical wedge allocator.' What this means is that not all ships will tether at the same radius. It has a lot of nice properties: first-come-first-serve, most efficient possible handling of radial energy, interesting dynamics (since ships will exist at varying radii from the rail, you will see ships passing you or vice-versa), and good handling of large ships (large ships are unlikely to be allocated close to the rail, because they require a big wedge.) The latter, in particular, is quite nice. It means that, even if large ships are using the rail, you may not be affected -- you may still get allocated to an 'inner wedge,' close to the rail, that the larger ships were too big for. This could be a very cool experience -- in a congested trade line, you may find yourself tucked inside an inner wedge, passing a bunch of bigger ships on outer wedges, almost like a tunnel but made out of big ships!

Now, ejection becomes slightly trickier when we handle allocation this way. The truth is, ejection is now a 'request' that must be handled carefully by the warp node's controller, not an instantaneous unlatching. If you're a small fighter travelling on a packed rail, you may not be able to eject immediately, because larger ships have been allocated to outer wedges that would make ejection dangerous at certain points in time. In reality, though, if the warp controller is clever enough, it can identify at what times there will exist a 'gap' in the outer wedges to allow you to escape. I can't imagine that rails would ever be so congested that you just wouldn't be able to eject the whole time, although in congested systems I can imagine that you may not always get to eject at the exact moment you wish. Seems very reasonable to me

Also, as DWMagus pointed out in the discussion surrounding rails, one of the nice properties is that the whole issue of directionality is no longer a problem. We don't need two rails to handle incoming and outgoing traffic. Since you're allocated your own wedge that extends down the entire rail, it doesn't matter whether you're coming or going, since you've basically got your own private flying space. I think it's going to be very neat to see passing traffic going the other way!

And...on the side? Still trying hard to wrap up the market interface

It could be a real big month. The next 24-48 hours will tell

Tuesday, November 4, 2014

All over the map. Been in the zone for a solid week now -- that's what I love about monthly update time. You just can't put a price on the productivity that comes out of it. As much as I dislike the stress of it, I absolutely can't deny the benefits -- and now that the dates are fuzzy, the stress is mitigated but the productivity remains. Wonderful situation, really

First of all: let me be honest: I didn't dedicate all of my time to warp nodes and the market as I should have. But you know, it's hard to be so single-minded during this time of the month when the code is flowing so thickly

The good news? I got way too much stuff done today

• New, more powerful object messaging system inspired by the awesome widget messaging system implemented in the new UI. Makes some object code a lot cleaner, and paves the road for extensibility to object messaging in LTSL!
• New 'custom' object type - an object that is defined entirely by an LTSL data type, much like the custom widgets that I've been using for months now. I haven't had much time to play with it yet, but I'm really stoked for this one. This is where I will be implementing a lot of gameplay in the near future -- not in hard code, but in custom LTSL objects. This should make it remarkably easy to iterate on gameplay. If, for example, I want to create and test a new type of drone -- say, a fighter drone that hovers around the ship and fires at enemies -- I could do it all without restarting the engine. I could prototype that entire piece of gameplay quickly in LTSL, hit F5, and launch an entirely new type of drone with new gameplay opportunities. New types of weapons. New types of ship modules. New types of space objects. Initial prototype of warp rail logic. Everything is now on the table. Absolutely can't wait to try this This is going to be what the LTSL widgets / UI were for the interface, but for gameplay. Fast, fast, fast!!
• Major advancements in profiling and optimization department. Loads of new power in my profiling tools, and already many optimizations as a result.
• Major improvement and simplification to the way that 'interiors' (systems, stations, colonies) are handled.
• Major improvements to transfer unit logic & graphics, which were both previously hindered by the complexity of something that I'll discuss below...

But there was also something even bigger that happened today. I made a rather large executive decision to move to a variable simulation step instead of fixed stepping. A lot of deep thought came before this move, as it's a big one. In the end, I decided to stick with my ultimate motto, the one thing that has gotten me further than any other principle: simplicity. Fixed stepping introduces a lot of complexity, but what's worse, there's no other way to rationalize that complexity other than to say it's to support frame interpolation for fixed-timestep updates. Thinking about explaining that in the LT modding guide makes me feel ill, because it makes me feel like it's all a mistake. I would have to explain how certain state is variable over time and how, if that state affects rendering, it must be interpolated between simulation frames, so it must keep a 1-frame history of its value. I would have to explain how, at render time, the 'real value' must be interpolated using history and this mysterious global interpolant. I would have to explain how, if you want to set up an object simulation in LTSL and have it render properly, you can't just write 'mySystem.Update' -- you have to set up an interpolant, write a fixed-timestep update loop, and call mySystem.SetInterpolant before you render. And why? 'Just because.' I finally got tired of it today. I killed the whole thing. I killed all the complexity, and replaced it with glorious simplicity. mySystem.Update it is.

Already I know that this was the right decision -- I have seen graphical artifacts caused by the complexity disappear. I have seen memory usage drop thanks to losing all those history buffers. I have seen performance rise thanks to no more interpolation. I have seen responsiveness increase, because what's drawn on screen is now the most recent state, not an interpolation of a historical state with the recent one (hence, input latency is reduced). Above all, it feels so right. I'm happy I did it. The thing that kept my finger off the trigger the longest was thinking about how modders might implement multiplayer, and that variable timestep might make networking harder. But step back for a second. A speculative potential complication with a feature that I know very little about and would have to be implemented by modders anyway stopping me from making a major simplification to everything? Come back to reality, Josh. When I read that the Unreal Engine (which obviously has fantastic MP support) uses variable time stepping (with an optional fixed sub-step for physics), I finally started thinking straight. I did the right thing Once I learn more about networking I'm sure I'd find a way to make it all work. I'm sure that someone else will make it work. Even still, what's most important is that LT 1.0 will work in the best, smoothest, most performant, and cleanest way possible. Great

The end of the month is burning bright, the end is in sight, yet still we must code all through the night, code valiantly into the twilight! Come, my friends, join the fight! The infinite universe will shine bright with light as we hammer back our plight with LTSL's might.

Every day. Every day it's feeling more polished, more smooth, more beautiful, more filled with potential, and more like my dream space game. That's all I can really ask for, right?

(Yes, I'm excited today. I seem to be getting more excited every day )

Wednesday, November 5, 2014

No time. Too much time spent yesterday!!! No time today. Another fantastic day, but it mustn't end yet. Sorry gents

Thursday, November 6, 2014

Sorry about that skimping yesterday! You know how I get during these update pushes Anyway, the madness continued today!!

List time, naturally..

• Finally implemented the dogfighting testbed! (you, an ice field, and a whole lot of angry ships coming at you...who will survive? ) Great fun already, despite the admittedly-still-simplistic combat AI
• Decoupled universe structure so that individual pieces can be run in isolation -- in particular, I can create and run a testbed within a single system without having to build a universe. Awesome news for testbeds. It already took a large chunk out of the loading times for all of them (I've actually started doing some of my gameplay testing in the dogfighting testbed, since it loads so much faster than LT now thanks to this advancement! Hah...a bit of testbed conflation going on there )
• Another hour or so of visual tweaking in which everything was fair game Improved virtually all of the shaders, lighting, texturing. No, this isn't filler, I'm serious -- it was an intense hour that spanned many testbeds and many, many files of .jsl (heh ).
• Continued writing the warp rail logic in LTSL Proving to be an excellent test of both the new LTSL custom object mechanism, as well as pushing LTSL's ability to handle real, beefy game logic.
• Put the finishing touches on the market interface prototype. There's still work to be done, but I think I can finally feel comfortable showing it!
• Spent slightly too long watching the AI mine. With all the various improvements of the month (graphical and otherwise), it's just darn fun to sit around and watch a fleet of mining barges scour the fields. Those transfer beams, those lens flares, that metal, those barges, that dust, those roids, that starfield...

Absolutely can't wait to show you guys all of this work

PS ~ Formally issuing an achievement challenge to future Josh, with reward at 100 JoshBucks: cut the devlog deficit by >= 10hrs tomorrow (post by 12PM EST). Come on monkey, work for those imaginary units of currency!!

Friday, November 7, 2014

Bah, no JoshBucks today Well, the good news is that that little fabricated reward did push me several hours longer than I usually would have worked yesterday (which is impressive when you consider that pre-update days are extremely long in the first place ). But I ended up falling asleep before I could claim that 4PM consolation prize

Today was mostly about warp nodes and rails, as expected. They're 100% in LTSL now, and the custom object mechanism is my new best friend. In getting this thing to work, I'm also having to give custom objects the ability to expose a custom widget to the UI. Per-object custom widgets are nothing new, as objects have had this ability for quite a while (the first notable usage was the prospecting drone). But now custom objects also have this power, which means we're able to define custom LTSL widgets for custom LTSL objects that show up on the UI. This will be key to interacting with warp nodes, but it's also just a darn cool functionality to have available!

Of course, as it's the end of the month (heh ), there were small, scattered improvements all over the place. But I've been hitting that list format pretty hard lately, so I'll omit it this time. I will say that one of the more interesting, 5-minute tweaks of the day was the implementation of a mining particle effect that makes it look like asteroids are heating up at the point of contact with a transfer beam. If you run the transfer beam over the surface, it leaves what looks like a scar of molten rock (of course, it fades after a few seconds since they're particles). Watching the AI mine with this little effect was quite cool. Unfortunately, performance may be a problem. But it was just a 5-minute idea, so there's time to play with it later. Cool

Once again, I will issue the same JoshBuck bounty, except this time I'm going to rename the currency to LTBuck to be a little less pretentious So, 100 LTBucks for devlog at 12PM EST

Additionally, 100 LTBucks for fully-working warp rails, meaning shell allocation + actual, in-game usability. Graphics don't have to be perfect, but it's got to work like I said it will work. Now that'll be a good accomplishment!

I think I'm going to start doing this more often. It's weird, I know, but there's just something about the feeling of earning made-up currency that makes you want to push through. We do it all the time in games, right? So why not do it in development too? Now I need to figure out what I get for LTBucks. Maybe....1000 LTBucks can be redeemed for an hour of my game of choice (yeah, we all know it's going to be Morrowind )? What do you guys think?

Saturday, November 8, 2014

Bah. Once again, no LTBucks for me today, but the motivation to nab them continues to provide that extra oomph to my productivity Someday I'll catch up with them!

For the first time in a long time, I was almost entirely focused on warp nodes and rails today. I didn't end up with a fully-functional system, as it's challenging me a bit more than I anticipated. That's mainly just because this is my first experience writing real gameplay logic in LTSL (fairly intense logic, to boot!), and there are many things that have needed hammering out to get me there. All is still looking great, though, and I'm going to try once more for that goal tomorrow!

Warp node visuals have taken another step up today, as I continue to explore the possibilities of LTSL + particle systems. My real-time iteration has shaped not only the graphics, but also how I think of what warp nodes actually are. I've now come to think of them as energy nodes that harvest energy from the surrounding space and channel that energy into the rail. I think the visuals convey this quite nicely Interestingly, the harvesting of energy is based on a probability distribution that feels a bit like an electron cloud -- while most energy comes from nearby space, there's technically a finite probability that a unit of energy could be drained from anywhere in space. I want to believe that this has some sort of neat gameplay ramification, because visually, it's pretty darn cool. You can be quite far away from a node, but still witness the materialization of a tiny fragment of energy and see it flow rapidly toward the node, which indicates to you that there's a node in the direction that the fragment went. Of course, if you're really far away I imagine you would need to wait a long time (and keep a really sharp eye) to witness this phenomenon (I haven't actually done it since I'm not sure that's the best way to spend my dev time ).

This got me thinking about wormholes. No doubt I will apply similar particle techniques to enhance the look of wormholes in the future, but I'd also like to have this same 'electron cloud' mechanism. As cool as it is for warp nodes, it's far more practical for wormholes, because hidden wormholes are something that we really want to find. A keen-eyed explorer with a love for hunting down wormholes might be so attuned to those little blips of energy that he/she could spot the rare occurances of extremely-far-away fragments, and immediately extrapolate the approximate location of a wormhole (of course, pulling out the scanner to finish the job)

Along with all my work in particles, I have necessarily had to improve the visuals and performance of the particle system. In particular, we have much faster particle rendering today thanks to some low-level optimizations in the particle renderer, as well as the introduction of both frustum and distance culling at the per-particle level. This was a huge step up, and allowed me to get a pretty big number of particles in the simulation without much performance hit. How many? Well, I'll just say that I had to change from using unsigned shorts to unsigned ints for the particle index buffers. Every particle consists of four vertices. Maybe one of you sharp nuggets can use that info to get a lower bound on how many particles I was working with today (And I went far in excess of that lower bound!)

Once again, the reward remains in place for tomorrow: 100 LTBucks for devlog at 12PM EST, 100 LTBucks for fully-functional warp rails. Really hope tomorrow's the day...not sure how many more days of this intensity I can take (nah, just kidding, we all know I love it )

Really want that day off! Gotta push this update soooooon