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.

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.

Thanks for reading and see you next week!

Developer update 2 (fr)

Read the english version of this post.

C’est vendredi! Nous sommes épuisés par cette semaine riche en émotions, mais c’est l’heure d’écrire le journal de bord !

Mise en ligne de la MkI

Cette semaine a été l’une des plus importante depuis le début du développement parce que l’on a uploadé sur Desura, après avoir pas mal bataillé contre le logiciel de mise en ligne, la version finale de l’alpha MkI.

Cette version d’accès anticipé est actuellement disponible en précommande et sera débloquée lundi 24 février.

Au menu de cette version, les 6 premières missions du scénario, le mode Escarmouche ainsi les modes de jeux multijoueurs “Dogfight” et “Team Dogfight”.

Notez que si vous achetez le jeu sur Desura, vous pourrez activer votre clef sur Steam une fois le jeu sorti sur cette plateforme . Mais pour que cela arrive un jour, il faut qu’on obtienne un certain nombre de votes sur Greenlight.

Au passage, je vais en parler tiens, de Greenlight. Ce système est pourri. Oui, pourri. Pourtant on adore Valve et Steam à la Moustache, mais Greenlight est vraiment quelque chose de mal fichu.

Pour être précis, c’est le mode de sélection qui est bancal. Personne ne sait vraiment comment il fonctionne, mais d’après ce que j’ai compris, il se base sur une analyse des statistiques du projet pour déterminer sa position dans un “Top”. Il y a le Top 10, le Top 50, etc..

Mais l’algorithme d’analyse est pensé très bizarrement.

Par exemple actuellement nous avons 6400 votes “oui” sur notre jeu, en un peu plus d’un an de présence sur Greenlight. Mais nous ne sommes qu’a 80% des votes du Top 100.

D’après ce que j’ai pu comprendre grâce à d’autres personnes parlant de leur projet, un jeu qui aurait disons, 50 votes “oui “en 1 semaine de présence serait lui dans le Top 50, donc plus prioritaire que le notre.

En gros le calcul de la position dans le top se fait selon la formule : nombre de votes “oui” / nombre de jours.

C’est extrêmement injuste parce qu’un jeu qui n’est pas greenlighté dans les quelques mois, voir semaines, après sa publication n’a virtuellement plus aucune chance d’être un jour accepté sur Steam.

Notre seul moyen actuellement d’espèrer être dans le top 100 c’est de faire plus de 1000 votes “oui” en quelques jours.

Comme l’interface de Greenlight ne permet pas de trier les projets par popularité ou nombre de votes, mais seulement par ordre chronologique, le seul moyen de les obtenir est de faire parler de nous un maximum possible un un minimum de temps.

Contacts presse

Donc nous sommes actuellement en train d’essayer de faire parler de nous au travers de la presse spécialisée. Une grosse partie de la semaine a été consacrée à l’écriture de mails à différents sites.

Aucun de nous d’eux n’est habitué à faire du “commercial”, on ne sait absolument pas comment s’y prendre pour contacter et convaincre les journalistes d’essayer notre jeu. Donc on envoie des mails à un peu tout le monde avec une clef d’essai et un petit explicatif du jeu.

Et cela commence à payer, avec notamment cet article tout frais de chez RockPaperShotgun (en anglais).

Avancement de la MkII

La Mk I étant sur le pas de tir, nous concentrons désormais nos efforts de développement sur la Mk II, même si à cause des points précédents nous n’avons pu nous y consacrer à 100%.

Le second cockpit du jeu a bien avancé, je suis en train de le texturer et d’ajouter les détails. J’ai pris un certain plaisir à implémenter un collimateur, cela m’a rappelé mes cours d’optique au lycée.

Depuis que ce cockpit – un vrai cockpit de chasseur – est dans le jeu, je m’amuse à faire des dogfights rapides en vue interne et avec le TrackIR, même si la présence de néons dans nos locaux m’oblige à prendre une position très inconfortable pour éviter que le TrackIR ne devienne fou.

Merci de votre lecture et à la semaine prochaine !

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 !

Developer update 1 (fr)

Read the english version of this post.

Alors que la Mark I est sur le point de sortir, il est temps de parler de la suite du développement du jeu et les prochaines releases, et plus particulièrement des cockpits.

Ceci est mon premier vrai post technique et explicatif sur un élément du jeu, tout n’est peut être pas très clair. Nous allons vraiment essayer de faire de temps en temps un article sur les futures améliorations et ajouts de contenus. Comme nous vendons un jeu en accès anticipé, je pense qu’il est important que les acheteurs sachent ce qui va arriver ensuite.

Dans la Mark I, seul l’avion de Marcel Gaston, le “Rorqual” dispose d’un cockpit, ici en image:

Comme on peut le voir, il y a plusieurs instruments de modélisés, et lorsque j’ai conçu le système de cockpit initialement je me suis dit: “allez, c’est un jeu arcade, tous les cockpits des différents avions utiliseront les mêmes instruments, ça sera plus simple.”

Sauf qu’aujourd’hui je suis en train de faire un autre cockpit, pour un autre avion. Et je n’ai pas envie d’utiliser les mêmes instruments.

Pour expliquer un peu le système de cockpits comme il était initialement, cela se passait en plusieurs étapes.

Les instruments sont modélisés dans un logiciel de 3D
Idem pour le reste du cockpit
Les instruments sont placés dans le cockpit, toujours dans le logiciel de 3D.
Un script d’export permet de générer un fichier .gauge qui contient la liste des instruments et leur position.

Le fichier .gauge ressemblait alors à ceci:

Prenons comme exemple la ligne :

RPM 1 [0.366772,0.0351799,4.15318]

Cela signifie que l’on va placer dans le cockpit un compte tour (RPM) à la position spécifiée entre les crochets. Le numéro après le type d’instrument, ici “1”, signifie que le compte tour concerne le moteur “1”.

Tout ceci c’est pas mal, mais déjà une limitation apparaît: si je fais un nouveau cockpit et que je veux placer un instrument, mais orienté d’une certaine manière dans le cockpit, je ne peux pas: l’orientation n’est pas incluse dans le fichier .gauge.

J’ai donc modifié le script d’export pour inclure l’orientation sous la forme d’un quaternion.

L’exemple n’est pas très probant, vu que pour ce cockpit aucun instrument n’est orienté. Mais cela permet à terme de placer vraiment n’importe quel instrument, n’importe où, et orienté n’importe comment.

Mais au fait, et si on ne veut pas utiliser les mêmes instruments pour tous les cockpits, comment on fait? C’est bien beau d’avoir des cockpits, mais si ils se ressemblent tous, c’est tout de même moins intéressant.

C’est là qu’intervient la plus grosse modification que j’ai du faire. Initialement, chaque instrument était codé en C++, avec sa petite classe à lui. Par exemple, la classe pour l’altimètre:

C’est super le C++ mais cela veut dire que si je veux rajouter un type d’instrument ou juste utiliser un instrument avec un look particulier, je dois soit rajouter une classe ou alors exposer tout plein de paramètres sur une classe existante.

Un cas typique est la manette des gaz: sur certains avions elle tourne autour d’un axe, et sur d’autres elle peut coulisser. Comment faire? Ajouter un paramètre pour savoir si c’est une manette tournante ou coulissante? Et pour la course, on fait pareil? Rajouter des paramètres dans tous les sens, avoir un code c++ générique mais horriblement long et compliqué ? Et le modding ? Comment ça se passe pour le modding ?

Autre exemple: l’avion de Marcel Gaston a des instruments en unités internationales classiques, c’est à dire en mètres. Si jamais je veux faire un nouveau cockpit avec des instruments en pieds, je suis foutu.

Définitivement, cela n’est pas la bonne solution.

Notre moteur maison offre l’avantage de pouvoir scripter en lua. Nous n’avons jusqu’à maintenant pas développé énormément de choses en lua, privilégiant le c++. Utilisons le script pour coder les instruments ! Comme ça si un jour quelqu’un rajoute un cockpit dans le jeu, il pourra faire virtuellement tout ce qu’il veut.

En gros dorénavant une ligne du fichier .gauge exporté se présente de la sorte:

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

defaultAltitude signifie que l’instrument utilise le fichier de script defaultAltitude.lua pour définir son comportement.

Lequel fichier ressemble à ça:

Le code est sensiblement le même, mais les possibilités totalement différentes. Ainsi, pour chaque nouveau cockpit réalisé, il sera beaucoup plus simple de rajouter un instrument spécifique ou ayant juste un look différent.

Pour les éventuels futurs moddeurs, c’est un énorme plus, cela permet de ne pas être contraint par la liste des instruments que les développeurs ( nous ) ont fixé.

Pour conclure cet article, voici un rendu du nouveau cockpit en WIP. Vous remarquerez que les instruments sont pour le moment les mêmes que sur le “Rorqual”, mais vous vous doutez bien que tout ce dont je viens de parler n’a pas été fait pour rien 😉

Well, what are we waiting for?

First things first: Happy new year !

Our page on IndieDB says the game has been released a few days ago. But in fact, it hasn’t.

This is outrageous!

What the hell are the developers doing ?!

Maybe they have a monstrous hangover after the new year’s eve?

No !

We are currently talking with the guys behind Desura to manage the release of the game. The Mark I version of the game is almost completed (just a few details to fix, such as finalizing the English translation) and it should be available in the next days.

We are also working hard on the launch Trailer, which has the highest priority on our TO-DO List.

New rain effect

Far better than the previous one !

Some news and the boxshot

As people may have seen on the Steam Greenlight page, we are planning to release BOMB into several updates, called Mark X, which are:

Mark 1
– Act I of the adventure (6 missions)
– Skirmish single player game mode
– Death Match and Team Death Match multi player game modes
– 4 playable planes
– 2 environments

Mark 2
– Act II of the adventure (5 missions)
– Race multi player game mode
– 3 additional playable planes
– 1 additional environment

Mark 3
– Act III of the adventure (5 missions)
– Capture the flag multi player game mode
– 2 additional playable planes
– 1 additional environment

Mark 4
– Linux version (native build)
– Mac version (native build)
– Dedicated server

Mark 5
– Modding Tools
– Documentation
– Samples

Right now, we’re polishing the Mark I version of the game, and we started the submission process on Desura.

To reward you for reading this looooong post here is the awesome boxshot of BOMB.