next »

[BTSeven]

Hello everyone!
Since today is the 23rd of september, you might have noticed that we didn't start our Kickstarter campaign on the 21st as we said.
Alas, our time estimates were a little too optimistic. Not too much though, don't worry - we were mainly busy preparing for a local event in Milan, so we couldn't work on the campaign as much as we wanted to.
That said, our campaign is delayed to mid-October (we will set a more specific date soon). We're very sorry about that, and to apologize, we're posting the Deep Flare: Explorer opening cinematic. Hope you'll like it! As usual, we're feedback-hungry.  

(Click on the image to watch the video)

[BTSeven]

Hello everyone!
We haven't posted in a while, since we're working hard setting up our Kickstarter campaign, and preparing ourselves for the upcoming Milan GamesWeek partecipation.
But let's stop talking: here are some recent screenshots. We've been playing with various blur effects... what do you think about it?

Also, here's the HUD! (character lines are still partially in italian, but we'll translate them soon)

[BTSeven]

Hello everyone!
It's been a while since we last posted something, and we're very sorry about that.

As we wrote last time, we were exhibitors at the Milan GamesWeek 2015. It's been an exhilarating experience. We had time to get to know a lot of other talented italian developers, as well as members of the press, and having the opportunity to get our game tested by tons of people passing by, we got an overwhelming amount of feedback.
Then, we got back to work.

First of all, we decided to add voice acting to our demo. It's been hard work, but it was worth the try. We still don't know if that feature will make it to the actual completed game, but at least now we're aware of every cost and pitfall involved.

We've also considered many possible means of getting financial support other than crowdfunding, though in the end we're probably sticking to it.

And last but not least, we tried our best to make something enjoyable. It's far from being perfect, but eventually we made it.

We still need some days to deliver, so if you're interested, please hold on a little more!

[diegzumillo]

Good to hear! =)

[BTSeven]

Just a little more time...

[BTSeven]

Hi! We're working on our Official Trailer™, but in the meanwhile, we've come up with this 'gameplay teaser':





What do you think about it? Any advice?

[BTSeven]

And so, after a long time...

Here we go!



The playable demo of Deep Flare: Explorer is ready!

You can get it on our Greenlight Concept page!
(Or IndieDB)

This little early version is set more or less 'in the middle' of the complete story arc.
After an unlucky incident, you got stranded on Europa, and you're unable to get your ship to lift off. So, with your module, you'll have to explore the icy moon searching for a solution... but of course, not everything's going as expected.

The demo is compatible with the Xbox360 controller, as well as keyboard, of course - even though we think it works better with the controller.

We added a full-fledged tutorial, but if you want to quickly jump into action, here's a as-brief-as-possible list of controls and features:

• A button \ UP arrow key: fire the engines. Doing so will consume fuel. Once depleted, it's game over, so be careful. You can craft more fuel units while docked into the main ship, opening the menu and going to the Crafting section (first icon from the top).
• LEFT analog \ LEFT-RIGHT arrow keys: rotate the module.
• L3 (pressing left analog) \ DOWN arrow key: dock\undock the module from the main ship.
• B button \ left Ctrl: toggle tractor beam.
• Y button \ left Shift: toggle zoom.
• L2-R2 \ Z-X: navigate through equipments.
• X button \ space bar: use selected equipment.
• (While landed) L1 \ Q: analyse the surrounding area.
• (While landed) R1 \ E: drill the terrain.
• START button \ ESC: open the menu.
• (While navigating the menu) LEFT analog \ arrow keys: navigate.
• (While navigating the menu) A button \ space bar \ Enter: select.
• (While navigating the menu) B button \ ESC: back.

The module is equipped with 5 different tools.

The Magnetic shield is one of the most useful. As the name suggests, you can use it to protect yourself from crashes. While it is equipped, you can activate and deactivate it by pressing the 'use equip' button. Once active, the shield will protect yourself, absorbing damage. It won't run out of power, but it has its own resistance points, so bashing around with it will result in the shield breaking. But don't worry: you can break it 2 times before having to craft another. It also has some interesting side-effects, like slowing you down and rotating you chaotically (because of increased friction with the atmosphere).	The Laser cannon can be used to melt thin ice, or, should you need... to kill things. Be careful though, since you can shoot only 5 times before having to craft new batteries.	The Repair kit will restore structure points as soon as it is used (even while flying!). Miracles of engineering...
The Engine booster is useful to make quick, powerful bursts of acceleration. Of course, you need to pay attention: smashing at high speeds against a 20m-thick layer of ice can be an unpleasant experience.	The Beacon deployer is the only tool you can use only if landed properly on a flat surface. As the name suggests it will deploy a beacon on the ground from the 3 it has in storage. Deploying a beacon will save the game (and overwrite your previous save).

And... that should be all. Thank you for your patience, and feel free to let us know anything you have to say about our work!

[BTSeven]

We're now on itch.io!

[BTSeven]

Hi there!
In the last few weeks we received quite a lot of feedback about the demo, so after a bit of testing from our part we managed to put out another version featuring a few fixes and "improvements" here and there.
Being more specific, we added labels to the in-game menu icons and a hint about what button\key you need to press in order to dock the module into the ship when you're in the "right spot".





We updated all the links you can find on Greenlight Concepts, IndieDB and itch.io.

Also, some people told us that they found the tutorial boring.
What do you think about it? Having a fairly complex gameplay, we thought that a linear, in-detail tutorial was needed, but we're always ready for suggestions.

[BTSeven]

Hi everyone,
as mentioned some time ago, after weighing up all the possible means of funding, we decided to proceed with the crowdfunding.
We were supposed to launch our campaign some months ago but, as already said, we took our time to make accurate plans concerning the work to be done: we're now confident to start on SATURDAY, 9TH APRIL 2016.
In the meanwhile we'll keep on adding contents and material, concerning both the game and the back-story, so keep on following us!

[BTSeven]

Hi everyone!

With our Kickstarter approaching (launch scheduled on April 9th) we decided to open a new series of backstory-related videos. The first one was about the Helios Mission and was set in the '70s. This one is going to tell the tale about how was the TSEF created, and is set in the late '90s.

Meet a young Kara Walker, one of the pivotal characters of Deep Flare: Explorer.

(Click on the image to watch the video)


Hope you'll like it!

T minus 13 days and counting!

[BTSeven]

Hi guys! We just started a Thunderclap campaign!



Please support us if you like Deep Flare: Explorer. Being based in Italy, we're having a hard time in reaching an international audience, so everyone of you could make a big difference for us with just a single click
However, thank you for giving a look to our project!

T minus 6 days and counting!

[BTSeven]

Hi everyone!

We're now live on both Greenlight and Kickstarter!

And there are still roughly 24 hours left to our Thunderclap!
If you're interested in our project, please consider supporting us! Even a single supporter could turn the tides of the campaign!

We also produced another backstory video!

(Click on the image to watch it)


Thank you for your time!

[BTSeven]

Hi everybody!

Some days have passed and both our Kickstarter campaign and Greenlight page are slowly crawling forward.
Too slowly, someone might say. But we're not giving up until the end.

We put out a couple of updates in the meanwhile - the first one covering all the first backstory 'season' set in the '70s, and the second about another planned feature: Planetary Bases.

Positive news: we got some press coverage! It's still only a little, but very much appreciated nonetheless.

And that's all folks

[BTSeven]

We've been greenlit!



Thanks to all who supported us!
There are still 12 days to go for our Kickstarter campaign. Maybe we won't make it, but who knows... one can still believe in miracles

[BTSeven]

Hi everyone!
We didn't post anything in a very long while: more than a year - actually, almost 2 years - but that doesn't mean that we weren't working on the project.
Actually, after our failed KS campaign, we managed to survive through a rough time. Some guys left the team, some others had to drastically reduce the work hours they could devolve into our project, and generally speaking anyone of us had some pretty huge amount personal-life issues to take care of. But as I said, we didn't stop working. The project saw a major overhaul of some features, but the core features (which were playable in the Europa demo) are still there, and are even more polished now. We had to basically rebuild the game from the ground up though.
We're now in an "advanced alpha" stage of developement. The core gameplay code is up and running, and so are all of the tools we needed in order to create the actual game content. Graphics are still in a graybox stage since we moved away from pixel-art and embraced a new high-definition 2D style.
We added a brand new lighting system, completely re-done the HUD, and modified the game controls - which now use both mouse and keyboard (or a gamepad if the player chooses so).

Of course there are many more news to come, but I think that's all for now.
Some alpha-stage gifs:


Timelapse of our new lighing system.


Of course, it's still possible to smack down ostacles in the usual way...

[BTSeven]

Hey guys!
Just a little catch-up - in the last few days we've been implementing some module equipments, like the magnetic snare for picking up things, and the analyzer, which you can use while flying around in order to discover (and, when possible, identify) mineral deposits, energy sources, and "important stuff" in general.
We're following a "gameplay-first" development approach, so don't mind the graphics (it's still blocktober, right? )


Magnetic snare, replacing our old (and not so realistic) tractor beam


Iron deposit on top of a mountain


Unknown object. By picking it up with the snare and carrying it to the ship, you will maybe identify it

[BTSeven]

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.   

Our 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.

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 pretty much everything for the past week

[BTSeven]

Hi!
This week we've all been busy with personal stuff, so we're going to make a 'delayed' devlog about something we've worked on some time ago.
As we briefly introduced last week, in Deep Flare the graphics style is no longer going to be retro-oriented as was planned for Deep Flare: Explorer. Instead, we're going for an hi-res 2D approach. We're still figuring out how to make most of it, so we don't have much to show - you might have noticed that from our WIP gifs. But there is one aspect of it that we settled for good: the terrain.

Old style vs New style

For our planets' ground, we went back and considered again one of our prototypes from back when Deep Flare: Explorer was still just an idea we were considering. At the time, we sketched most of the gameplay using a black-and-white, vector-style graphics. It was just a prototype, but there is something about that style that sticked with us. Aesthetics aside, this approach gives us a considerable technical advantage: the ability to represent the whole planet - or chunks of it - as a list of vertices, one connected to the next, forming a circle. In DFE, the terrain was tile-based, as the pixel-art tradition dictates. But that approach forced us to either work with a very limited set of graphics, or to put more work on our artist's shoulder, asking him to make more and more different tilesets - most of which would be used only a couple of times in the whole game.
With a vectorial approach, we trade the neat grid of the tile-based system for a more flexible one, which perfectly fits our new graphics style.

Representing the terrain as a list of vertices leads naturally to think about it as a flat 3D model. And if the terrain is a flat 3D model, we could use Unity to create our levels directly in-editor! Long story short - after some hard work, we coded a bespoke solution for creating and editing our planets by using custom editor windows and inspectors. This way, Matteo will be able to iterate his level design directly, without having to ask for changes to be made, and that of course is going to ease a lot the development process.

If you're wondering about how does this system work, it's dead simple. We coded a script which uses Unity's Mesh class, in order to create one and assign it to an object's MeshFilter. Inside the script, we have a set of terrain vertices, which are used to compute the actual mesh vertices, indices and UVs by some code that prevents the end result from having weird distortions - and adds the terrain collider using a PolygonCollider2D with the same list of vertices. On top of all of that, we have a custom inspector which overrides the OnSceneGUI method to provide a handy editing tool, and a custom editor window for creating planet terrain objects.

A new level is born!


Editing the terrain


End result!

[BTSeven]

Hello everyone!
Once again we're going with a delayed devlog about some stuff we've done some time ago. Alas, lately we've all been busy taking care of various things such as day jobs or university commitments. As we wrote in our first catch-up message, we knew that such moments were going to come and we planned our work accordingly. So, things are slowing down but definitely not stopping.
Enough with non-developing business! Let's talk about today's topic: the evolution of our game's HUD.

Ye olde HUD vs the brand new one.

The HUD in Deep Flare: Explorer was designed around the idea of simulating a cockpit display, so everything the player would ever need to know was basically visible all the time. "Vitals" values - such as hull integrity and fuel amount - aside, that meant having to take some screen space away to show the system messages log, William's personal log, the minimap, the focused documents section, and so on.

This approach received kinda mixed feedback. While some people didn't really care about it, some others criticized it as a "screen space theft" at the expense of the actual game view and all of its graphical features (parallax backgrounds, particle effects and so on). Alas we didn't have time for remaking it again while also working on our crowdfunding campaign and the other game features, so we stuck with it. But since we've decided to remake large portions of the game anyways, the HUD was actually one of the first things we got to work on.
But now, let's dive into the new system we came up with:

VITAL VALUES AND MINIMAP
Hull integrity and fuel level were, and still are, the most important things the player has to keep his eye on. Hull integrity is represented as a curved bar that gets depleted when the exploration module is hurt. Fuel level, on the other hand, is now actually called Battery Charge - due to changes in the scientific design behind the game's tech - and is represented as a percentage.
The new minimap shows a wireframe-styled terrain and background now, instead of the old scaled game view, and we're planning to add several markers on it to help the player navigate the level.

MESSAGE ZONE
In the old HUD design, there were 2 main 'messaging' areas, both at the bottom of the screen. The left one was William's personal log, where he commented what he saw during his exploration. His face was also visible, in a sort-of Doom fashion, to let the player know about his emotional status. The right messaging area was the actual 'system log', showing messages about incoming transmissions, analysis results, and so on.
In our quest to free up screen space, we completely removed those two areas, which have been replaced with popup messages that will show up around the module. William's personal thoughts and comments are shown on top of the module, while the system log is now actually split into two kinds of popups: "standard" system messages (shown on the left) and system warnings (shown on the right). The former are those related to player activity's result, such as amounts of material drilled, names of objects taken, and so on. The latter are of course 'alarms' for the player, signaling whether there is little battery charge or hull integrity left.

Thoughts - Messages - Warnings

EQUIPMENT SELECTION
Equipments are still selected by scrolling through them through pressing a button, but the relative graphical interface has been moved from the top-left corner of the screen to the center of the view. Its visibility is toggled by a change in equipment selected; after a few seconds, it fades away, freeing the screen space.

EQUIPMENT HUD
Once an equipment is selected, its peculiar HUD is activated. Every single utility has its one, allowing the player to get clear and concise information about its capability. And, since some utilities have different control systems based on which input system is selected (mouse + keyboard or gamepad), the HUD can display different icons based on it.
Here are a few examples:

Cannon HUD, displaying allowed shooting area and aiming line


Magnetic Snare HUD, displaying allowed area


Flyby analyzer. Different kind of markers are added to the game view and minimap upon analysis


The Drill HUD is displayed on landing. It shows how much material is drilled and the amount of space left