Al'Blog

 Vous pouvez essayer la démo pendant 30 jours (la version indie complète), qui est compatible avec tout bon soft de 3D (et 2D bien sûr), comme ce satané Blender. Rassurez-vous, l'interface d'Unity n'est pas la même que dans Blender !

Si vous aimez, mais ne voulez pas passer 149€ dans Unity, vous avez deux solutions au moins pour faire des jeux avec un minimum de code : utiliser Neo Axis Engine ou des outils de moddings (mais pas de commercialisation alors). Eventuellement Blender.

Un tutoriel assez spécial pour mon retour. Je parlerais aujourd'hui d'une méthode de programmation, et de quelque chose de plutôt méconnu

Plus jeune, quand je programmais, j'essayais de faire du code super propre, qui marche tout le temps. En cas de bug, blocage ou problème. Donc tests très rigoureux et corrections.

Seulement, ce n'est pas toujours possible de tester suffisamment, et c'est presque impossible, surtout sur des projets conséquents, de corriger tout. J'ai donc évolué pour adopter une autre approche : un code "idiot-proof", c'est-à-dire qui ne va pas "exploser" s'il y a un problème.

À éviter : les blocages (boucles infinies, threads interlockés), les leaks trop importants (création d'objet dans boucle, pointeurs perdus/mal détruits (C/C++), référence statiques non nettoyées ou inter-références (que le garbage collector n'aime pas du tout en Java), écriture sur adresse mémoire non initialisé, utilisation d'une fonction membre d'un objet non créé...

L'idée est d'avoir d'une part un code qui va reprendre la main dans la plupart des cas de bug non-bloquants (comme l'utilisation d'un objet non-initialisé), et d'écrire une partie du code de facon à éviter certains cas. Par exemple, j'ai utilisé une API qui décodait des chaines de caractères avec quelque chose comme ça:

Inconvénient, s'il existe un caractère autre que celui désiré (comme une fin de chaine), ca boucle à l'infini. En l'occurrence sur une création d'objet, donc crash sévère après un temps. Croyez le ou non, ce bug était tellement simple qu'il m'a fallu plus de 2 mois pour le trouver. Sortir le iIndex++ de la boucle permet déjà de faire mieux: ca risque simplement de lever une exception, lorsqu'on lira en dehors de la chaine.

Mais idéalement, il faut prévoir la fin de chaine, et tous cas inattendu. Je rajoute une gestion assez large des exceptions (pour exemple et par flemme, il vaudrait mieux mettre des exceptions concernant les éventuels problèmes du bloc, mais ça ne gène pas ici), car ce morceau de code n'est pas important par rapport au reste du programme et, donc, je ne veux pas qu'il plante mon programme en cas de problème :

C'est juste une facon de faire, pas forcément optimale, mais qui peut minimiser les problèmes ! Pour résumer le principe : "J'assume que je peux faire des bétises, donc j'écris mon code pour y résister" . L'idée est que les portions de codes bien écrites, mais idiot-proof, vont amortir les problèmes des portions buggées et, si possible, me donner des indications me permettant de corriger ces portions ! Bien sûr ça ne marche pas toujours, malheureusement.

Plein plein plein de lignes de code, mes tutoriels sont très en retards. Mais le jeu ressemble à quelque chose. Le système d'arme est sophistiqué, vous pouvez dessiner avec les torpilles et les missiles Et ça a un intérêt stratégique, pour les missiles pour le moment (sans doute pour les torpilles aussi plus tard) : quand une unité repère un missile, elle essaye de l'intercepter. Ces missiles sont spéciaux, et ne vont pas accrocher une unité, seulement des missiles, mais l'interception peut très bien se faire sur votre unité... Avec un chemin, vous diminuez les chances d'interception sur des unités alliés. Bien sûr ce sera aussi bien pratique si je fais une version multijoueur.

Il devrait bientôt y avoir une version de test en beta (c'est-à-dire correctement jouable), une page web plus complète alors (peut-être sur le forum pour le début, pour des changements fréquents), et sans doute aussi un appel à volontaires: IA, niveaux, systèmes de jeux (paysages statiques, autres armes et unités), gfx, réalisme/tuning, musique et sons. Mais pour l'instant je me débrouille bien tout seul Tant que je ne suis pas épuisé, ça va !!!

Pour jouer, c'est toujours ici.

Pulpcore offre un rendu beaucoup plus beau que Graphics2D, avec un antialisasing sur tout, une gestion simple de sprites et d'autres, surtout si vous réaliser un jeu "compatible" (c'est-à-dire se contentant des fonctionnalitées offertes, ce qui n'était pas mon cas), mais surtout une vitesse monstrueuse. Bon, pour mon jeu ca ne se voit pas trop, parce que la version actuelle est beaucoup plus complexe. Mais c'est bien largement plus rapide, en fait j'ai gardé mon moteur de jeu, juste changé le moteur de rendu (grace au "renderer" présenté dans un billet précédant, mais avec quelques autres modifications), et avec un jeu plus de 3 fois plus complexe, c'est encore plus rapide qu'en Java simple.

Pour voir une version récente (mais pas la dernière), avec encore des problèmes (version alpha), c'est ici (ce sera mis à jour au fur et à mesure).

Bon, la suite des tutoriaux manque... C'est parce que j'ai trop avancé le code, et pas assez les tutoriaux :O(

Mais pas mal de choses marchent, et c'est bien adapté à certains types de jeux (mon RTS tout d'abord ;O) ). Voici la version test actuelle, si vous cliquez sur Continuer à lire "Sub-engine et Sub-game ... »

Au programme, particules, unités "sprite" (mais Java ne fait pas l'anti-aliasing correctement alors), détecteurs "réalistes" (les unités sont vu quand les détecteurs les voient, ce sont les carrés qui apparaissent. Les unités alliées sont visibles sinon). Et les éléments peuvent être attachés les uns aux autres: la fumée qui sort de la cheminée des portes-avions (oui, oui, ce sont des portes avions) est générée par un émetteur de particules attaché au bateau. Les particules sont des sprites. Les détecteurs sont aussi attachés aux unités, sauf s'ils sont "globaux" (indépendants), comme le satellitte (qui balayent la carte rarement). Chaque détecteur garde sa propre liste d'unités trouvées. Les détecteurs actifs, tels radars et sonars, émettent des signaux qui peuvent être détectés et donc donner la position d'émission (mais les signaux ne sont pas encore détecté, mais très bientôt ).