Martian Agora: Structure statuses. Distributed resource consumption and production.

It's that time again to celebrate progress. Here's a nice video so you know what I'm talking about:

The Details

Introducing: the virtual reality visor! This overcomes a game immersion issue I had.

Game immersion..? You know that feeling when your mind dives into a game, movie, or book so much that the real world goes away? That is full immersion. It can be disrupted many ways: a real life phone call, cat, awkward writing, or bad game design.

Those blue transparent "blueprints" don't exist in the game world. That ruins immersion because it makes no sense for us to see them. I needed an excuse to show them to the player. So now you must be wearing the visor to see the structures you have planned. This way it still feels like you're only seeing what your Martian is really seeing. I thought this was a great solution because "virtual reality" is a real technology that we have today. It also got me started on my first of many "visor" items.

Structure list

Resources can be produced, consumed, or stored. A resource with a green circle means that structure produces that resource, a red bar means it consumes it, and a white square means it can store it. Not super beautiful but it works great. Note that the number of icons is an approximation of the rate/capacity. The game uses real units internally like kwh, kg, etc.

Structure blueprints

The new blueprint window! It's getting easier and easier making new windows like this because I can re-use code. Resources are displayed here just like how they're displayed in the structure list. That is my ResourceReusable class, just one of many "reusable" classes for GUI stuff. This is one of the advantages to planning out my GUI system. I know in advance which visuals I am going to re-use.

Coroutines

Coroutines? If you're not a programmer, maybe skip this paragraph.

I started using coroutines. This way, every single building isn't calculating what it's doing every single frame (which can be up to 60 times a second). Each structure does its thing every second and generally on a different frame because the coroutine is started whenever you start the building. I am aware there are cleverer uses of coroutines, as I've read about them and even went to a talk from a Unity3D software engineer about them! But this is actually my first time using them in any language so it's great to start simple. They're performing great.

Comments

I wrote a ton of comments in my code.

Comments? Commenting is this thing that programmers always say is great to do, but then never do it. As you can see from the picture below, code is weirdly halfway between human-readable and computer-readable. Humans can "read" computer code like this, but it's more work than reading English comments.

Well this is now my second biggest Unity3D project (4942 lines of code). Even though my pseudo-professional design patterns and coding architecture choices are all in my head now, they won't be forever. Sometime, future Stuart is going to wonder what the hell past Stuart was doing with his bizarro code. When that happens, it is much nicer reading a paragraph in English than trying to make sense of hundreds of lines of magic code.

I've never felt the need to comment my code this thoroughly for any project. But I intend for it to get a lot bigger. And that's not going to be possible if it's too hard to remind myself how the pieces are put together.

Milestones

I keep a spreadsheet listing all game ideas I've ever thought of, sorted by priority (around 100 ideas now). Well I invented a "milestone" system which allowed me to go through them all and re-prioritize. My first milestone is "plausible survival and death". Everything I do will be focused on that until I feel I've achieved it. I was surprised how some tasks ended up being much higher priority or lower priority than I thought when put into context.

Distributed resource consumption and production

This also used coroutines. Whenever a structure tries to consume or produce electricity, water, oxygen, or whatever, it makes a request to nearby structures. A producer must check nearby storage if there is space. A consumer must check nearby storage if there is enough to operate. For now, all structures are magically connected to all storage.

Flywheels are like batteries.

They store energy by spinning a heavy internal disc. Thanks for the idea, Karl.