Category: #GAM


7 Jours et plus si affinités…

May 10th, 2013 — 11:35am

Comme promis dans le post précédent, voici quelques détails sur le défi auquel j’ai participé durant le mois de mars. Le but était de créer un roguelike en 7 jours ou moins. Si vous voulez en savoir plus sur les roguelikes ou comment ceux-ci sont faits, l’excellent Roguebasin wiki (EN) est très recommandé. Mais en résumé, un roguelike est en quelque sorte un jeu de rôle avec le gameplay mis au centre de l’expérience. Traditionnellement, ils ont des graphismes ASCII et une longue liste de commandes, sont des jeux au tour par tour, et sont caractérisés par leur mort permanente (c’est-à-dire que, si votre personnage meurt, vous ne pouvez pas reprendre à partir d’un checkpoint mais devez recommencer depuis le tout début du jeu).

D’un point de vue personnel, j’ai toujours apprécié les roguelikes, et j’ai décidé que cette année serait un bon moment pour m’y essayer. Avoir des délais tend à me rendre plus productif, donc c’est tout à fait naturellement que j’ai entamé le défi 7DRL.

L’idée

Depuis toujours, j’ai été un grand fan du livre et du film Battle Royale. Logiquement, je me suis demandé de temps en temps comment je pourrais adapter l' »expérience Battle Royale » dans un jeu auquel je jouerais. Un jeu en vision subjective a d’abord été l’idée principale mais même sans songer à tous les assets nécessaire et la complexité de la programmation, le nombre énorme de paramètres nécessaires pour vraiment recréer un Battle Royale intéressant et fidèle aurait été bien trop important.

Entrent alors en jeu les roguelikes et leur propention à adapter des situations détaillées et des interactions complexes sans avoir besoin d’art d’aucune sorte. Plus j’y songeais, plus cela me semblait évident qu’un roguelike serait, en fait, le parfait type de jeu pour ce que j’avais en tête. Si je ne voulais pas créer un match à mort glorifiant, j’allais avoir besoin de plusieurs choses :

  • Plusieurs styles de gameplay viables : certains personnages de Battle Royale adoptent le jeu et tuent à vue, d’autres essaient d’approcher leurs proies par la ruse, d’autres essaient de trouver la sécurité dans le nombre, d’autres essaient de se cacher quelque part et de placer des pièges ou des gardes pour se défendre, et d’autres essaient même de s’échapper du jeu même. Tout cela et plus devrait idéalement être possible pour le joueur. C’est à dire que ces options devraient être envisageables par l’AI. Si c’était juste une question de combat, l’arme distribuée aléatoirement au début déciderait toute seule la fin.
  • Une île inconnue : Pour un meilleur effet, il faudrait arriver sur une île dont on ne sait rien, sauf peut-être vaguement la forme et quelques points de repères. Cela permettrait au jeu de rester neuf et stressant. Sans cela, on jouerait juste en optimisant ses mouvements de départ.
  • Les interactions sociales : peut-être le point le plus important de cette courte liste. L’un des facteurs faisant de Battle Royale une histoire avec un fort impact est que les participant du « jeu » ne sont pas des étrangers les uns pour les autres. Venant tous de la même classe, les rivalités, les amitiés et les groupes sont déjà présents dans le groupe bien avant que l’histoire ne commence. Inclure cet élément est crucial pour recréer l’atmosphère de Battle Royale.

Cette liste semblait répondre aux critères du roguelike, avec l’emphase sur la stimulation et le contenu procédural dont ce genre de jeu tend à faire étalage. La prochaine étape était de faire de cette idée un jeu que je pourrais créer en 7 jours…

Le jeu dans ses premiers instants.

Le jeu dans ses premiers instants.

Le plan

Clairement, faire tout ce que je voulais dans un temps très court était impossible. J’ai décidé de réduire le concept à sa forme minimale.

Ce qui signifiait couper beaucoup de l’ouverture au niveau de la fin du jeu. Pas de possibilité de s’échapper en désactivant les colliers explosifs, ni de tuer les soldats dans l’école et s’emparer de l’île, pas de hacking, juste la possibilité basique de tuer les autres joueurs. Le seul aspect que je ne voulais pas abandonner était l’aspect social. J’ai décidé d’inclure une certaine forme d’alliances/amitiés dans le jeu, avec des implications dans le gameplay. Par exemple, si vous avez un meilleur ami, le ou la tuer aurait des pénalités sévères (mais temporaires) pendant que votre personnage était dépassé par son deuil.

J’ai aussi décidé de revenir sur mon idée de la génération d’îles. Plutôt que de faire plusieurs types de structures et de terrains, j’ai décidé de ne faire que des mares, des arbres et des buildings rectangulaires. C’était un point sur lequel je pourrais toujours ajouter d’autres items plus tard, mais ayant déjà participé à un certain nombre de jams, je savais qu’on n’a jamais autant de temps qu’on croit avoir.

Mon plan était donc le suivant :

  • Jour 1 : Génération d’îles
  • Jour2 : Mouvement du joueur, champ de vision…
  • Jour3 : Autres étudiants et combat
  • Jour4 : Temps et zones interdites
  • Jour5 : Armes et autres objets
  • Jour6 & 7 : Améliorations finales

Cela semblait tout à fait faisable à l’époque…

L’exécution

Comme on dit, le meilleur plan ne survit jamais à un engagement avec l’ennemi. Bien que cela commença rondement grâce à mon choix d’outils (Python et libtcod), vers le milieu de la semaine je suis tombé malade et une montagne de travail s’empila sur mon bureau, deux choses qui se combinèrent pour m’empêcher d’atteindre les buts que j’avais décidé d’atteindre.

J’ai commencé à documenter le processus de création de mon jeu sur mon blog personnel (lire les articles ici en anglais) et plusieurs systèmes furent complétés en temps et heure (combat pour la plupart, trouver son chemin, champ de vision, génération random…). J’ai essayé de continué durant les dernières 36h du challenge mais ai reçu un coup fatal quand j’ai réalisé que le jeu ralentissait énormément quand 20 et quelques personnages essayaient de comprendre où ils devaient aller. J’avais plusieurs solutions possibles en tête, mais à ce point, j’étais fatigué, et trop déçu pour y arriver.

En fin de compte, pas mal de fonctionnalités étaient incluses dans le jeu...

En fin de compte, pas mal de fonctionnalités étaient incluses dans le jeu…

La conclusion

Au vu de comment un plan bien pensé tomba à plat, ce serait gentil de penser que le challenge fut une amère déception, n’est-ce pas? Bien, dans un sens, oui, sûrement j’aurais adoré terminer la semaine avec un nouveau jeu à montrer.

Mais, dans une vision globale des choses, j’ai enfin commencé un de mes projets « de rêve ». Et c’est queqlue chose. J’ai une bonne base de code sur laquelle je vais continuer à travailler jusqu’à obtenir un projet plus abouti.

Et je prévois de participer au challenge de nouveau l’an prochain, c’est certain !

2 comments » | #GAM, 7DRL

Mars

April 2nd, 2013 — 5:15pm

#GAM février et mars

Ce défi, commencé avec beaucoup de détermination, demande malheureusement un peu trop de temps pour que nos développeurs parviennent à s’y consacrer pleinement.

Cependant, les projets avancent !

Continue reading »

Comment » | #GAM, 3D, Alun Hevel, Bloboy's journey, Ludum Dare

Février

February 25th, 2013 — 9:08pm

Et nous revoici en février, comme promis !
Donc, une petite review de janvier…

#GAM janvier

Suite à divers problèmes, Thomas a reporté son attention directement sur son projet de février, un dungeon crawler dont les données du level design seront stockées sur un serveur de base de données.
Bastien n’est pas entièrement satisfait de son propre projet, pas tout à fait abouti (LINK : lisez ses propres commentaires sur son blog). Celui-ci lui a cependant donné l’occasion de faire ses premiers pas avec Unity et de l’adopter au passage. Il a perfectionné le jeu en février.

FOSDEM

Nous avions dit que nous y allions, et en effet…

D’abord, une petite présentation, reprenant leurs propres mots : “le meeting des développeurs européens de programmes libres et Open Source (Free and Open source Software Developers’ European Meeting) est un évènement de deux jours organisé par des volontaires pour promouvoir l’utilisation des programmes libres et Open Source.”

Des présentations et débats sont organisés sur de nombreux projets et des stands présentent différents produits, dont les très connus Gnome, Firefox, Ubuntu, LibreOffice… mais aussi d’autres bien moins connus ou avancés.

Bastien et Pascale, en vrais warriors, s’y sont rendus dès le samedi. Le reste de l’équipe les a rejoint le lendemain, pour suivre quelques “talks” sur les jeux Open Source, bien sûr, mais aussi plein d’autres sujets.

ephy Personnellement, je me suis sentie à la fois très intelligente (je comprenais le titre des bouquins, moi qui ne codais pas il y a dix-huit mois !) et très novice. Comme j’ai peu de connaissances techniques, je ne savais pas toujours suivre.
L’an prochain, je compte bien m’améliorer et participer davantage !

Alun Hevel

Bien que ce projet soit passé au second plan, nous continuons à travailler dessus, notamment au niveau des visuels.
Le dernier en cours? Les forges angéliques… qui ont demandé un certain effort d’imagination.

forge

Bloboy

Le long et dur travail de code est en route, merci à nos développeurs !

Ce mois-ci ils ont travaillé sur les sauts, sous une forme très particulière : le personnage est en effet lancé en utilisant la souris selon un système de lance-pierre et est propulsé lorsque la souris est lâchée.

bsj_jump1

bsj_jump2

De plus, un gros effort a été fourni pour donner un effet élastique au mouvement de notre personnage qui est, après-tout, un blob.

bastien Pour arriver à cela, j’ai découpé le rectangle du sprite selon une grille, et je déplace les différents points pour déformer le rectangle. La texture (l’image de Bloboy) est donc déformée de la même façon, ce qui donne l’impression que le sprite s’écrase dans le sens du pointeur de la souris.

Et les tests sont concluants !

[youtube=http://www.youtube.com/watch?v=rXBEScsXhhE&w=600&rel=0]

Reste à raffiner l’effet…

Comment » | #GAM, Alun Hevel, Bloboy's journey, Navigation

Back to top

404