Fin 2017, j'ai eu l'occasion de tester ma force et mon enthousiasme en tant que participant à l'un des nombreux Game Jams mondiaux.
Comme c'était ma première expérience dans un tel projet, j'ai appris quelques leçons utiles et quelques surprises agréables. Eh bien, j'ai aussi acheté un jouet que je pourrais jouer avec mes collègues le vendredi des vacances.
Sous le chat, une description de l'intensité de 30 jours de développement et de la lenteur de 20 jours d'attente des résultats.
Remarque: l'article est de nature narrative, avec peu de détails techniques.Prologue
Je voulais depuis longtemps m'essayer en tant que développeur de jeux, et l'année dernière, ce désir est devenu de plus en plus intrusif et intrusif. À la fin de l'année, j'ai décidé de commencer à faire quelque chose - assister à des rencontres sur le développement de jeux, lire des livres et même faire un petit prototype du jeu.
Et puis un jour, Selim, mon collègue, a proposé de participer à l'un des nombreux Game Jam et j'ai pensé que c'était la meilleure occasion d'étudier la cuisine de jeu sans aucune obligation à long terme. Ce n'est pas un prototype, mais pas encore son projet de longue date. De plus, des délais serrés sont souvent parmi les meilleurs motivateurs. Et le principal avantage est que dans tous les cas, le résultat est quelque chose d'holistique et complet, qui inspire toujours de nouvelles réalisations.
Nous avons donc décidé de participer. Deux développeurs Java, sans aucune expérience dans la création de jeux. Mais quand faut-il commencer?
La préparation
Le Game Jam choisi était thématique, et les organisateurs devaient annoncer le sujet strictement avant le début du développement. Les candidats ont eu 1 mois pour créer le jeu.
Nous nous sommes inscrits une semaine avant le début et, faute de sujet, nous avons passé du temps dans l'attente languissante et l'inaction. Peut-être valait-il mieux passer ce temps à choisir un genre et une mécanique de jeu. Et puis enveloppez-le dans un style approprié.
À l'heure X, les organisateurs ont annoncé le thème du concours - Retour (retour) et le compte à rebours a commencé.
Selim avait le seul souhait pour le jeu - la présence d'un serveur de jeu et forcément en temps réel. Il souhaitait connaître les délices et les difficultés du développement côté serveur. De plus, le jeu aurait dû être simple, sinon nous n'aurions peut-être pas le temps de le terminer.
En ce qui concerne le sujet, les réflexions ont d'abord porté soit sur le rétro, soit sur la préhistoire. Le thème rétro ne m'intéresse pas, j'ai donc essayé de trouver quelque chose sur les dinosaures ou les anciens. Cependant, je n'ai pas pu trouver quelque chose de simple et multi-utilisateur sur ce sujet.
Et puis j'ai eu l'idée de faire un jeu de bac à sable, au sens littéral - une référence au divertissement des enfants sur la plage. Nous construisons des châteaux, courons et jetons du sable sur nos rivaux (j'espère que tout le monde n'a pas eu une enfance aussi difficile), mais les parents mécontents sont punis pour cela. Tout cela en 2D avec une vue de dessus.
Selim a estimé que le sable était trop cruel aux yeux et a suggéré de remplacer le sable par de la neige et des châteaux par des forteresses de glace. Sur cette option, nous nous sommes arrêtés. Au mieux de nos capacités et de notre temps, nous pourrions ajouter de nouvelles fonctionnalités et de la variété.
Développement. Semaine 1
Nos rôles dans le projet étaient divisés par eux-mêmes. Comme je l'ai dit, Selim ne s'intéressait qu'au développement de serveurs. Et j'étais intéressé à essayer le développement de l'interface utilisateur, car, à mon avis, il est le plus différent du développement d'applications commerciales. L'interface de jeu était prévue sur le web.
Brève description des technologies utiliséesL'interaction client-serveur a été entièrement construite sur des sockets Web, car nous devions envoyer des messages du serveur au client de manière asynchrone et régulière. Les messages du client ont également été transmis via la prise Web, mais simplement pour la raison «pourquoi pas». Tous les messages étaient au format Json.
Pour travailler avec des sockets Web sur le serveur, le micro-framework Spark a été utilisé. Et comme un moteur physique box2d a été utilisé, comme l'un des plus populaires. Il était responsable du calcul de la physique sur le serveur.
Le client a été écrit en JS pur, sans utiliser de frameworks, car je ne suis pas fort avec eux, et d'ailleurs, cela n'a pas de sens pour un petit projet. En tant que moteur de jeu, Phaser 2 a été utilisé - un moteur JS jeune et prometteur. Contrairement au moteur physique du serveur, son objectif principal était les graphiques et les calculs physiques simples. KnockoutJS a également été utilisé pour
la liaison de données .
Les produits JetBrains ont été utilisés comme IDE: Intellij IDEA et une version d'essai de WebStorm (juste une version de 30 jours, au moment du Game Jam).
Le développement a commencé par une réunion conjointe le jour de congé. Au cours des 2 premières heures, j'ai ramassé des sprites «temporaires» et j'ai réalisé un garçon qui courait et qui savait lancer des boules de neige. Il aurait pu y avoir une image de «c'était / est devenu», mais elle est dépourvue de tout sens - visuellement ce qui était, reste alors.
Ayant une interface utilisateur fonctionnelle, il
ne restait
plus qu'à resserrer l'interaction du serveur. Le reste de la journée a donc été consacré à l'intégration: discussion de l'API, mise en place de la connexion, mise en place de l'interaction. À la fin de la journée, notre petit homme pouvait se déplacer de 1 pixel sur le côté, en appuyant sur une touche. Ce fut modeste, mais toujours réussi.
Le développement s'est poursuivi uniquement pendant le temps libre du travail, avec 6 jours par semaine séparément pour les foyers et un jour de congé ensemble. Cela suffisait largement grâce à une API simple et une distribution rigide des rôles.
Pour répéter le succès de la première journée (courir et lancer des boules de neige), mais déjà via le serveur, cela nous a pris une semaine. Cela a également été affecté par de nombreux facteurs techniques, notamment des problèmes avec des outils mal conçus pour notre modèle d'interaction client-serveur. Je voudrais m'attarder sur ce modèle plus en détail.
Modèle d'interaction client-serveur
Initialement, il a été décidé que le serveur serait responsable de tout mouvement, et le client n'enverrait que des commandes, comme appuyer sur une touche, et dessiner ce qui proviendrait du serveur. Plus tard, cette philosophie a été légèrement modifiée, mais le serveur jusqu'à la fin est resté le lien central.
Dans la première implémentation, le serveur envoyait des mises à jour au client à chaque tick. C'est-à-dire par exemple, si une touche est maintenue enfoncée, la position du joueur change toutes les quelques millisecondes et une nouvelle position est envoyée au client.
En utilisant un algorithme aussi simple, nous avons implémenté le mouvement du joueur. Mais rechercher le meilleur nous a incités à changer l'algorithme en un événement: seuls les événements importants suffisants pour la synchronisation sont envoyés au serveur, ainsi qu'au client.
Par exemple, pour déplacer un joueur sur la carte, vous avez besoin de 4 événements:
- Client : touche haut enfoncée;
- Serveur : le joueur a commencé à se déplacer à partir du point [x, y1 ], selon un angle α, avec la vitesse ν;
- Client : touche haut enfoncée;
- Serveur : le joueur a fini de se déplacer au point [x, y2 ].
Cette approche a des avantages et des inconvénients.
Inconvénients- beaucoup plus de logique sur le client: le client lui-même doit calculer le mouvement, les collisions, etc.
- la logique sur le client doit répéter très précisément la logique sur le serveur, sinon des sauts dans le mouvement des objets sont obtenus. Plus loin dans l'article, il y aura plusieurs exemples à ce sujet;
- en cas de problèmes de réseau, la réception d'événements par la suite peut conduire à des états incorrects (sortir des limites, traverser des objets, etc.);
- en général, il est beaucoup plus facile de désynchroniser l'état sur le serveur et le client.
Avantages- beaucoup moins de charge sur les E / S;
- une logique supplémentaire peut être accrochée aux événements. Par exemple, au début / fin d'un mouvement, vous pouvez démarrer / arrêter l'animation;
- les problèmes de réseau affectent moins la fluidité du mouvement. Pendant que la boule de neige vole, un retard de même une seconde n'affectera rien, car le serveur ne devrait rien envoyer;
- L'API et l'interaction elle-même deviennent plus transparentes.
À partir de ces listes, il est clair que si vous travaillez dur sur la mise en œuvre du client, il y a presque un avantage. Pour notre projet, nous y sommes parvenus et l'interaction client-serveur a parfaitement fonctionné. Mais nous devons rendre hommage, il a fallu beaucoup de force et de nerfs.
Développement. Semaines 2 et 3
Une semaine plus tard, lorsque nous avons réussi à maîtriser l'intégration à tout le moins et à prendre en charge plusieurs types de messages entre le serveur et le client, il était temps d'ajouter plus au jeu qu'un simple garçon en cours d'exécution.
Par conséquent, nous avons décidé d'ajouter une fille qui court! En cours de route, pour la fille, j'ai dû faire une fenêtre de sélection de personnage. Et comme il fallait encore faire la fenêtre, c'est un péché de ne pas ajouter de nom aussi. De plus, j'ai dû étirer les images, comme pour l'
approche à 9 patchs .
Cela ressemblait à la première version de la fenêtre de connexionÀ cause de tout cela, une tâche si simple et si importante d'ajouter une fille a pris quelques soirées, mais cela en valait clairement la peine. Et puis est venu le quotidien gris avec les mêmes tâches: nouvelles fonctions simples, corrections de bugs, améliorations visuelles mineures.
Au fur et à mesure que mes progrès progressaient du côté client, le problème de la vitesse de développement du serveur et de l'interface utilisateur inégaux est apparu. Et puisque le serveur est une partie centrale de toutes les interactions, sans la fonctionnalité terminée et fonctionnelle sur le serveur, le développement client s'est arrêté.
Par conséquent, j'ai implémenté un serveur simulé simple directement dans le client. Beaucoup de choses y ont été mises en œuvre très maladroitement, y compris grâce à l'utilisation de l'état global du monde du jeu. Cela a suffi pour développer une interface utilisateur complètement indépendante du serveur et m'a fait gagner beaucoup de temps.
Le faux serveur avait un autre avantage certain. Il y avait des robots qui ne savaient pas comment tirer, donc il y avait au moins une chance de gagner.
En même temps, Selim a lutté avec le serveur. Sur le serveur, il a connecté le moteur physique box2d pour simuler la physique dans le jeu. Ce moteur a beaucoup de ses nuances et leur étude a pris beaucoup de temps. La plus grande difficulté dans le développement était le manque de visualisation du monde du jeu. Notre client n'a rendu que ce dont il avait besoin. Et certains éléments du "monde des serveurs" étaient cachés du côté client. De plus, il n'y avait aucune garantie complète que le client rendait tout correctement.
L'une des sous-tâches importantes que Selim a dû résoudre était de vérifier les collisions d'objets. Sur le client, les collisions ont été vérifiées uniquement pour les éléments fixes. Sur le serveur, il fallait tout faire honnêtement pour ne pas empiéter sur les droits des objets en mouvement.
Pendant le développement des collisions, je me suis souvenu d'un bug amusant qui pouvait prétendre à une fonctionnalité spéciale: lorsqu'un joueur lançait une boule de neige, elle était renvoyée avec un «rebond». Cela est arrivé parce que dans box2d, par défaut, tout le monde peut entrer en collision avec tout le monde, et la répulsion se produit toujours.
Ce problème a été résolu en introduisant des masques, c'est-à-dire en spécifiant des classes d'objets qui ne peuvent pas entrer en collision. Par exemple, pour un joueur et ses boules de neige, le masque était le même.
Selim a décidé de ne pas perdre de temps sur la gestion spéciale des collisions entre boules de neige et a commenté une telle collision:
// for the unlikely event that we collide with a sibling snowballComme la pratique l'a montré, la fréquence de cet événement "peu probable" tend à la fréquence des lancements de boules de neige, car lorsque vous vous tenez face à face, les trajectoires des boules de neige coïncident. Pour cette raison, les boules de neige extraterrestres battent constamment les leurs. Nos opinions sur ce comportement divergeaient, nous l'avons donc laissé tel quel.
Pendant que Selim s'amusait avec les collisions, j'ai débogué le mouvement synchrone des objets sur le serveur et le client. Il y avait des bugs mineurs dans notre propre implémentation, mais Phaser a présenté la plus grande surprise. Dans son moteur physique, la vitesse réelle des objets est ajustée au FPS et arrête le monde. Ceci est fait pour augmenter la douceur. Malheureusement, ce comportement intelligent n'était pas compatible avec un fonctionnement synchrone par rapport au serveur, et j'ai dû faire ma propre implémentation d'objets en mouvement.
Description des spécificités de la vitesse dans Phaser ou «course avec l'ombre»Afin de vérifier et de déboguer la vitesse, j'ai ajouté l'objet d'un autre joueur à la carte, qui se déplaçait à la même vitesse, mais à proximité. Ce joueur fantôme et ce joueur normal utilisaient différents algorithmes de déplacement. J'ai donc organisé des compétitions et comparé la stabilité de la vitesse.
Au début, j'ai essayé de résoudre le problème de la vitesse inégale en utilisant les paramètres du moteur et la physique que nous utilisons. Mais, si je comprends bien, ce comportement ne peut être modifié en aucune façon. Il était possible de passer à une implémentation plus complexe de la physique, mais je ne voulais pas le faire uniquement pour la vitesse. De plus, cette implémentation n'a pas non plus donné une vitesse absolument stable.
L'étape suivante, j'ai essayé de mettre en œuvre le mouvement des objets moi-même, mais à partir du moteur, j'ai pris le contrôle et le delta de temps entre chaque cycle du monde. Il existe plusieurs modèles temporels dans Phaser et l'implémentation de la vitesse standard est basée sur l'un d'eux. Mais, pour une raison inconnue, aucun de ces moments n'a de stabilité et ils ne peuvent pas fournir une vitesse constante. Il s'agit d'un problème connu qui ne devrait pas être résolu dans la version 2:
github.com/photonstorm/phaser/issues/798 .
J'ai passé 2 jours sur la «compétition» du joueur et de l'ombre et n'ai pas trouvé d'option de travail. Donc à la fin, j'ai fait tout mon traitement de vitesse basé sur le temps standard dans JS. Il est très surprenant qu'une fonction aussi importante ait reçu un support aussi étrange dans le moteur et ait dû mettre en œuvre son propre vélo.
Avec de telles blagues et blagues, nous avons tranquillement passé les deuxième et troisième semaines. De plus, chaque semaine commençait par la phrase "eh bien, la semaine prochaine, nous sommes obligés de préparer une version jouable" - chaque fois il nous semblait que nous étions sur le point d'être prêts. Le manque total d'expérience et la présence d'un formidable optimisme sont la pire façon d'évaluer le calendrier.
Une semaine avant la livraison, lors de la réunion des développeurs, nous n'avons même pas pu montrer la version normale et avons dû montrer le faux serveur.
Bien sûr, avec une telle vitesse de développement, il n'y avait rien à rêver sur une liste de fonctionnalités initialement conçue, et encore plus sur le plaisir d'avoir des choses. Par conséquent, nous avons dû oublier le "bac à sable" et nous arrêter au tireur 2D le plus simple.
Développement. Semaine 4, dernière
Au cours de la dernière semaine de développement, nous nous sommes concentrés sur la correction des bogues. Il vaut mieux avoir quelque chose de modeste et de fonctionnel que multifonctionnel, mais en ruine. Les problèmes étaient nombreux et la plupart concernaient l'intégration malheureuse. Ici et là, des défauts mineurs sont apparus, aggravant considérablement l'impression du jeu.
En plus de corriger les bugs, j'ai également apporté le brillant final à l'interface utilisateur: ajouter de la musique et des sons, jouer avec les polices et améliorer les petits détails.
De toutes les fonctionnalités, cette semaine, seul le système de points a été ajouté, ainsi que la limitation du stock de boules de neige et leur restauration.
Le dernier jour de Game Jam, nous avons pu jouer un peu avec des collègues. Malgré les critiques positives générales, cette session de jeu a échoué en raison d'un bug critique - les boules de neige ont volé sur le serveur et sur le client à différentes vitesses. Pour cette raison, entrer dans d'autres joueurs était plus susceptible d'être un accident.
Description de la cause et correction de l'erreurNous avons fait ce bogue au dernier moment, réduisant le nombre de FPS sur le serveur de 1000 expérimental à 100.
Il convient de noter que jusqu'à présent, nous ne pouvions pas réaliser un mouvement entièrement synchrone sur le client et le serveur - il y avait parfois des sauts de mouvement. En modifiant FPS, nous avons essayé d'augmenter la réactivité du serveur.
Quand j'ai commencé à rechercher ce bug, j'ai découvert 2 modèles:
- le mouvement du joueur a fonctionné correctement et de manière stable;
- le mouvement de boule de neige sur le client était toujours plus rapide que sur le serveur.
La valeur de la vitesse des objets revient au client à partir du serveur, c'est-à-dire qu'il ne peut pas s'agir d'une asymétrie banale de valeurs. De plus, une augmentation inverse du FPS à 1000 a amélioré la situation.
J'ai passé beaucoup de temps à essayer de corriger cette erreur. Mais rien n'y fait. Et à la fin, la raison a été trouvée en utilisant googling - box2d limite indirectement la vitesse maximale en déplaçant l'objet de pas plus de 2 pixels en une seule étape du monde. C'est-à-dire à 100 FPS, la vitesse maximale est de 200 pixels / s (p / s) et à 1000 FPS - 2000 p / s. Cette valeur est spécifiée dans une constante et ne peut pas être modifiée dynamiquement. Cela expliquait pleinement la raison du ralentissement de nos boules de neige, car leur vitesse aurait dû être de 700 p / s, ce qui nécessitait un FPS stable au-dessus de 350.
Pour résoudre ce problème, j'ai augmenté le FPS à 500, mais pour une raison. Dans box2d, vous devez passer à la fonction step du monde combien de temps s'est écoulé depuis l'étape précédente. Avant mon changement, nous avons toujours calculé cette différence avant d'appeler la fonction. Mais maintenant, connaissant la fréquence souhaitée, il était toujours possible d'indiquer un delta constant de 2 ms. Le monde étant à la traîne du réel, les étapes devaient être répétées les unes après les autres, jusqu'à ce que le temps du monde rattrape le décalage. Puis un peu de sommeil et tout est nouveau.
Cette correction, comme prévu, a résolu le problème de vitesse de boule de neige. De plus, le problème des mouvements non synchrones sur le serveur et le client a finalement disparu. À cette époque, cette guérison miraculeuse était une surprise complète pour nous, mais maintenant j'ai compris la raison: malgré le maximum de 1000 FPS, personne n'a annulé la lenteur du serveur, et surtout la collecte des ordures. C'est-à-dire à certains moments, le FPS pouvait tomber librement en dessous des 350 FPS requis, ce qui entraînait des sauts de vitesse arbitraires.
Donc, heureux d'un bug fermé et d'un jouet fonctionnel, 2 heures avant la date limite, nous étions prêts à nous rendre. Il ne restait plus qu'à envoyer le jeu sur le site du projet.
Je m'attendais à ce que la sortie du jeu se passe en douceur et en vain. Il était nécessaire de créer une page de projet, de faire une description, de télécharger des captures d'écran et bien plus encore. Nous nous sommes rencontrés, comme prévu, de bout en bout. Bien que plus tard, les organisateurs ont toujours accepté individuellement les projets tardifs.
Capture d'écran de la version finale du jeuVote
Selon les termes du concours, immédiatement après l'achèvement du développement, un vote de 20 jours a été ouvert. Pendant cette période, tout le monde a pu voir les projets achevés, dont plus de 200 ont été accumulés. Seuls les participants ont été autorisés à voter pour les projets. Chaque jeu peut être classé dans les catégories suivantes: général, graphisme, son, gameplay, caractère innovant et pertinence par rapport au thème.
La phase de vote nous a préparé une mauvaise surprise liée à la nature multijoueur de notre jeu. Il y avait relativement peu de gens qui regardaient les matchs et la chance de rencontrer l'ennemi tendait à zéro. C'est-à-dire les gens sont allés chercher une carte vide, ont lancé quelques boules de neige, ont couru sur quelques mètres et sont repartis déçus.
Nous avons essayé d'organiser des sessions de jeu via le forum du projet. De plus, Selim et moi sommes entrés périodiquement dans le jeu, espérant divertir un vagabond solitaire et ennuyé. Tout cela n'a donné presque aucun résultat.
J'étais intéressé de voir des gens tester le jeu. Je me souviens surtout du cas où un joueur a entré plusieurs caractères en même temps et construit un pentagramme de garçons. Je ne sais pas ce que l'auteur voulait dire, mais j'ai toujours une capture d'écran du processus de sa création.
Un autre joueur a «piraté» notre jeu. Nous avons une vérification de la longueur du nom, mais uniquement du côté client. En conséquence, il a contourné cette défense et a commencé à correspondre avec moi de cette façon, en entrant chaque fois un nouveau caractère et en entrant sa phrase au nom d'un homme.
Parallèlement au vote, mes collègues et moi avons joué à nouveau, se vengeant du match infructueux le jour de la fin du projet. Cette fois, tout s'est très bien passé et nous avons eu un certain nombre d'idées pour de nouvelles fonctions, qu'il était cependant trop tard pour ajouter.
À mon avis, la qualité du jeu, notamment en ce qui concerne l'interaction avec le serveur, s'est révélée à un très bon niveau. Combien de fois nous l'avons joué, nous n'avons remarqué aucun problème et nous ne les avons pas entendus des autres joueurs. Pour moi personnellement, ce fut une surprise, compte tenu de la qualité et du nombre d'erreurs quelques jours avant la livraison.
Les 20 jours accordés à l'évaluation des jeux ont duré très longtemps, mais finalement ils se sont terminés et le temps tant attendu des résultats est venu.
Ainsi, nous avons pris la 36e place sur un peu plus de 200 participants. Ce qui, d'une part, n'est pas mauvais pour le premier projet, mais d'autre part, c'est un peu désagréable pour la fierté. Surtout si l'on considère que le top 10 a obtenu de bons matchs, mais tous ne méritaient pas une attention particulière.
Leçons apprises
Pour obtenir des leçons dans des conditions de semi-serre, tout a commencé. Nous avons essayé d'inventer beaucoup de choses nous-mêmes et nous sommes limités à un ensemble minimal d'outils afin de ressentir les problèmes et de faire l'expérience de mauvaises approches dans notre propre peau. Mais maintenant, sachant comment le faire et pourquoi, étudier la théorie sera plus facile.
Le besoin d'un artiste . Comme l'a montré la pratique (pas seulement la nôtre), vous pouvez faire un bon jeu sans de bons graphismes. Cependant, la sélection des bonnes images, polices et éléments d'interface utilisateur prend la plupart du temps. Et le pire, c'est qu'en fin de compte ils ne coïncident pas. De là, l'atmosphère du tube chaud est perdue et le jeu ne semble pas holistique.
Les tests de jeu sont très importants . En raison de problèmes de vitesse de développement, nous n'avons pas pu tester la jouabilité de notre implémentation la plupart du temps. Lorsque nous avons pu jouer normalement, nous avions trop peu de temps pour résoudre les problèmes. Et nous avons eu beaucoup de chance qu'il n'y ait pas eu autant de problèmes de ce genre.
À mon avis, pour les jeux, de tels tests sur des utilisateurs réels sont beaucoup plus importants que pour les applications commerciales, car en plus de la commodité et de la résolution des problèmes des utilisateurs, il est toujours nécessaire de maintenir un certain niveau d'émotions et d'implication.
Toutes les bibliothèques ne sont pas également utiles . Presque personne ne développe de jeux sur leur propre moteur et il existe des moteurs sur le marché pour toutes les occasions. Dans la cour était 2017, et on s'attendrait à leur haute qualité. J'ai choisi Phaser comme l'un des moteurs JS les plus recommandés et les plus jeunes. Après tous les problèmes que nous avons rencontrés avec lui, j'ai peur d'imaginer à quel point les moteurs semblent pires. Non, en général, les impressions de travailler avec Phaser sont plutôt positives, surtout compte tenu de la bonne documentation et des exemples. Mais travailler avec lui sans connaître un grand nombre de nuances est très difficile. Au printemps, une nouvelle version sort et j'espère une amélioration significative. Et aussi dans mes plans est un mini-projet sur un autre moteur à comparer.
Et je me souviendrai longtemps de ce problème de vitesse maximale dans box2d.
Dans le processus de Game Jam, il est tout à fait possible d'apprendre . Au démarrage de ce projet, nous ne savions presque rien du développement des jeux, ni des bibliothèques que nous utilisions. Et la plupart du temps était consacré à l'étude de ces choses. Malgré cela, nous avons quand même réussi à amener le jeu dans un état complet.
Pas beaucoup de fonctionnalités requises . Je suis un peu surpris que beaucoup de gens aient aimé notre jeu. Oui, ils ne s'y assoient pas tous les soirs, mais profitent d'une ou deux petites séances. Mais dans notre jeu, il n'y a ni idée originale, ni grande quantité de fonctionnalités, ni histoire. La même chose peut être dite de la plupart des jeux de Game Jam qui ont reçu des notes positives.
(Jeu) Jam est une excellente raison d'essayer . Peu importe quoi: une idée, une nouvelle bibliothèque, vos propres forces. Lorsqu'il y a un objectif clair et que d'autres devraient voir votre résultat, c'est très motivant de ne pas devenir mou et de donner le meilleur. Et même si le résultat est pire que prévu, il ne sera pas dommage de le jeter, de tirer des leçons par vous-même et d'aller de l'avant!
Liens vers les ressources:
Merci à tous pour votre temps et votre bonne humeur!