Lunokhod Devlog

[Seabass]

Hi everyone! I have been working on a small game in my free time for about a month now called Lunokhod (named after the soviet lunar rover). My goal is to make something in 2-3 months with a reasonable amount of polish, since I have 2-4 days a week to work on the project.

One of the ways I wanted to challenge myself, was to do all of the art myself. I am not an artist, but I was curious to see what it would look like if I had to create art. I think you might find my workflow neat/interesting.

I decided to start with the UI. I knew I wanted to emulate the look of old spaceship cockpits, but since the game takes place in the 80s, there should be legacy electronics alongside more modern displays. A good example of the displays I wanted to emulate are the original “glass” displays in the F15 or US Space Shuttle.

I have heard that this aesthetic is called “Cassette Futurism” but really the examples of cassette futurism I have seen online don’t really look similar and are all over the place.

I really like the extreme Skeuomorphism of the UI in the game Highfleet. The Highfleet UI is hand-drawn, but I think the reason it looks so accurate is because all the dials and gauges use real military hardware as references. I think that even if you don’t know what the milspec UX rules were for old radios, your brain picks up on the design rules implicitly. So when someone copies those design rules or violates them, things will look “wrong” or “right”. I tried to keep this in mind while working.

Initially I started with photobashing. There are some old Tektronix oscilloscopes and function generators at a local hackerspace. I took some images of them and I liked the results:

Unfortunately, photobashing doesn’t provide me with the level of control I’d like for animated buttons with multiple states. It is also very difficult to do well without images that you can control yourself. So if you don’t have access to a flight control panel, it can be hard to make things look right.

I decided to try using CAD to mock up control panels that looked similar to existing ones, pull them into Blender, fix up the normals and UV mapping, and then apply materials to make them look how I wanted.

This is a panel from the Buran Soviet space shuttle:

If you notice, there are 2 sizes of screws. For most things that fly, you get a Jenga block-shaped hole for your avionics panel to go in. That “block” often has different subsystems, which themselves can be removed. That’s why it looks like panels on panels. This totally clashes with the appearance of the minimap UI element, so at a later date I need to figure out how to make it look more “space-ey”.

I created a CAD model with this “panels in panels” look in FreeCAD, exported that to Blender, and gave it a “powder coated metal” material (plus some 3D models of screws from McMaster-Carr)

That same maker space has an old Eletronika BK-0100-01 home computer, so I copied the color scheme of that keyboard and found an STL file for old Commodore 64 keycaps. Then I rendered each one individually in up/down positions so they would have accurate lighting. I think the end result looks pretty good.

The current iteration of the UI:

It’s a bit ugly and not very cohesive at the moment. The top-left and bottom-right elements match each other, but the bottom-left elements feel discordant. I think either everything needs to be rendered, or everything needs to be photobashed. I also need to do another pass to add wear to elements, make the screws brushed stainless steel, etc. This is turning out to be much harder than I thought. I’m gonna take a break on this UI stuff and revisit the game loop for a bit.

Negatives:

• The resource UI panel in the top-left is very dense and I find it difficult to read. Unfortunately I’m not sure of a better way to represent the resources in the game
• Upon reflection, it doesn’t make sense for the oscilloscope elements to be on a space thingy. Mixing consumer electronics elements and aerospace elements does look a bit discordant.

Positives:

• With the audio connected, I think the UI buttons are very fun/satisfying to use. I recorded the button sounds from a vending machine at the office for the time control buttons, and used an old IBM keyboard for the unit menu button sounds. They feel very satisfying to use (to me at least).

Quick demo of the UI:

2026 05 18 14 57 45

[exodrifter]

I think the reason the bottom-left UI element might look a bit off is because its the only element that is rendered with wear.

Looks great so far to me though! It’s a nice aesthetic.

[Seabass]

Thanks! I’m debating if I should make the minimap a render, or add wear to the renders to make them match the minimap. I might try both

[Seabass]

To keep the game small and simple, I limited the number of mechanics. One of the two obstacles you can encounter is meteor showers. To counter the meteor showers, you can build turrets which will blow up the meteors before they hit their target (ignore debris, it’s game logic).

I recently watched The Wandering Earth II (same author as the 3-Body Problem). In the movie, humanity has directed its entire economy into a massive geoengineering project to save Earth from the Sun’s rapid expansion. It is an over the top disaster movie in many ways, but I am a sucker for movies where everyone works together to carry out a dangerous mission at the 11th hour.

In this film, there is a scene where CIWS turrets are shooting down meteors! I thought that was neat.

The Wandering Earth 2 - All Impact Scenes

Here you can see a much less impressive screenshot of the CIWS turrets protecting a small base from meteors.

In “Rockets and People” a memoir by Boris Chertok, he discusses why the soviet lunar exploration projects (most famously the N1) were abandoned in the early 1970s since they had no demonstrable value to the military-- and resources that were being used for space exploration were desperately needed to catch up to the US’ much larger nuclear arsenal.

Since I don’t want to include violence in this specific game, I am wondering what peaceful reasons would make a moon base an industrial imperative. Maybe some kind of global disaster (those are always good motivations). Or an anachronistically early discovery of Helium-3 fusion making moon mining a strategic goal of the next five-year plan.

For such a small game maybe I am overthinking it, but I think that the more you think about the world it gets easier to make art and design decisions.

[exodrifter]

I think Helium-3 mining is a pretty fun idea to play around with! Maybe you can lean into it by setting up the moon as a profoundly economically important harbor and shipyard that humanity relies on.

If you want something more competitive, maybe you could take a page from Skymines and have the players compete by buying stocks in competing companies.

[ColdEmber]

Really love the look of the game so far!

[Seabass]

I think that the pixel shader and outline shader does a good job of making my programmer art look less bad.

The rover is now just a Kharkovchanka, but I kind of hate how it looks. I think I might make an alternative model based off this:

The main gameplay loop is finished if anyone wants to playtest it. I really need to balance the difficulty level of some of the hazards.

[pigdeons]

if your able to build to MacOS, i’d like to playtest it! not very familiar with the genre, but i do like the aesthetics a lot!

[Seabass]

You are the second person to use Mac, so I guess I need to add that to my automated build pipeline. I will let you know when it’s ready! I appreciate you willing to test.

[Seabass]

Ok I tested the Windows and Linux builds, the MacOS build should work but you will have to be my guinea pig.

Lunokhod by soft_cactus

EDIT: just realized I need to exclude all of my source files because the build is like 400MB right now.

EDIT 2: Builds are much more reasonably-sized now.

[exodrifter]

It appears I did not prepare adequately during the tutorial.

Those meteors do a lot of damage.

Here’s some unsolicited feedback from me after my first playthrough:

• There’s no tooltip for the rover describing its cost.
• The regolith overlay doesn’t update while it is open, I think it should.
• If you click the delete a building under construction, you can never build anything in that spot ever again.
• It’s kind of hard to tell if a rover is idle or doing something.
• Rovers can get stuck building blocks of structures at a time, like the solar panel, as they get stuck inside.
• One turret seems to occasionally fail, but two never seem to.
• Everything feels expensive. I think this is because of how much time it takes to produce enough resources to build, but I’m not sure.

Took me three tries but I got it:

[Seabass]

This is unintentionally hilarious

Thank you so much, this is excellent feedback! A lot of these are in my list so I’ll just follow up on the ones I haven’t heard yet or need clarification on:

How did your base get destroyed so early in the game? That’s actually a pretty common occurrence so it must be a design issue. It should be set up so that one turret can intercept all meteors, but maybe I have just gotten lucky in my playthroughs.

One turret seems to occasionally fail, but two never seem to.

Could you explain what you mean by this?

Everything feels expensive. I think this is because of how much time it takes to produce enough resources to build, but I’m not sure.

Does it feel slow or boring because of this? I think that it takes too long to build the biodome habitat in the tutorial. I have designed each of the units around “time to recoup the cost”. A refinery should pay for itself in about 45-60 seconds, rovers in 20-30 seconds, solar panels in 20-30 seconds, I found that this gives a decent cadence in the middle of the game, but it can be slow in the early game and too fast in the late game. I will need to actually watch others play I think.

There should actually be some .ndjson files that contain time-series data about the economy. If you send those to me I can see what your economy looked at over time, but I have realized that it might not actually contain all the information I need to make good decisions.

The files should be under
.local/share/godot/app_userdata/MoonMiner/telemetry

The problem I have is that the metal generation goes exponential in the lategame. Even massive resource sinks like the launchpad and rocket factory barely take any time to recover the cost after building.

To pad out the lategame a bit more I have been thinking of adding a reactor meltdown mechanic, or some scripted events like a simultaneous solar flare and meteor shower when you start the fueling sequence.

Did the game ever feel unfair or frustrating? Was the tutorial easy to follow, were there any mechanics you think should have been covered in the tutorial? How did it feel when parts of your base got blown up? How did it feel when the rocket finally launched?

Your base looks very neat and organized, mine usually ends up scattered all over the place.

[exodrifter]

Here’s the telemetry:
2026-06-05_14-46-05_4347536.json (28.4 KB)
2026-06-05_14-56-57_6667162.json (53.1 KB)
2026-06-05_15-15-26_8670015.json (9.2 KB)
2026-06-05_15-18-32_3648661.json (181.0 KB)

One turret seems to occasionally fail, but two never seem to.

Could you explain what you mean by this?

It seemed like more often than not, one turret would fail to destroy all the meteors in time. If this isn’t usually true for you, I would wager a guess that it might have something to do with the way meteors are spawned. My bases tended to be lopsided early on, with the turret located in the corner of the base. Maybe this setup makes this result more likely? Once I had two turrets to cover every area of my base, it always seemed to be successful in defense.

To me, the meta appeared to be:

• Build a turret
• Build a second turret
• Build enough batteries to support those turrets during solar flares
• Expand

This is also probably why the game felt boring me; this particular sequence of actions involves a lot of waiting, especially early on. However, it offers the maximum amount of safety. This was an attractive strategy because taking a risk to deviate from this checklist in my first three games would leave me softlocked.

When your first three tasks are to build two turrets and a bunch of batteries, you don’t have very much to do but watch 5 rovers run around on the surface while the metal accumulates. Afterwards, you can scale. But, as you’ve pointed out, the game scales exponentially and the problem is not very difficult after you’ve established a safezone.

Did the game ever feel unfair or frustrating?

It was a bit of a fun puzzle trying to figure out how to deal with meteor showers, but the solution (as I outlined below) was not very enjoyable. This makes me think that the meteor strikes don’t feel very fair, and that they could be used a bit differently to make a better experience.

Was the tutorial easy to follow, were there any mechanics you think should have been covered in the tutorial?

The tutorial was mostly fine – I got bored waiting for the metal to build the hab.

How did it feel when parts of your base got blown up?

I was surprised by how much damage was done, but I also kind of liked that. I wish it didn’t leave me in a softlocked state though. Some way to forecast upcoming meteor showers and their intensity would be nice. Having the meteors do less damage might be nice… or it might be a result of me packing my base too tightly together and that being a skill issue.

How did it feel when the rocket finally launched?

A little anticlimatic; because of the exponential nature, once you start going you really start zooming off with the resources. Also, since I built the shuttle right next to the launchpad I didn’t need to “escort” the shuttle like the tooltip suggested. I thought that would have been a fun thing to do.

To address the exponential nature, you might want to consider adding competition or exponential costs.

For example, maybe the cost of habs increases exponentially instead of having a static price. Or you need to build electric distribution which scales exponentially with the size of your base (since area grows faster than the perimeter). Or maybe as you have more astronauts, you need to mine more Helium-3 to refuel delivery ships for essentials, and this would compete with your desire to mine regolith.

Something that I would want to do is add more risk-taking to the game. I would probably do something like this:

• Regolith is easy to find at the beginning, but there’s not much of it.
• You need meteors to fall on the surface to replenish the regolith, but only where your buildings aren’t.
• You can build things to intentionally land big, dangerous meteors on the surface, but you have less control over where they might land.

So this might make an interesting balance where the larger your base gets, the less regolith is available, but you can also take risks by flirting with danger. But, I don’t know! There’s probably more ways to do it.

[Seabass]

The meteors scale with a hidden “colony wealth” value, and then the radius and center of the meteor shower is set by your colony centroid and average size, which isn’t ideal, since it punishes players who build dense. The system clearly needs a rework.

It’s funny because you are by far the most conservative player, another playtester who has played the game for hours at this point is the exact opposite and just spams spread out structures, and I am somewhere in the middle.

I was worried that the core gameplay loop would be too fundamentally exploitable, to the point that it:

1. becomes boring in your case (conservative)
2. becomes absurdly easy (and boring) in the opposite direction
   Both of which are “meta”. This seems to be the case.

The problem is that I’m not sure how to give the player a more active role without complicating the game. I’d like to do it without adding more structures or a new resource type to the game.

• solar flares permanently damage a percentage of structures which require repair? currently solar flares are kind of nothingburgers unless they are timed with a meteor shower
• nuclear reactor meltdown
• scripted meteor showers for certain milestones

None of these options really increase player agency and add a risk-reward dynamic though.

I like your idea of triggering meteor showers intentionally. Your faucet also becomes your sink. Making regolith more scarce makes the player more conscientious about building placement earlier in the game, and increases the frequency that players are encountering danger. The hard part I think would be balancing it to where players aren’t constantly calling in meteor showers or never calling in meteor showers.

It might also be nice to have destroyed buildings drop resources, so that there is a somewhat closed system. Meteors showers only need to be triggered when you need to increase the regolith in the system, but regolith/metal doesn’t just “disappear” when something is destroyed, you only pay for destruction in time.

Initially I had the idea that players send ships to earth in exchange for things they couldn’t obtain from ISRU, but when I was finalizing the scope I decided to keep the game about as small as a Flash game, and the loop was pruned down and simplified a lot.

I shouldn’t have picked a game with an economy for my first game :(, but in the process I learned that games are a lot more fun to make when you’re playing with mechanics, so for my next game I want to make something where I can constantly throw new ideas into the mix, rather than just tweaking an economy (boring).

EDIT: now that I think about it, meteors delivering resources makes a lot of mechanics more interesting like refinery placement, building placement, needing to actually use your resource radar, and a limit to exponential growth in the lategame. In the early game I can make things cheaper while there is still the starting regolith on the ground. The meteor faucet becomes more important in the lategame.

[pigdeons]

Getting this error from the .app! Unsure why that is…

[Seabass]

The other Mac user reported the same thing. Unfortunately I don’t know if I’ll be able to troubleshoot without access to a macbook, so I am probably going to push Mac builds back towards the end of my todo list

[exodrifter]

This is a really annoying and misleading thing Apple does, which is hostile to developers who do not take the time to pay Apple for an Apple computer and a subscription for an Apple developer account to do proper app signing. The application isn’t actually damaged; it just isn’t signed.

If you are comfortable using the command line, here is how you fix it:

xattr -dr com.apple.quarantine "<application.app>"

…where <application.app> is replaced with the path to the application.

[Seabass]

@exodrifter

xattr -dr com.apple.quarantine "<application.app>"

Oh that’s really helpful. I have a couple of friends with macbooks. If that’s all it takes I can just do that before I ship the executable.

[exodrifter]

No, it is not so easy. If I remember correctly, MacOS applies this attribute on the fly when the file is downloaded. I’m not sure if there is a way to circumvent it.

[Seabass]

(T_T)

How do people that make applications for Mac get around this? Is there some official Apple certificate server that you have to register with-- or is the expectation that everything is download through the app store? Never used an Apple computer before so I have no idea.