3D view

http://upload.wikimedia.org/wikipedia/commons/3/39/Etna_3D_version1.gif reprend tout juste le genre de "survol autour d'un point d'intérêt" qui me semblerait coller pour le jeu.

Tune 1 in progress

Jack Boost - Tune 1 (ZigZag in Alien flight) by Cyborg Jeff

Voici un état d'avance de la bande son du jeu intitulée "Zig Zag in Alien Flight"... le style oldschool à la sauce Amiga et une mélodie un peu chip me plait assez bien... Je vais encore broder autour de cela, mieux proportionner le timing de la zik... Mais moi j'aime là cela va :)

Whoaa! What's *that* ?

Il nous faut un boss pour le niveau 1. Et puisque les aliens ne sont pas venus envahir (militairement parlant) mais moissonner (ou quelque-chose d'approchant), il n'est pas possible de débarquer avec un méga-laser ou des tentacules ...

D'où l'idée du superviseur de chantier, qui vient voir pourquoi les travaux n'avancent pas comme prévu au-dessus du canyon 51. Il va tenter de scanner le vaisseau de Jack, et s'il parvient à la conclusion (au bout de 3 scans) que ce n'est pas un alien qui est aux commandes... Eh bien disons que là, ça risquerait de vraiment tourner mal.

Avec un vaisseau comme celui de Jack, on pourrait penser qu'il peut s'en sortir sans problème, surtout qu'il faudrait que le superviseur parvienne à s'aligner. Le hic, c'est que le rayon-scanner a aussi un fort effet gravifique, genre "rayon tracteur" ou "aimant laser" (comme disait l'autre). Seul un overdrive des propulseurs (obtenu en faisant haut-bas-haut-bas-haut-...) par exemple pourra l'en dégager.

L'autre hic, c'est ce chapelet de sphères aliens qui semblent graviter autour du superviseur. Pas résistantes, mais vu la vitesse à laquelle elles se déplacent, il va y avoir du sport.

Bien sûr, la "coquille" est trop résistante pour l'armement du Tétrapod, et il faudra viser le "coeur" qui apparaît lorsque le boss sort ses appendices d'analyse.

ships upgrade!

version revue et corrigée des vaisseaux, avec une petite animation possible pour le paratrooper.

How does it sounds ?

Il est clair que je suis très enthousiaste à l'idée de travailler à la B.O. de ce project de Shoot'm up. Comme vous l'aurez compris, avec mon frangin Pype, nous avions par le passé déjà mis en place différents projets autour de ce thème, mettant en scène Jack Boost et le Poly Cosmos. Simon lui aussi m'a connu à mes débuts muscaux,... et j'avais déjà à l'époque écrit quelques titres dans le genre.

Après quelques semaines à avoir vu grandir le projet ici, j'ai maintenant une meilleure idée de ce que je voudrais... quelques qui mélangera des petits sons Chips (C'est un peu pour cela que l'on m'a choisi) et un style Rave comme dans la B.O. de Project X (Team 17).... le tout mixé dans une qualité supérieur aux MOD 4 pistes de l'Amiga tout de même !!

Voici déjà un petit essai, une base tout du moins qui pourrait coller au Canyon...

 (if you can't hear it, may be, should you follow me on SoundCloud.)

Jack Boost - Tune 1 by Cyborg Jeff

[post update]

Première tentative en pixels. remis à jour avec 3 couleurs alternatives pour les essais multi-joueur.

The physic engine adventure

[This is just a tech crazy talk between myself and everyone wondering why I didn't post progress on the game since a few days]

Hello everyone,

Since a few day I had a great but sad idea in mind. Why should I use my home brew collision engine while there is plenty very good one out there. Using one of them would save me plenty time relying on a good, working, performent, tested engine :D

Well, so I took my litle keyboard, wear my geek mode on, and start learning, coding, failling, learning again to code again and fail again.

So what's the result.... hem well. I tried multiple engines, and the problem is: they don't do what I want. I want a per pixel collision detection, most engine works with boxing items in shaped (what my engine does with rectangle shape as first step too). But then converting a pixel art into a shape is hell, not safe and time consuming.

Most simple games (ie: angry birds) don't care about this convertion hell has they have sprites that basically doesn't mutate a lot (not shape change). But in our game, even the most simple alien can have a shape change (take the U-Interceptor for instance) on every tile of the sprite sheet.

The need of updating the shape become huge. Even if it's still possible to compute all possibles shapes since the begining, every engine I tried just burn and explode as soon as we start updating the world object shape.

Some workarounds may be found, like switching between a collection of world object for one single game actor, activating and desactivating them on the fly, as well as synching there positions, rotations etc, but this would be time consuming.

Anyway...

This was just to makes things better, but it screw them a lot. So as far as I see it, until I have time to look more deeper into real working physics engine, I guess my home brew collision detection will do the trick.

Of course I can still optimize it a bit, using test points for bullets, changing the order of per pixel check according to some rules etc, or even implement a shape - intersection algo and make my own shape-collision engine.

But yhea, too much work for just this game, let's focus a bit more on funny stuffs first :D I miss a game test :D