Hi everyone!

In the past few days, we've been working on some behind-the-scenes stuff.
Right now Matteo is focused on designing the first episode's content, so he started by drawing a sketch map and writing a gameplay flow example for the Moon level.
One of our main struggles in developing our project is to keep a proper balance between scientific rigor and game design needs. We want the player experience to be neither too toyish nor too harshly simulative: while Deep Flare is of course a game, mechanics and plot are both firmly grounded in scientific (and political) realism. We based our work mostly on good old "hard" scifi and we want to respect that. But of course, the game also needs to be fun to play. Digging too much on realism can result in both a frustrating experience for the player, and a diffucult time for us to develop the actual content.
When it comes to level design, one of the first issues to take care of is the map size. We want our explorable bodies to be proportional to their real counterparts, but we can't use the real planet\moon circumference for each one of them: this would result in huge levels, impossible to properly fill with content in a realistic working time. We need to shrink them down, but not too much, or we're going to face the opposite problem and get ridiculously little maps.

In our old Europa demo, we went without a proper planning, and the level was sketched on a 1080x1080 sheet - setting the scale at 1 pixel : roughly the module's size. The resulting level was about 3400 pixels in circumference, while the real Europa has a mean diameter of 3121km, thus a 9805km circumference if we take a 2D slice passing through its center. Let's take a very rough estimate here and approximate the exploration module as a 10x10x10m box. Its 2D slice would of course be a 10x10m square. If each pixel in the Europa map sketch had the same size of the module, that would leave us with a level circumference of 34km... about 1/288 of the real thing.

The old Europa sketch map.

Surprisingly enough, it didn't feel too little to explore. A game should prioritize fun and playability after all, and as we said before, a real-scale Europa would not be so enjoyable to visit, being mostly a barren icy rock. Moreover, it was only a demo, so it didn't feel wrong to have a small level; and of course, the internal ocean added a whole underwater surface to explore, not to mention the water in between, which was a 'vertical' content layer on its own. The inner core had more or less half the radius of the outer surface, so its circumference would be 17km. Inbetween the two, the ocean area would roughly be the difference of the two circles: after some quick math, that's about 68km^2.

Size comparison between old and new scale

But now, tackling the Moon and having no internal ocean at disposal, we had to set a proper scale, one to be maintained throughout the whole development. The Moon's mean diameter is 3476km, so if we used the same proportions as Europa's, we would have sketched the map on a 1200x1200 sheet. That would never be enough: on Europa we had a total 51km of surface + a 68km^2 area, while on the Moon, we would have only a  37km surface to work with. Having no exact reference for a proper scale, we went by trial and error. After a bit of work, turns out that a 1km:1px conversion is a good balance: that way, assuming the module section as the 10x10 square we used in the previous estimate, the scale would be exactly 1:100. That means that the new Europa will be about 3 times the old one. Luckily, we were planning to make it about that size from the get-go, so we're fine :)

Speaking about more technical matters, Michele has been working on a lot of internal tools for developing the game's content. "Videogames are just databases with a pretty front end" - I don't remember where did I read this sentence, but working on DF I can't help but agree. The game is going to need tons of data - missions, dialogues, crafting blueprints, and so on - and in order to streamline the writing workload, we developed a simple DB system using Unity's capability for writing custom editing tools.

Basically, we save all our data in a bunch of xml files using the XmlSerializer provided by .NET; the actual data content can be accessed directly via Unity Editor, using some custom editor windows we've coded. We had a minor hiccup while developing all of this, because it turns out there's no way to access a project's asset only by knowing its name (or path in the original project folder) in standalone mode, and of course we need to save quite a lot of images and prefabs references on xml. In order to solve this, we had to take advantage of the Unity Asset Bundles, which - by the way - we were going to use in any case to support the game's episodic release structure.
In the meanwhile, we've also been working on our save\load system. The problem here would have been to save each single object's state. Since our gameplay makes quite a heavy use of physics, we're going to have no shortage of rigidbodies around our levels, and we'll need to be able to uniquely identify each one of them when saving or loading. The .NET Guid class did the trick, by allowing us to assign an unique ID to each object in the editor.

And... that's all folks!