[8] Lunar Lander WIP [3/9]

This week was a bit tedious and frustrating, so let me show you how.

It has to do with being forced into a lot of manual data entry and number crunching.

Firstly, I wanted to make an image point for every labelled landing zone, which took me about an hour:

You can technically land anywhere on the terrain and not just those 50 places, though you'll get less points.

That is unless you try the "Skyrim Horse" mode, in which you're not only supposed to land anywhere, but you get more points the weirder of a spot you choose to land on:

Do keep in mind, that you'll always get diminishing returns on points if you try and land at the same spot over and over again.

Playing into the theme of jury rigging things, I had a big problem that was almost immediately apparent. However, the solution I came up with inside the bounds of Construct wasn't optimal in the slightest (at least I hope so).

This big problem was presented to me in the form of a seemingly small question: how can I properly handle collisions between the moon and the lander?

Any sane person would respond to that by calling for the usage of collision polygons, and they'd be right.

One small problem:

If I act like nothing's wrong and make the polygon anyway, FPS count might reach single digits. So what now? How do I have Construct handle a collision polygon fit for my Moon?

The answer is simple. I don't.

What I do to get around this is by splitting up the polygon over multiple frames in the same sprite, while switching to the section closest to the lander at any given time. This will make sure only the closest set of 16 points are checked per tick (or a given timestep).

If nothing else, this is almost certainly better than having a single polygon with 700+ points.

One tricky step of this is finding a balance between having points be spread out, as opposed to having points be accurate. Here's an example of the amount of separation between points based on the detail of a given area, where the vertical strikes represent those edges:

And here's an example of cutting corners to save on space:

You can see a problem emerge, where it gets harder to quantize the shape of something the more its topology changes. This is nowhere better described than this sorta-semi-circle.

As I was working on creating these different sections, I encountered more and more fun and silly little things like this:

And this:

This as well:

Also this little gem here:

I had progress deleted via a crash at least twice, losing about 3 and 5 sections respectively.

Keep in mind that these are just the instances I bothered to record.

I ended up making a finished product of 52 individual frames for all of those polygons

(not counting frame 0, which isn't active and is used as reference for location names).

Having 52 individual frames in a sprite over 3000 pixels in width and height can sure bloat byte size, which is why the game currently takes 5 seconds to load and weighs 15mB.

Finally, to check which section is nearest to the lander, I thought of just lining up some median with those strike marks carved into the moon, and just write down a list of angles of each of the section's edges. After that, I can check where the moon's angle lies in that range list.

Here's how that was done for each section's edge:

And that's it.

This week was brain smootheningly tedious, and the creation of this blog was easily more enjoyable than any point of work at any point in time between Monday and now. The polygons alone took at minimum 10 hours for those 700+ points over 52 sections.

To end this, here's a short gallery of things that I straight-up wasted my time doing:

Making this script:

Writing this document:

Which was used to make this graph: