Developer update 3

Lire la version française de cet article.

Desura

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.

Greenlight

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:

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.

Anti-aliasing

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:

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

Developer update 3 (fr)

Read the English version of this post.

Desura

A l’heure où j’écris ces lignes, nous avons vendu 100 jeux sur Desura, ce qui est plutôt bien compte tenu du fait que Desura est une plateforme relativement petite et que le jeu est encore en alpha.

Greenlight

Nous avons maintenant plus de 6666(!) votes oui sur Greenlight, merci à tous pour votre soutien. En une semaine nous avons fait plus de votes que durant le mois précédent, et ce, entre autres, grâce aux différents articles parus sur divers sites (dont notre deuxième mention sur RPS!).

Nous ne comprenons toujours rien au processus de calcul, surtout à un des indicateurs: les courbes permettant de se situer par rapport aux autres jeux soumis sur Greenlight. En effet, celles-ci changent continuellement, et ce plusieurs fois par jour.
Par exemple hier, voila les différentes évolutions:

Variation des statistiques le 27 février 2014

On peut voir sur les deux premières captures que nous sommes au dessus de la courbe du Top 100, cependant l’indicateur de pourcentage donne toujours : 83% du chemin pour arriver dans le Top 100.

Si quelqu’un à une idée pour expliquer tout ça, nous sommes preneurs.

Premier patch

Suite à la sortie du jeu, un certain nombre de problèmes ont été rencontrés par les premiers joueurs. Nous avons fait notre maximum pour les corriger le plus rapidement possible et un patch est dors et déjà en attente de validation par l’équipe de Desura.

Ce patch corrigera les problèmes suivants:

Résolution de crashs

Certaines des missions du jeu pouvaient crasher suite à une succession d’évènements particuliers. Ceci était du à un changement majeur dans le système de script (lié au travail sur les cockpits), et tous ces crashs devraient être corrigés par le patch. Le conditionnel n’est pas très rassurant je sais, mais mon expérience m’a appris que même en testant à fond un jeu, on ne pouvait jamais être sur que tous les bugs soient corrigés.

Amélioration des sons

Il y avait (et j’espère qu’il n’y est plus) un bug de son assez gênant qui, aléatoirement, faisait que les sons moteurs semblaient “étouffés”. Ceci semble être un problème d’OpenAL, même si je n’en suis pas totalement sûr, et un “hack” a été fait pour le contourner.

De plus, le mixage des sons en vue cockpit a été légèrement amélioré.

Au passage, OpenAL a été le pire choix technique que j’ai pu faire sur ce projet, surtout maintenant que Creative semble ne plus le supporter. Nous avons du passer à OpenAL Soft, un “fork” d’OpenAL en cours de production, heureusement sans trop de bobos.

Antialiasing

Il n’y a pas eu grand chose de notable cette semaine côté technique, mise à part l’amélioration de l’antialiasing. Suite à une erreur de manipulation, l’antialiasing qui était présent sous le nom de FXAA ne pointait pas le bon shader. J’ai donc corrigé le problème, et la méthode qui était présente a été renommée SSAA (pour Screen Space Anti Aliasing).

Le FXAA est plus gourmand en ressources que le SSAA, mais offre une bien meilleure qualité visuelle, petit comparatif:

Pas d’AA à gauche, SSAA au centre, FXAA à droite.

De plus, jusqu’à maintenant l’antialiasing n’avait aucun effet sur le cockpit. C’est corrigé!

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 😉