Prelude

Turns out writing devlogs is harder than I expected. I presume it’s mainly because it’s not as fulfilling. While I know that some time down the line I will be glad that I documented my journey, right now it’s hard to value that distant future, when I can do things that are rewarding right know, such as adding new features. This is a long-winded way to say that it’s been ~3 days since last entry and a decent amount of progress. Hopefully I’ll write those devlogs more often in the future.

What changed?

Commits since last entry:

 1* d2b654e Basic upgrade system
 2* 241fb5e some scattering improvements
 3* a06d2ff Rock scattering
 4* 62ab493 git-lfs setup
 5* 55b41af noise shader adjustement
 6* 22bb5aa Resolution scaling and grayscale
 7* e4a7f47 Strands, signal noise
 8* bffd68d Terrain improvements
 9* 5592282 Add video to devlog/0
10* 4058040 stuff
11* bfa53ad Remove unused shader
12* 484cff2 Shrink down wheeled drone

I’m glad I commited to commiting more often (pun intended!). Otherwise it would be hard to remember what I’ve done.

I’ve scaled down the wheeled drone by about a factor of 2, to keep it more to-scale with built-in units. I’ll probably adjust that in the future, but I’ll leave it for future me. It will make more sense once I have more models to reference.

I added more surface materials, mainly a dark-rock one that makes it look much more like Venus that Mars, which is what I’m going for.

Next up, I created a basic model for Strands - that’s what I decided to call the antennas that the player will place to extend the range of the drones. It’s very crude placeholder, but I will refine it later, once I have a clearer vision on how the tech should look. I also added the code for them to work. What does that mean, you ask? They will work similarly to “Tethers” from Astroneer: they will need to be connected to the main “base” and they will be chained together to reach further places. Except instead of providing oxygen or power, they will relay signal between the base and the drones. Mainly video feed, but probably also audio and controls. I’m planning to add the functionality where if the drone totally loses signal it will be unresponsive - meaning the player will have to use another drone to rescue it. But I haven’t fleshed out the fail-states yet (i.e., how player can get stuck, how can they get un-stack), so it’s postponed for now.

Then I moved on to resolution scaling. The idea is that the drones will start with a low resolution grayscale camera (let’s say 180x120px) that the player will be able upgrade to higher resolutions. Similar thing will apply to framerate. Generally, I look at what I can take away from players and gate it behind an upgrade ;] I achieved the resolution scaling by rendering to a viewport, setting that viewport size to the resolution of the camera and then stretching the viewport container to fill the screen.

I also tried to breathe more life into the environment by adding rocks. While browsing through Terrain3D documentation, I saw a few mentions of a plugin named ProtonScatter that can randomly place props. So I enabled the integration between the two plugins and grabbed some rock assets from ambientCG.com. Using the ProtonScatter plugin was surprisingly easy, but when I tried to place a larger amount of rocks I noticed it takes a long while. What’s worse, it was doing that on each tab change, so navigating the editor was slow.

I experimented with various settings (just copying the scene, multimesh instancing, pre-baking to tree), but all of them were either slow or were missing physics colliders. It turned out that the model I was using was needlessly detailed (I didn’t know the “16K” in the name meant 16K vertices…) and after I decimated the model down to ~700 vertices it got much faster. What’s counterintuitive is that multimesh instances are slower than copying the rock scene, both during generation and when running the game. Remember to always test the performance!

Finally I got it to the point where it’s performant enough. Enough is the key here, because placing 8000 rocks with their own colliders is bound to take some time. Maybe I’ll get back to optimize it more in the future, who knows.

Last but not least, I started working on the component and upgrade system. It’s going to be a pretty foundational part of the game loop, so I wanted to get it right from the start. I spent some time thinking how should I structure it in a way that is easy to use from the editor (e.g., adding new upgrades, changing them), but also maintainable in the code. I’ve decided to use Godot’s Resources for that. They are serializable structs that (generally) only hold data and can be easily modified from the editor. And they can be store other Resources, so I can have a Camera resource that has a Resolution resource and changing from 120p to FHD will be as simple as swapping the Resolution. I’m pretty satisfied with that solution, although I don’t doubt it will require some adjustments in the future. But you can’t predict everything!

In the past few days I’ve also been thinking about my view on using other people’s assets or addons in my game. It might seem weird, it’s pretty obvious that that’s what you do, right? But I’m worried about making an asset flip, or that assets made by other people won’t have the soul for this game specifically. And I kinda take pride in doing things by myself, implementing things on my own, etc. However, if I think about it realistically, assets made by me would take a lot of my time and would still look bad. And combining things other people made in a coherent and visually appealing way is a skill of it’s own, right? Same goes for using tools. It’s what helped us excel as a species: using tools and helping each other. What helps me further “justify” it, is that some games that I love also do that, so you can make a great game even if you don’t make everything from scratch. I hope one day I’ll be able to pay back for all those free things I used.

Now I’m going to implement a battery that will be drained passively and while moving. As a side-quest I’ll probably do some HUD to display current battery level and maybe signal strength as well.

Postlude

Another value that those devlogs bring is making me reflect on what I’ve done. It really helps appreciate the total work that I’ve accomplished. It’s too easy for me to only see current feature/problem that I’m working on. And that current thing is never finished, because once it’s finished, it’s no longer current, so I’m at 0% of next feature. But with devlogs (and a general todo-list) I can see the forest for the trees.

And, surprisingly, this devlog was quite a joy to write. I feel like I’ve maybe written too much and it’s not as condensed as I would like, but “if I had more time, I would have written a shorter letter”.