Al'Blog

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 ).

Dans les deux précédents posts, je commence avec un petit système, puis j'y retouche. C'est une processus itératif: je préfère concevoir le minimum, proprement, puis rajouter par étape. Ce n'est pas toujours possible, quand les éléments sont très interconnectés, mais c'est une façon propre de travailler.

Du fait, nous pouvons rajouter les particules de cette façon. En fait j'avais rajouté les particules avant de retravailler le système de rendu. Je vais commencer aujourd'hui à en parler, parce que c'est un peu long. Et je vais me concentrer sur la méthode.

Tout d'abord, quel est mon besoin? Un simple système, extensible, donc avec:

- particules, des éléments qui conservent de simples paramètres comme vitesse, position, énergie, couleur

- émetteurs, qui crée les particules avec des paramètres initiaux (ils les créent et les "lancent"),

- un système de particules, qui englobe tout ca,

Et en réserve, pour plus tard:

- des modifieurs, des zones (a priori) qui modifient certains paramètres des particules, appliquent des forces, changent la couleur...

- des réflecteurs, qui stoppent et reflètent les particules.

Mais pour l'instant j'ai trois classes: Particle (une particule), Emitter (un émetteur), Particles (un système de particules). Et cela s'utilise ainsi:

Donc le RenderingManager doit être mis-à-jour aussi, nous verrons que c'est très simple. On commence par créer un émetteur avec ses paramètres (et il en manque ! ), puis un système de particules. Les particules sont définies par les paramètre de l'émetteur, c'est tout.

Mais ce que je veux montrer, pour le moment, c'est le début de Particles:

Non ce n'est pas modifié, il y a bien deux classes internes vides. Et les classes Particle et Emitter étaient internes aussi. J'ai fait ça parce que la classe Particles englobe les autres, donc réfère beaucoup à celles-ci (je crée des particules en fonction des paramètres des émetteurs, je modifie sur cette zone, je reflète ici... ). Pour travailler, j'ai commencé ainsi, puis j'utilise le Refactor d'Eclipse pour convertir un type membre au niveau le plus haut (c'est-à-dire indépendant).

Quand je travaillerais sur les modifieurs et les réflecteurs, je commencerais en interne, avec toutes les intéractions qui m'obligeraient à naviguer d'une classe à une autre, pour finalement remonter la classe quand le principal est là.