«Je crée mon jeu vidéo» est une série d'articles sur la création d'un jeu vidéo, depuis la feuille blanche jusqu'au résultat final. On y parlera de tout : de la technique, du contenu, de la joie de voir bouger des sprites, de la lassitude du développement solitaire, etc. Vous pourrez suivre cette série grâce au tag gamedev.
Dans l'épisode 07, on a parlé de cartes, de données et de systèmes à entités. Avec beaucoup de questions et peu de réponses. Et ce n'est pas dans cet épisode qu'on va y répondre. Non, aujourd'hui, cet épisode est consacré à un livre qui m'avait été conseillé dans un des premiers épisodes. Je l'ai acheté, je l'ai lu avec attention et je vous en parle maintenant.
Sommaire
L'Art du game design
«L'Art du game design : 100 objectifs pour mieux concevoir vos jeux» (de son nom complet) est un livre écrit par Jesse Schell. L'auteur a beaucoup travaillé avec Disney, que ce soit pour des jeux vidéos, comme Toontown online ou pour des attractions, comme Pirates des Caraïbes.
Résumé du livre
Tout le livre est fondé sur l'idée que le travail du game designer n'est pas de créer un jeu mais d'offrir une expérience à travers un jeu. Après avoir défini ce qu'était un jeu (notamment par rapport à un jouet), l'auteur définit ce qui fait un jeu. Les quatre éléments fondamentaux sont les mécaniques, l'histoire, l'esthétique et la technologie. À partir de là, on peut définir un thème pour le jeu (de préférence fédérateur), puis partir d'une ou plusieurs idées et tenter de définir différents problèmes à résoudre dans le jeu. Ensuite, on s'intéresse au joueur, c'est-à-dire à qui s'adresse le jeu, notamment son âge et son sexe, la manière dont il peut s'intéresser au jeu et la méthode pour qu'il continue à s'y intéresser, en combinant une montée en compétence et en challenge.
Un jeu doit contenir des mécaniques qui s'inscrivent dans un espace, avec des objets et des actions sur ces objets, des règles du jeu (dont l'objectif final du jeu), le tout faisant appel à la compétence du joueur ou à la chance. Un jeu doit être globalement équilibré : équitable, permettant des prises de risques, avec un bon rapport entre compétition et coopération, une durée de vie correcte, des récompenses (symboliques) adéquates mais aussi des punitions (game over), des mécaniques à la fois simples et complexes, et qui permettent de faire appel à l'imagination du joueur. L'interface du jeu se décompose entre une partie physique (manette, écran) et une partie virtuelle (ce qui s'affiche à l'écran, l'univers du jeu) qu'il est nécessaire de coordonner pour une meilleure immersion. Pour cela, il faut afficher les informations nécessaires et suffisantes via divers canaux et divers modes.
Un jeu doit avoir une courbe d'intérêt globalement croissante avec des pics au début (pour capter l'attention) et à la fin (pour le clou du spectacle). Pour cela on doit combiner l'intérêt inhérent du jeu, la poésie du jeu et la projection que peut avoir le joueur. Un jeu doit avoir une histoire à raconter mêlant des obstacles, des voyages, des univers (qui peuvent dépasser le simple cadre du jeu), des personnages. Ces personnages ont une fonction par rapport au jeu, et un statut par rapport à l'avatar du joueur, Les univers de jeu ont une architecture qui structure l'espace du jeu. Un jeu peut se jouer à plusieurs. Il est alors intéressant de favoriser l'émergence de communauté, tout en évitant les brebis galeuses.
Le game designer (professionnel) travaille en équipe, rédige des documents et organise des séances de tests. Il doit choisir des technologies sans succomber à la mode, et satisfaire son client, le convaincre que le jeu peut réaliser un profit. Le jeu transformant les joueurs, le game designer a également une responsabilité sur son jeu.
Mon avis
Il faut le dire, ce livre m'a plu. Il est très simple d'approche, il est très pédagogique. Il n'y a pas de grandes théories fumeuses mais plutôt du bon sens. Oui, ce livre enfile des perles, il n'y a rien de vraiment nouveau ni surprenant dans son contenu, il est d'une banalité affligeante. Mais c'est justement sa force : mettre en ordre une quantité impressionante de conseils et d'astuces sous forme de fiches pratiques.
Le fait que les exemples soient tirés de divers domaines, pas seulement des jeux vidéos, apporte un plus indéniables. Jeux de plateau, jeux de cartes, attractions dans un parc à thèmes, tout y passe. L'expérience de Jesse Schell au service de Disney aide beaucoup mais il va plus loin. Quand vous arrivez sur une page avec une photo de Swiffer, vous vous demandez bien ce que ça vient faire là, mais ça fonctionne parce qu'il y a une explication tout à fait logique à côté ! De même, quand il cite comme exemple la mouche incrustée au fond des toilettes d'un aéroport, on a du mal à en croire ses yeux.
Chaque chapitre débute avec un morceau d'un diagramme qui se construit au fur et à mesure et qui permet de voir les relations entre les différentes parties. On dirait presque une carte heuristique. Il est organisé autour de pôles qui sont l'expérience, le joueur, le jeu, le processus (de création), et le concepteur. Tout s'emboîte bien jusqu'au diagramme final. On peut donc par la suite revenir sur les différentes parties de manière aléatoire.
Ce livre s'adresse avant tout à des game designers professionnels comme le montre la fin du livre. Mais il est très intéressant pour des gens comme moi qui fabriquent un jeu amateur, parce qu'on ne fait pas un jeu uniquement pour se faire plaisir, mais aussi pour faire plaisir à d'autres. Même si je ne vendrai sans doute jamais mon jeu, il faut quand même penser à sa diffusion et donc avoir une approche professionnelle de sa conception. Quand je dis ça, je ne dis pas que je vais devenir game designer, mais je vais essayer d'appliquer tous les bons conseils de ce livre, du mieux que je peux. Mais bon, je ne suis pas le prochain génie du jeu vidéo.
Je sais que certaines personnes font des jeux. Connaissiez-vous ce livre ? Si oui, comment vous aide-t-il ? Si non, allez-vous l'acheter ?
Dévelopements
Après tout ça, revenons au jeu lui-même qui avance doucement mais sûrement.
La carte du monde
Sur le front du développement du jeu, j'ai revu complètement le chargement de la carte comme indiqué la dernière fois. J'en ai profité pour réfléchir à comment organiser la carte et je pense converger dans les semaines qui viennent. Ce travail est nécessaire pour une des prochaines grandes étapes qui sera de générer procéduralement une grande carte. Il faut que je sache à l'avance ce dont j'ai besoin pour pouvoir générer un maximum de choses. Par exemple, maintenant que j'ai des sprites d'arbres, je peux générer des forêts sans aucun problème, reste à savoir la meilleure manière de générer ces forêts et l'endroit le plus pertinent où les placer.
Par effet de bord, j'en ai profité pour améliorer libtmx qui me sert à charger les cartes au format TMX. Et j'ai réécrit l'utilitaire tmx_render en utilisant Qt5 à la place de SFML, de manière à pouvoir générer l'ensemble de la carte dans une image. Ça me sera très utile pour gérer une minimap dans l'interface, mais on aura l'occasion d'en reparler.
Il me reste à définir un ensemble de tuiles de base que j'utiliserai pour construire la carte (pas forcément le dessin final mais au moins la structure). J'envisage en fait deux ensembles : un ensemble pour le terrain proprement dit, c'est-à-dire le sol ; un ensemble pour ce qui se trouve sur le terrain (rivières, routes, etc). J'ai longtemps hésité à inclure les maisons (plus précisément les toits) dans ce deuxième ensemble (l'autre solution étant de faire des sprites), mais je crois que je vais garder cette solution. L'inconvénient est qu'on aura des maisons dont les murs sont horizontaux et verticaux (on pourra peut-être pousser vers les murs obliques à 45°). Ça donnera sans doute une impression old-school (pour être gentil), à voir donc.
Les dialogues
J'espère finir cette partie assez vite pour m'attaquer aux dialogues. Mais je dois dire que je me pose encore pas mal de questions. Il y a tout d'abord le problème de la traduction, mais pour ça, après avoir hésité et regardé ce qui était possible, j'en reviens systématiquement à Gettext. La foultitude d'outils existants me poussent vers cette direction. Et même Boost.Locale peut utiliser les fichiers au format Gettext (sans avoir besoin de Gettext). Ensuite, il y a le format des chaînes de caractères, et là, je n'ai pas encore fait de choix. J'ai à ma disposition le printf standard des familles, boost::format, ou encore FastFormat qui semble assez bien foutu même si assez complexe (vous aurez remarqué que iostream est disqualifié d'office). Enfin, il y a le format de stockage de tous ces dialogues, je m'oriente plutôt vers du YAML, j'aimerais savoir s'il existe déjà un dialecte YAML permettant de stocker des dialogues, mais je n'ai pas encore réussi à trouver.
Donc, je fais appel à tous ceux qui auraient des idées sur ces différents sujets et qui pourraient éclairer mes lanternes, ou me confirmer que mes choix ne sont pas trop mauvais.
Aller plus loin
- Akagoria, la revanche de Kalista (153 clics)
- le tag gamedev (115 clics)
- le livre chez un marchand en ligne (183 clics)
# Art of game design, c'est bon mangez-en
Posté par case42 (site web personnel) . Évalué à 4.
Oui, oui, c'est un des meilleurs livres sur le sujet. S'il ne fallait en garder que deux, ce serait celui la et "A Theory Of Fun" de Raph Koster ( http://www.theoryoffun.com/ )
Je ne peux pas dire que je l'utilise dans le sens ou je ne le ressort pas de la bibliothèque pour le consulter, mais j'ai profondément intégré beaucoup de ses leçons et je les utilises régulièrement de façon naturelle..
J'ai eu l'application de ses "lenses" sur mon smartphone pendant quelques temps et je les lisais quand j’étais en transport, j'arrive pas trop a me souvenir si c’était vraiment utile ou pas pour le coup…
( https://play.google.com/store/apps/details?id=com.schellgames.deckoflenses )
# Des liens à propos de design
Posté par potate . Évalué à 4.
Le blog "Les Forges" est très intéressant. En particulier les articles "pas de biscuit" qui listent pas mal de mauvaise idées de gameplay/design à éviter.
Sinon, deux billets évoquant une erreur courante lors de la réalisation d'un RPG : vouloir faire trop grand. C'est là et là.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . Évalué à 2.
Merci pour les références, je vais les lire avec attention vu que ça me concerne assez directement ;)
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . Évalué à 2.
Du coup, je me réponds à moi-même pour dire ce que je pense de ces articles. Je pense qu'ils sont tout à fait exact, et je pense que dès le début, je savais que je me lançais dans un projet assez grand. Mais comme je le sais, j'ai pris les devants. Premièrement, j'ai dit que je me donnais deux à trois ans pour finir le jeu, ce qui représente un temps considérable. Ce temps sera vraisemblablement partagé pour moitié dans le codage des mécaniques du jeu, et pour l'autre moitié (voire une très grosse moitié) dans la création de contenu (graphisme, quête, dialogue, etc). Deuxièmement, je prévois de générer un maximum de chose de manière aléatoire, notamment le fond de carte, ce qui va me faire gagner un temps considérable. Reste à trouver la bonne taille. Je retiens en tout cas ce conseil : sur chaque écran, il doit y avoir quelque chose d'intéressant.
[^] # Re: Des liens à propos de design
Posté par Azrou . Évalué à 1.
Je trouve les articles "pas de biscuits" sont plus à même à faire sourire un lectorat de joueurs amusés par la dénonciation d'incohérences dans les jeux, qu'a réellement donner des conseils à des game-designer.
Beaucoup sont d'une banalité affligeante (je ne pense pas qu'un quelconque game-designer ait besoin qu'on dénonce les camera 3d mal calibrés), et l'auteur dénonce souvent sans chercher à comprendre ou expliquer les contraintes techniques ou les réelles motivations des responsables de ces soit-disant boulettes (Les oiseaux qui transportent des épées)
Il dénonce fréquemment des choses qui sont complètement assumés par les game-designer, et même très importantes pour le jeu (les caisses de counter-strike sont fondamentales au gameplay du jeu, leur présence ne choque pas l'oeil, là où une arène plus cohérente aurait sans doutes été nettement moins intéressante à jouer)
Y'a t'il réellement un point qui, en lisant ses articles, vous a permis de réaliser une erreur que vous avez pu faire dans le développement d'un jeu, ou vous permettre d'en éviter une ?
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . Évalué à 3.
Au contraire, j'ai trouvé ces articles fort pertinents. L'exemple des caisses est vraiment caractéristique. Certes, c'est fondamental au gameplay, mais pourquoi une caisse ? Pourquoi pas un autre objet ? Tout simplement parce que la caisse est l'objet standard qu'on peut mettre partout, tellement standard que ça en devient ridicule parce que ça n'a souvent aucun intérêt dans le contexte d'avoir une caisse. Plutôt que de chercher quelque chose d'identique niveau forme mais avec une vraie raison, les game designers iront au plus vite.
J'ai beaucoup ri sur un des premiers qui décrit comment les RPG transforment souvent le joueur en marchand d'armes d'occasion. Typiquement ce qu'on retrouve dans beaucoup de MMORPG (et pourtant, l'article original date de 1998). Il y a beaucoup d'autres choses qui sont intéressantes quand on programme un jeu, pour éviter les erreurs. Quand on est joueur, effectivement, on ne se rend pas forcément compte de ce que ça peut représenter.
[^] # Re: Des liens à propos de design
Posté par Azrou . Évalué à 3.
J'imagine que tu fais référence à l'article "Tuer un monstre / Ramasser l'épée / Vendre l'épée / Acheter une autre épée / Tuer un autre monstre" (quelque part ici)
C'est justement un très bon exemple de "biscuit" que je trouve douteux, manquant cruellement d'objectivité et de recul par rapport à des mécaniques éprouvés par le temps.
On pourrait disserter pendant des heures sur l'intérêt de ce genre de gameplay, et ça serait sans doute un débat passionnant.
Mais je vais prendre un raccourcis et poser une autre question : si ce gameplay était fondamentalement mauvais, pourquoi des pointures reconnus du game-design, qui ont développés des véritables hits du jeu vidéo, continuent, en tout état de conscience, à refuser leur biscuit ? (citons Baldur's Gate, Fallout, Diablo, World of Warcraft, et plus récemment, Path of Exile)
Les jeux type porte-monstre-trésor sont légions, et la plupart d'entre eux sont intimement liés à la notion de commerce. Et des jeux de ce genre continuent de sortir, en grand nombre, et à trouver un publique toujours croissant.
La conclusion pragmatique est que c'est un modèle de game-design qui plait aux joueurs, donc qui fonctionne.
Il aurait alors été très intéressant d'en comprendre, et d'en expliquer les raisons, et pourquoi pas même chercher à isoler l'élément ludique de ce modèle pour chercher un modèle qui puisse apporter une expérience similaire aux joueurs tout en satisfaisant les critères de qualité de l'auteur de l'article (que je comprends assez mal, soit-dit en passant)
Mais l'article ne va pas plus loin qu'une dénonciation d'un type de jeu qui trouve pourtant son publique, et c'est bien dommage.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . Évalué à 7.
Je ne pense pas qu'il dise que c'est mauvais comme gameplay, il dit simplement que le game designer n'a pas fait beaucoup d'effort pour imaginer autre chose que le cliché. Maintenant, il pourrait évoquer le pourquoi (c'est-à-dire pourquoi on voit sans cesse les mêmes clichés), et il l'effleure à peine à deux moments dans la suite de la série. Premièrement quand il parle du turnover, deuxièmement quand il parle des FPS qui sont les nouveaux sidescroller.
Son discours est de dire qu'à cause du turnover, il n'y a pas de mémoire et donc, les game designers refont toujours les mêmes bêtises (ce qui est discutable). Et ensuite, il dit que c'est dans les FPS qu'on retrouve la plupart de ce qu'il dénonce et que ce sont les nouveaux sidescroller, sous-entendu il en existe une tétrachiée qui se ressemblent tous comme les sidescrollers dans les années 90. À mon sens, il analyse bien la conséquence mais il ne voit pas la vraie cause qui est l'industrialisation massive du jeu vidéo. Quand il commence sa série, les «gros» studios sont des nains composés de pionniers, avec une technologie très changeante. Aujourd'hui, on a des entreprises énormes, une industrie qui surpasse le cinéma et la musique, des milliards de brouzoufs à engranger ou à perdre. Donc, comme pour le cinéma, on fait ce qui marche et donc, on ne s'écarte pas trop des clichés et de ce qu'il considère comme des mauvaises conceptions. Je pense qu'il n'a pas vu venir l'industrialisation et sa puissance. Alors oui, actuellement, on voit beaucoup de clones et oui, ça se voit dans les FPS, jeux qui s'adressent à la catégorie qui consomme le plus de jeux vidéos : le mâle trentenaire sans enfant avec une profession intermédiaire ou supérieure.
Dans le même ordre d'idée, il parle beaucoup des sauvegardes, de la manière de faire pour que le jeu vieillisse bien, etc. Bref, des trucs de long terme. Mais ça ne peut plus marcher quand on veut sortir une version par an (avec un delta par rapport à l'année d'avant qui va du minimal au négligeable). Dans ce cas là, on s'en fout de bien gérer les sauvegardes, de toute façon, on en ressortira une version l'année suivante. Ça aussi ça vient de l'industrialisation massive : quelques gros titres tirent le reste des jeux qui marcheront moins bien. Mais sans ces gros titres, le reste aurait du mal à survivre. Pareil que dans le cinéma, ou dans la musique.
Donc, quand il dénonce tout ça, il a raison et tort. Raison quand on se place du point de vue d'un fan de jeu vidéo qui aimerait un peu plus de diversité, mais tort quand on examine les raisons économiques qui poussent à l'utilisation de ces clichés. Quand on développe un jeu amateur (et même indie), on doit écouter ces conseils, pour proposer autre chose, parce qu'on ne pourra jamais rivaliser avec un gros studio sur les clichés.
[^] # Re: Des liens à propos de design
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 3.
En lisant la liste des mauvaises idées, j'ai eu l'impression de lire absolument tout ce qu'il faut faire pour réaliser un jeu intéressant.
La mécanique [petite épée/ monstre / grosse épée / gros monstre] est un élément de gameplay basique de n'importe quel openworld.
Je m'attendais à ce qu'il prétende que le leveling était sans intérêt.
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . Évalué à 2.
Le leveling (dans le bon sens du terme) n'est pas sans intérêt, au contraire, il permet au joueur de mesurer sa progression.
[^] # Re: Des liens à propos de design
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Je suis assez d'accord, mais la découverte d'items et leur inventaire permet aussi de mesurer la progression, un peu comme des trophées. C'est pour ça que je ne comprend pas trop son propos.
C'est un peu comme s'il remettait en cause les livres, parce qu'ils étaient écrits avec des mots, regroupés en paragraphes, avec parfois un « read play » différent pour les dialogues. Il pourrait en déduire que tous les écrivains font les même choses : des pages de paragraphes contetant des mots (on pourra étendre l'analogie avec les procédés stylistiques et toute autre technique destinée à capter et conserver le lecteur).
[^] # Re: Des liens à propos de design
Posté par rewind (Mastodon) . Évalué à 3.
Si on voulait faire un parallèle, on prendrait plutôt les clichés dans les romans. Par exemple, quand tu prends 90% de la littérature de médiéval fantastique, c'est uniquement du cliché vu et revu. C'est lassant, et c'est ça qui est dénoncé. Maintenant, ça ne veut pas dire qu'un énième titre de médiéval fantastique rempli de clichés ne marchera pas.
# Dialogues
Posté par zyphos . Évalué à 3.
Pour les dialogues, voici un petit exemple dans un autre jeux libre (Andors' trail). Ce n'est pas du YAML mais du JSON (JSON est compatible YAML il me semble), la structure en YAML serait presque la même:
http://code.google.com/p/andors-trail/source/browse/#git%2FAndorsTrail%2Fres%2Fraw
[^] # Re: Dialogues
Posté par rewind (Mastodon) . Évalué à 3.
Merci ! C'est exactement le genre d'exemple que je cherchais. Où je vois donc qu'il a adopté Gettext (ouch, le fichier de 10000 lignes de traduction !), et les chaînes de format de Java (ça, plutôt normal).
# Génération automatique de cartes
Posté par Snark . Évalué à 2.
Dans nethack, slash'em et warmux, il y a du code pour créer automatiquement des cartes ; ça peut être une source d'inspiration sur comment s'y prendre.
[^] # Re: Génération automatique de cartes
Posté par rewind (Mastodon) . Évalué à 4.
Sans dévoiler de grands secrets, mes sources actuelles d'inspiration sont :
Je vais aller voir tes références pour ajouter des sources d'inspiration.
# pour les (toits des) maisons
Posté par bobo38 . Évalué à 2.
J'ai peur de dire une connerie, n'ayant pas suivi toute la saga à 100%…
Mais si ça te parait limité des toits aux bords verticaux et horizontaux, n'y a-t-il pas moyen d'introduire une propriété « angle » ? Et tant qu'à y être ajouter un « décalage XY » du centre par rapport au milieu de la tuile ? (ces propriétés supplémentaires pourraient avoir des valeurs « à zéro » pour les terrains, si bien que tous ces objets serait d'une seule famille)
Arrêtez-moi si je dis une connerie !
[^] # Re: pour les (toits des) maisons
Posté par rewind (Mastodon) . Évalué à 4.
Je me suis peut-être mal exprimé, je reprends. Tout d'abord, le jeu est en vue de haut (à la verticale), donc on ne voit vraiment que le haut. Ensuite, la carte est basée sur des tuiles, c'est-à-dire un ensemble prédéterminée de petits morceaux de cartes qu'on va assembler pour construire une grande carte. Et le problème il est bien là, c'est que si tu ne peux pas avoir une quantité monstrueuse de tuiles, pour tous les angles possibles, il faut faire des choix sur ce qui est possible, et dans mon cas, ça sera deux ou trois orientations pour le toit (et ça va déjà faire un paquet de tuiles à faire).
L'autre solution, ça aurait été de poser un sprite (une image) de toit, et là, on pouvait le placer comme on voulait, avec l'angle qu'on voulait. Mais d'un autre côté, il fallait faire correspondre exactement le toit et l'intérieur (sur une autre couche), ce qui n'est pas forcément évident à la main. Il y a également d'autres problèmes que je n'évoque pas. Bref, solution plus flexible mais solution plus complexe.
[^] # Re: pour les (toits des) maisons
Posté par bobo38 . Évalué à 2. Dernière modification le 20 janvier 2014 à 22:01.
J'avais suivi cette affaire de vue du dessus uniquement. C'est un choix de design qui me plaît, une sorte de figure imposée du jeu vidéo, un peu désuète mais rétro, et qui peut être déclinée brillamment – notamment avec cette histoire d'ombre qui m'a réjoui à la lecture (j'ai vu le cowboy marcher au soleil couchant).
[passage poético-inutile tendance ma_life]
Je voyais les « tuiles » comme des sprites qui une fois posés sur des ancres s'abuttent (s'il n'y a ni angle, ni offset). J'étais naïvement resté sur la composition de paysage pittoresque avec des petits villages de bric et de broc, ou de capitales avec des quartiers huppés construits en dur et tirés au cordeau avec de grandes allées à statues, contrastant avec des faubourgs plus authentiquement bordéliques, voire bidonvillesques.
Je n'avais pas même pensé aux visites d'intérieur, si ce n'est sous l'angle Zelda*, avec une vue « plan d'évacuation ISO machin bien carrée » décorrélée de l'extérieur (décalage de boussole en option ? moyen de faire des tipis ronds quand même… et des cloisons biscornues ? un must pour une bicoque de sorcière…).
[/passage poético-inutile tendance ma_life]
J'étais dans mes rêves quoi. Merci pour les explications, et bon courage !
*: terme désignant tout bon vieux jeu d'aventure de l'époque avec vue 2D du haut. Je n'ai que très peu joué à Zelda, donc veuillez passer mes approximations.
[^] # Re: pour les (toits des) maisons
Posté par rewind (Mastodon) . Évalué à 2.
pour l'instant, ça tient du rêve, mais ce n'est pas impossible ;) J'y travaillerai quand j'aurai bien avancé sur le reste.
En fait, si je comprends bien ce que tu dis, tu voudrais construire des cartes uniquement avec des sprites. C'est une idée très intéressante que j'ai déjà vu utilisé pour des sidescroller. L'avantage, c'est qu'on peut avoir des cartes superbes. L'inconvénient, c'est qu'il faut avoir tout un tas de sprite qui se coordonnent bien, qu'on peut redimensionner comme on veut, et que la construction de la carte est moins facilement automatisable.
Rien n'empêche d'avoir un jeu de tuiles spécifique pour des bâtiments uniques. Mais bon, ça ne compte pas ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.