[12] Lunar Lander WIP [7/9]

This introduction will be short, but I can't say the same for my contributions this week, as they're easily greater in number than the past two weeks combined. Let me show you how.

To start off the week, and after being told what the problem was, I solved the issue of literal tens of thousands of "moon_point" sprites being spawned, far past its intended maximum:

After making sure that the init loop only occurs at the start of layout, the moon_point count now rests at a comfortable 50, with one point for each landing zone:

Much better.

One feature that was put on the back burner, due to how hard I thought that feature would be to add, turned out to be a lot simpler than I expected. I'm referring to the mechanic that would allow for dynamic zoom, based on the lander's distance to the Moon.

When I got around to tackling this, I did so by first looking at two elevations, the highest peak, and the lowest valley. While it's pretty obvious that Davy Jones' Locker is the latter of the two, I was surprised to find that R Cuesta was, in fact, the highest.

After comparing those two elevations (~1100 - > ~1675), I found that the range between the two was around 575 pixels. Taking into account that I wanted a zoom of no less than 1, and no more than 5, this is the formula that governs the zoom factor:

And this is how the zoom mechanic actually behaves:

(The two numbers in the top-left corner denote the lander's current elevation, and the layer's current zoom factor)

Next up on the list, Is making sure the Moon is rotated according to the lander's under-the-hood position. For this next video, I set it up such that the lander's on-screen position is compared to the green ball. This green ball is a smaller visualization of the moon.

For instance, if the lander is to the right of the ball, then the actual Moon's right side will be facing the lander: (The number in the top-left of the screen denotes the angle of the vector created from the ball and the lander's positions)

Lastly, I also wanted to implement the idea I had involving a variable thrust.

While I didn't finish the thrust's physical behavior, I did finish its visual behavior.

I thought I'd go about this by stretching the flame based on its real length,

multiplied by a number from 0-1. This did lead to a minor annoyance in the form of the lander sprite itself, though. If I wanted to stretch the flame, I'd have to stretch the lander, too.

After splitting the flame into a separate sprite, before pinning it to the lander, all that was needed then is to add a single event in the update sheet that changed the flame's size:

(Throttle is shown in the top left, of course)

To end this, and following the theme of half-finishing things, here's the proof that will allow for tidal locking of the lander to avoid on-screen confusion with the moon: