DevBlog Janvier 2021

Comme beaucoup d’entre vous le savent, et suite √† un premier √©chec avec un d√©veloppeur, je reprend mon projet de jeu vid√©o depuis la premi√®re moiti√© de 2020.

J’ai d√Ľ reprendre seul et √† partir de z√©ro, le d√©veloppement en plus du graphisme que je produisais d√©j√† auparavant.

Ce premier DevBlog vous donnera une premi√®re id√©e de l’avancement du jeu et des prochaines √©tapes du d√©veloppement.

J’ai s√©par√© les diff√©rentes phases en leurs donnant des noms explicites afin d’en conna√ģtre le contenu principal

Phase 1 (v 0.1) : Base build

C’est dans cette premi√®re version (que j’ai refaite 3 fois en passant) que j’ai d√©fini les “bases” du jeu. Comment faire l’isom√©trie sur Construct ? Comment implanter mes sprites et donner d√©limiter les collisions ? Est ce que le rendu de la premi√®re version des √©l√©ments d’environnement est bonne ? Est ce que le format/r√©solution est bon ? Est ce que le moteur de jeu pourra me permettre de faire tout ce que j’ai besoin dans KarotWar ? Etc…

Cette phase est aujourd’hui termin√©e. Des choses que je n’ai pas pu perfectionner ont √©t√© report√©es √† la phase 4.

Phase 2 (v 0.2) : Defender build

La version dans laquelle je suis actuellement en train de travailler m√™me si j’arrive vers la fin. Ce build a pour but d’implanter les vagues d’ennemis, les armes et les tirs ainsi que les tours de d√©fense.

Phase 3 (v 0.3) : Crafting build

La version √† venir permettra, entre autres, √† interagir avec les PNJ pour les crafts des armes et tours, les am√©liorations de celles-ci, les ventes, la gestion d’inventaire, etc‚Ķ

Phase 4 (v 0.4) : Confort build

Tout ce qui n’a pas √©t√© tout a fait fini dans les 3 pr√©c√©dents build sera termin√© dans celui-ci. Pourquoi je proc√©de ainsi ? Premi√®rement, plus je pratique de choses diff√©rentes sur le moteur de jeu, plus j’apprends les fonctionnalit√©s et la logique du logiciel. Je vais donc plus vite aujourd’hui sur des points qui me bloquaient au tout d√©but. Deuxi√®mement, je n’ai pas envie de me d√©go√Ľter : rester bloqu√© sur un probl√®me de code pendant 1 semaine peut tr√®s vite √™tre d√©moralisant. Et enfin en troisi√®me partie, j’ai des nouvelles id√©es tous les jours que je note sur mon t√©l√©phone et/ou un carnet qui pourraient s’int√©grer facilement dans le logiciel et rendre le jeu plus dynamique et sympathique √† jouer.

> Lancement de l’alpha priv√©e

Phase 5 (v 0.5) : Expansion build

Apr√®s avoir fini tous les syst√®mes et la premi√®re parcelle, il faut ajouter du contenu et d’autres parcelles. C’est dans cette phase que je compl√©terai le jeu avec diff√©rentes parcelles d√©blocables, la totalit√© des armes, des tours, la musique, etc…

Cette phase permettra aussi de corriger les bugs reportés par les testeurs de la version alpha privé.

> Lancement de l’alpha public

Phase 6 (v 0.6) : Correction build

Ici, je corrigerai la quasi totalit√© des bugs d√©tect√©s lors de l’alpha public.

> Lancement du jeu

Dans la seconde partie, je vais vous expliquer la plupart des features d√©j√† mises en place, les probl√®mes que j’ai rencontr√©, etc‚Ķ Cela vous donnera de mani√®re assez pr√©cise l’avanc√©e de KarotWar.

Dans tous les cas, je tenais √† vous remercier tous pour votre soutien aussi bien sur les r√©seaux que sur mes lives. Sans vous l’aventure aurait moins de saveur !


Petit disclamer avant de commencer √† lire la suite : je ne suis pas un professionnel du d√©veloppement, ni un professionnel du graphisme. Ce que je raconte ci-dessous est l’exp√©rience que j’ai v√©cu pendant ses deux ann√©es de cr√©ations en pixel art et plus r√©cemment dans le d√©veloppement.

Dans la version 0.1, il a fallu s’assurer que la plupart des syst√®mes indispensables √† KarotWar pouvaient √™tre g√©n√©r√© par le moteur de d√©veloppement Construct 3. N’ayant aucune notion en code, le logiciel permet de “coder” via des conditions et actions logiques. Par exemple : je mets en condition “appuyer sur la touche Z du clavier” et en r√©action “le sprite du personnage se d√©place verticalement vers le haut”. Avec un peu de pratique, de logique et √† l’aide de tuto et ressources, on peut se d√©brouiller dessus.

Les premiers essais ont donc été :

L’isometrie : KarotWar est graphiquement cr√©√© en isom√©trique. Pour faire simple, cela permet d’avoir une 3D avec une fausse perspective. En pratique en pixel art, l’angle de la perspective est de “2 carr√©s horizontaux pour 1 carr√© vertical”. Contrairement donc √† la 2D classique que l’on voit dans la plupart des jeux de plateforme ind√©, cela demande 1 √† 2 vues suppl√©mentaires comme montr√© dans l’exemple ci-contre. L’isom√©trie est aussi plus capricieuse avec les courbes qui sont beaucoup compliqu√©es √† appr√©hender que dans des axes orthogonaux. Par contre au niveau du rendu global, je trouve l’isom√©trie d’une beaut√© assez peu exploit√©e dans la cr√©ation des jeux aujourd’hui.

Le mouvement : L’autre revers de l’isom√©trique‚Ķ Les plateformers classiques ont un mouvement droite-gauche : on peut donc dire que c’est une animation sprite en miroir. Les jeux vu par dessus peuvent avoir jusqu’√† 8 directions, et √ßa sera une animation de sprite avec une direction diff√©rentes. Le vue isom√©trique oblige √† avoir des 5 animations de sprites diff√©rentes : une de face, de dos, une droite gauche, une diagonale droite gauche et enfin une diagonale haut bas. Il faut aussi prendre en compte que la diagonale est pour l’isom√©trique la “v√©ritable” direction principale.¬†

Les angles : Les angles isom√©triques ne sont pas de 45¬į mais bien de 30¬į et 60¬į. La premi√®re fois ton cerveau bug compl√©tement. Donc quand tu cr√©es ton angle pour le mouvement de ton personnage, tu ne peux pas utiliser le logiciel de fa√ßon classique, mais tu dois adapter le mouvement iso. √áa donne ce cercle de mouvement un peu barbare.

Les tuiles (ou tiles) : Et oui encore plus difficile avec l’iso. Pour Construct, la solution que j’ai trouv√© c’est de cr√©er 2 calques en faisant une sorte de damier pour chacun d’entre eux. La raison est simple, c’est que le logiciel comprend des tuiles rectangulaire. Donc quand tu places sur la tuile d’√† c√īt√©, il efface les zones de chaque coin. Pour ceux qui se souviennent de mes marathons “tuiles d’herbes” interminables !

Les sc√®nes (ou layout) : quand vous changez de zone dans un jeu, le code ne consiste pas √† effacer tous les sprites de la premi√®re sc√®ne et faire appara√ģtre les sprites de la sc√®ne suivante. L’id√©e est simplement de cr√©er plusieurs zones (par exemple pour moi ce sont les int√©rieurs des b√Ętiments) dont le logiciel basculera suivant les diff√©rentes conditions que je lui donnerait. Au d√©but je croyais qu’une sc√®ne √©tait li√© √† une feuille de code, finalement le logiciel permet de lier toutes les sc√®nes a la m√™me feuille.

¬†La direction artistique : j’ai toujours voulu faire un peu de que je voulais sans avoir d’accroche, de r√©f√©rence, ou d’exemple. Un ami m’a quand m√™me conseill√© avant de me lancer de faire un r√©pertoire de r√©f√©rence et de d√©finir pourquoi et comment je souhaitai cr√©er mon univers. Je me suis donc bas√© sur la r√©volution industrielle, les usines de briques normandes, un poil de steampunk et des grosses r√©f√©rences dans le genre isom√©trique comme Dofus. Aujourd’hui je suis vraiment heureux du petit univers tout en couleur que j’ai cr√©√© !

L’environnement : apr√®s la direction artistique, il fallait que je place les sprites d’environnement dans le logiciel pour voir un peu la t√™te que √ßa avait. Petite astuce sur Construct : placer des √©l√©ments sur des tuiles plut√īt que dans des sprites permet une meilleure optimisation de performance du jeu.

L’UI (User Interface) : comme la plupart des jeux aujourd’hui, le joueur dispose d’une interface fixe sur son √©cran permettant de lui donner des informations comme sa vie, son mana, sa position, etc‚Ķ Dans Construct, l’id√©e est de d√©dier un layer √† l’UI en le fixant √† l’√©cran et en lui indiquant que le calque est global (√ßa veut dire qu’il se r√©p√©tera a chaque sc√®ne). Dur √† comprendre mais une fois saisi, assez intuitif.


Une fois cette partie finie, je savais que KarotWar √©tait quasi faisable. J’avais encore un l√©ger doute vis √† vis des vagues de monstres, c’est pour cela que j’ai mit en second temps, la version attrait au combat.

La version v0.2 j’ai donc pu tester ces vagues d’ennemis, ces armes et ces tourelles pour √™tre vraiment s√Ľr que c’√©tait faisable. La r√©ponse est oui. J’arrive tout doucement √† la fin de cette version, car j’ai pu tester basiquement tous les fonctionnalit√©s que j’ai souhait√© mettre dans KarotWar.

Spawn : l’apparition des ennemis doit se faire de fa√ßon semi al√©atoire. Il me reste encore un petit peu de travail sur cette partie pour indiquer au logiciel que je veux que les points d’apparition se fasse de fa√ßon al√©atoire dans une zone pr√©d√©fini (pour pas que les ennemis Spawn trop pres de la base par exemple)

Le pathfinfing : les ennemis qui apparaissent doivent pouvoir se diriger entre les b√Ętiments, l’environnement ou les tourelles. Ils doivent aussi avoir l’intelligence d’attaquer le joueur quand il s’approche trop pr√™t et de repartir sur leurs routes vers la carotte sacr√©e lorsque le joueur est trop loin. Le logiciel aide beaucoup a √ßa. Il faut d√©finir un point d’arriv√©e (ici la carotte sacr√©e) et dire √† l’ennemi de checker toutes les X secondes son environnement pour ajuster son itin√©raire. Il faut aussi donner des valeurs a l’itin√©raire : par exemple, le lapin se retrouve devant un mur patate, il a le choix entre le contourner ou le d√©truire et suivant le coup de la destruction ou le contournement par une br√®che, un calcul se fait et permettra de lancer la bonne action pour l’ennemi.

Le tir : Le personnage contr√īl√© par le joueur doit pouvoir tirer sur les ennemis pour pouvoir les √©liminer. En ce moment m√™me, je teste diff√©rents effets d’armes (comme le laser avec des d√©g√Ęts sur la dur√©e, le d√©g√Ęts en cone du fusil a pompe, etc‚Ķ).