[Week 4] Orbiting Fields & Asteroids

Last week wrapped up well. The foundation is in place for interactive FPV consoles with initial passes at tactical, navigation and ship status.

This morning was spent optimizing planetary generation. It hadn't occurred to me that Earth moves in open space at ~30,000 m/s so a two-minute interval between updates within 25M km is clearly too slow. That and optimizations to cloud generation and atmosphere brings us back to smooth planetary motion at 120fps with room to spare.

This week I'm starting with scene building. For the current single player target, I'm going with JSON-defined scenes utilizing the existing system infra. That will entail geo-sync orbits and docking - perfect for new cell types.

So, scene building didn't happen yesterday. Here's why:

I'll preface that it's important to me that the game maintain a degree of realism in appearance and physics. But, it's vitally important to me that this game have a high degree of intuitive playability; that players can pick it up and play.

As such, I want the system to support all of:

• Keplerian orbits & geo-synchronized structures (dynamic, realistic)
• Point-and-go travel at both near and far ranges (pure playability)
• Artificial drag

I want to avoid the whole click-to-warp, click-to-rotate stuff that some games do which can make battles dull and repetitive.

So the challenge is three-fold when thinking of ships nearby a structure in geo-synchronous orbit:

1. How to keep ships effectively locked/anchored in the vicinity of other structures and other ships
2. How to avoid constant position updates on idle ships in said reference frame (as of now everything is measured from the ecliptic center)
3. How and where to ease transition into these frames

Popular games handle these issues in their own ways. Stationary planets and moons is the easy way out. Structure reference frames being another extreme.

The approach I'm trying: two concentric spheres around each structure, with a hysteresis band between them. Outside, you're in sector frame. Inside the inner sphere, your position and velocity are stored relative to the structure — it's "stationary" as far as physics cares, so drag pulls you toward matching it, stationary detection fires, and idle ships stop eating bandwidth. The transition band between the spheres applies drag against your velocity relative to the structure, quadratic in relative speed, so fast crossings get grabbed and slow ones glide in untouched. By the time you reach the inner sphere you're already matched. Sort of like atmospheric entry.

So far, the spherical field with horizon approach is working well, however there's a ton to account for with the original client built against ecliptic (world) coordinates, and still needing to work between the two frames.

What's working:

• Geo-synced orbits work great - really cool to have a station attached to a moon whizzing through space too!
• "Sticky" fields bound to geo-synced structures are working well

What's not working yet:

• Field horizons
• Relative coordinates, interpolation on the client

To save myself from being derailed from the EA/VS plan, I'll give myself through tomorrow to prove out the idea. So far though, it looks promising.

This was the idea, and a visual:

$$v_{cap}(d) = \|\mathbf{v}_{rel}\| \cdot (1 - \rho(d)) + K \cdot \rho(d)$$

$$\mathbf{v}_{\text{ship}}' = \mathbf{v}_{\text{anchor}} + \hat{\mathbf{v}}_{\text{rel}} \cdot \min\!\bigl(\lVert \mathbf{v}_{\text{rel}} \rVert,\; v_{\text{cap}}(d)\bigr)$$

The idea was that the outer horizon would sort of soft land you into the field whose drag was kept relative to the orbiting body. Yeah, I know what it resembles. And it didn't work either; or rather it was more like landing on an aircraft carrier than a gradual entry.

So this mess was next:

This is a radical deviation from the prior approach. The idea here is that we very briefly take control from the player and vector them in safely to the field.

And after playing with that for a while, I quickly abandoned it. Reconsidering the numbers involved: likely maximum velocity of celestial bodies relative to their stars, maximum likely distance between two planets in the same system, speed required for interlunar, interplanetary travel within 5-15s.

Roughly, that's ~100kms local, 3c interlunar and 3000c interplanetary at 5s. So, we'll need magic and velocity differentials will have to be dealt with independently.

To get back on the road, the goal today is straightforward:

• Relative coordinates will now be passed based upon proximity to nearest body or orbiting structure
• Handoff will inherit speed and remain geo-synced, permitting navigation in that frame at low speeds

And I'll have to think on hyperspace-style mechanics.

The new static-orbit field is working great. This preserves Keplerian orbits and geosynchronous structures in a Newtonian system with added drag for playability. The only change I've added versus the original plan is a variable velocity clamp to make approaching from high speed intuitive. While it makes direct travel at 100kms reasonable, for anything more than that we'll need some form of hyperspace magic.

Today is work on asteroids. They'll be procedurally generated, and the first mesh structures in the collision engine.

Asteroids! Complete with high-speed collision handling, damage, impact effects and residual heat spots.

I'm starting to feel the game as a "cute creatures in a somber environment" which I'm hoping will help guide me on music, effects, timing, NPCs, missions and general culture of the game.