Ou, plus simplement, ne pas se lancer dans l'aventure du multi-joueurs, qui est nettement plus complexe à mettre en place à tout point de vue.
Je suis tout à fait d'accord avec ça.
Mais je ne parle pas de studio de développement à proprement parler, je parle des jeux vidéos, dans leur ensemble. Je ne suis pas sur que tout les jeux vidéos aient à gagner à être libre, parce que certains d'entre eux risqueraient de ne pas être capable de gérer les problèmes de tricherie.
J'ai toujours pour souvenir mes expériences de Tremulous, excellent FPS libre dans lequel j'ai eu l'occasion de contribuer un peu il y a quelque années. Dans ce jeu, l'équipe de développement du fork du client du jeu visant à y ajouter des outils de triche était plus grande et plus active que l'équipe de développement elle même, si bien qu'il est devenu impossible de repérer certaines tricheries offrant pourtant de très gros avantages, ce qui a fortement contribué à dessouder la communauté du jeu.
Bien que j'ai pris énormément de temps et de plaisir à développer des patchs et entretenir des serveurs pour ce jeu, je pense qu'il est tout à fait possible qu'il ait pu être plus agréable à jouer s'il avait été propriétaire.
Je ne suis convaincu de rien, mais je trouve que c'est une interrogation qui fait réfléchir.
Je ne parle pas d'optimisation logicielle pour accélérer le temps de calcul. Ca, en dehors de gros MMORPG avec des centaines de joueurs par zone, c'est de l'ordre de l’instantané. Je parle uniquement des latences réseau.
Mme Michu (ou son gosse, si elle n'aime pas les jeux vidéos !) ne va ni choisir un fournisseur d'accès, ou un type de connexion pour sa latence. Elle peut également être victime de programmes intrusifs infectant son système d'exploitation qui vandalisent sa bande passante.
Ou peut être vit-elle simplement dans un pays où les connexions n'ont pas la même qualité que par chez nous, et que même en y mettant les moyens, elle n'aura pas de latence convenable.
Il est probable que d'ici une dizaine d'années, les latences réseaux ne seront plus un problème pour le jeu vidéo. Mais en 2014, si on souhaite avoir un jeu accessible par Mme Michu, ou son gosse, on ne peut pas l'oublier.
D'où la nécessité de garder un minimum de traitement côté client, qui aura pour but de faire tampon sur la latence réseau.
Tu me diras qu'a l'aide de bons algorithmes, et en y consacrant le temps de calcul nécessaire, on peut arriver à repérer en aval les situations où il y a eu tricherie (via une série d'input caractéristique par exemple), et sanctionner le joueur en conséquent, et je pense effectivement que c'est possible dans la quasi-totalité des cas. Mais c'est beaucoup de développement et de puissance de calcul en plus, et une veille constante pour arriver à prendre en compte les nouvelles méthodes de tricheries que des joueurs inventifs ne manqueront pas de trouver.
Autant c'est quelque chose qui est envisageable pour des jeux avec de gros moyens (c'est d'ailleurs utilisé pour certains FPS compétitifs afin de repérer les assistants à la visé), autant avec des projets d'envergure plus modeste, ça me parait complètement surréaliste, quand je vois déjà le coût que demande la lute anti-triche même à des projets qui n'hésitent pas à avoir recours à l'obfuscation ou au DRM pour l'enrayer.
Après, pour le reste de la triche, c'est plus la manière de coder et de concevoir qui va permettre d'éviter la triche ou pas.
A partir du moment où un jeu cherche à mettre en compétition les compétences de plusieurs joueurs, et que des outils informatique permettent d'obtenir un avantage sur les autre joueurs, comment concevoir un jeu qui évitera la triche ?
Comment éviter un système d'aide à la visée dans un FPS, ou l'utilisation d'une intelligence artificielle pour mieux prévoir l'évolution d'une partie dans des jeux de stratégie en temps réel si les joueurs peuvent librement réécrire les règles d'interaction avec le jeu ?
La problématique gravite entre trois contraintes :
- Un code libre.
- Un jeu agréable à jouer.
- De bonnes protections contre la triche.
Voici un exemple concret où je ne vois aucune issue pour respecter ces trois contraintes :
Dans les jeux en temps réel à déplacement libre (FPS, MMORPG, …), la latence réseau engendre une différence de position du joueur côté serveur et côté client.
D'habitude, dans un système client/serveur, on se débrouille juste pour resynchroniser régulièrement.
Dans un jeu vidéo, une telle resynchronisation nuit souvent à l'immersion (syndrome du joueur téléporter à cause d'un pic de latence), et on laisse donc au client une certaine marche de manoeuvre, le serveur acceptera, jusqu'à une certaine mesure, la position d'un client même si elle est différente de celle qu'il a lui même calculé.
Ce système est plus agréable pour le joueur, mais est la porte ouverte à de nombreuses méthodes de triche (passage à travers des murs, augmentation de vitesse de déplacement), qui, dans le cadre de jeux propriétaires, sont empêchés, du mieux que possible, grâce à des techniques d'obfuscation de code et de protocole, et de DRM.
J'ai beau tourner le problème dans tout les sens, je ne vois pas comment résoudre le problème dans un jeu librement compilable.
J'ai l'impression qu'il y a un petit soucis dans ton approche du problème.
Tu prévois une interface basé sur des widgets, traditionnellement conçu et utilisé pour un dispositif de pointage, mais tu veux concevoir ton jeu pour des contrôles qui n'ont pas de dispositifs de pointage (clavier ou manette).
Est-ce que tes interfaces ne sont pas tout simplement mal adaptés à ton jeu et à tes contrôles ?
Si ton jeu nécessite des interfaces à l'utilisation complexe, faut-il vraiment lui penser un support manette, ou clavier uniquement ? Aussi ergonomique que sera la solution que tu trouveras, le joueur ne se retrouvera t'il pas frustré de devoir se contenter d'un substitut de dispositif de pointage ? Ne faut-il pas repenser le jeu lui même pour réduire le nombre d'interfaces ou leur complexité ?
Si au contraire tes interfaces sont plutôt simples, n'y a t'il pas de moyens plus simples pour naviguer entre elles ?
Parmi les jeux récents jouables à la manette, même les jeux de gestion les plus compliqués évitent d'afficher trop d'interfaces simultanées et préfèrent ne les afficher qu'au besoin, via l'utilisation de sous menus ou d'onglets. Et lorsqu'il y a peu d'interface, il devient possible de les associer à l'utilisation d'un, ou d'une combinaison de boutons.
Finalement, ton problème peut-être ramené à celui de la navigation au clavier dans des interfaces type GTK, et ça a toujours été une horreur à gérer. Le jeu vidéo, avec son emballage graphique et sa nécessité de rester ludique, ne pourra qu'empirer le problème, car naviguer dans des menus, en tant que tel, c'est pas amusant.
Une difficulté, comme tu le dis, c'est de représenter le relief et la pente en vue de dessus. Je pense que c'est hyper difficile, et que ça n'apporte pas grand chose étant donné le niveau de zoom sur le personnage. Mais on peut donner des indices visuels qui permettent, pour certaines situations (comme les zones infranchissables) de suggérer qu'il y a un relief. Et on peut toujours permettre au joueur de voir une grande carte générée par mon programme en l'état actuel pour qu'il voit les reliefs ;)
Des tuiles de montagnes en trompe l'oeil sont aussi un excellent moyen de simuler du relief.
Les vieux RPG 2D l'utilisent beaucoup, comme les montagnes au nord de Link's Awakening.
Il serait sans doutes très amusant d'essayer de trouver des algorithmes pour placer ce genre de trompe l'oeil dans une carte généré aléatoirement, tout en gardant un résultat cohérent et en prenant en comptes les nombreuses contraintes (positionnement, orientation).
C'est un sujet sur lequel je me suis déjà un peu penché, j'ai hâte de voir tes solutions :)
J'ai d'abord essayé des systèmes réalistes d'écoulement d'eau, mais sans grand succès.
Finalement, je me suis simplement penché sur un bête A* en utilisant la topologie de la carte comme heuristique, le résultat s'est montré satisfaisant dans le cadre du projet sur lequel je travaille, bien qu'il montrerait très vite ses limites si on cherche à représenter un monde trop réaliste.
Je me permet quelque questions :
Puisque, si j'ai bien compris, tu travaille sur un jeu 2d, comment penses tu représenter visuellement une topologie aussi précise que celle que ton algorithme est capable de générer ?
Au final, sous quelle forme vas tu représenter le monde au joueur ? Vas tu granulariser ta carte pour l'afficher sous forme de tuiles, comme la plupart des jeux 2d ?
Comptes-tu utiliser des graines différentes pour chaque partie afin de générer des niveaux aléatoires, ou n'est-ce qu'un moyen pour toi d'accélérer et de simplifier le level-design d'un monde unique ?
Merci encore pour ces séries d'articles, c'est toujours très enrichissant, d'autant plus que c'est des sujets qui me tiennent particulièrement à coeur :)
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.
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 ?
Autant réussir à tenir des milestone longue pour la partie programmation, c'est faisable avec un peu de méthodologie (modulo la motivation).
Autant c'est une très mauvaise idée de partir sur des milestones longue pour les problèmes de game-design.
Parfois (particulièrement quand on débute en game-design, mais même les meilleurs s'y font prendre…), le gameplay qu'on a prévu pour le jeu ne fonctionne tout simplement pas : pas amusant, pas intuitif, trop compliqué, pas ergonomique, lassant… Tant de choses qui peuvent entraîner une désillusion monumentale par rapport aux objectifs de départ.
Parfois, il suffit d'une retouche par ici, d'une rustine par là et on redresse le cap. Et parfois, c'est l'idée de base du jeu qui n'est pas bonne et les rustines parviendront alors tout juste à en faire un jeu médiocre.
C'est pour ça qu'il est important de prototyper son jeu très tôt, à grand coup de carrés, de cercles et de code crade s'il le faut. Et continuer à pouvoir tester régulièrement toute les améliorations, parce que tant qu'une feature du jeu n'a pas été joué, on a jamais vraiment moyen de savoir si cette feature respectera vraiment son rôle de rendre le jeu plus amusant.
Pour ma part, pour les projets persos, je me fixe des objectifs sur une ou deux semaines maximum. Je note soigneusement mes grands projets d'avenir qui en feront un jeu parfait, mais j'évite d'y réfléchir trop profondément, parce qu'il est de toutes façons absolument certain que le gameplay ne sera pas dans la pratique tel que je l'avais prévu, et que 1 mois plus tard mes prévisions devront être complètement revu pour coller avec ce que le jeu est devenu.
D'après moi, le principal avantage se ressent surtout du point de vue du non-programmeur.
Ca permet aux autres corps de métiers du jeu vidéo (level-designer, game-designer, artistes 3d, etc…) de créer très rapidement des entités à leur convenance sans avoir à mettre le nez dans les "trucs de devs", sans avoir à passer par eux, et en utilisant des notions qu'ils comprennent facilement et qui s'intègrent bien à leurs outils.
Dans des projets que je fais en solo, je ne trouve pas très utile de séparer données et comportements, et j'en reviens plus souvent à des modèles de programmation par traits.
[^] # Re: Du temps
Posté par Azrou . En réponse au journal Modèle économique dans les jeux libres. Évalué à 3.
Ou, plus simplement, ne pas se lancer dans l'aventure du multi-joueurs, qui est nettement plus complexe à mettre en place à tout point de vue.
Je suis tout à fait d'accord avec ça.
Mais je ne parle pas de studio de développement à proprement parler, je parle des jeux vidéos, dans leur ensemble. Je ne suis pas sur que tout les jeux vidéos aient à gagner à être libre, parce que certains d'entre eux risqueraient de ne pas être capable de gérer les problèmes de tricherie.
J'ai toujours pour souvenir mes expériences de Tremulous, excellent FPS libre dans lequel j'ai eu l'occasion de contribuer un peu il y a quelque années. Dans ce jeu, l'équipe de développement du fork du client du jeu visant à y ajouter des outils de triche était plus grande et plus active que l'équipe de développement elle même, si bien qu'il est devenu impossible de repérer certaines tricheries offrant pourtant de très gros avantages, ce qui a fortement contribué à dessouder la communauté du jeu.
Bien que j'ai pris énormément de temps et de plaisir à développer des patchs et entretenir des serveurs pour ce jeu, je pense qu'il est tout à fait possible qu'il ait pu être plus agréable à jouer s'il avait été propriétaire.
Je ne suis convaincu de rien, mais je trouve que c'est une interrogation qui fait réfléchir.
[^] # Re: Du temps
Posté par Azrou . En réponse au journal Modèle économique dans les jeux libres. Évalué à 0.
Je ne parle pas d'optimisation logicielle pour accélérer le temps de calcul. Ca, en dehors de gros MMORPG avec des centaines de joueurs par zone, c'est de l'ordre de l’instantané. Je parle uniquement des latences réseau.
Mme Michu (ou son gosse, si elle n'aime pas les jeux vidéos !) ne va ni choisir un fournisseur d'accès, ou un type de connexion pour sa latence. Elle peut également être victime de programmes intrusifs infectant son système d'exploitation qui vandalisent sa bande passante.
Ou peut être vit-elle simplement dans un pays où les connexions n'ont pas la même qualité que par chez nous, et que même en y mettant les moyens, elle n'aura pas de latence convenable.
Il est probable que d'ici une dizaine d'années, les latences réseaux ne seront plus un problème pour le jeu vidéo. Mais en 2014, si on souhaite avoir un jeu accessible par Mme Michu, ou son gosse, on ne peut pas l'oublier.
D'où la nécessité de garder un minimum de traitement côté client, qui aura pour but de faire tampon sur la latence réseau.
Tu me diras qu'a l'aide de bons algorithmes, et en y consacrant le temps de calcul nécessaire, on peut arriver à repérer en aval les situations où il y a eu tricherie (via une série d'input caractéristique par exemple), et sanctionner le joueur en conséquent, et je pense effectivement que c'est possible dans la quasi-totalité des cas. Mais c'est beaucoup de développement et de puissance de calcul en plus, et une veille constante pour arriver à prendre en compte les nouvelles méthodes de tricheries que des joueurs inventifs ne manqueront pas de trouver.
Autant c'est quelque chose qui est envisageable pour des jeux avec de gros moyens (c'est d'ailleurs utilisé pour certains FPS compétitifs afin de repérer les assistants à la visé), autant avec des projets d'envergure plus modeste, ça me parait complètement surréaliste, quand je vois déjà le coût que demande la lute anti-triche même à des projets qui n'hésitent pas à avoir recours à l'obfuscation ou au DRM pour l'enrayer.
[^] # Re: Du temps
Posté par Azrou . En réponse au journal Modèle économique dans les jeux libres. Évalué à 2.
A partir du moment où un jeu cherche à mettre en compétition les compétences de plusieurs joueurs, et que des outils informatique permettent d'obtenir un avantage sur les autre joueurs, comment concevoir un jeu qui évitera la triche ?
Comment éviter un système d'aide à la visée dans un FPS, ou l'utilisation d'une intelligence artificielle pour mieux prévoir l'évolution d'une partie dans des jeux de stratégie en temps réel si les joueurs peuvent librement réécrire les règles d'interaction avec le jeu ?
La problématique gravite entre trois contraintes :
- Un code libre.
- Un jeu agréable à jouer.
- De bonnes protections contre la triche.
Voici un exemple concret où je ne vois aucune issue pour respecter ces trois contraintes :
Dans les jeux en temps réel à déplacement libre (FPS, MMORPG, …), la latence réseau engendre une différence de position du joueur côté serveur et côté client.
D'habitude, dans un système client/serveur, on se débrouille juste pour resynchroniser régulièrement.
Dans un jeu vidéo, une telle resynchronisation nuit souvent à l'immersion (syndrome du joueur téléporter à cause d'un pic de latence), et on laisse donc au client une certaine marche de manoeuvre, le serveur acceptera, jusqu'à une certaine mesure, la position d'un client même si elle est différente de celle qu'il a lui même calculé.
Ce système est plus agréable pour le joueur, mais est la porte ouverte à de nombreuses méthodes de triche (passage à travers des murs, augmentation de vitesse de déplacement), qui, dans le cadre de jeux propriétaires, sont empêchés, du mieux que possible, grâce à des techniques d'obfuscation de code et de protocole, et de DRM.
J'ai beau tourner le problème dans tout les sens, je ne vois pas comment résoudre le problème dans un jeu librement compilable.
# Tu te trompes de problème
Posté par Azrou . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 7.
J'ai l'impression qu'il y a un petit soucis dans ton approche du problème.
Tu prévois une interface basé sur des widgets, traditionnellement conçu et utilisé pour un dispositif de pointage, mais tu veux concevoir ton jeu pour des contrôles qui n'ont pas de dispositifs de pointage (clavier ou manette).
Est-ce que tes interfaces ne sont pas tout simplement mal adaptés à ton jeu et à tes contrôles ?
Si ton jeu nécessite des interfaces à l'utilisation complexe, faut-il vraiment lui penser un support manette, ou clavier uniquement ? Aussi ergonomique que sera la solution que tu trouveras, le joueur ne se retrouvera t'il pas frustré de devoir se contenter d'un substitut de dispositif de pointage ? Ne faut-il pas repenser le jeu lui même pour réduire le nombre d'interfaces ou leur complexité ?
Si au contraire tes interfaces sont plutôt simples, n'y a t'il pas de moyens plus simples pour naviguer entre elles ?
Parmi les jeux récents jouables à la manette, même les jeux de gestion les plus compliqués évitent d'afficher trop d'interfaces simultanées et préfèrent ne les afficher qu'au besoin, via l'utilisation de sous menus ou d'onglets. Et lorsqu'il y a peu d'interface, il devient possible de les associer à l'utilisation d'un, ou d'une combinaison de boutons.
Finalement, ton problème peut-être ramené à celui de la navigation au clavier dans des interfaces type GTK, et ça a toujours été une horreur à gérer. Le jeu vidéo, avec son emballage graphique et sa nécessité de rester ludique, ne pourra qu'empirer le problème, car naviguer dans des menus, en tant que tel, c'est pas amusant.
[^] # Re: lacs et cours d'eau
Posté par Azrou . En réponse à la dépêche Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1). Évalué à 2.
Des tuiles de montagnes en trompe l'oeil sont aussi un excellent moyen de simuler du relief.
Les vieux RPG 2D l'utilisent beaucoup, comme les montagnes au nord de Link's Awakening.
Il serait sans doutes très amusant d'essayer de trouver des algorithmes pour placer ce genre de trompe l'oeil dans une carte généré aléatoirement, tout en gardant un résultat cohérent et en prenant en comptes les nombreuses contraintes (positionnement, orientation).
[^] # Re: lacs et cours d'eau
Posté par Azrou . En réponse à la dépêche Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1). Évalué à 3.
C'est un sujet sur lequel je me suis déjà un peu penché, j'ai hâte de voir tes solutions :)
J'ai d'abord essayé des systèmes réalistes d'écoulement d'eau, mais sans grand succès.
Finalement, je me suis simplement penché sur un bête A* en utilisant la topologie de la carte comme heuristique, le résultat s'est montré satisfaisant dans le cadre du projet sur lequel je travaille, bien qu'il montrerait très vite ses limites si on cherche à représenter un monde trop réaliste.
Je me permet quelque questions :
Puisque, si j'ai bien compris, tu travaille sur un jeu 2d, comment penses tu représenter visuellement une topologie aussi précise que celle que ton algorithme est capable de générer ?
Au final, sous quelle forme vas tu représenter le monde au joueur ? Vas tu granulariser ta carte pour l'afficher sous forme de tuiles, comme la plupart des jeux 2d ?
Comptes-tu utiliser des graines différentes pour chaque partie afin de générer des niveaux aléatoires, ou n'est-ce qu'un moyen pour toi d'accélérer et de simplifier le level-design d'un monde unique ?
Merci encore pour ces séries d'articles, c'est toujours très enrichissant, d'autant plus que c'est des sujets qui me tiennent particulièrement à coeur :)
[^] # Re: Des liens à propos de design
Posté par Azrou . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. É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 Azrou . En réponse à la dépêche Je crée mon jeu vidéo E08 : fiche de lecture de «L'Art du game design» par Jesse Schell. É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: Trop gros, passera pas.
Posté par Azrou . En réponse à la dépêche Je crée mon jeu vidéo E02 : le jeu et ses challenges. Évalué à 2.
Autant réussir à tenir des milestone longue pour la partie programmation, c'est faisable avec un peu de méthodologie (modulo la motivation).
Autant c'est une très mauvaise idée de partir sur des milestones longue pour les problèmes de game-design.
Parfois (particulièrement quand on débute en game-design, mais même les meilleurs s'y font prendre…), le gameplay qu'on a prévu pour le jeu ne fonctionne tout simplement pas : pas amusant, pas intuitif, trop compliqué, pas ergonomique, lassant… Tant de choses qui peuvent entraîner une désillusion monumentale par rapport aux objectifs de départ.
Parfois, il suffit d'une retouche par ici, d'une rustine par là et on redresse le cap. Et parfois, c'est l'idée de base du jeu qui n'est pas bonne et les rustines parviendront alors tout juste à en faire un jeu médiocre.
C'est pour ça qu'il est important de prototyper son jeu très tôt, à grand coup de carrés, de cercles et de code crade s'il le faut. Et continuer à pouvoir tester régulièrement toute les améliorations, parce que tant qu'une feature du jeu n'a pas été joué, on a jamais vraiment moyen de savoir si cette feature respectera vraiment son rôle de rendre le jeu plus amusant.
Pour ma part, pour les projets persos, je me fixe des objectifs sur une ou deux semaines maximum. Je note soigneusement mes grands projets d'avenir qui en feront un jeu parfait, mais j'évite d'y réfléchir trop profondément, parce qu'il est de toutes façons absolument certain que le gameplay ne sera pas dans la pratique tel que je l'avais prévu, et que 1 mois plus tard mes prévisions devront être complètement revu pour coller avec ce que le jeu est devenu.
[^] # Re: Et les traits ?
Posté par Azrou . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 3.
D'après moi, le principal avantage se ressent surtout du point de vue du non-programmeur.
Ca permet aux autres corps de métiers du jeu vidéo (level-designer, game-designer, artistes 3d, etc…) de créer très rapidement des entités à leur convenance sans avoir à mettre le nez dans les "trucs de devs", sans avoir à passer par eux, et en utilisant des notions qu'ils comprennent facilement et qui s'intègrent bien à leurs outils.
Dans des projets que je fais en solo, je ne trouve pas très utile de séparer données et comportements, et j'en reviens plus souvent à des modèles de programmation par traits.