[projet webmog] WIMD : Wortels I, Mortelles Dryades

Répondre
Partager Rechercher
Je vais essayer d'apporter des éléments de réponse à la question "pourquoi les codeurs ne terminent jamais ce qu'ils commencent".
  • Coder, c'est globalement assez long. Dans un projet amateur, la motivation peut fluctuer, ainsi que les aléas de la vie personnelle. Plus ça dure longtemps, plus le risque de perdre un membre de l'équipe est grand.
  • Quand on s'arrêter de coder quelques temps sur un script, ce peut être assez difficile de reprendre (selon notre méthode de travail).
  • Coder une application, c'est faire des scripts que l'on a peut-être déjà fait des tas de fois (Inscription/connexion, messagerie privée, gestion du profil utilisateur, etc.). Là aussi, selon notre méthode de travail, ça peut atténuer le problème. Quand on doit les refaire complètement, c'est pénible et ça entame parfois la motivation.
  • Des codeurs qui n'ont pas une ligne de conduite stricte vont avoir tendance à coder à tort et à travers, d'une manière peu méthodique. L'idéal est de découper le développement. On se fixe une date butoir pour avoir une version (jouable) qui contient tels ou tels mécanismes.
Voilà le simple point de vue d'un codeur. Je te souhaite bonne chance dans ta recherche de développeurs amateurs, ton projet est vraiment bien et mérite vraiment de voir le jour.

Si je n'étais pas sur Seelies, je postulerait pour faire partie de l'équipe de développement.


Sephi-Chan
Citation :
Publié par Ebe
Apres je me demande si le jeu ne fait pas quand même un peu l'objet d'une malédiction, si je suis vraiment quiche avec les gens qui participent ou bien si c'est un déboire naturel de la création amateur, parce qu'en ce moment j'ai pas de nouvelles de Gulix.
Je pense pas que ça soit une malédiction, car j'ai jamais vu quelqu'un terminer son projet de jeu vidéo amateur en montant une équipe avec des inconnus

Si tu veux terminer ton jeu, apprend la programmation sinon même dans 20 ans tu en seras toujours au même point. Même en partant de zéro, tu y dépensera 1000 fois moins d'énergie qu'à essayer de recruter et d'encourager un programmeur amateur

Moi c'est ce que j'ai fait, ben ça marche
Merci pour vos réponse à tout deux.

Sephi-chan, je connais bien tout ça et j'ajouterai deux points qui sont les aleas de la vie et la rumeur qui veut qu'un certain nombre de codeurs travaillent pour le challenge et non pour la réalisation complète d'un projet. C'est à dire qu'une fois leur défi personnel relevé, le reste n'est plus motivant, donc on arrête.

Mais ça ne m'empêche pas de me demander de quelle façon on peut se prémunir de tout cela, et de chercher.

Quant à ta dernière remarque, c'est celle que j'ai du entendre le plus souvent au final. Normal, quand on sait coder, on a ses propres projets. De même qu'en général les graphistes ont les leurs également.




Tigrounette, j'ai vu l'évolution de ton projet de loin et il m'impressionne beaucoup.

J'en ai suivi un tas d'autres, effectivement pour un projet qui voit le jour, cent mordent la poussière. Mais même constitués d'inconnus, certains finissent par créer quelque chose. Tiens, je vais citer Dirty Conscience par exemple, un projet que j'apprécie beaucoup. Ils ont une démo jouable quelque part, avec une ambiance graphique de toute beauté. Bon, ça leur a pris quatre ou cinq ans, certes. ^^ Mais je crois qu'ils ont beaucoup appris durant tout ce temps.

Effectivement, j'aurais pu apprendre à coder, c'est même une question que je me pose régulièrement. Mais quelques points m'ont retenue :

- Wimd, c'est un terrain d'expérience. Entre autres choses, l'idée est d'apprendre à travailler en équipe. Comment puis-je tirer des leçons sur le travail d'équipe si l'équipe se résume à moi même ? ^^

- Ces efforts de communication ne sont pas vains, c'est en apprenant à clarifier mes propos que j'ai aussi pu me préparer à parler de ce que je fais professionnellement. C'est en faisant des recherches sur la question que j'ai aussi mieux compris ce domaine et rencontré des gens qui m'ont encouragée à aller de l'avant. Pour expliciter un peu, je suis level-designer depuis quelques temps, pas directement graçe à wimd mais tout ce que je viens de mentionner y a contribué.

- Wimd, c'est une démo. Ca signifie qu'il y a un projet derrière, un peu plus conséquent. J'en ai encore plein d'autres dans mon sac, c'est vers les métiers du gamedesign que je me dirige alors c'est principalement là dessus que j'essaie d'expérimenter. Si j'apprend à coder Wimd seule, ce sera chouette. Mais ensuite, quand j'aurais à nouveau besoin de comprendre comment faire avancer les choses à deux, ou trois ? Et si jamais un jour je rejoins ou monte une petite boite toute neuve, sur quelles expériences pourrais je compter ? La chance ne suffira pas.

- Je partage déjà mon temps libre (très réduit depuis que je bosse :/) entre le design et le stylisme. J'essaie de me maintenir à niveau là dessus, et ça prend du temps. Si je veux apprendre assez pour pouvoir coder WIMD, je devrais abandonner l'un des deux autres. Et professionnellement, ça risque d'être une perte conséquente de qualité d'apprentissage et de travail. Pas envisageable, ça.

- Wimd, ça aurait du voir le jour en quatre mois. Même si je travaille dessus de temps en temps pour le refresher, j'ai d'autres projets et d'autres engagements, je ne peux pas passer tout mon temps sur un projet qui reste assez fidèle à lui-même et ne me permet pas d'explorer d'autres tendances. Ca rejoint un peu le point précèdent, sauf que je ne travaille pas forcement seule et que des gens attendent donc que je tienne mes promesses.

- Mettons qu'un jour je rencontre enfin la perle rare grâce à ce projet, que pourrait il advenir ? Si c'est un équipier compétent et que ça le branche, il est bien possible que je m'arrange pour pouvoir bosser avec lui. Et c'est comme ça que la sphère pro dans laquelle j'évolue progresse, en rencontrant des gens qui s'en sortent bien et en leur ouvrant des portes. C'est un discours que les gens qui m'ont aidée tenaient et que je ne comprenais pas trop avant, mais c'est pourtant simple, le jeu vidéo en France est un petit monde, c'est en enrichissant le marché du travail qu'on a le plus de chances de tomber sur de bons collègues plus tard. Alors ça me fait une raison de plus de continuer à prospecter. :]

Voilà, les choses peuvent évoluer, peut être que je changerai d'avis avec le temps ou que je trouverai d'autres alternatives pour wimd. Mon métier me porte un peu vers l'apprentissage de certains langages de script, je bidouille un site en php en ce moment, peut être que j'irai plus loin. Pour l'instant, ce n'est pas la direction que j'essaie de prendre, mais on verra. ^^




J'espère avoir à peu près su expliquer ce qui me motivant sans m'être trop étendue sur mylife, même si évidemment, un projet perso reste un projet perso et qu'on aurait du mal à dissocier les deux.. En tout cas, merci à vous deux d'être intervenus, ça m'a fait réfléchir et ça m'a aidé à redéfinir certains points de ma démarche.
Je serais-toi, Ebe, plutôt que de demander à mes collaborateurs programmeurs : "aidez-moi à faire WIMD", je leur demanderais : "aidez-moi à faire mon système de connexion", "aidez-moi à faire mon système de frizes", "aidez-moi à faire le système de dons", etc...

Sauf si tu as déjà adopté cette approche évidement, je pense que ça devrait t'aider beaucoup à obtenir des résultats plus rapidement.

Bien sûr pour être capable de faire ça, il faut d'abord définir les différents "contrats" que partagent les différentes parties de ton application.

Si tu veux de l'aide sur ce que je t'explique là, je peux t'aider, là dessus ça devrait pas poser de soucis, comme cela devrait pas me demander énormément de temps/investissement.
Eh bien, disons déjà que si les gens qui se proposent partent du principe qu'ils ne font que m'aider, c'est mal barré. L'idée, c'est que chacun en retire quelque chose. Un codeur qui ne propose rien qu'une idée de base et son code n'invite pas les gens à l'aider, mais à le rejoindre. Pourquoi est ce que le fait que la situation soit inverse et différée dans le temps devrait changer cette donne ? Il y a des choses à retirer de cet échange, je ne cherche pas un exécutant, et c'est aussi pour ça que je laisse le projet vivre sa vie entre les mains des gens qui voudraient y toucher. Ca n'est pas un truc figé, "faites moi ça", c'est une base. Comme dans n'importe quel projet amateur, il y a des trucs qu'on a pas envie de voir bouger, d'autres sont très libres. "On va faire un projet ensemble".

Du coup, je ne sais pas, ta proposition rejoint le conseil de Tigrounette même s'il se rapproche plus d'un travail d'équipe. C'est pas un mauvais compromis du tout, et puis j'ai cru comprendre que le principe des missions ponctuelles te bottait bien. Si c'est le cas - si tu y crois - pourquoi pas. Si ça marchait, ça pourrait peut être diversifier le principe du recrutement de projet.

Par contre effectivement je ne suis pas capable de définir moi-même les différentes missions qui pourraient composer WIMD. A la base, c'était le travail de Fenn, ce qui garantissait que le projet reste réalisable et raisonnable, je ne me suis preoccupée que de ces limites et pas du coté réalisation de la chose..

Je crois que tu es encore quelqu'un de très occupé, donc vraiment je te remercie de ta proposition qui est super sympathique. :] Ce serait avec plaisir, rien que pour celui de discuter à nouveau avec toi. On ne te voit plus beaucoup ces temps ci, sur l'irc, c'est triste. :|
Question de priorités.

Pour ce qui est de définir les missions, c'est ce dont je t'avais parlé succinctement la dernière fois : c'est à toi de définir ces missions, simplement parce qu'à l'origine c'est ton projet, c'est toi qui connait le mieux ses tenants et aboutissants.
Alors, va falloir apprendre à le faire ;-) En plus ça fait un truc à mettre en plus dans le CV, c'est pas plus mal.

Sephi-chan parlait de découper le problème en petits morceaux me semble-t-il....

Essaie de séparer les diverses fonctionnalités de ton projet en différentes sections.
Du genre ce qui a attrait aux comptes, ce qui concerne les dons, les guildes, tout ça...
Ca, c'est déjà fait, c'est ce qui délimite les principes enoncés dans le gdd (que tu as lu si je me souviens bien). Mais ça ne correspond pas au design d'un code. Et pour savoir ce dont on a besoin pour le code, eh bien, logiquement il faut savoir coder.

Serpent qui se mord la queue ?
Je ne pense pas que fragmenter le programme en unités logiques et fonctionnelles induise de savoir coder. Bien sûr, avoir un développeur à tes côtés te permettra de voir les chose d'une façon plus pragmatique.

L'idéal serait de mettre au point un modèle de base de données et de classe. Ceci permet de poser complètement le problème, du côté du développement.

Ainsi, tu pourrais par exemple définir les propriétés et actions (dont le nom est ici suivi de parenthèses) de chaque entités du jeu, qu'elle :

Code:
Dryade {

	Dryade.Nom : // Vrai nom de la Dryade
	Dryade.Identifiant : // Nom affiché sur les canaux
	Dryade.Sève : // Sève restante
	Dryade.Chrysalide : // Activé ou désactivé
	Dryade.Don : // Nom du don possédé par la Dryade
	Dryade.Localisation : // Lieu actuel où est située la Dryade
	Dryade.ScoreRéputations { // Stock le nombre de points de réputation "gagnés"
		Truand-Sentinelle : // Total de réputation Truand-Sentinelle
		Shaman : // Total de réputation Shaman
	}
	
	
	Dryade.Parler(message)
	Dryade.Crier(message)
	Dryade.Chuchoter(cible, message)
	Dryade.VoterRéputation(cible, typeRéputation) // typeRéputation = Truand/Sentinelle/Shaman
	Dryade.IncanterDon()
	Dryade.Mordre(cible)
	Dryade.SeDébattre()
	Dryade.Chrysalide()
	Dryade.Manger(nourriture)

}
Code:
Truand (extension de Dryade) { // Nouvelles propriétés et actions ajoutées à la Dryade si elle a un ScoreRéputations[Truad-Sentinelle] négatif

	Truand.Camouflage : // Activé ou désactivé
	
	Truand.Camoufler()
	Truand.UsurperIdentité(cible)

}
Code:
Don {
	
	Don.Nom
	Don.Effet
	Don.CiblePermise {
		Allié // Oui ou Non 
		Ennemi // Oui ou Non
	}
	Don.Formule { // Associe une position à chaque mot de la formule
		1 : // Premier mot de la formule 
		2 : // Deuxième mot de la formule
		...
		n : // Nième mot de la formule
	}
	
}
Ceci n'est qu'un exemple de modélisation, que chacun, codeur ou non, peut mettre en place. Avec un tel modèle, le travail des développeurs est vraiment simplifié : Ils n'ont plus qu'à en faire découler leurs classes et les éléments de la base de données.

Si tu es intéressée par la mise en place d'un modèle de ce genre, je serais ravis de t'aider. Toi seule peu définir tout ce qui ne l'est pas dans le GDD, c'est à dire la documentation précise du jeu : la liste des sorts, leurs effets, la manière de les générée, etc.



Sephi-Chan
Ca ressemble au sommaire du gdd de wimd (le vrai, celui que vous ne trouverez pas sur le net et qui contient des chiffres ). Je ne suis pas sure de saisir ce que ça change, si l'organisation reste la même que celle que la logique commande.

Et la je vais me répéter, mais entre la logique humaine et le design de programmes il semblerait qu'il y ait quand même un fossé. Je ne peux pas deviner qu'untel aura besoin de tel système pour pouvoir coder tel autre. Ca semblera évident à un codeur, pas à moi.

.. Qui n'ait d'ailleurs aucune notion de ce que demande le coeur d'un jeu réseau, tout ce qui n'est pas features de gameplay : le système de comptes, de connexion, la securité, les identifiants, les pass, ... Techniquement, comment ça s'agence ? Aucune idée.. :/ Enumerer les besoins, je peux faire, mais les organiser..

Donc au final je veux bien effectuer ce travail, c'est pas bien long, c'est le détail de mon sommaire. Mais je ne sais pas trop ce que je pourrais en faire et encore moins si ce sera valable....
Le faire permettra aux développeurs de coder chaque chose sous forme d'unités fonctionnelles et logiques : pensée pour le codeur. On se rend tout de même compte qu'au final, c'est la documentation la plus brute et la plus efficace qui puisse être, même s'il elle n'a pas l'avantage d'être très digeste.

Coder avec un tel modèle devient une partie de plaisir puisque tout est posé : il n'y a plus qu'à coder sans avoir à embêter le gamedesigner et donc attendre ses réponse : le développement est accéléré et on n'oublie rien.

Je pense que le plus difficile dans ton cas, c'est de suffisamment "éclater" le fonctionnement de tes Dons de l'Âme.

Si tu le fais, liste un maximum de chose, s'ils ne sont pas bien organisée du premier coup, ceux avec qui tu le fais ne manqueront pas de te le faire savoir et de te conseiller sur l'organisation.

Concernant les modèles systèmes, ils sont les moins importants puisque souvent proche d'une application à l'autre.

Par exemple :
Code:
Joueur {
    
    Joueur.Nom
    Joueur.MotDePasse
    Joueur.Email

    Joueur.Connexion()
    Joueur.Deconnexion()
    Joueur.MessagePrivé(destinataire, objet, contenu)
    Joueur.ChangerMotDePasse(ancienMotDePasse, nouveauMotDePasse) 

}
Ce n'est encore qu'un exemple.

Si tu veux de l'aide pour mettre au point un modèle, je peux t'y aider via Hotmail (mon adresse est dans mon profil) ou autre messagerie instantanée (ou à défaut, par email) : je suis sur mon ordinateur presque toute la journée à l'école, et bien souvent disponible.



Sephi-Chan
Mais on a déjà plus besoin de demander de l'aide. Le gamedesign document ne sert pas à faire joli... En pratique, je peux disparaître demain : les personnes qui ont ce gdd et les ressources graphiques sont capable de développer le jeu complet sans moi. Si elles suivent ce qui est écrit, c'est wimd. Maintenant il y a des points moins detaillés car laissés à l'appréciation de l'équipe travaillant dessus, ce sont les zones de liberté dont je parlais et je tiens à ce qu'elles existent : la différence entre des développeurs travaillant sur un jeu et des exécutants vient de là.

J'ai un peu réfléchi à tout ça et finalement ça me laisse assez sceptique, je ne vois pas comment quelqu'un qui travaillerait juste sur le développement du système de morsures des chaussures de l'archeveque pourrait bien se sentir partie prenante du projet.. Et là, on s'éloigne beaucoup du travail d'équipe que je recherche.

C'est peut être plus dur et plus long avec la méthode que j'emploie, mais ça me semble aussi beaucoup plus humain...
Le problème, c'est que voir un gamedeisgn comme ça peut effrayer le développeur.

On a l'impression que le fonctionnement détaillé n'est pas défini. En particulier sur les points très évasifs comme celui concernant les Dons de l'Âme (alors que c'est un point clé), la façon de les générer, leurs effets.

L'idée en listant le tout n'est pas de fixer aux développeurs un plan figé, mais bien d'avoir une documentation suffisemment précise pour pouvoir déterminer seul les besoins logiciels sans l'aide du gamedesigner : cela n'exclue pas de discuter des différents points du gamedesign avec les développeurs. Au contraire, ceux-ci étant au cœur du mécanisme, ils sont à même de déterminer ce qui risque de ne pas aller.

Cette manœuvre n'est pas là pour déshumaniser le développement, seulement pour l'organiser d'une manière optimisée. De plus, quand les choses sont bien posées dès le départ, le travail de maintenance, de suivi et d'amélioration est simplifié.


Sephi-Chan
Ebe, je crois que ce qu'il te faudrait, c'est un pote irl qui est développeur et que ton projet intéresse. Si j'ai tout suivi, ce que tu cherches ce n'est pas à déléguer ton projet, mais à le faire avance avec d'autres gens, en gros pouvoir dire au développeur j'ai ca et ca en tête, t'en penses quoi et ensuite avoir quelques discussions avec lui et le laisser parfaitement libre de faire ce qu'il veut.

Pour ça, il y a deux solutions : ou bien faire ça avec un/des pote(s), ou bien recruter sur le web. Dans le premier cas, c'est pas dit que t'aies des potes (), que certains de ces potes fassent du développement, et qu'en plus il y en ait un suffisamment intéréssé et motivé. Dans le second cas, tu vas te taper 20 demandes de mecs qui ont jamais rien codé de leur vie, ou qui ne savent pas coder proprement, ou qui ont aucune méthode, ou autre, pour une seule (voire aucune) candidature valable.

C'est dans le fond la raison pour laquelle je me suis décidé à développer mes projets tout seul (que ce soit mon projet de jeu ou les autres trucs que je code), avec eventuellement des gens qui viennent se greffer pour faire évoluer le produit une fois qu'une première version est sortie.

Bref, je ne vois pas trop de solution pour toi... Je t'avoue que wimd me tente, mais j'ai trop de projets, et j'en ai un peu marre de coder des UI ces temps ci
Sephi-chan, tu confonds la traduction du gdd que tu vois sur le site de wimd et qui est volontairement littéraire et le vrai gdd que tu n'as jamais lu et que je n'ai donné qu'à cinq personnes. Quand je parle du gdd utilisé par les codeurs, c'est de ce second document que je parle.

Vyol, à la base Wimd n'a été initié de cette manière que parce que Fenn, Dru et moi étions justement dans ce cas de figure. Maintenant, la proximité n'a pas suffit à finaliser le projet. Maintenant, je pense quand même que c'est plus simple que via le web, mais pour l'instant les programmeurs de mon entourage proche ont déjà des projets en cours. Quand à en parler aux autres, eh bien j'y travaille.

En tout cas merci pour ton intervention, ça me fait quand même plaisir et ça me motive un peu de voir que les gens ne restent pas de marbre.

Je vais poursuivre mes recherches.
Bien le bonjour !

J'ai deux mois de retard sur mon propre planning mais je n'avais pas donné de nouvelles de la chose de ce coté du web. En ce moment donc, je bosse sur un site plus visuel et agréable, plutôt orienté démonstration du jeu / aide aux joueurs. Il s'agit en fait d'un site/blog qui doit contenir une série de strips explicatifs. L'habillage de l'espace web m'a pris un moment - je ne suis pas très productive et le php m'a fait bobo.. - je commence le design des persos qui devront présenter le jeu.

Comme l'un d'entre eux à l'air d'avoir du succès, je vous le poste et j'en profite pour vous demander si pour vous, ça correspond à l'esprit wimd.

Voici donc pour rappel l'interface du jeu :

http://fenntasy.com/wanuts/ebene/images/Filigrane/exemplewimdTO.jpg

Voici l'habillage presque définitif du blog :

http://fenntasy.com/wanuts/ebene/images/Filigrane/blogwimd1.jpg

http://fenntasy.com/wanuts/ebene/images/Filigrane/blogwimd2.jpg

http://fenntasy.com/wanuts/ebene/images/Filigrane/blogwimd3.jpg

Voici quelques personnages choisis dans mes recherches actuelles :

http://fenntasy.com/wanuts/ebene/images/Filigrane/todry4.jpg

http://fenntasy.com/wanuts/ebene/images/Filigrane/todry2.jpg



... Ceci dit vous trouverez plus d'images et de détails sur le principe, ici et . :]
Bonjour à tous,

Après quelques discussions avec Ebene, j'ai eu l'autorisation de tenter à mon tour l'expérience Wimd. J'espère que cette fois-ci, je réussirais.

Cette décision a été prise durant la première partie du mois de juillet 2008. Juste avant mon départ en vacances, pendant lesquelles j'ai passé une petite semaine à commencer à mettre les mains dans Wimd. Voilà ce que ça a donné :
http://img116.imageshack.us/img116/8384/wimdcapture1qz5.png

Comme vous pouvez le voir, c'est simpliste, tout en proposant, en plus de la génération du plateau de jeu, quelques fonctionnalités de bases de Wimd telles que :
  • Les déplacement dans et entre les plateaux de jeu (symbolisés par les artworks) ;
  • La possibilité de parler et de crier (avec la résolution des portée, on ne peut pas lire un message posté avant que l'on ne soit présent, et pas s'il a été dit trop loin de nous) ;
  • Se présenter aux autres, avec en prime la gestion des usurpations d'identité (A se présente à B sous le nom de C).

Du côté technique, le jeu est développé en PHP à l'aide du Framework CakePHP, et reposera probablement sur une base de données PostgreSQL (actuellement, j'utilise une base MySQL, mais je pense changer pour pouvoir profiter de certaines fonctionnalités). La partie cliente sera développée de manière assez classique, du XHTML/CSS avec une grosse dose de Javascript (développé avec la librairie jQuery) pour plus de confort.

J'espère que cela redonnera un peu d'espoir à ceux qui croyaient et appréciaient ce projet. Je tenterai de proposer rapidement des versions jouables (même minimalistes) afin de permettre aux gens de tester un peu ce qui est fait ou n'est pas fait, ou simplement de voir ce à quoi ça ressemble.


Sephi-Chan
Citation :
Après quelques discussions avec Ebene, j'ai eu l'autorisation de tenter à mon tour l'expérience Wimd.
Genre "l'autorisation de tenter"... Je ne mords personne en vrai, pas même toi !
Pour être précise, Sephi est venu me voir en disant "salut-je-peux-coder-ton-jeu-au-fait-j'ai-déjà-commencé...!". J'allais pas refuser, c'était mignon comme tout.

Donc il est dessus, ce qui me force à bouger plein de trucs parce que môssieur veut du tour par tour, des infos sur le système de quêtes pas finies, cent balles et un mars. Ça tombe bien, j'avais pas le temps.

Du coup comme il a l'air d'avoir envie de remuer des montagnes, peut être que WIMD a une chance de voir le jour.

Corrolaire, si WIMD est développé, je fais les graphismes de Seelies.
News groupées.

Tout d'abord, le site sur lequel sont entreposés depuis bientôt deux ans les visuels, quelques histoires et surtout le détail du gameplay de WIMD vient de subir une petite mise à jour. En-tête un peu plus agréable, modifications mineures du contenu et surtout, surtout, des pages bien plus courtes et mieux indiquées sur le menu. Je n'ai modifié aucune adresse : aucune raison de s'affoler si vous pointiez dessus car rien n'est supprimé. En revanche la page d'accueil est disponible via un lien plus court : http://fenntasy.com/wanuts/wimd.html

Ensuite Wimd m'inspire bien évidemment lorsque je réfléchis à des problématiques de gamedesign. Puisqu'en ce moment j'écris un peu sur la question, j'ai quelques morceaux de texte en relation avec ce webgame. Dans un premier billet sur le public auquel on s'adresse pour son jeu , Dans un second billet sur la morale et la façon dont on présente son jeu .

Enfin je viens de publier le système de combat de WIMD, mais le voici directement ici :

Citation :
Un joueur (cA : chef agresseurs) décide de combattre un joueur (cB : cible brutalisée). Deux options : soit c'est pour rire ou s'entraîner ! Dans ce cas, c'est un défi, on y perd pas de vie – mais les transactions sont réelles – et le combat doit être accepté par l'agressé pour avoir lieu. Soit c'est une vraie méchante attaque, une agression, et dans ce cas cB n'a d'autre choix que se défendre. Chaque équipe peut atteindre trois membres, un combat peut donc accueillir six joueurs.


Lorsque le combat débute, on commence par ramener les copains pour faire plus mal dans le cas de cA, et de crier au secours pour pouvoir en sortir vivant, dans le cas de cB. En tout cas, ils en ont la possibilité. Durant cette phase et pour toute la durée du combat les protagonistes se retrouvent sur une grille de combat, une instance donc, isolés du reste du monde – qui pourra tout de même consulter les détails du combat en chiffres pendant son déroulement.


Pour qu'ils puissent rejoindre le combat, cA doit appeler ses amis dans une liste des gens qui se trouvent près de lui. Ceux là peuvent refuser, ou demander un paiement pour agir qui suivant les modalités de la négociation sera automatiquement libéré si l'issue du combat est bonne, ou simplement pour avoir été là. Le prix convenu peut être un point de réputation de la part de cA, un point spécial si cA peut en délivrer, une goutte de sève de cA si ça ne le tue pas.


cB quand à lui peut appeler à l'aide et accepter ou refuser les proposition au fur et à mesure qu'elles lui parviennent. Le même système de négociation existe de son coté, et enfin cette étape se fait en temps limité mais comme elle est primordiale, sera clairement montrée comme une phase décisive du combat. C'est aussi à ce moment que les canaux d'équipes seront disponibles afin que chacun organise sa stratégie et informe ses coéquipiers de ce qu'il fait, et que les joueurs pourront choisir leur placement sur les cases disponibles de leurs équipes. Une fois cette phase terminée, le combat commence véritablement, chaque personnage agissant à son tour – dans un ordre que je n'ai pas encore établi.


Le combat se termine soit avec la mort de cB, soit avec la fuite de cB, soit avec la mort de l'équipe de cA et sa dispersion (j'y reviens plus tard), ou bien avec une négociation entre cA et cB : l'un ou l'autre demandent la reddition de l'adversaire, qui peut s'accompagner d'un paiement, en échange de la cessation du combat. Si cA meurt au cours du combat, ses équipiers se retrouveront fortement pénalisés – ils auront perdu leur tête, leur motivation et leurs éventuels gains ! .. Donc ça se ressent en jeu. En contrepartie c'est cA qui a la primauté sur la morsure des adversaires – étant le chef s'il y a un conflit sur la question c'est lui qui ramasse la sève ou le don de l'âme du mort. On ne peut pas mordre une personne de son équipe, sauf s'il s'agit d'un traître (voir plus bas).


Il y a plusieurs plateaux de jeux, chacun mettant en scène le principe d'une embuscade (cul de sac, goulet d'étranglement, barricades, ..). C'est à dire que les déplacements joueront énormément puisque dans un premier temps le joueur cB se retrouvera dans une impasse, isolé ou avec ses aides suivant les plateaux, et que ses agresseurs seront stratégiquement placés pour l'empêcher de fuir par l'issue (ou les issues) qu'ils bloqueront.


http://fenntasy.com/wanuts/ebene/images/Divers/areneswimd.png
Plateaux de jeux : les rouges attaquent, les bleus se défendent et les croix sont des points de fuite.


De fait sur ce plateau et pendant son tour de jeu on pourra avancer, bloquer quelqu'un, essayer de repousser quelqu'un qui nous bloque, et divers mouvements de cet ordre de façon limitée par tour de jeu. Autre point important, pour entendre l'Incantation de quelqu'un il faudra être tout près de lui. Pour gagner la sève (ou le Don de l'âme) de quelqu'un qu'on achève, il faut être contre lui et l'avoir mordu le tour où il meurt. Je rappelle qu'il est indispensable de connaitre l'Incantation du Don de l'âme de quelqu'un qu'on veut voler si l'on veut pouvoir utiliser son Don en le récupérant.


Les attaques sont basées sur l'utilisation des Dons de l'âme, les défenses également (si vous n'êtes pas familier avec le principe des Dons de l'âme je vous suggère de consulter le site dont l'adresse a été donnée plus haut), appliquées sur une ou plusieurs cases suivant différentes configurations et portées en fonction du Don. Le soin n'existe qu'en dehors des combats à heures fixes, toutes les heures et pendant dix minutes, ceci pour favoriser les attroupements et rencontres.


Naturellement on sort du combat avec ses blessures (ou mort), on peut néanmoins patienter jusqu'à l'heure du soin en se cachant dans un coin ou en utilisant son mode afk (je vous renvoie encore une fois sur le site de WIMD, partie "la chrysalide : afk et déconnexion").


Quelle que soit l'issue de l'agression, les personnages de l'équipe attaquante ne peuvent à nouveau directement combattre ceux de l'équipe de l'agressé, tout ceci pour éviter le harcèlement. Ils peuvent par contre se retrouver dans un même combat concernant d'autres protagonistes, en rejoignant ceux-ci s'ils les acceptent – y compris dans une même équipe s'ils le désirent. Les personnages (encore vivants) d'une équipe peuvent en revanche agresser leurs ancien coéquipiers, sauf dans le cas des traîtres qui sont plus ou moins considérés comme faisant partie de l'équipe adverse.


Les traîtres sont des équipier que le chef de groupe rejette. C'est un acte qui annule les négociations ayant fait entrer le personnage dans le combat et le pénalise fortement, en revanche celui-ci peut alors mordre ses anciens coéquipiers mourants et récupérer ainsi leur sève ou Don de l'âme, ou quitter le combat. Les traîtres ne comptent pas dans le nombre de personnage en vie dans l'équipe de cA donc lorsque ceux qui ne sont pas traîtres sont tous morts cA perd le combat s'il meurt : on parle de dispersion de l'équipe.


Enfin, les traîtres ayant rejoint une équipe en échange d'un paiement qu'ils n'auront donc pas, s'ils s'estiment lésés, peuvent attribuer un point de "mauvais payeur" à leur ancien chef d'équipe. Naturellement tout le monde le fera sûrement, mais c'est le nombre de points reçus qui permettront aux joueurs de reconnaître un chef d'équipe peu fiable qui rejetterait ses équipiers pour ne pas avoir à les payer.
A ce jour le système de déplacement, de chat, et une partie des réputations existent en terme de code, donc "ça avance".
Merci pour les encouragements.

Le projet avance doucement, de mon coté seulement parce que j'ai privé Sephi de game design document à jour. En attendant il mange des racines et moi des cas particuliers en essayant d'inclure le système de combat dont j'ai parlé plus haut au reste des mécanismes du jeu.

On va sortir un devblog dans quelques temps, dès qu'on pourra dire régulièrement des choses sur l'avancement du projet.

Il y a eu un petit article ici sur les habitudes quotidiennes des dryades, pour ceux qui aiment ce genre de détail.

Voiloù.
Je comprends mieux

Excellent projet, je te dois mes encouragements également alors !

Du reste, merci pour le billet dans ton blog ! Cela nous a fait très plaisir. Nous tacherons de t'accueillir dans notre petit cercle d'alpha-testeurs.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés