Little discaimer: Before you start reading, this article is something in between technical and game design, as "game design drives technical decisions".

This week I've been working mainly on one feature, I don't know where the idea came from, but probably I've seen that in games I've played. What am I talking about?

Well, something like this...

In other words, the transition from the homescreen to the actual game is a smooth animation and not a loading screen.
I personally LOVE this change.

Edit: it looks like I was using the wrong term, this is actually a title screen (according to this page and this Glossary of video game terms)

Anyhow, this transition thing also implied a bigger change. Before, the orbital view and the ground view were one BIG scene, and it was too heavy. As I want this to run smooth on mobile devices, even on not so powerful ones, I needed to break things down into smaller pieces, especially considering that I'll have to add some other features that are going to add weight to it.

So... I've spent quite a bit of time separating components, or scenes, into a hierarchy that goes like this:

The Toolbar loads the following UI elements as needed:

• the orbital view UI
• the ground view UI
• the mission view UI

Those are instanced as children of the Toolbar when you click the start button, or when, from the ground level you call the orbital view again. Each type of UI has it's own sub components and specific functions to drive the 3D scenes.

The 3D scenes I'm talking about are (for now):

• the planet  Mars as seen from orbit (animations can be called as soon as it is loaded)
• the ground level (this is the heaviest scene)

This kind of structure implied the use of custom signals, meaning that a 3D scene can send a signal to the UI (and vice-versa) so that the UI can act accordingly. I think this is a valid design decision, but I might be wrong (I'm open to suggestions in the comments).

I believe those animations, or transitions make the UX more immersive, as transitions are not abrupt, but rather smooth. I will probably refine this process later on, and will surely add the same from the orbital view to the ground view.

Divide and conquer

Well, not sure about the conquer part, but divide a bigger scene into a smaller one make things easier to manage:

• code is simpler, as it is subdivided accordingly
• scenes "components" become reusable as needed

Of course, this has to be done wisely, or else you'll make it worse. Godot makes it easy to do that even on a later stage, when the scene becomes too complex.

This subdivision implied also a reorganization of the folders structures, I have one for UI elements (control nodes), another for the 3D scenes (orbital view and ground view for example).

Some of them are further subdivided into "components" UI or 3D elements that can be used multiple times, being via code instancing, or directly into the scene.

World simulation and game state

Well, I've not been relaxing this week, I've also worked on another VERY important aspect of the game, the gamestate and the world simulation.

I needed an efficient way to have the world simulation interact with the visual elements of the game, still been able to parametrize from the editor units, buildings, cameras, and so on without making everything too complicated. And of course save that into a reasonably small file.

World simulation

What I mean by "world simulation" is, basically, everything happening around you, or on the planet: global storms, meteorites striking the surface, your bases running out of food or oxygen, your units loosing energy and health, and so on.

As you can imagine, on a planet, even a desertic lowlpoly one, there are tons of things going on, so I needed an efficient way to represent that, and, of course, easy to save onto a file.

So after reading the documentation I realized I can do this using 3 different classes:

• an object
• a resource
• a dictionary

Actually, resources are a class inherited by objects, and have their advantages over objects, being that I can assign them as parameters for the object (scene) I'm working on, being a unit speed, health, relative position, and so on. This means I can work with them from within the object inspector in the game engine.

The advantage of the resource is that it's lightweight, editable from the editor and easy to save. The only disadvantage is that it's a little bit heavier in terms of size when saved.

Gamestate (or the state of the game ?_?)

For gamestate I'm referring to the possibility to save the current game status into a file and to be able to reload that, a savegame.
So I had to study, I read the official documentation about how to save user data and tried different, but similar approaches:

First, I just followed the official documentation's tutorial and copy pasted the code (so to speak). Problem is, the size becomes huge even with just a few objects (4KB it's way too much for 3 units and a base). So what I did was investigate about file compression. COOL! Godot allows that! I tried the fast compression and things got way better... less than 1KB!

As soon as I managed to reload and read that data I left things there (because chronologically speaking I've worked on this first, and transitions after).

Will continue work on world simulation and gamestate next week and most likely for a while. Can't wait.

Final note: I should thank my brother that spends a lot of time checking my tweets, giving me feedback, suggesting features, making the music and some of the models.
And a BIG thanks to my friend Buoy, I'm bothering him to help me proofreading, I'm not native English speaker.
I have also other friends helping me with internal testing, so thanks to them too (even if I know none of them will read this).