Gameplay / Programmation : Relation Contractuelle

[Seren]

Tout d'abord, bonjour à tous, c'est mon premier post ici.

Je suis encore dans la phase de définition pour un jeu qui sera un tapkaz "avancé", c'est à dire avec des options commerciales, diplomatiques, etc..

L'implémentation, ça sera du php/mysql avec peut être une ou deux touches de JS.

Parmi, les options que je veux proposer, c'est la possibilité pour les joueurs d'établir des "relations contractuelles".

C'est à dire qu'un joueur A peut proposer une mission/un objectif à un joueur B, et lorsque les objectifs sont rempli, le payement est automatiquement effectué depuis le compte du joueur A.

Je tiens particulièrement à cette option parce que dans la plupart des jeux auxquel j'ai joué, ça faisait cruellement défaut. C'est à dire que la plupart du temps, il n'y a qu'un contrat oral entre les joueurs, et il peut y avoir des mauvais payeurs à la fin ou de la mauvaise foi de part et d'autre.

Finalement, le manque de confiance limite les interactions entre joueurs à se foutre sur la gueule.

Types de relations contractuelles possible :
- escorter quelqu'un à certaine coordonnées ou lieu (= la personne doit arriver en vie et un seul morceau)
- livrer un objet à quelqu'un ou à un endroit
- saboter/assassiner un rival..


Maintenant j'ai un problème technique. Pour certains contrats, la vérification est assez facile. Par exemple l'assassinat, il suffit que à chaque mort je fasse un check sur l'existence d'un contrat ou non sur la victime.

Par contre dans le cas de la livraison ou de l'escorte, ça devient un peu un casse-tête. Je veux pas vérifier si chaque déplacement de chaque joueur va remplir les conditions pour un contrat.

La solution c'est déjà de mettre un flag sur quelqu'un si il est impliquer dans un contrat et de vérifier que les personnes flagués.

Mais j'ai peur de devoir quand même vérifier beaucoup de choses à chaque actions et de faire bcp de requêtes. J'ai éventuellement pensé à faire un check enfin de journée sur tous les évènements récents, ça me parait la solution la plus propre même si ça reste couteux.


Maintenant mes questions :
- est ce que vous connaissez un jeu qui implémente ce genre de fonction ?
- est ce que vous avez des idées de conceptions "élégantes" pour s'épargner un max de vérification ?

Je ne cherche par forcément une solution technique, si vous avez idées de règle plus simple que des "contrats" avec plus ou moins la meme finalité, je suis preneur.

(désolé c'est plutot un long premier post )

[the-gtm]

Tout d'abord, très bonne idée !

Ensuite pour la solution technique, mon conseil est simple : garder ça pour plus tard ! Fais déjà un jeu qui marche ce sera pas mal (rendez vous dans quelques mois si tu vas très vite). Si tu arrives jusque là (tout en ayant gardé ton idée en tête) tu pourras alors la mettre en place.

Le problème technique n'est pas simple, alors ne cherche pas à commencer par ce qu'il y a de plus compliqué !

[Seren]

Je comprends ton conseil mais je veux partir sur un design propre parce que ça m'intéresse pas de faire un Xème Tap Kaz, il y en a déjà plein de très beaux.

Je développe en partant sur le principe que le plus important dans un jeu en ligne, c'est les interactions inter joueur, et ensuite seulement le côté technique/Tap Kaz.

L'objectif ambitieux ( ) c'est un jeu :
20% politique
20% commercial
20% exploration
20% combat

et si il reste un peu de pourcent, il faudrait que le jeu soit amusant aussi .

En gros si je peux pas implémenter cette fonction, c'est inutile que je fasse le reste.


De toute façon, je vais avancer en parallèle sur le reste.

[Manest]

Je pense qu'il a raison. Concentre toi sur le game design avant de penser à la technique trop en détail. Quand tous les aspects de ton jeu seront clair, que tu auras mis sur papier ce que tu veux et pourquoi, tu pourras passer au comment.

Ton idée de contrat est bonne. Développe la d'avantage. Un des principaux problème et de savoir quel type de contrat utiliser et est-ce qu'il sera intéressant pour eu de le faire (c'est le problème de ta méthode, tu es obligé de lister les contrats possibles, les joueurs ne pourront pas contracter ce qu'ils veulent).

"livrer un objet à quelqu'un ou à un endroit" par exemple. Ça va supposer que l'environnement est suffisamment vaste pour que le joueur n'est pas intérêt à le faire lui même. Il faut savoir également si la livraison se fait à un autre joueur ou également à un PNJ, si oui, dans quel but il ferait ça? Ça va supposer aussi que certaines matières ai un intérêt à s'échanger. C'est logique mais pas évident dans tous les jeux.


Techniquement ça me parait simple à résoudre en l'état. Ça le sera d'avantage si tu t'es posé les bonnes questions au préalable.


Bref travaille encore d'avantage ton game design. T'es sur la bonne voie.

[OracleBA]

Je travaille sur la même chose actuellement, dans le cadre de l'introduction des techniciens et des Talents sur battle-arenas.

Mon approche est de considérer qu'un contrat n'est pas forcément rempli : comme dans la vraie vie, on peut signer un contrat et être en désaccord sur le fait qu'il ait été correctement rempli ou non.

Je considère donc les contrats comme un engagement mutuel entre les joueurs, en introduisant également une couche de Justice dans le jeu. Donc les joueurs peuvent convenir d'un acompte à la "signature" du contrat, et ensuite :

* les deux joueurs sont d'accord sur le fait que le contrat ait été correctement rempli => le solde est réglé, fin de l'histoire.
* désaccord, le client n'est pas satisfait (bonne ou mauvaise foi) et veut payer => procès dans le jeu.

Le fait que cette Justice soit gérée par l'Admin ou que les rôles de juges soient donnés aux joueurs est une décision de Gameplay. J'ai choisi la seconde option, ce qui complique le développement, évidemment (élections, etc.).

[Damascus]

Une solution possible : le tier neutre.

Lorsque deux joueurs concluent un accord, l'argent est prélevé immédiatement MAIS l'autre parti ne le touche qu'une fois le contrat rempli.

En cas de litige, l'argent reste là où il est jusqu'à ce qu'un accord à l'amiable soit trouvé. (avec un juge ou autre, à toi de voir).

[Ephleim]

Un petit avis technique pour avoir l'autre vision de la question :

Si tu as peur de passer trop de temps en vérification, prend le problème dans l'autre sens, traite tes contrats comme des actions complémentaires qui s'accrochent à tes autres objets du jeu.

Par exemple :
Contrat de livraison : le contrat est attaché au lieu (la case, la zone) et c'est lors d'une dépose dans le lieu que la validité du contrat sera vérifiée, et l'argent transféré

Contrat d'escorte : le contrat peut aussi être attaché au lieu, ou à la personne.

La chose à ne pas faire c'est de vérifier régulièrement toujours la même chose sinon (comme pour une gestion de collision dans les jeux temps réels) => Au revoir les perfs !

[Mindiell]

Dans MountyHall, il existe une action (1PA) pour valider une étape de quête. C'est à ce moment-là que la vérification a lieu et elle est forcément lancée par un joueur ayant une mission.

C'est simple, efficace, techniquement réalisé : Maintenant, tu peux te remettre à bosser sur ton game-design