Journal Webcrise: ébauche d'architecture

Posté par  (site web personnel) . Licence CC By‑SA.
18
17
août
2012

Bonjour Nal,

Je continue mon travail de préparation d'un futur projet de jeu libre, Webcrise, que je décrivais il y a peu dans le journal suivant: https://linuxfr.org/users/devnewton/journaux/webcrise-appel-a-contribution

Au lieu de me lancer, comme trop souvent, dans le code tout de suite, j'ai décider de faire un peu de modélisation. J'envisage aussi de faire une maquette de la gui, mais chaque chose en son temps.

J'ai réalisé deux diagrammes, un de classe et un autre de séquence, pour avoir une vue d'ensemble du système.

J'ai essayé d'avoir une architecture flexible afin de pouvoir gérer des cas peu évidents dans un jeu de stratégie temps réel:

  • les unités qui peuvent changer de rôle: un pompier brûlé devient une victime à sauver.
  • l'état du terrain peut évoluer, une zone peut être brûlée ou inondée, un pont peut être construit pour traverser une rivière…
  • certaines unités ne sont pas présentes physiquement sur le terrain: un témoin qui signale une émeute par exemple.
  • chaque joueur doit avoir une représentation différente de la situation: si la police découvre une victime, les pompiers ne sont pas automatiquement au courant.

Cet exercice de modélisation m'a aussi permis de déterminer deux choses importantes:

  • le jeu sera en temps long, cad sur une journée ou une semaine. Le joueur pourra suivre l'évolution de la crise régulièrement, mais comme un préfet ou un gradé dans un poste de commandement, cad recevoir des alertes et faire des points réguliers, puis prendre des décisions de haut niveau.
  • le terrain sera un ensemble de case (tiling) pour simplifier. Une seule unité pourra occuper une case.

J'ai également repéré deux frameworks intéressants, même si je n'ai fait aucun choix définitifs: vert.x côté serveur et melonjs côté client.

Comme éditeur de niveau, je pense utiliser Tiled, auquel je contribue déjà dans le cadre de la refonte graphique de Newton Adventure.

Diagramme de classe

Diagramme de séquence

Plus de news, dès que possible!

  • # Oubli

    Posté par  (site web personnel) . Évalué à 1.

    J'ai oublié la traditionnelle nimage. J'espère qu'elle contentera tout le monde.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Détail linguistique

    Posté par  . Évalué à 3.

    En lieu et place d'Ambulance, préfère le terme EMT pour Emergency medical technician: c'est ce qui désigne notre équivalent français des équipes de secours d'urgences.

  • # quelque idée gratuite et libre ?

    Posté par  . Évalué à 0.

    les unités qui peuvent changer de rôle: un pompier brûlé devient une victime à sauver.

    a sauver en priorité, pour que l équipe puis réutiliser sont matérielle ;)

    un pont peut être construit pour traverser une rivière…

    les militaires on bien ce qu il faut pour réaliser ca ne les oublie pas ;)

    un témoin qui signale une émeute par exemple.

    une grand mère ca peut être cocasse ;)

    Merci aux personnes qui mon aidé a trouvé des solutions pour essayer d’écrire sans faute d’orthographe.

  • # Temps long

    Posté par  (site web personnel) . Évalué à 1.

    Quand tu dis que

    le jeu sera en temps long, cad sur une journée ou une semaine.

    Tu fais référence au temps IRL ou dans le jeu ?

    • [^] # Re: Temps long

      Posté par  (site web personnel) . Évalué à 3.

      Les deux!

      Par défaut temps IRL = temps dans le jeu, mais on pourra accélérer ou mettre en pause un scénario, voire planifier son déroulement (tous les soirs de 20 à 22h par exemple).

      Ce temps long réponds à plusieurs impératifs:

      • une stratégie de haut niveau, par opposition au micro-management.
      • la volonté de trouver un compromis entre les RTS classiques où tout va trop vite et les jeux au tour par tour où on s'endort pendant que les autres joueurs réfléchissent.
      • l'autohébergement d'une instance sur mon petit serveur :-)

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Temps long

        Posté par  (site web personnel) . Évalué à 2.

        on pourra accélérer ou mettre en pause un scénario, voire planifier son déroulement (tous les soirs de 20 à 22h par exemple).

        D'accord, donc pas de contrainte en terme d'horaires de connexion (comme c'est malheureusement souvent le cas dans les jeux par navigateur) pour les joueurs. Je ne peux qu'approuver joyeusement cette approche.

      • [^] # Re: Temps long

        Posté par  (site web personnel) . Évalué à 3.

        Dans un RTS classique, il manque en général des ordres de très haut niveau pour gérer ses unités. En général, cela se limite à va ici et attaque cette unité. "total anniliation" proposait des ordres plus sympa comme des défenses de zones avec poursuites ou non des unités adverses.

        "La première sécurité est la liberté"

        • [^] # Re: Temps long

          Posté par  (site web personnel) . Évalué à 2.

          Ca me fait penser qu'il me faudra trouver une techno d'IA pour implémenter des missions complexes…

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Temps long

            Posté par  (site web personnel) . Évalué à 2.

            Tu devrais surtout penser à des actions types du joueur pour définir ce qui est réellement intéressant et pas seulement le coté simulation. Dans le temps vrai, il y a des actions tellement longue que cela peut être chiant (cf les simulateurs d'avion) ou trop courte pour gérer la masse de chose à faire.

            Pour un RTS, j'aurais aimer avoir une notion de "plan d'attaque" où tu définis des point clefs à chaque unités qui doivent aller à ces points ayant le même numéro avant de passer au suivant, c'est plus facile de coordonner les attaques. Ensuite, il suffit de "déclencher les plans" pour que les unités l’exécutent.

            "La première sécurité est la liberté"

            • [^] # Re: Temps long

              Posté par  (site web personnel) . Évalué à 2.

              Dans certains scénarios que j'envisage, la crise ne se déclenche pas tout de suite et fait l'objet de prévisions: zones sismiques, quartiers avec des maisons non ignifugés…

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

        • [^] # Re: Temps long

          Posté par  . Évalué à 3.

          "total anniliation" proposait des ordres plus sympa comme des défenses de zones avec poursuites ou non des unités adverses.

          J'ai joué à un jeu qui proposait ça (Age of Empire II, iirc), au final, c'était plutôt inutile parce que l'ennemi attaquait en plus grand nombre et que les unités autour ne rappliquaient par défendre l'unité attaquée tant que ce n'était pas dans leur périmètre, même si elles étaient juste à côté.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Temps long

            Posté par  (site web personnel) . Évalué à 2.

            Il fallait définir une zone plus grande. C'est vrai que dans TA j'utilisais surtout le mode "tir à vue" sans déplacement. Car en cas de déplacement, l'unité se mettait à porter de tir de beaucoup d'unité adverse et était rapidement détruite.

            "La première sécurité est la liberté"

            • [^] # Re: Temps long

              Posté par  . Évalué à 3.

              On ne pouvait pas définir de zone dans le jeu dont je parle. Mais je pense qu'un système avec une garnison et des guetteurs aurait été beaucoup plus utile.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Temps long

                Posté par  (site web personnel) . Évalué à 2.

                Pour avoir un jeu militaire où la tactique et la planification prime, il faut aussi qu'il prenne en compte un grand nombre de facteur (surprise, moral, angle de tir, approvisionnement…). Sinon autant bourriner!

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                • [^] # Re: Temps long

                  Posté par  . Évalué à 3.

                  Oui, mais c'est tout de suite plus compliqué, je parle d'un jeu qui tournait sur un Pentium 150Mhz.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Temps long

          Posté par  . Évalué à 2.

          Ce qu'il me manque souvent c'est des macro-commandes. Il y en avait un peu dans TA et un peu dans SupCom mais à mon avis on est loin du potentiel que ça pourrait avoir. On peut définir des « escouades » avec n infanteries et m fantassins, mais pas de possibilité de définir leur ordre de marche ni de jouer sur les priorités de cibles pour chacune. Certains jeux permettaient de choisir entre plusieurs formes de déplacement (en ligne, en carré, etc), c'est déjà bien.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Temps long

            Posté par  (site web personnel) . Évalué à 2.

            Le pire étant la formation genre gros char devant, lance-missile derrière qui tire loin mais sont fragiles. En formation, il roule au moins à la même vitesse, sinon les chars se font dépassé et les camions sont détruit. Au premier obstacle ou rétrécissement(pont), les chars s'engagent et le superbe algo A* (à la con) décide de faire faire le tour aux camions de derrière. Et paf, le camion.

            Le joueur qui gagne est donc celui qui clic le plus vite.

            "La première sécurité est la liberté"

            • [^] # Re: Temps long

              Posté par  . Évalué à 2.

              Le joueur qui gagne est donc celui qui clic le plus vite.

              Je ne sais pas si tu le dis en connaissance de cause mais les joueurs qui font de la compétition parle d'Action par minute et oui avoir des macro sophistiquées ça contrecarre cela :)

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Temps long

                Posté par  (site web personnel) . Évalué à 3.

                oui, je le sais bien et cela me gonfle :)

                J'imagine un rts style pierre/papier/ciseau (hélicoptère/char/infanterie) avec juste une notion d'amélioration de chacun des éléments quand il s'affronte entre eux et une grosse pris en compte de la map : ralentissement dans la terre pour garder le coté stratégique des routes, augmentation de la porté et de la vision sur les points haut, effet de la météo sur la vitesse de déplacement, difficulté pour déterminer le coté ami/ennemi des troupes (tir fratricide qui est un vrai problème irl), changer aussi la vision avec la nuit (genre alternance toutes les 5 minutes pendant le jeu). On pourrait ainsi réellement tirer parti du terrain. Il manque aussi la gestion des lignes de ravitaillement.

                J'imagine bien le thème comme l'affrontement de compagnie pétrolière pour le contrôle de champ pétrolier, avec des objectifs de livraison à la maison mère qui engendre des hausses de budget et donc des livraisons de matériels militaires. Cela permet de remplacer les Fremen par des vrais civiles :)

                "La première sécurité est la liberté"

                • [^] # Re: Temps long

                  Posté par  . Évalué à 3.

                  J'ai joué à un jeu comme ça (conquest earth) ou pendant un combat, on pouvait miner des ressource pour avoir des crédits pour le prochain combats.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: Temps long

                  Posté par  (site web personnel) . Évalué à 2.

                  Tu peux trouver des jeux aussi détaillés, mais au tour par tour.

                  En temps réel, je pense qu'il faut se le coder :-)

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

          • [^] # Re: Temps long

            Posté par  (site web personnel) . Évalué à 2.

            C'est un aspect qui est encore flou dans ma tête: quel sera exactement le rôle des joueurs et les interactions possibles?

            Si c'est trop haut niveau, l'IA jouera toute seule, si c'est trop bas, le joueur va être perdu…

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Temps long

              Posté par  (site web personnel) . Évalué à 1.

              "C'est un aspect qui est encore flou dans ma tête: quel sera exactement le rôle des joueurs et les interactions possibles?"

              C'est pourtant le plus important, le gameplay.

              "La première sécurité est la liberté"

              • [^] # Re: Temps long

                Posté par  (site web personnel) . Évalué à 2.

                J'ai eu le même problème avec Newton Adventure: pour savoir ce que donnerait mes idées, il a fallu écrire un prototype avec 90% du code final.

                Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

            • [^] # Re: Temps long

              Posté par  . Évalué à 4.

              Un truc que j'avais bien aimé dans un dont je ne me souviens plus, c'était qu'il était possible de faire les deux en même temps: tu peux soit tout prévoir, soit tout contrôler soit tu prévois pour une partie (ou pour la totalité) et tu peux reprendre la main sur les unités que tu veux soit parce que tu le veux, soit parce que ton plan ne se déroule pas sans accroc.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # [HS] Diagramme de séquence

    Posté par  . Évalué à 4.

    J'aimerais savoir si ce diagramme est utile pour certaines personnes. Personnellement, il me semble assez évident et je ne vois pas bien l'intérêt de ce diagramme. Je ne cherche pas à dénigrer, uniquement à comprendre s'il n'y a que moi qui trouve ce diagramme inutile dans la plupart des cas où je le vois utilisé.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: [HS] Diagramme de séquence

      Posté par  (site web personnel) . Évalué à 8.

      Pour moi, c'est la construction du diagramme qui est utile plus que sa consultation, car elle oblige à mettre ses idées en forme.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: [HS] Diagramme de séquence

      Posté par  . Évalué à 1.

      Hum, ta question est-elle "est-ce que tout le monde trouve que UML c'est de la merde", ou est-elle vraiment innocente ? Ca vaudrait le coup d'un autre journal pour répondre à ça. Ca sent la digression (et le troll) à plein nez.

      Bon, un élément quand même : moi, du texte ou un diagramme UML, ça me donne exactement la même info. Mais parfois, la vision graphique donne une vision d'ensemble en plus.

      Après, ça n'empêche pas UML d'être de la merde.

      • [^] # Re: [HS] Diagramme de séquence

        Posté par  . Évalué à 3.

        Non, je parle spécifiquement du diagramme de séquence. Je trouve un diagramme des classes ou des cas d'utilisation relativement utile par exemple.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: [HS] Diagramme de séquence

          Posté par  . Évalué à 2.

          Ah. Dommage, j'aurais bien aimé troller là dessus.

          Ben en l'occurrence, je trouve que là on a une illustration d'un bon usage. Ca aide bien à comprendre comment est initiée une partie, on voit les intervenants, la séquence, les méthodes, etc.

          Dans ce cas, je dirais que je trouve ça plutôt utile, et vraiment enrichissant par rapport à un texte qui aurait été lourd et long - et donc chiant.

        • [^] # Re: [HS] Diagramme de séquence

          Posté par  . Évalué à 2. Dernière modification le 17 août 2012 à 15:34.

          Au contraire, moi je trouve qu'un diagramme de séquence est bien plus utile qu'un diagramme de classe, puisque sur un diagramme de séquence, on ne préjuge pas forcement la manière dont les messages/événements sont échangés, ni quelle est la nature des acteurs. Ça peut être des classes, des nœuds sur un réseau, des services sur une même machine … donc on peut représenter plein de choses avec.

          Alors qu'un diagramme de classe présuppose que l'on utilise principalement de l'orienté objet, du coup si tu en fait pas ou que ça y ressemble de loin (du genre C avec vtable à la main, policy based design ou collection de petit composants), cela fait un diagramme de classe peu-compréhensible ou peu représentatif… du coup l'utilité d'un diagramme de classe est plus restreinte.

          Il y a certes d'autres diagrammes plus adaptés, mais ils sont beaucoup moins connus, et donc moins compris.

          • [^] # Re: [HS] Diagramme de séquence

            Posté par  . Évalué à 3.

            Alors qu'un diagramme de classe présuppose que l'on utilise principalement de l'orienté objet, du coup si tu en fait pas ou que ça y ressemble de loin

            Et si tu fais de la danse classique, ça n'aide pas du tout. Je parle évidemment de l'utiliser dans le cadre du développement objet.

            Ce que je reproche au diagramme de séquence (sauf cas particulier) , c'est qu'il est soit trop général et donc peu utile soit trop détaillé et il faudra diverger pendant l'implémentation ou il est bien fait et on aurait pu coder pendant ce temps et le programme serait déjà fini (je ne dis pas qu'il ne faut pas réfléchir avant de coder mais on peut faire un brouillon vite fait sans formaliser ça en diagramme de séquence).

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: [HS] Diagramme de séquence

              Posté par  . Évalué à 2.

              Ce que je reproche au diagramme de séquence (sauf cas particulier) , c'est qu'il est soit trop général et donc peu utile soit trop détaillé et il faudra diverger pendant l'implémentation ou il est bien fait et on aurait pu coder pendant ce temps et le programme serait déjà fini.

              Ça c'est un reproche que l'on peut faire à UML en général, ce n'est pas spécifique à un diagramme particulier. Surtout pour le diagramme de classe : on pourrai l'écrire en code avec des classes presque vides que l'on serait aussi rapide (sauf en Java, mais bien fait pour sa gueule).

              Alors qu'un diagramme de séquence pour représenter des messages qui circulent sur un réseau entre des hôtes, cela va prendre bien plus de temps à implémenter qu'a dessiner des diagrammes détaillés complets, et ça va aider à déterminer à définir quels type de messages doivent être utilisés.

              • [^] # Re: [HS] Diagramme de séquence

                Posté par  . Évalué à 3.

                a c'est un reproche que l'on peut faire à UML en général, ce n'est pas spécifique à un diagramme particulier.

                Bien sûr et surtout, ça dépend des gens. C'est pour ça que je demandais aux utilisateurs ici présent leur avis.

                Surtout pour le diagramme de classe : on pourrai l'écrire en code avec des classes presque vides que l'on serait aussi rapide

                Mais on voit moins bien les liens entre les classes (c'est surtout pour ça que j'aime avoir un diagramme des classes), ce qui est toujours utile même en cours de développement.

                (sauf en Java, mais bien fait pour sa gueule).

                Justement, c'est très facile et rapide à faire en Java.

                Alors qu'un diagramme de séquence pour représenter des messages qui circulent sur un réseau entre des hôtes, cela va prendre bien plus de temps à implémenter qu'a dessiner des diagrammes détaillés complets, et ça va aider à déterminer à définir quels type de messages doivent être utilisés.

                Tu décris un détournement du diagramme de séquence qui ne se fait normalement qu'entre des objets.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: [HS] Diagramme de séquence

                  Posté par  . Évalué à 2.

                  Mais on voit moins bien les liens entre les classes (c'est surtout pour ça que j'aime avoir un diagramme des classes), ce qui est toujours utile même en cours de développement.

                  Ça peut se générer à partir du code source, tout les bons outils de documentations te génèrent des diagrammes de classes.

                  Tu décris un détournement du diagramme de séquence qui ne se fait normalement qu'entre des objets.

                  J'ai du mal à voir en quoi c'est un détournement, surtout quand on considère qu'UML définit des messages asynchrones, des messages avec accusé de réception de durée limitée ou pouvant être mis dans une file d'attente … le genre de chose qu'on fait pas simplement entre des objets.

                  Et puis bon, il suffit juste de remplacer l'hôte par l'objet qui tourne sur l'hôte et on en parle plus.

                  • [^] # Re: [HS] Diagramme de séquence

                    Posté par  . Évalué à 3.

                    Ça peut se générer à partir du code source, tout les bons outils de documentations te génèrent des diagrammes de classes.

                    Je ne vois pas ce que je dis qui laissait penser le contraire.

                    J'ai du mal à voir en quoi c'est un détournement

                    Je n'ai pas dit que c'était un grand détournement.

                    surtout quand on considère qu'UML définit des messages asynchrones, des messages avec accusé de réception de durée limitée ou pouvant être mis dans une file d'attente … le genre de chose qu'on fait pas simplement entre des objets.

                    Je ne vois pas ce qu'il y a de compliquer à le faire entre des objets. Ce n'est pas trivial mais pas bien compliqué non plus et il y a beaucoup d'outils pour faire ça.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: [HS] Diagramme de séquence

              Posté par  . Évalué à 1.

              Le danger avec cette approche c'est que tu te retrouves vite à ne plus faire de documentation.

              La doc, les specs, ce n'est pas uniquement pour préparer l'étape développement, c'est aussi pour communiquer. Avec les utilisateurs, et valider ce que tu vas faire. Avec tes pairs, pour discuter/valider tes choix. Avec les autres développeurs, qui feront le support/la maintenance. Etc.

              Alors évidemment, il y a l'approche "j'ai mis plein de commentaires, les variables et noms des méthodes sont explicites, pas besoin de doc", mais sur des projets complexes impliquant plein de règles "métier", ça ne marche pratiquement jamais.

              D'ailleurs, c'est pour ça que j'aime pas UML, qui était pensé au début pour pouvoir communiquer avec les utilisateurs, mais qui est illisible pour qui n'est pas dans l'informatique et déjà un peu versé en UML.

              • [^] # Re: [HS] Diagramme de séquence

                Posté par  . Évalué à 3.

                Je trouve qu'un diagramme de séquence complexe est illisible (dès qu'il y a quelques boucles ou option), je préfère un schéma différent accompagné de beaucoup de texte et s'il n'est pas complexe, c'est qu'une documentation textuelle est aussi utile.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: [HS] Diagramme de séquence

                  Posté par  . Évalué à 1.

                  Alors je te rejoins totalement ; on néglige souvent la valeur d'une explication textuelle "classique".

  • # img.linuxfr.org

    Posté par  (site web personnel) . Évalué à 1.

    Si vous accédez à linuxfr en https, les diagrammes ne seront visibles que si vous acceptez le certificat de img.linuxfr.org…

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: img.linuxfr.org

      Posté par  (site web personnel) . Évalué à 1.

      Et si comme Adonaïe vous ne savez pas comment afficher une image à sa taille originale, utilisez un clic droit puis "Afficher l'image" dans Firefox ou la commande équivalente dans votre navigateur web.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: img.linuxfr.org

      Posté par  (site web personnel) . Évalué à 2.

      Ou si vous faites confiance au certificat de l'autorité CAcert.

  • # Ne pas se compliquer la vie!

    Posté par  . Évalué à 5.

    Bonjour,

    Tout d'abord, le thème de ce jeu me semble très intéressant, et je vais suivre son développement avec intérêt.

    Mais cela me fait réagir :
    * les unités qui peuvent changer de rôle: un pompier brûlé devient une victime à sauver.

    Il me semble que c'est un peu se compliquer d'emblée la réalisation pour pas grand-chose. En effet, c'est pousser vraiment loin la modélisation, et il me semble que cela ne vaut pas le coup par rapport à ce qu'en tirera le joueur (à mon avis, pas grand-chose), et aux difficultés de réalisations que cela va ajouter. Il me semble de plus qu'il y a bien assez de boulot, sans cette fonctionnalité.

    Pour appuyer mes propos, des exemples ;
    dans Theme Hospital, les médecins ne tombent pas malades (et pourtant c'est un problème dans la vraie vie)
    dans Settlers, les personnages ne changent pas d'affectation
    Et pourtant, ces jeux de simulation sont très amusants, et déjà bien complexes.
    (Bon, ma culture de jeux vidéos est très faible, et je joue peu ces dernières années, donc ce sont des exemples de vieux jeux propriétaires)

    A contrario, diviser le terrain en cases me semble assez évident comme simplification pour ce type de jeu.

    Sinon, concernant ton diagramme, j'ai du mal à comprendre ce que représentent les classes :
    Entity
    Feature
    UpdatableFeature
    Mission
    Pourrais-tu en dire un peu plus?

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Ne pas se compliquer la vie!

      Posté par  (site web personnel) . Évalué à 2.

      Je vais commencer par la fin et expliquer les différentes classes:

      Entity représente un élément de la simulation, ça peut être une case du terrain, un camion de pompier, un pont, une victime…

      Une entité est définit par un ensemble de Feature, qui sont ses propriétés ou ses compétences. Par exemple, les êtres humains ont tous une feature Health, un pompier à la feature ExtinguishFire, un feu ou une explosion peut blesser un humain grâce à sa feature Wound…

      Certaines features qui peuvent avoir une action dans le temps implémentent Updatable que la simulation appellera à chaque tick (pas de temps). Par exemple une maladie infligera des dégâts de plus en plus importants à ses victimes au cours du temps.

      Mission est simplement la spécification d'une mission que le joueur peut affecter à une unité (chercher des victimes dans une zone, éteindre un feu à tel endroit…).

      Pour le changement de rôle en cours de jeu, il suffit d'ajouter ou de retirer certaines features à une unité.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # graphisme

    Posté par  (site web personnel) . Évalué à 2.

    Pour ce genre de jeu, il ne serait pas plus joli et moins couteux en temps, de générer une carte en 3D plutôt que d'utiliser des tiles ou des modèles tout fait ?

    L'avantage des modèles générés est le coté carré et répétitif qui disparait, ainsi que la variété du graphisme. Il est sans doute possible de trouver un modèle de 3D généré qui est aussi modulaire que ce que fait Minecraft, non ? (en plus, cela serait plus facile de coder les tremblement de terre, ras de marré, tsunami et autre dévastation de la nature)

    "La première sécurité est la liberté"

    • [^] # Re: graphisme

      Posté par  (site web personnel) . Évalué à 2.

      Sans doute, mais pour un jeu dans un navigateur, il vaut mieux minimiser la complexité graphique.

      Après si quelqu'un veut s'éclater à coder un client opengl de la mort pourquoi pas :-)

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # UML

    Posté par  . Évalué à 2.

    Content de voir que le projet avance, mais je me demandais un truc tout con : tu utilise quoi comme modélisateur UML ? Il existe sous Linux et en libre ? J'en cherche un depuis pas mal de temps mais je trouve pas grand chose de vraiment utilisable et sympa (et sans bugs trop gênants, ou qui ne nécessite pas de lancer Éclipse). Du coup tu conseille un truc spécifique ?

    • [^] # Re: UML

      Posté par  (site web personnel) . Évalué à 3.

      J'ai utilisé DIA, ce n'est pas vraiment un modeleur UML, mais un logiciel de dessin de diagrammes avec quelques formes UML.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: UML

      Posté par  . Évalué à 4.

      J'ai fait quelques tests avec Umbrello, ça me semblait utilisable sans trop de bugs, sinon j'ai aussi testé modelio mais vu que tu ne veux pas lancer eclipse…

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: UML

        Posté par  . Évalué à 4.

        J'ai oublié de parler d'ArgoUML qui m'avait l'être très bien pour les quelques tests que j'ai fait.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: UML

      Posté par  . Évalué à 1.

      J’ai entendu parler de UMLet, mais je ne sais pas ce qu’il vaut.

  • # Dwarf Fortress

    Posté par  (site web personnel) . Évalué à 3.

    Connais-tu Dwarf Fortress ? Il me semble que ça t'intéresserait d'y jeter un coup d'œil pour le gameplay, mais aussi pour le développement.

    Pour le gameplay:

    Le joueur ne contrôle directement le déplacement des unités que lorsqu'elles partent en guerre, soit potentiellement jamais. Le reste du temps, il définit le métier des unités, et dit comment modifier la carte (cultiver ici, chasser tel type d'animal, creuser là, tailler ces arbres, dériver l'eau…) ou quoi fabriquer (nourriture, vêtements, arbres, bâtiments). Cela reste agréable à jouer car on peut faire des milliers choses, et il y a toujours des évènements surprenants qui donnent un aspect narratif au jeu.

    Chaque unité vit sa vie, a un nom, des amis, des qualités qui progressent ou régressent, des préférences, un caractère, peut avoir des enfants, tomber malade, mourir, etc. Le joueur apprend à les connaître. Certaines unités ne résistent pas au stress par exemple, si un de leur proche meurt, elles deviennent alors ingérables, tandis que pour d'autres, ce moment est vite oublié.

    Pour le développement:

    Il n'est pas open source, mais il y a des fichiers de configuration modifiables qui donnent une idée de son fonctionnement. En simplifiant, il y a trois choses: les matières, les unités, et les réactions.

    Les matières sont définies par des caractéristiques physiques: masse, densité, couleur, températures de changement d'états (fusion, solidification, évaporation).

    Les unités sont soit des vivants, soit des objets, soit des composants de vivant ou d'objet. Par exemple, l'homme a deux bras, chaque bras est fait de peau, de chair et d'os, qui sont des matières particulières. Les objets sont eux aussi composés de différents éléments, eux-même composés de matières. Vivants et objets ont en outre des caractères: fécondité, sachant nager, voler, marcher, immobile, force, vitesse, masse, tranchant, contenant, habillant, fabriqué avec art pour les objets. Les caractéristiques physiques des unités sont définies par les matières qui les composent: avoir de la peau en or donne beaucoup de valeur à l'animal, outre qu'il est très résistant.

    Les réactions définissent ce qui se produit quand on mélange plusieurs unités: Le champ et la graine donnent une plante, la farine et l'eau donnent du pain, etc.

    À partir de ces trois choses (matières, unité, réactions), il est possible de définir tout l'univers. Ainsi, hormis les réactions, c'est le moteur physique qui gère la plupart des évènements (un saut brisé voit son eau couler par terre).

    • [^] # Re: Dwarf Fortress

      Posté par  (site web personnel) . Évalué à 2.

      J'en ai beaucoup entendu parler, mais le mode ASCII ART me rebute. J'attends de voir ce que donnera le clone plus graphique A Game of Dwarves.

      L'idée d'un monde qui a sa vie propre et sur lequel on intervient que de temps en temps me plait beaucoup et si je réussis à écrire un bon moteur, je le réutiliserais sans doute pour d'autres styles de jeux.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Dwarf Fortress

        Posté par  (site web personnel) . Évalué à 1.

        On peut remplacer l'ASCII ART par des "packs graphique" si tu veux tester

      • [^] # Re: Dwarf Fortress

        Posté par  (site web personnel) . Évalué à 2.

        le mode ASCII ART me rebute

        Peut-être devrais-tu réviser cet avis. Entre l'ascii art et des tiles pixellisés, il n'y a pas grande différence. Dans les deux cas, le regard n'est pas tourné vers l'image elle-même, mais vers ce qu'elle symbolise, et étrangement, à travers l'ascii, on « voit ».

        On voit les abeilles derrière les « . », le chat derrière le « c », les licornes courir en troupeau dans la forêt, les cristaux dans la cave, on voit couler la rivière souterraine et s'élever la tour au sommet de la montagne, on voit le soleil qui rougeoie et le ciel qui bleuoie.

        Regard mêlé d'imaginaire, porté par la narration plus que par l'image.

        Ouvrir un tel regard, n'est-ce pas le but du jeu vidéo ?

      • [^] # Re: Dwarf Fortress

        Posté par  . Évalué à 1.

        Dans le genre "refonte graphique de Dwarf Fortress" avec quasiment exactement le même gameplay tu as aussi Towns : http://www.townsgame.com/

        En plus tu peux télécharger la démo pour te faire une idée

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.