Developer update 5

Lire la version française de cet article.

As most of the problems encountered by the first players have been solved, we’ve focused at 95% on the Mk II.

General progress

We are a little late compared to what we hoped for initially, but we’re doing everything we can to ship the first big update before the end of March. We question ourselves about the new multi player mode: races. This mode is implemented for quite a while but we would like to make it more “spectacular”, and this requires more 3D models and more visual effects.Presently, 3 out of 5 missions from the second act are done, requiring only to polish and test them as most of the heavy work is done. The couple of last missions are far more complex in term of scenario (and far more long to play!), so we care especially for them. For information, all the missions from the second act (except for the introduction one) are as long as “Storm” from the first act, and harder as well.

The second cockpit is almost finished, small texture elements are still missing, as well as the animations for the stick, throttle and rudder, in order to be compatible with the new system.

We are (with help from our KGP3D friends) also adding several 3D objects to add life and diversity during the missions.


We have also spent time to make the game look greater, especially by tweaking desert colors.

Some of the missions are set by dawn or sunset and the past colors weren’t a barrel of laughs. Let the new settings speak by themselves.

I must confess that this picture randomly found on internet has helped me a lot:

desert sunset


Lastly, here’s an update on our Greenlight status.  Since the last validated batch (early March) we have climbed to 90%, then 89% of our way to the top 100. With several batches validated, we should be validated as well, by lack of projects ahead of us.

Although, it’s been two days our curve is above the Top 100 one, but without being in the Top 100. We still don’t understand nothing about how it works.


Update: 88%

Developer update 3

Lire la version française de cet article.


At the time of writing, we have sold 100 copies of the games on Desura, which is pretty good given the fact that the platform is relatively small and the game is still in alpha stage.


We have now more than 6666(!) votes “Yes” on Greenlight, thanks you to everyone for your support. In one week, we’ve got more votes than during the previous month thanks, among other things, to the articles on us from several websites (one of which being our second appearance on RPS!).

We still don’t understand shit to the computing process, especially one of the indicator: the curves of our performance compared to other submitted projects. Indeed, they continually change, several times a day. For example, look at yesterday’s variation:

Variation of statistics from 02/27/2014
Varying statistics from 02/27/2014

We ca see on the first couple of captures that we a above the Top 100 curve, nonetheless the percentage indicator still give us : 83% of the way to get into the Top 100.

If anyone has a clue on this, please tell us.

First patch

Quickly following the public release, several problems has been encountered by the early players. We have done our best to fix them as quickly as possible and a patch is already pending Desura staff validation.

This patch will fix the following problems:

Crashes fix

In some of the missions, a succession of special events could lead to a crash. This was due to a major change in the scripting system (linked to the cockpit work), all should be fixed by this patch. I know, the conditional tense may not be very reassuring, but I know by experience that even with intensive testing of a game, we cannot be sure all the bugs are gone.

Sound improvements

There was (and I hope there isn’t anymore) a quite annoying sound related bug that would randomly make the engine sounds muffled. This seems to be an OpenAL issue (even I am not 100% sure) and a workaround hack had been done.

In addition, sound mixing inside the cockpit view has been improved.

By the way, OpenAL has been the worst technical choice I have made on this project, mainly since Creative doesn’t seem to support it anymore. As an alternative, we had to switch over to OpenAL Soft, a fork of OpenAL (currently in development), without a lot of harm luckily.


There was no much interesting things last week, technically wise, besides the improvement of anti-aliasing. Due to a file handling error,  the anti-aliasing labeled as FXAA (Fast approXimate Anti Aliasing) wasn’t bound to the right shader. So I have fixed this problem and the used method was renamed SSAA (Screen Space Anti Aliasing). FXAA method requires more computing power than SSAA, but offers a far better visual quality. Let’s see:

Left: No AA, center: SSAA, right: FXAA.
Left: No AA, center: SSAA, right: FXAA.
Left: No AA, center: SSAA, right: FXAA.
Left: No AA, center: SSAA, right: FXAA.

Furthermore, until now anti-aliasing effect wasn’t used in the cockpit. It’s fixed!

Developer update 2

Lire la version française de cet article.

We are exhausted by this eventful past week. It is time to write about it!

MkI public release

This week has been one of the most important since the begining of BOMB’s development; we have uploaded the final apha MkI version of the game on Desura (after a struggle with the releasing software).

This early access version is available now.


This version features:

  • The first 6 missions of the adventure mode
  • Skirmish mode (Player vs. AI enemies)
  • Dogfight multi-player game mode
  • Team Dogfight multi-player game mode

If you buy the game on Desura, you will be able to get it on Steam  once it is available on it. If we want this to happen, we need to get a certain amount of votes on Greenlight.


By the way, let’s talk about Greenlight! This system is shit. Yes, it’s real shit! We love Valve at La Moustache but Greenlight is really clumsy.

To be precise, it is the selection system that is dubious. Nobody really knows how it works, but based on my own understanding, it is based on the project’s statistics analysis to get its position on the “Top”. There is the Top 10, Top 50, and so on…

The analysis algorithm is very weirdly designed.

E.g. currently BOMB has  6400 “Yes”, after a little more than a year on Greenlight. But we have only 80% of the Top 100 votes.

What I’ve understood from others who’ve spoken about their projects, a game that has, let’s say,  50 “Yes”votes in a week will be in the Top 50, putting it way ahead ours.

Briefly, it seems like the position in the Top is determined by this formula: number of “Yes” votes / number of days of presence.

It is really unfair, because a game that is not validated in the following months, even weeks of a project announcement, has virtually no chance to be accepted on Steam.

Our only way to appear in the Top 100 now would be to get more than 1000  “Yes” votes in a few days.

As the Greenlight user interface doesn’t allow you to sort projects by popularity or by number of votes, but only by chronological order, the only way to get them is to obtain a lot of popularity in a short time window.

Press contact

We are currently trying to get us talked about in the specialized press. A big part of the week has consisted in emailing the different websites.

None of us is really a “pro” of this PR domain, so in order to get the journalists try and talk about our game, we send everyone a gift key with a pitch.

It is already starting to pay off with this fresh article from RockPaperShotgun.

MkII progress

MkI being released, we are now focusing on MkII development, put aside the time spent on the above duty.

The second cockpit of the game has improved greatly, I’m texturing and adding details on it. I’ve had a great time implementing a collimator, reminding me high school optical courses.

Since this cockpit – a real figher one – is present ingame, I enjoy doing quick dogfights in internal view with the Track-IR, even if the fluorescent tubes  in our premises force me to adopt a very uncomfortable posture to avoid it to behave crazy.

BOMB 2014-02-21 14-12-00-90BOMB 2014-02-21 14-41-00-01

Thanks for reading and see you next week!

Developer update 1

Lire la version française de cet article.

As the Mark I is about to be release, we think it’s time to speak about the game development and future releases, especially about cockpits.

This is the first truly technical post about a game element, everything may not be totally clear. We’ll do our best to write about future improvements and content updates. We are selling an early access game so it’s the least we can do.

In the Mark I version, only Marcel Gaston’s plane, the “Rorqual” has a cockpit, here the image:


As we can see, several 3D gauges are present. When I first created the cockpit system I told myself: “come on, it is an arcade game, every plane cockpits will have the same gauges, it will be simpler that way.”

Except today I’m doing another cockpit, for another plane and I don’t want to use the same ones.

Here is the first cockpit system as it were initially designed:

  • On-board instruments are modeled in a 3D modeling tool.
  • The same goes for the rest of the cockpit.
  • Instruments are positioned in the cockpit, also in the 3D modeling tool.
  • An export script generates a .gauge file containing the list of the instruments and their positions.

Here is what the .gauge file looked like then:


Let’s take as an example the following line :

RPM 1 [0.366772,0.0351799,4.15318]

This means that a rev counter (RPM) is going to be positioned at the coordinates between brackets. The number following the instument name, here “1”, means that the rev counter is for the engine “1”.

This system is quite alright but has already a limitation: if I’m doing another cockpit with an instrument oriented different way, I can’t: orientation is not included in the .gauge file.

So I’ve modified the export script in order to include orientation as a quaternion:


The example above is not very convincing because none of the cockpit instruments are oriented. But it could position any instrument, anywhere, with any orientation.

By the way, if we don’t want to use the same instruments for every cockpits, how can we do that? Having different cockpits is a thing, but if they all look alike, it’s not so interesting anymore.

Here’s come the most important modification I’ve had to do. Initially, every instrument was coded in C++, with its own class. For example, here’s the altimeter class:


C++ is great, but in order to add a new instrument type, or just use an instrument with another look, I need either to add a new class, or expose a whole lot of parameter from an existing one.

A typical case is the throttle: on some aircrafts it rotates around an axis, on others it slides. How to do it? Add a parameter to know the kind of throttle? Do the same for its travel? Add parameters like crazy in order to get a generic but horribly long and complicated C++ code? And what about the modding?

Another example: the first aircraft’s instruments has instruments with international units, i.e. meters. If I want to make a new cockpit with instrument labeled in foot, I’m doomed.

Definitly, it is not the right solution

Out in-house game engine features lua scripting. We have not developed a lot of things in lua, favoring the C++ so far. Let’s use lua scripts to code instrument! If anyone would want to add a cockpit in the game, he could do anything he wants.

So here’s a .gauge file line now:

defaultAltitude 0 [-0.013462,-0.05001,4.15774] [0.0,0.0,0.0,1.0]

defaultAltitude means that the instrument behavior is defined in the defaultAltitude.lua script file.

Which looks like :


The code is almost the same,  but the possibilities are totally different. Thus for every new cockpit being made, it is much simpler to add a specific instrument, in its behavior or look.

For future modders, it is a big feature, they will not be constrained by a fixed instrument list from the developers (us).

In order to conclude this post, here’s a new cockpit render (wip). As you can see, the instruments are the same than on the “Rorqual” one, but you can imagine that everything I just mentioned has not been for nothing !;)