Journal Rolling: un nouveau jeu libre

50
23
juil.
2020

Sommaire

Déjà deux ans de travail, il est temps de présenter le projet !

image principale

Petite vidéo disponible ici (2.47 MB, WEBM)

Qu'est-ce que c'est ?

Tout d'abord, c'est un jeu. À la fois un jeu de gestion, d'aventure, de rôle et de coopération multi-joueurs. Vous incarnez un personnage qui devra, pour commencer, trouver à boire et à manger. Et ce, à chaque tour. Mais au delà de ces besoins de base … il vous faudra assurer votre survie face aux autres joueurs. Car dans ce jeu, tout est permis. Du moins l'idée c'est d'en permettre un maximum !

Pour survivre, à vous de choisir comment: Construire et fortifier un village. Développer un réseau commercial. Payer des mercenaires. Ou encore, être payé par les villages pour les protégers. Êtres vous même les brigands …

Le jeu met à disposition les mécaniques nécessaires pour réaliser vos projets. Rolling est un jeu où on confie aux joueurs le soin de créer l'environnement, le contexte et les évènements du jeu.

Gameplay

Rolling associe le tour-par-tour et le temps réel. A dates fixes, le "tour passe". Entre chaque passage de tour, vous êtes libre de faire jouer votre personnage en consommant ses "points d'actions" (qui se rechargent au passage de tour). Entre les passages de tour, vous pourrez:

  • Chercher, produire ou consommer de la nourriture/de l'eau
  • Déplacer votre personnage (sans consommer de points d'actions) dans la "zone" où il se trouve
  • Voyager vers d'autres zones (quitter votre zone pour une autre)
  • Fabriquer des outils, des armes, des vêtements, …
  • Construire des bâtiments, des murs, des enceintes, des fours, etc
  • Relationner avec d'autres joueurs, créer/rejoindre des affinités pour se protéger mutuellement et partager ses biens
  • Définir ce que votre personnage protège, comme l'accès à un bâtiment, un endroit …

Lors du passage de tour, différentes opérations seront effectués par le serveur:

  • Calcul des pertes/gains de points de vies
  • Péremption/re-génération des ressources (la forêt pousse, les animaux se reproduisent, la viande faisande…)
  • Fonctionnement des bâtiments (un feu s'éteint si il n'a plus de bois à bruler)
  • Exécution des actions programmées

Cela, dans un monde persistant et partagé entre tous les joueurs : ce que vous laissez trainer (une épée, votre nourriture, un cadavre…), ce que vous construisez, etc, les autres joueurs y auront accès.

Une liste des fonctionnalités développées et à développer est disponible ici.

Jeu de rôle

Rolling est également un jeu de rôle : Votre personnage évoluera en connaissances et compétences. Vous pourrez proposer des quêtes, exprimer des besoins commerciaux, rédiger des histoires avec d'autres joueurs si vous avez l'âme d'un écrivain. Des outils de gestion, de création de quêtes et d'évènements seront mis à disposition des maîtres du jeu pour alimenter l'univers.

Le serveur enregistrera un certains nombre de données comme les déplacements, les concentrations de populations, l'urbanisation, les affrontements… Afin de générer des cartes, des fils d'évènements racontant l'histoire de l'univers.

Et lorsque votre personnage meurt, c'est terminé. Vous devrez recommencer avec un nouveau personnage !

Comment se démarque Rolling

Un jeu dont l'univers est construit par les joueurs.

  • Un monde persistant : chaque objet laissé au sol, construction effectuée ou cadavre laissé derrière vous fait partie de l’univers
  • Un mélange de jeux tour par tour et de temps réel
  • Pendant que vous ne jouez pas, votre personnage peut interagir : participer à une attaque, se défendre, faire des échanges commerciaux
  • Une grande liberté d'action
  • Multijoueurs

Serveur

Univers configurable

Le moteur que je développe permet de configurer et de faire fonctionner un univers issue de votre imagination, cela grâce à un maximum de configurations :

  • La carte du monde et des zones
  • Les objets et leurs caractéristiques
  • Les ressources
  • L'articulation des actions (voir un peu après pour plus de détails)
  • Les compétences/connaissances

Quelque exemples

Définition de la carte du monde:

::LEGEND
~ SEA*
^ MOUNTAIN
ፆ JUNGLE
∩ HILL
⡩ BEACH
⠃ PLAIN
::META
SPAWN:RANDOM:BEACH,
::GEO
~~~~~~~~~ፆ^ፆፆ~~~~~~~~~~~~
~~~~~~~~ፆ^^^∩ፆ~~~~~~~~~~~
~~~~~~~⡩ፆ∩∩∩∩⡩~~~~~~~~~~~
~~~~~~⡩ፆፆ∩∩∩ፆፆ⡩~~~~~~~~~~
~~~~~~⡩ፆፆፆፆፆፆፆ⡩~~~~~~~~~~
~~~~~~⡩⠃⠃⠃ፆፆፆፆ⡩~~~~~~~~~~
~~~~~~⡩⠃⠃⠃⠃⠃⠃⡩~~~~~~~~~~~
~~~~~~~⡩⠃⠃⠃⠃⡩~~~~~~~~~~~~
~~~~~~~~⡩⡩⡩⡩~~~~~~~~~~~~~

Définition d'une carte de zone (qui correspond a une coordonné sur la carte du monde). Ici toute petite pour servir d'illustration représentant une plage. C'est un octogone où chaque "bord" permet de se déplacer vers une autre zone:

::GEO
       ⡩⡩⡩⡩⡩⡩⡩
      ⡩⡩⡩⡩⡩⡩⡩⡩⡩
     ⡩⡩⡩⡩⡩⡩⡩ʛ⡩⡩⡩
    ⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
   ⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
  ⡩⡩⡩⡩ʛ⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
 ⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
⡩⡩⡩⡩⡩⡩⡩⡩⡩ʛ⡩⡩⡩⡩⡩⡩⡩ʛ⡩⡩⡩
⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩ʛ⡩⡩⡩⡩⡩⡩⡩⡩⡩
⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
⡩⡩⡩⡩ʛ⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩ʛ⡩⡩⡩⡩
⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩⡩
⡩###⡩⡩⡩#⡩⡩⡩###⡩⡩⡩#⡩⡩⡩
 ~~##~~~~~~##~~~~~#~
  ~~~~~~~~~~~~~#~~~
   ~~~#~~~~~~~~~~~
    ~~~~~~~~~~~~~
     ~~~~~~~~~~~
      ~~~~~~~~~
       ~~~~~~~

Note: J'ai prévu d'abandonner le format "texte" pour celui de l'image où les tuiles seront représentés par des pixels de couleurs.

Configuration de ressources :

[resources.BEACH_SAND]
    name = "Sable de plage"
    weight=1600.0
    material="SANDY"
    unit = "L"
    clutter = 1.0
    actions = ["DROP_RESOURCE", "MIX_RESOURCES", "TRANSFORM_RESOURCES_TO_RESOURCES"]

[resources.PEBBLES]
    name = "Galets"
    weight=2000.0
    material="LITTLE_OBJECT"
    unit = "L"
    clutter = 1.0
    actions = ["DROP_RESOURCE", "MIX_RESOURCES", "TRANSFORM_RESOURCES_TO_RESOURCES"]

image inventaire

Configuration d'objets:

[LITTLE_SKIN_CANTEEN]
    name = "Petite gourde de peau"
    filled_at = 0.0
    filled_unity = "L"
    filled_capacity = 1.0
    weight = 0.1
    clutter = 1.0
    actions = ["DROP_STUFF","FILL_STUFF","DRINK_STUFF","EMPTY_STUFF"]
    material_type = "OBJECT"
    classes = ["BOTTLE"]
[LITTLE_SKIN_BAG]
    name = "Petit sac en peau"
    weight = 1200.0
    clutter = 0.0
    clutter_capacity = 5.0
    actions = ["DROP_STUFF","USE_AS_BAG","NOT_USE_AS_BAG"]
    material_type = "OBJECT"
    is_bag = true
    classes = ["BAG", "LITTLE_BAG"]

Configuration d'actions:

[ACTIONS.COOK_LITTLE_GAME_WITH_SKIN]
    actions = ["TRANSFORM_STUFF_TO_RESOURCES"]
    required_one_of_stuff_ids = ["HARE", "RABBIT", "FOX", "MARTEN", "BOAR", "DEER"]
    required_all_stuff_ids = []
    required_one_of_skill_ids = []
    required_all_skill_ids = []
    required_one_of_ability_ids = ["HEAT_UP_LOW_TEMP"]
    required_all_ability_ids = []
    produce = [
      {resource="COOKED_MEAT", coeff=0.3},
      {resource="LITTLE_ANIMAL_SKIN", quantity=1.0}
    ]
    cost = 1

image actions

Une base d'actions à étendre

Comme abordé dans la partie précédente, le moteur met à disposition une série d'actions. Une partie est "fixe" et l'autre extensible par configuration. Les actions "fixes" à ce stade sont:

  • Les mécanismes de communications
  • Les mécanismes de commerces
  • Les mécanismes d'interractions avec les bâtiments
  • Les mécanismes d'interractions avec les autres joueurs (affinités/attaque/vol/tuer/prendre/donner/enseigner)
  • Les mécanismes de déplacements/voyages
  • Interaction avec des objets (remplir, vider, utiliser comme arme/bouclier/armure/sac)

Les actions extensibles proposent un fonctionnement de base avec des modalités (ce sont celles-ci qui sont configurable). Ces actions peuvent être restreintes à certaines conditions (type de zone, compétences, possession d'objets):

  • Construction d'un bâtiment (modalités: ressources requises, durée de construction)
  • Chercher de la nourriture (modalités: ressources et quantités obtenus)
  • Chercher du matériel (modalités: ressources et quantités obtenus)
  • Transformer des ressources en un objet (modalités: ressources/objets et quantités)
  • Transformer un objet en un autre (modalités: objets et quantités)
  • Transformer une ressource en une autre (modalités: ressources et quantités)
  • Construire un objet sur la durée qui prendra plusieurs tours de jeu (modalités: objet/ressource et quantités)

API HTTP

Le serveur propose son interface à travers une api HTTP. De cette manière, il est possible de scripter ce que l'on souhaite ou développer un client graphique différent. La documentation de cette api est générée d'après le code source et et visible ici par exemple.

Interfaces normalisées

Le serveur communique au client graphique une représentation structurée de l'interface qu'il doit afficher. Cela a des avantages : Le client implémente la manière d'afficher les interfaces une fois et le serveur peut ajouter de nouvelles interfaces sans que l'on doive mettre à jour le client graphique. Mais aussi des désavantages : Moins de souplesse quand il s'agit de donner une spécificité à un des écrans.

Graphismes

Le serveur fournit au client graphique le nécessaire pour savoir quoi afficher dans son interface. A ce stade, j'ai réalisé une implémentation simpliste mais suffisante pour commencer à jouer.

Une zone est donc composée d'une couleur de fond et d'une suite de tuiles de différents types que l'on représentera avec ces images:

image tuiles1

Les objets / constructions / personnages sont également des images, appliqués par-dessus:

image tuiles2

La carte du monde suit ce même principe:

image tuiles3

image monde

Note: je me pose sérieusement la question de passer à des tuiles de 32 pixels au lieu de 16 pixels.

Pourquoi développer ce projet et ce mode de jeu ?

Plusieurs raisons m'ont poussé à démarrer ce projet. Premièrement, j'ai toujours fortement apprécié les jeux permettant de laisser libre cours à l'imagination du joueur. Ainsi que les jeux de rôles et les jeux de coopération. Aussi, il n'est pas possible pour tout le monde de pouvoir effectuer de "longues" sessions de jeux mais de ne pouvoir jouer que par de brefs moments. Alors je me suis lancé dans ce "mélange".

Les jeux que l'on peut considérer comme des sources d'inspirations sont: Dwarf Fortress, Fract, Fallout, Stronghold.

La pile technique

Le serveur est écrit en python et utilise aiohttp. La base de données est en SQLite mais passera en Postresql dès qu'il faudra maintenir des scripts de migrations. L'api HTTP est présentée, configurée et documentée avec hapic et serpyco.

Le clent graphique actuel est écrit en Rust et utilse Coffee comme librairie graphique.

À ce stade

Au bout de ces deux ans de travail, une première version du jeu est enfin testable. Elle est limitée mais permet, selon moi, de pouvoir élargir un peu le spectre des "joueurs testeurs".

Comme pour beaucoup de projets, l'aide de quiconque est la bienvenue ! Vous pouvez (détails sur comment contribuer ici):

  • Tester, imaginer, proposer, jouer !
  • J'ai cruellement besoin d'une aide "graphique", c'est pas mon fort !
  • Développer le moteur, ajouter des objets/ressources/actions
  • Toute aide est bonne à prendre :)

Quelque questions restent en suspens, peut-être auriez-vous de bon conseils:

  • Un aspect important est qu'un joueur n'ai qu'un seul personnage. Comment appliquer cette limitation efficacement ? Je n'ai pas trouvé d'autres solutions que d'exploiter des systèmes tiers comme Steam pouvant faire office "d'identificateur". Pas top pour la vie privée …
  • J'utilise des tuiles de 16x16 pixels. Surtout parce que j'ai trouvé une suite gratuite sympa de cette taille. Mais je me pose vraiment la question de passer à du 32x32 pixels. Bien qu'il me faudrait quelqu'un pour faire quelque tuiles ! Qu'en pensez-vous ?
  • Le premier serveur de Rolling aura besoin d'un "univers" (fantastique ? médiéval ? post-apocalyptique ? steam-punk ?) si vous avez envie d'en être l'auteur, venez participer c'est possible !

À vous de jouer

N'hésitez surtout pas à faire vos retours vos retours en commentaire, sur le site de Redbricks (qui est également libre et open source) ou à laisser votre email sur https://framalistes.org/sympa/info/rolling-news pour être tenu au courant de la prochaine phase de tests.

  • # Chapeau !

    Posté par  . Évalué à 6 (+4/-0).

    Salut,

    Juste pour dire chapeau l'artiste.

    J'avais essayé sur une période un peu creuse de développer un logiciel similaire (le but sous-jascent n'étant que de programmer, mais il me fallait une idée).

    C'est vraiment pas le style de logiciel le plus facile à faire !

    • [^] # Re: Chapeau !

      Posté par  (site Web personnel) . Évalué à 2 (+2/-1).

      Merci !

      Blog: http://blog.bux.fr, github: http://github.com/buxx

      • [^] # Re: Chapeau !

        Posté par  . Évalué à 4 (+2/-0).

        Salut,

        De rien. C'est juste super d'être allé au bout.

        De mon côté, c'était juste une idée pour me ré-auto-former, et quand j'ai trouvé un boulot, j'ai tout laissé en plan : plus de temps pour finir.

        Je vois très bien les difficultés (même si pas le même langage) ;)

        • [^] # Re: Chapeau !

          Posté par  (site Web personnel) . Évalué à 3 (+1/-0). Dernière modification le 23/07/20 à 23:46.

          et quand j'ai trouvé un boulot, j'ai tout laissé en plan

          Je ne sais pas exactement comment il fait, mais je peux dire que bux combine les deux avec brillo :)

          • [^] # Re: Chapeau !

            Posté par  . Évalué à 2 (+0/-0).

            Salut,

            Je ne sais pas exactement comment il fait

            Aucune idée :)

            Je sais juste que moi, quand j'ai passé ma journée à coder, le soir ce n'est plus trop possible.

            • [^] # Re: Chapeau !

              Posté par  (site Web personnel) . Évalué à 2 (+1/-0).

              Le secret c'est un peu, mais régulièrement ! Mais faut aimer manger du code comme on dit :p

              Blog: http://blog.bux.fr, github: http://github.com/buxx

  • # Bravo

    Posté par  . Évalué à 4 (+4/-1). Dernière modification le 23/07/20 à 13:32.

    Salut,

    Bravo pour ce jeu.

    Une petite question que l'on t'a déjà certainement posé.

    Pourquoi ne pas être passé par un client web ? Ça faciliterait grandement l’adoption notamment.

    • [^] # Re: Bravo

      Posté par  (site Web personnel) . Évalué à 8 (+7/-0).

      Salut,

      Je vais te faire l'historique complet des clients pour commencer :p

      Au départ je voulais faire un truc de geek:

      Le premier client que j'ai développé était un client texte utilisant des caractères utf-8 utilisable dans un terminal. Ça marchait mais j'ai trop vite été limité en terme de capacité de rendu.

      Ensuite je me suis décidé à faire un truc moins exclusif avec un rendu web pour les raisons que tu avance. Je voulais apprendre le Rust aussi et j'ai trouvé une lib type rogue like avec rendu web: doryen-rs (le développeur est francophone est super sympa !)

      Ca donnait ça:

      rolling rogue like

      Mais pareil, je me suis trouvé coincé en terme de rendu. Voulant toujours faire du Rust je suis allé vers Coffee, qui lui, n'a pas de rendu web.

      J'ai envisagé d'utiliser une techno javascript, mais je voulais vraiment apprendre le Rust :p

      Mais le développement du client graphique n'est pas le plus complexe et on peut facilement en faire un nouveau. Donc peut-être un client web un de ces jours !

      Blog: http://blog.bux.fr, github: http://github.com/buxx

  • # Code source

    Posté par  (site Web personnel) . Évalué à 4 (+3/-0). Dernière modification le 23/07/20 à 15:18.

    Je réalise que je n'ai même pas mis les liens vers le code source (si un modo veut les ajouter …):

    Blog: http://blog.bux.fr, github: http://github.com/buxx

  • # Licence MIT

    Posté par  . Évalué à 4 (+3/-0). Dernière modification le 23/07/20 à 15:22.

    La licence MIT est précisée sur le site donné en fin d'article : https://redbricks.games/home/rolling-117

  • # Limitation des personnages

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 23/07/20 à 16:34.

    Avant toute chose, superbe projet. Ca sent le projet infini tant les possibilités semblent infinies.

    Un aspect important est qu'un joueur n'ai qu'un seul personnage. Comment appliquer cette limitation efficacement ? Je n'ai pas trouvé d'autres solutions que d'exploiter des systèmes tiers comme Steam pouvant faire office "d'identificateur". Pas top pour la vie privée …

    Il n'y a sans doute pas de solution miracle mais tu devrais pouvoir créer ton propre système de gestion de comptes avec ta propre API. Alors oui, ça n'empêchera pas les utilisateurs de créer d'autres comptes pour jouer un autre personnage mais ton système actuel souffre de la même faiblesse, il est possible de créer un autre compte Steam…

    Avec ton client lourd, tu peux aussi vérifier s'il existe une autre instance active afin de limiter le nombre d'instance à 1 par machine pour éviter le multiboxing.

    C'est déjà un peu contraignant de devoir créer un compte par personnage et de conteneuriser/posséder plusieurs machines pour chaque instance. Mais ça résout au moins ton problème de vie privée.

    Bien du courage pour continuer ce projet, j'aime beaucoup l'idée et je suis conscient du travail monstre qu'il y a derrière. Chapeau.

    La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

    • [^] # Re: Limitation des personnages

      Posté par  (site Web personnel) . Évalué à 7 (+5/-0).

      Il n'y a sans doute pas de solution miracle

      Et est-ce vraiment nécessaire ? Pourquoi un même joueur qui voudrait essayer deux manières de jouer différentes avec deux personnages différents ne devrait pas le faire ? Surtout que les personnages évoluent en compétences, donc on peut prendre du plaisir à jouer des personnages très différents, qui suivent des voies différentes. Appliquer une limite de 1 perso par joueur dans un jeu de rôle (ou assimilé), ce n’est pas loin de n’autoriser le joueur à jouer qu’à un seul jeu sur son ordinateur (faudrait choisir entre Rolling ou SuperTuxKart ?)… c’est dommage, surtout pour un jeu qui semble offrir une telle richesse dans les manières de jouer !

      • [^] # Re: Limitation des personnages

        Posté par  (site Web personnel) . Évalué à 4 (+3/-0). Dernière modification le 23/07/20 à 17:07.

        Salut jyes,

        Dans l'absolu ça ne pose pas de problème c'est vrai. Le problème se pose lorsque l'on regroupe des joueurs sur un serveur qui souhaitent jouer un partie "jeu de rôle":

        Ton personnage, une fois tué, est perdu. Mais c'est le jeu: Si une faction adverse est venu t'attaquer, ou si tu as pris des risques avec ton personnage, c'est le jeu. Mais si ton personnage est tué parce que des joueurs on crées un certain nombres de personnages "factices" juste pour être plus fort, ce plus "le jeu" (de rôle).

        C'est un équilibre compliqué …

        Je tire cet enseignement du jeu de rôle fract.org, où la création de personnages "multis" est un vrai problème au sein de la communauté.

        Blog: http://blog.bux.fr, github: http://github.com/buxx

        • [^] # Re: Limitation des personnages

          Posté par  . Évalué à 4 (+2/-0). Dernière modification le 23/07/20 à 18:06.

          Le problème à mon sens n'est pas de pouvoir créer plusieurs personnages, c'est de pouvoir les jouer en même temps.

          De nombreux MMO permettent la création de plusieurs personnages mais ne te permettent pas de les jouer au même moment (sauf moyennant plusieurs abonnements pour WoW ou FFXIV par exemple). Le fait de devoir payer plusieurs abonnements est en général suffisamment dissuasif pour éviter ce qu'on appelle le multiboxing. Oui ça existe quand même mais dans des proportions négligeables pour créer un déséquilibre trop pesant. Sur les serveurs privés, cette pratique est en générale interdite.

          Pour un jeu qui se veut gratuit, il faut donc trouver d'autres stratégies.

          La vérification d'IP unique n'est pas une bonne mesure à mon sens, comme ça a été proposé en-dessous, elle empêche une famille de jouer ensemble et c'est franchement dommage.

          Il faut trouver le juste milieu entre le fait que ce soit assez lourd pour décourager les gens de faire du multiboxing sans pénaliser les joueurs honnêtes (procédures d'inscription lourdes, 1 seul joueur par IP…).

          Dans tous les cas, il est impossible de mettre en place une solution parfaite. Il reste toujours la possibilité de créer des logs avec une alerte quand la même IP est connectée plusieurs fois et de faire une vérification manuelle de ce qui se passe sur ces IP. Il est très facile de repérer les joueurs qui font du multiboxing, soit les personnages ont exactement le même comportement, soit chaque personnage agit l'un à la suite de l'autre. Ca prend un peu de temps de faire la police mais si déjà tu mets en place une solution comme celle que j'ai proposé, tu vas décourager énormément de "multiboxeurs". Ne restera que les plus acharnés, c'est là que l'alerte log intervient. Tu peux même partiellement automatiser tes bans si tu détectes un comportement identique répété X fois. Il ne restera plus que ceux qui jouent l'un à la suite de l'autre… A moins de trouver un algo du tonnerre, ce sera vérification à la mano.

          Avec toutes ces mesures (un compte avec mail unique, éventuellement plusieurs personnages par compte mais une seule connexion par compte autorisée, une instance par machine, alerte log sur même IP, vérification auto du comportement des personnages qui partagent la même IP et enfin vérification manuelle sur les personnages qui partagent la même IP sans avoir le même comportement), tu te protèges plutôt efficacement du multiboxing. Le plus difficile à mettre en place étant de trouver du temps ou des gens qui ont du temps pour faire la police.

          La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

          • [^] # Re: Limitation des personnages

            Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

            Merci pour ton analyse très instructive ! Un détail: dans Rolling, il n'est pas nécessaire de jouer les personnages en simultanés pour profiter du multiboxing (mélange de jeu asynchrone et synchrone).

            Blog: http://blog.bux.fr, github: http://github.com/buxx

        • [^] # Re: Limitation des personnages

          Posté par  . Évalué à 7 (+5/-0).

          Salut,

          Je tire cet enseignement du jeu de rôle fract.org, où la création de personnages "multis" est un vrai problème au sein de la communauté.

          Je joue à au moins deux petits jeux web et c'est pareil : même problème mais pas de solution.

          Je crois qu'il faut prendre le problème à l'envers pour qu'il soit plus simple :

          • tu indique dans les conditions que c'est un seul personnage par joueur et tu fais confiance. Quasi tout le monde va s'y astreindre.
          • et si tu vois qu'un petit malin joue plusieurs personnages, bin paf. kick-ban.

          C'est beaucoup moins de boulot ;)

          • [^] # Re: Limitation des personnages

            Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

            C’est aussi la méthode que je conseillerais, en particulier parce que contrairement aux autres suggestions elle ne pénalise pas le joueur qui respecte les règles.

            Partir du principe que les joueurs sont des tricheurs ça aboutit à des horreurs façon DRM, un repoussoir pour beaucoup de joueurs. En plus ça ne fonctionne pas ;)

  • # hop

    Posté par  . Évalué à 6 (+4/-0).

    Félicitation; le jeu à l'air plutôt bien aboutit.

    Pour répondre a tes questions :

    Effectivement la limitation à n personnage par joueur parait indispensable, n n'étant pas forcément 1. Surtout si tu autorise le pvp (par exemple je crée un groupe de 15 bandits pour raider les autres);

    • Y a des solutions utilisées par les traqueurs pour identifier les machines via les brouteur web (pas top coté vie privée, et tu risque de dégager ceux qui aseptisent les informations divulguées)
    • tu peux avoir plusieurs mondes et ouvrir les inscriptions sur ceux ci à un compte par IP (ça se contourne, et une famille se retrouvera éparpillé sur plusieurs monde, et il faut une base d'utilisateur plus importante, sinon les mondes vont être vides, attention avec l'ipV6 qui arrive)
    • demander pleins d'infos spécifique (combien de fenêtre dans la pièce?, le jour de naissance dans le moi? combien font 0.2 plus 4.) sur plusieurs pages, et dégager ceux qui répondent différemment à la page 1 et à la page 5 avec un petit ban de 30 minutes sur l'IP, évidemment les questions répétés ne sont pas toujours les mêmes par contre tu risque de pas avoir grand monde.
    • demander un scan de la pièce d'identité (par contre va falloir demander l'avis de la cnil ;)
    • envoyer un code de création de compte par sms, limité à un compte par monde, tu stock le hash du 'nom du monde' + n° de téléphone pour éviter qu'on puisse retrouver facilement les numéros, et tu n'associe pas le numéro à un compte; (c'est ce qui me parait le moins intrusif, mais tu risque d'avoir pas mal de refus de laisser leur n° comme ça)

    C'est une problématique qui est loin d'être simple, et qui est renforcée par la compétition entre joueurs ; les jeux à micro transaction s'en accommodent très bien (il l'interdisent souvent dans les CGU, mais a moins d'abus manifeste et dénonciation de la part des joueurs, ils laissent faire)

    enfin ça c'est juste mon avis; quelle que soit la solution envisagée ce sera sans moi, le pvp j'aime pas vraiment.

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: hop

      Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

      Merci c'est plein d'infos utiles !

      Blog: http://blog.bux.fr, github: http://github.com/buxx

  • # Editeur de carte

    Posté par  (site Web personnel) . Évalué à 9 (+6/-0).

    Plutôt qu'un format "pixel", pourquoi ne pas adopter le format TMX ?

    Il est un plus compliqué qu'une simple matrice de texte/pixel, mais bien documenté et l'éditeur graphique vraiment simple à utiliser.

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Editeur de carte

      Posté par  (site Web personnel) . Évalué à 3 (+2/-0).

      En effet je pourrais utiliser le format TMX. Je l'ai utilisé pour cet autre projet de jeu: OpenCombat. J'avoue que j'hésite … J'aime bien l'idée de dessiner une carte avec un éditeur comme GIMP. Mais les outils comme Tiled sont très aboutis aussi …

      Blog: http://blog.bux.fr, github: http://github.com/buxx

  • # coquilles

    Posté par  (site Web personnel) . Évalué à 2 (+1/-0). Dernière modification le 23/07/20 à 19:46.

    brigants -> brigands
    péromption -> péremption

  • # Authentification

    Posté par  (site Web personnel) . Évalué à 3 (+0/-0). Dernière modification le 23/07/20 à 23:28.

    Un aspect important est qu'un joueur n'ai qu'un seul personnage. Comment appliquer cette limitation efficacement ? Je n'ai pas trouvé d'autres solutions que d'exploiter des systèmes tiers comme Steam pouvant faire office "d'identificateur". Pas top pour la vie privée …

    Un utilisateur pourra toujours créer plusieurs comptes Steam…

    Si tu n'as pas envie d'authentifier tes utilisateurs toi même, tu peux utiliser une authentification délégué sur un site sympa, par exemple avec l'API de linuxfr.

    Peut être que le plus simple est de ne pas authentifier les utilisateurs, mais de diviser l'XP par nombre de personnages pour une même IP ?

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Authentification

      Posté par  . Évalué à 4 (+2/-0).

      diviser l'XP par nombre de personnages pour une même IP ?

      Tu interdirais des gens qui partagent la même connexion de jouer dans de bonnes conditions (même habitation, même entreprise, etc).

      Par contre, voir un "Connectez-vous avec LinuxFr", ça serait rafraîchissant !

  • # Kenney et ses ressources graphiques en CC0

    Posté par  . Évalué à 2 (+2/-0).

    Pour ton éventuel passage à des tuile de 32x32 as-tu pensé à utiliser une des pack de sprite en CC0 de https://kenney.nl en particulier ceux orienté roguelike comme https://kenney.nl/assets/roguelike-rpg-pack (bon celui-là est en 16x16 donc tu pourrais limite l'utiliser sans changer des masse ton moteur) ou https://kenney.nl/assets/rpg-base (qui est en 64x64 mais fourni les SVG) ? Et idem pour les persos ils ont qq pack qui pourrait avantageusement remplacer tes tuiles actuelles.

    En tout cas super projet… le possibilité me laisse juste rêveur…

  • # victime de son succès? :)

    Posté par  . Évalué à 1 (+1/-0).

    coucou,

    j'ai l'impression que je n'ai pas été le seul par avoir envie de tester. le serveur semble ne plus répondre :

    Retrieve world source from server
    thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Request, url: "http://91.121.134.31:7431/world/source", source: TimedOut }', src/server/client.rs:283:33
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    

    En tout cas, chouette projet :)

  • # Un univers ?

    Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

    Le premier serveur de Rolling aura besoin d'un "univers" (fantastique ? médiéval ? post-apocalyptique ? steam-punk ?) si vous avez envie d'en être l'auteur, venez participer c'est possible !

    Tu peux aussi regarder dans les univers libres déjà existants. Je ne me suis pas encore penché sur les mécaniques de jeu pour voir comment ça peux s'associer mais au hasard :
    - L'univers de Khanat (CC-BY-SA)
    - Celui de Pepper&Carrot (CC-BY)
    - Ou encore celui de Shaedra (CC-BY)

    Et on en trouve d'autres… Sur ces trois-là, je suis assez sûre que tu peux contacter les gens qui les font vivre, en français, et qu'ils seront ouverts à la discussion :)

    Concernant les aspect graphiques, c'est vrai que la limitation des tuiles de 16x16 pixels est une sacré contrainte, on peut faire un peu plus détaillé sur du 32x32 pixels. Peut-être regarder d'autres jeux libres avec le même mode graphique pour emprunter des assets ? Glitch avait libéré pleins d'assets superbes pour la 2D, par contre c'est pour des tuiles bien plus grosses.

    L'aspect graphique est assez complexe : les joueurs ne s'arrêtent pas à des graphismes "moches" si le jeu est vraiment bon, mais la qualité graphique est quand même ce qui va en motiver pas mal à tester… ou pas. Là pour moi, c'est une qualité qui va me demander une bonne motiv pour aller tester (mais c'est parce que je suis feignasse et que je n'ai pas tant de temps pour tester, donc je filtre beaucoup). Le pixel art n'est pas forcément le plus simple à faire en plus. La difficulté consiste donc à trouver soit un bon set de base, soit un graphiste qui a envie de participer. Bon courage sur ça ! Il est possible de payer des commissions à des artistes sur Deviant Art et compagnie, ça peut être une piste si tu as des sous…

Envoyer un commentaire

Suivre le flux des commentaires

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