Lighting Tweak, Bug Fixes, and Work On New System Map

Hi Folks! Made a few useful changes and fixes today, as well as started a look into an improved nav station.

One of the first tasks on my list was to fix item placement when doing manual installation. There was a bug in the layout code that allowed me to place walls and floors anywhere I wanted when on a docked ship, even on top of existing walls and floors. It turns out this was a really simple fix, and I just had to update my ancient item-fitting code to use a more recent "get tile below this point" feature, which accounted for docked ships.

And something else I've been meaning to address is the helmet lamp. Previously, it would illuminate a cone in front of the crew, but it was annoying to constantly be clicking around to point it at things nearby to get my bearings. So I added a really dim radius of light to it, enough to make out local surroundings in a dark ship. You can see that on the left of today's screenshot. In fact, I think it almost looks more realistic, as it simulates the reflected light off of walls and other nearby items.

Also, while testing these, I noticed that loading a saved game would cause the star system's clock to reset to the past, causing havoc with condition timers. So I fixed that.

And finally, I've started exploring some improvements to the orbit plotting UI. One of our higher priority tasks for this milestone is the ability to navigate local space around a station or debris field (i.e. junkyard). We're talking within tens or hundreds of km of a target.

However, the old System Map 2.0 has real precision issues when zoomed in that close, and we got a ton of jitter. So zoom was clamped to about 4000km range, and docking just assumed that was close enough to dock.

If we're going to let the player start as a shipbreaker, though, they're going to be exploring derelicts in a junkyard with a lot less space between hulks. It would be ideal if they could navigate from hulk-to-hulk using RCT and maneuver jets, then board the ships using tools and such.

We have some thoughts on how to approach this, including an instanced "short range" map we load in when close enough to targets. We can then move around that local map until we leave, and it returns to the macro System Map.

So this requires a separate plotting and maneuvering UI, though it will likely still use the same rendering style. Because everyone likes it, especially me :)

That said, there are also some things in the System Map 2.0 that might benefit from the stuff I've learned since I made it, long ago. E.g. changing certain frequently-drawn vector line bits to be sprites, for better batching. Or doing more in the main game renderer instead of the canvas UI renderer. Plus some UX changes to make it more accessible.

The right side of today's screenshot is an ultra-early peek at my sprite rendering tests. So far, it looks like we can get comparable plotting styles using sprites as we did with vectors, so I might split it up such that vectors get used for very large things (orbital tracks, gravity vectors, grav wells, and nearby planets), while sprites get used for everything else (ship and other "pings" on the map, and celestial bodies that are below a certain rendering radius).

It's a daunting task, but the payoff should be worth it!

Tags: Ostranauts


ra1's picture

Why not periodically shift all world object coordinates to center around the player's location? (When moving fast, you could do this less often).

dcfedor's picture

I think that might work if all of the celestial objects were positioned using universal gravitation. We could assume the body we're looking at is the origin, and the forces acting upon an object would be calculated relative to that object, and it wouldn't matter so much if objects multiple au away had jitter of a few dozen km.

But I'm not simulating celestial body positions using gravity. Too expensive and/or innaccurate (sliding scale). I've been using elliptical equations, which have a focus at or near the Sun. And that means their positions jitter no matter where I choose the coordinate origin, since either the planet or the focus will be very far away, and suffer precision issues.

Though, now that I say it, I wonder if I could get away with gravitationally simulating planet positions, but then using elliptical equations for moons? In theory, ~10 planetary bodies wouldn't be too bad to calc regularly. And the moons are close enough that their parent-body origin would cause no jitter.

Of course, we have a lot more than 10 bodies orbiting the sun. If we are considering dwarf planets (Pluto, Ceres, etc.), we're immediately up to 500+. Minor planets pushes us up to 750k+. We'd have to draw the line somewhere, limiting which bodies could be approached at close range. (Which might be fine. A couple dozen would probably cover most points of interest.)

Another approach might be to use elliptical orbits for everything until we get close to an object, then switch that object to universal gravitation. We would theoretically get smooth motion as long as it was under g-forces from distant bodies, even at very close ranges. Then, when we are far enough away, switch back.

Might actually be simpler than trying to create a copy of local space and keeping that in sync with macro many questions!

But I might try that elliptical->gravitational->elliptical swapping thing first, as it might be the easiest to build and test. Thanks for the comment, it really got me thinking!

Dan Fedor - Founder, Blue Bottle Games