|
Alpha & Oméga
|
Citation :
Après ce sera aux joueurs de savoir gérer s'ils ne veulent pas que cela lag dans leur donjon. Tous les concepteurs de NwN et SL ont appris à le faire, cela fait partie du jeu. La seule chose à quantifier c'est combien allouer au sous-programme qui va gérer la zone d'un DM. Et cela peut se faire grâce au paiement d'une ressource de jeu que le DM lui-même gagnera en fonction de son succès: plus de succès auprès des joueurs => plus de ressources en jeu => plus de ressources affectées à son instance virtuelle. Maintenant je ne dis pas non plus que cela se fait en un claquement de doigts, mais les techniques pour faire cela existent déjà, le reste c'est de l'huile de coude et des euros. Citation :
MMO = Massivement multijoueur.... rien dans ce termes n'indique un "univers" ni une "persistance", même si c'est assez commun parmi les MMO. Ensuite, même si on choisi cet axe, ce qui me va en soit, même si ce n'est pas une obligation dans la problématique posée, rien n'empêche le scénario d'un joueur d'être rejouable et répétable... mais rien ne dit non plus qu'il faut que cette répétition soit gratuite. On peut exiger d'un DM qu'il paie pour chaque spawn de loot, ce n'est ni affolant ni idiot... je dirais même que c'est nécessaire, sinon ce serait encore une création de ressource "ex-nihilo" et j'ai déjà expliqué plus haut qu'une telle chose ne peut pas être acceptée Dans cette optique, quand un DM va créer un monstre (source d'xp) ou un loot (source d'objet), il devra définir son nombre de spawn maximum et son délai de respawn. Il devra bien sûr payer à l'avance l'ensemble de ces spawns. Impossible donc définir l'existance d'un loot surpuissant et de le faire spawn indéfiniment... à moins de récolter assez de ressources entre chaque lors de spawn pré-payer pour commander le lot suivant. Citation :
Plutôt que des loots, on peu mettre des matières premières à looter ou récolter, et le jeu définira ce que les joueurs peuvent crafter avec, pas les DMs... ceci dit, cela ne fait que déplacer le problème: il faudra quand même faire payer le DM pour chaque spawn de la matière première, car sinon on se retrouve encore dans un cas de création de ressource "ex-nihilo" ce qui sera source de problèmes. Tout ce qui a de la valeur pour un autre type de joueur doit être payé comptant et unitairement par le joueur-DM pour pouvoir être créée. Ce qui me pousse à la réflexion suivant: Le DM doit en fait avoir deux types de ressources nécessaires pour faire son rôle. - Une ressource correspondant aux ressources physiques et techniques nécessaires à faire tourner son donjon. Acquérable uniquement par de la monnaie réelle, directement (paiement) ou indirectement (fréquentation de son donjon), elle sert à acheter et à entretenir les éléments de son donjon qui consomment des ressources. - Une ressource correspondant aux éléments ayant une valeur virtuelle. Elle sert à créer les éléments qui font office de récompense pour les joueurs: xp, or, matières premières. C'est elle qui doit être acquise en fonction de la difficulté du donjon, c'est à dire du nombre de morts qu'il cause... si un donjon tue 3000 PJs par mois, il est légitime qu'il puisse faire spawner une Excalibur ou deux dans le dit mois. |
19/09/2012, 14h47
|
Réflexion de fond pour: Faire créer le contenu d'un MMORPG par ses joueurs
| Suivre |
|
|
Partager | Rechercher |
|
Bagnard
|
Pas trop le temps mais quand tu entends "payer" tu parles du financement du jeu ? EJ voyais pas ta discussion comme englobant cet axe. J'écrirai quelque chose de plus complet ce soir à ce sujet.
|
|
19/09/2012, 18h32
|
|
[P.H.]
Alpha & Oméga
|
Citation :
Les contraintes, c'est plus concernant la montée en charge. Dans une application en temps réel comme un jeu vidéo, ça n'est déjà pas évident de s'assurer que le serveur ne ramera pas, même lorsque tout les joueurs se décident en même temps de faire les suites d'actions les plus coûteuses pour le serveur. Il faut généralement plusieurs mois/années post-release aux MMO actuels pour apprendre à tenir cette montée en charge. Si on donne un accès (plus ou moins) direct aux joueurs au processeur, le phénomène sera amplifié. Il est important de bien savoir cloisonner les possibilités offertes aux joueurs, et c'est à prendre en compte dans le gameplay, parce que concernant la faisabilité technique, il y a la théorie, et la pratique ^^' |
|
19/09/2012, 18h35
|
|
Héros / Héroïne
|
Pour ma part, je pense que le DM ne doit pas gérer entièrement les loots. Il doit juste pouvoir dire ce qu'il imagine comme loots et le nombre qu'il compte distribuer. Il pourra créer plusieurs tables pour un même boss/coffre et dire combien de loots de chaque table l(les) aventurier(s) recevra(ont).
Exemple pour un boss dont le DM aura décidé qu'il donnera des objets magiques : table1 : 0 à 1 loot - épée magique - dague magique - baguette magique table 2 : 1 à 1 loots - casque à protection magique - torse à protection magique ... table3 : 2 à 3 loots - matière de craft à connotation magique - tissus ... Ensuite c'est au jeu de déterminer la difficulté du donjon en fonction de: - des monstres du donjon. - leurs caractéristiques. - le nombre de joueurs qui meurent par rapport au nombre de loots effectués. En gros, je verrai bien le système suivant : les données fixes ( monstres et caractéristiques ) donnent une valeur de base aux loots. Et le ratio morts/loots effectués lors de la dernière semaine donnent des bonus aux loots. Je vois deux problèmes à ce système ( n'hésitez pas à dire si vous en voyez d'autres ) : - à la mise en place du donjon, le ratio n'existe pas encore, du coup il risque de moins attirer de monde vu que les loots ne seront pas encore très intéressants. - un gros nombre de joueurs peut se mettre d'accord pour se laisser mourir en boucle afin d'augmenter artificiellement la valeur des loots. Pour le premier problème, je vois bien la mise en place d'un système de récompense des aventuriers. Le but serait d'attribuer de la renommée en fonction de la date à laquelle quelqu'un finit le donjon. Ex : Le premier à finir un donjon gagne 100 de renommée ceux qui finissent le donjon dans la même journée gagne 80, ceux qui finissent dans la même semaine 50 et ceux qui le finissent dans le même mois gagnent 10 points de renommée. Ces points de renommées pourraient être utilisés pour acheter de l'équipement spécial. Ça pousserait les joueurs à tester les nouveaux donjons et cela réduirait probablement l'impact du second problème. Les éventuels loots gagnés lors de la première semaine ne devraient alors être distribués qu'à la fin de cette semaine afin d'avoir suffisamment de statistiques afin de déterminer la difficulté du donjon. Pour le second problème, j'ajouterai un système qui limite la qualité des loots en fonction de la valeur minimale d’équipement qui a suffit à un joueur/groupe afin de réussir le donjon. Si un joueur/ groupe à réussi le donjon avec un équipement ayant une valeur moyenne de 512, le stuff distribué ne pourra par exemple pas excéder 110% de cette valeur, soit 563. Qu'en pensez vous ? |
|
20/09/2012, 08h37
|
|
Empereur
|
Une solution pour éviter la répétitivité des instances des mmos serait de mettre des joueurs pour contrôler les Boss et autres montres des instances, au final, un donjon ne serait plus une simple étape à passer mais un véritable défi.
Avec un système de côte (elo) pour les joueurs et ceux qui contrôlent les monstres, on aurait un résultat vraiment intéressant. Bien sur pour que ce système tienne debout, il faudrait une énorme masse de joueurs et donc une grosse médiatisation. Un projet indépendant n'aurait aucune chance. |
|
20/09/2012, 10h19
|
|
Alpha & Oméga
|
Citation :
|
|
20/09/2012, 15h02
|
|
Invité
|
pouvoir creer ses propres quetes, avec un systeme de choix de mots clefs predefinis pour eviter les abus, du genre:
[La guilde TuroX] [vous rachete] [vos peaux d'ours] [pour 20 pieces de cuivre] que se soit par une sorte d'hotel des quetes, de pnj, ou de pancarte plantées dans les villes. le mec qui accepte la quete a un temps pour l'accomplir, defini par le donneur de quetes. apres ca depends du jeu mais on peu imaginer des quetes plus compliquées qu'un simple 'va me chercher x ressources' genre, 'guilde TuroX recherche un garde a temps plein pour faire la ronde autour de son chateau, 3 heures par nuit, prime par ennemis/monstres tués. Payé au SMIC sans experience s'abstenir' j'ai dit plus compliquée, pas forcement plus fun 
|
|
20/09/2012, 20h01
|
|
Alpha & Oméga
|
-> il a un stock initial, quand il l'aura épuisé, c'est fini, faut repayer : pas le droit à l'erreur sinon CB$$ => un aventurier n'a pas ce problème, si il foire son perso, il peut en refaire un gratos. -> or il va FORCEMENT faire des erreurs au debut, le reglage des monstres / loots etc... pour trouver un truc qui fonctionne, c'est pas inné. ca demande du temps / test / reglage... ce système risque de couter une fortune aux DM avant d'arriver à un point de "rentabilité" (dans le sens, gagner plus que ce que cela coute pour pouvoir faire grandir son niveau). -> de plus, le joueur DM payera aussi un abo, ou pas ? si il en paye un, c'est double CB$$... :X mais si il n'en paye pas, çà veut dire que sur un compte on pourra pas faire les 2... ce qui n'est pas tres pratique... |
|
21/09/2012, 10h18
|
|
Alpha & Oméga
|
Tes points sont intéressants, Gardien. Mais les problèmes cela se résout, il ne faut pas s'arrêter dès qu'on en voit venir sinon on ne va jamais nulle part...
Dans le cas présent, voilà comment je verrais les choses après réflexion: Les comptes DM et PJ ne sont pas séparés, mais sont soumis à restriction: - Tu peux créer autant de PJs que tu veux, mais tu ne peux te logger avec que si tu es en train de payer abonnement: c'est en effet avec ces PJs que tu consommes le contenu, et c'est donc normal que ce soit quand tu veux les jouer que tu paies la marge bénéficiaire des devs, mais surtout les ressources techniques nécessaires à faire tourner le contenu qu'ils dévorent. - L'accès en DM est ouvert à ton ouverture de compte, avec des ressources initiales financées par ta boite de jeu. Si tes ressources de DM tombent à zéro, cet accès se ferme (la zone concernée avec, car il n'y a plus rien à faire dedans pour les joueurs: plus de monstres, plus de trésors, etc) et pour le ré-ouvrir tu dois acheter un ticket de réouverture contre euros... dans ce cas, tes ressources seront réinitialisées De cette façons, tu n'es pénalisé que si tu te foires... mais à la base tu ne paies rien pour être DM (la boite de jeu), donc, globalement sauf si tu es très mauvais, tu paieras quand même bien moins d'un joueur de PJ. |
|
21/09/2012, 16h27
|
|
Légende
|
RECAPITULATIF
Après la constatation que les jeux proposés finissent toujours par épuiser leur contenus proposition est donc faite de donner une part active au joueurs dans l'élaboration de nouveaux contenu à consommer faisant qu'un jeu ne s'épuise plus..... ou que tout au moins il le fasse plus lentement. je pense que dans un premier temps il est nécessaire de définir plusieurs paramètres sans les quels il me parait difficile de faire des propositions concrètes et constructives. un jeu qui propose au joueurs de contrôler l'évolution du jeu doit déterminer tres exactement les objets sur les quel le joueur peut interagir et les objectif que ce faisant il compte atteindre. DEVELOPPEMENT en effet le nombre d'option que les joueurs peuvent désirer développer est extrêmement vaste; un challenge pvp/pve avec plus ou moins de donjons un challenge pvp/ pve open world une IA des mobs programmable un pve et/ou pvp associé a des quêtes des règles économique (monnaie) un pve et/ou un pvp associé a une économie (extraction transformation distribution) des règles politique (interdiction) un pve et/ou un pvp associé a la politique (justice armée élection) des règles religieuses (auto discipline) un pve et/ou un pvp associé a la religion (enseignement monastère prêtres) un monde ou il y ait interaction entre religion économie et politique la possibilité d'éduquer (programmer) des pnj a réaliser des taches économie et politique et religieuses pve / pvp la possibilité de créer des objet de craft nouveau avec un objectif religieux économique politique la possibilité de développer un housing a tendance villa, village, ville...pve et/ou pvp la possibilité d'inventer des skill cac magique ou mecanique la possibilité de rajouter des emotes roll play je suis sur que j'en oubli et que vous pourrez rallonger la liste :-) Arrivé a ce stade je pense qu'il faut réaliser que chacune de ces proposition reviendrait a proposer au joueur les outils permettant de créer l'environnement dans lequel il veut évoluer et a lui donner la possibilité des les organiser pour qu'ils s'intègrent a l'ensemble du jeux et je pense qu'il est nécessaire de faire deux réflexions la première est qu'il est impossible de demander a des joueurs concentré sur leur game play de prévoir les grandes ligne de développent du Jeux. cela revient a dire qu'il est indispensable que pour chaque outil de développement proposés aux joueur une place soir prévu par les dev pour accueillir les proposition au sein d'une structure organisée. cela revient a accepter une vérité première et inéluctable: Les outils proposés aux joueurs ne peuvent être qu'un moyen de diversifier un ou des scenarios prévus d'avance et en aucun cas de donner au joueur le développement du jeu. la seconde consiste a pouvoir dans un monde unique tester la création et gérer l'échec des développement choisis par les joueurs. je pense que la forme la mieux adaptée est celle des serveur jumelée. Certains jeux ont développé plusieurs serveurs pour une même map afin de répartir l'affluence. je pense que l'idée est intéressante non pour gérer l'affluence mais pour permettre le développement de différentes hypothèses de jeu. Cependant cette proposition me tracasse car proposer différentes possibilités de jeu afin que le joueur détermine par ce qu'il va construire celle qui lui plait le plus est tout de même l'aveu d'un manque de clairvoyance de la part des concepteurs et implique forcement certaines lacunes quand a la vision globale du jeu. En conclusion je dirais que dans ce cas aussi les différents apport de contenus ne peuvent et ne doivent se faire que dans le cadre des prévisions faites par les dev pour le développement du jeu. Si a cela on rajoute que le problème de la programmation ou comme le dit moon le fait de scripter, il faut reconnaitre que très peux de joueurs possèdent la capacité ou l'envie de créer des environnements de qualité commerciale. il faut donc que la participation des joueur se limite a choisir tel ou tel propositions faites par les développeurs. je pense que la solution réside dans le fait que le joueur doit simplement organiser les éléments qui lui sont fournit et non pas les créer. on pourrait par exemple élaborer un jeu ou les moyens de défense des uns seraient les objectifs a combattre des autres. si l'on récapitule les argument prés cités on en arrive a la conclusion que pour définir comment ajouter du contenu a un jeu il faut tout d'abord donner une vision globale du jeu, quel sont ses ressorts et son mode d'évolution et c'est seulement a ce moment que l'on peut faire connaitre a partir d'éléments prévus d'avance de quels manière on peut donner l'impression au joueur qu'il participe a l'évolution du jeux et de quel manière il peut le complexifier. Dernière modification par alfomegawatt ; 04/10/2012 à 17h01. |
|
04/10/2012, 16h55
|
|
Alpha & Oméga
|
Ou tout simplement un système à niveau "ouvert".
Actuellement, tous les jeux qui sortent fonctionnent avec un level max, à partir duquel on enchaine ce qu'on appelle le "end game". Il faut donc que ce level max soit atteignable dans des délais plus ou moins raisonnable. Je me souviens d'un jeu nommé "La Quatrième Prophétie", où il y avait aussi un level max, mais: a) c'était un level tellement élevé et tellement long à obtenir qu'on comptait sur les doigts d'une main ceux qui y sont arrivés (sur serveur classique, bien sûr, pas ceux avec xp amélioré) b) il n'était pas nécessaire d'atteindre ce niveau pour affronter les dernières épreuves du jeu. L'idée, c'est qu'actuellement il y a peu de niveau, avec un gros gain de puissance par niveau. Pour moi il faudrait faire l'inverse: un petit gain de puissance par niveau, avec beaucoup, BEAUCOUP de niveaux. Déjà avec ça on augmente la durée de vie, et on vire cette connerie de end game qui nous a pourri toutes les sorties MMO depuis quelques années. |
|
17/10/2012, 22h37
|
|
Alpha & Oméga
|
Dans une première mesure je vois plutôt une liaison entre du thème et de la création de contenu.
Le thème est créé par les Devs eux-mêmes (qui prennent la casquette de GM), comme, par exemple, vous allez me créer une map dédiés au pvp. Vous avez tel et tel outils, restrictions, obligations a fournir. Création solitaire ou en équipe sur une période de temps donné (ca peut meme donner lieu a une nouvelel forme de e-sport avec un mois d'abo a la clé ou autre recompense pour favoriser la competition). Les GM valident la meilleure création et l'intègre au jeu. Les créateurs passent alors GM de leur création et font alors l'animation, réglementation, modifications mineures en temps réel ou non, main mise sur la gestion d'un boss (le GM remplace alors l'IA scripté). Les Devs reprennent la casquette de GM, un autre thème se lance, comme refaire un vieux donjon de début de jeu. On reprend la même chose. ça permet de mieux contrôler ce qui va être fait (le Devs fait office de contrôleur en désignant un desiderata pour le jeu - ce que le jeu a besoin). Mais laisse le contrôle du contenu aux joueurs en mettant certaines bornes. Pour ma part, dans les Neverwinter Night 1 et 2, ce qui a défavorisé ces deux jeux c'est l'éditeur en lui-même. On file un éditeur clé en main (et trop pensé "informatique") mais avec rien derrière et donc demandant trop de compétence (mapping, scripting, scénaristique, gestion réseau). Faut mieux partir d'un truc plus simple. Pas oublier que c'est des joueurs en face et pas des informaticiens. On peut très bien segmenter aussi le contenu comme les maps (pvp, pve, pvpve, rvr) suivant la base du jeu. Par contre le défaut que je vois c'est le contenu de système ne pourra pas être créé par des joueurs comme des métiers de fabrication (le syndrome des campagnes haut level pour ceux qui connaissent les jeux de rôles sur table ou plutot le probleme avec une table de loot traditionnel ^^). Demander aux joueurs de fabriquer une nouvelle classe sera aussi impossible car de facto on va se retrouver avec une création de skill puissant, etc etc (quoiqu'on peut aussi demander une classe stylé graphiquement (gun+katana!!), avec 1 skill aoe, 1 skill single-distance, 1 skill de regen dans ce genre la quoi ^^ - repassant le boulot aux Devs pour les manip de creation 3d, etc, en suivant les specification des joueurs). Donc faut quand même du contrôle derrière, des bornes et des limitations. Ca sous entend aussi beaucoup de discussion entre Devs <> Joueurs (ce qui serait pas un mal aussi car beaucoup de jeu ont de la communication d'autiste). Sans compter le renouvellement de contenu pour éviter de se retrouver avec 20 000 quêtes dans une zone de 10 mètres carrés, éviter 5000 map de pvp ou casser le copinage par une equipe de joueurs qui reste en place trop longtemps avec leur carte pvp ci-dessus par exemple ^^. Dernier point aussi, la base d'une montée de niveau traditionnel (je commence lvl 1, je termine lvl 100) est a proscrire car en plus du contenu il faut aussi trouver un équilibre au niveau de la puissance (ou sinon ça réduit le champ des possibilité si c'est automatique comme une puissance de monstre et redondant). Donc il faut trouver une autre progression beaucoup plus souple. Voila mon opinion sur ce sujet 
Dernière modification par Sonia Blade ; 26/10/2012 à 22h29. |
|
26/10/2012, 22h19
|
|
Empereur
|
Bah ya la loi de Sturgeon qui dit en gros "90% de ce qui est crée, c'est de la merde" ... c'est juste à prendre en compte, c'est pas forcément un tord. J'aime plutôt bien les trucs bien pourris
Si on prend pas ça en compte dès la conception on va vers de grandes désillusions. Dernière modification par GtB ; 29/10/2012 à 23h19. |
|
29/10/2012, 23h02
|
|
Alpha & Oméga
|
Je partage, hélas. Ça a quand même été pas mal prouvé.
Même sur des jeux comme NwN, où cas extrême mais parlant, un paquet de joueurs se contentaient de reprendre des modules clef en main juste pour .. Le plaisir d'avoir le leur. Où c'est eux l'chef, je suppose. Mais c'était exactement le même module que les cinq autres à coté. Une simple copie avec un nom différent. Après, dans le lot il y a des perles, heureusement. Mais à moins d'un bon système de filtre (et qui acceptera de passer du temps à filtrer des trucs pas intéressants ?), c'est mal engagé. Le système de filtre de Tigrounette, mentionné plus haut, marche bien. mais c'est parce que le contenu se teste en 2 minutes par xx joueurs. Donc l'élimination va vite. C'est donc forcément pas valable pour un donjon. Ceci étant dit, si c'est à la fois assez verrouillé pour que ça puisse pas être nul (ou que le joueur s'en morde les doigts), et assez libre pour permettre de la surprise, pourquoi pas. C'est sans doute faisable, mais probablement très très coûteux en temps de dev (ressources modulables et équilibrages..). J'ai découvert l'autre jour un trailer de jeu qui est visiblement... Exactement ce que tu propose dans le post d'origine. C'en est frappant. Reste à voir comment ils s'en sortiront, mais là comme ça sur le papier, c'est sympathique. |
|
12/11/2012, 18h21
|
|
Alpha & Oméga
|
NwN Online semble aussi reprendre quelques bases, cependant le manque d'outils de DMing me fait penser qu'on risque de se retrouver avec un simple jeu d'action avec un éditeur de cartes.
J'ai comme l'impression que les développeurs commencent enfin à faire le même constat que j'ai déjà fait depuis 4-5 ans, à savoir que sur un MMO, si on tente de satisfaire la consommation PvE des joueurs par une équipe de devs, on ne s'en sort pas au final. |
|
13/11/2012, 18h30
|
|
Alpha & Oméga
|
si vous voulez permettre tout ce que alfomegawatt à mis dans sa liste, vous avez pas vraiment d'autre choix que d'avoir un jeu open source (client et serveur)
du coup ça va directement à l'encontre de ce qu'il dit Citation :
après un projet open source c'est pas l'anarchie, il y a une liste de "TODO", les administrateurs valident et contrôlent les commit avec des build de test, c'est pas "je checkout à l'arrache, je découpe le code et je release/déploit ma nouvelle version"... en open source on a ryzom maintenant, mais pourquoi pas envisager un projet directement open un peut plus au norme actuel. mais concretement les gros projets open qui partent de rien c'est super rare, que ce soit blender, UNIX, etc, ils partent presque tous d'une société qui abandonne l'exploitation d'un produit. concrètement soit on veut un petit éditeur de map pour poser des module préfab et des mob dans le style de shootmania, soit on en veut plus et il faut oublié le user friendly, y'a un moment on demande pas à un "simple joueur" de recoder une IA, interface graphique kikoo ou pas. Dernière modification par Titan. ; 14/11/2012 à 01h19. |
|
14/11/2012, 01h13
|
|
Alpha & Oméga
|
L'open source est complètement contradictoire avec le but visé ici: On essaie ici de faire que le contenu puisse être créé par les joueurs pour pallier au fait qu'on aura jamais assez de devs pour alimenter une communauté de joueurs de MMO en contenu à la vitesse où ils le consomment.
S'il faut que les dits joueurs touchent au code du jeu (attention: je ne parles pas ici de simple scripting) pour créer le contenu, alors on retourne sur le fait que ce sont des devs qui créent le contenu, et on a juste admis des devs provenant des joueurs, mais on aura toujours pas assez de monde pour alimenter le contenu du jeu. Bref: il vaut mieux restreindre les possibilités de créations et rester sur du non-open, que de partir dans cette voie qui restreindrait l'accessibilité des moyens de création de contenu. Du moins c'est mon avis. J'ajouterais aussi que pour avoir travaillé avec de l'open-source, je ne vois pas du tout le principe s'appliquer à un logiciel de haute-disponibilité, comme l'est en MMO. Dernière modification par Moonheart ; 14/11/2012 à 12h09. |
|
14/11/2012, 11h54
|
|
Alpha & Oméga
|
Citation :
On peut faire le même système d'event que RPG maker le proposer aux joueurs et c'est user friendly et plein de possibilité. La programmation c'est trop complexe même les devs de la boite peuvent faire des bugs alors j'imagine pas si les joueurs doivent programmer pour faire une instance alors que même la compagnie utilise tout un tas d'outil préfabriqué. |
|
14/11/2012, 14h05
|
|
[P.H.]
Alpha & Oméga
|
Ca n'est pas contradictoire, juste différent, et l'open source permettra inévitablement d'améliorer la quantité de contenu. C'est ce qu'on comprit tout les jeux permettant d'être "moddés".
Half-Life n'aurait certainement pas été aussi riche qu'il l'a été si une partie de son moteur n'avait pas été open sources. Des développeurs "annexes" à l'équipe de développement principale permettent de diversifier les fonctionnalités du jeu, donc de toucher plus de monde, donc de toucher plus de créateurs de contenus, même ceux qui ne sont pas développeurs. Mais comme je le dis dans un post précédent, c'est peu envisageable dans le cadre d'un MMORPG dans lequel du contenu scriptable créé par les joueurs devrait être intégré dynamiquement à un serveur dédié sans vérification humaine préalable (ou faire péter le serveur à cause de joueurs-scripteurs maladroits ou mal intentionnés). Quand au logiciel libre en tant que tel, un jeu massivement multijoueurs sur ce modèle ne peut tout simplement pas fonctionner, parce que : 1) Il doit être financé. Des éditeurs de logiciels libres vendent des services autour d'un logiciel, pas le logiciel lui même. Le logiciel ne peut qu'être gratuit, puisqu'il est librement re-distribuable. Un jeu ne pourra pas empêcher les serveurs privés de pulluler et aura donc beaucoup de mal à générer du revenu. 2) Il doit imposer des règles. Impossible d'empêcher des triches au niveau du client dans un jeu totalement libre d'être modifiés. |
|
14/11/2012, 14h21
|
|
Alpha & Oméga
|
Je pense que vous ne réalisez pas qu'on parle ici d'une création de contenu sur une base quotidienne par des centaines de personnes.
Il est impossible d'administrer une telle chose manuellement pour valider les contenus un à un à mon sens, et l'outillage puis l'intégration automatique reste pour moi la seule option crédible. Les exemples cités précédemment démontrent qu'on peut faire bien plus riche encore qu'un open source avec un produit correctement outillé. NwN2 n'était pas en open source et à eu beaucoup de contenu créé. Second Life explose les records de contenu encore plus avec des possibilités de codage encore moindre. |
|
14/11/2012, 18h15
|
|
Alpha & Oméga
|
Citation :
De plus cela touche le gameplay. En dehors "du testeur de niveau" le jeu redevient bloquer. Pour moi l'open source c'est tout ouvert pour permettre de modifier ou reprendre si c'est pour améliorer le contenue d'un jeu/ le diversifier ce n'est pas la même approche. |
|
14/11/2012, 18h41
|
|
Alpha & Oméga
|
Citation :
pour revenir à ce que je disais dans mon précédent post, même si avec un bon editeur on peut faire à peut prét ce qu'on veut, les limites imédiates sont les assets, pour moi, faire uploader des assets par les joueurs est à exclure: vous partez du principe que le joueurs qui rajoute du contenu n'est pas developpeur (trés discutable à mon avis) il faut rester logique et ne pas en attendre d'avantage de l'infographie ou du sound design. mais en fait, avec cette logique là, pourquoi devrait on considerer que le joueur est game designer ou scenariste ? aprés tout, ce sont aussi des métier. du coup j'ai un peut de mal à saisir votre notion de ce que le joueur "normal" est capable de faire. |
|
14/11/2012, 19h09
|
|
[P.H.]
Alpha & Oméga
|
Citation :
Il faut garder à l'esprit que les serveurs NWN étaient sous la responsabilité de leurs administrateurs. L'administrateur savait quels scripts ou modules il mettait en ligne, et se devait d'être au courant des ressources demandés pour ce module. Si le module était trop gourmand, il en changeait, ou corrigeait le problème manuellement. Second-life est totalement libre, mais l'absence de contenu scripté par les joueurs réduit ses possibilités à du housing dont le coût en charge serveur est beaucoup plus facilement régularisable qu'un contenu scripté. Un jeu comme minecraft possède un gameplay indirectement scriptable (par le biais des outils mécaniques de certains blocs comme la redstone), mais n'est pas un MMO, et est très loin de pouvoir en être un (le jeu est très gourmand en matière de charge serveur, et des joueurs mal intentionné peuvent facilement apprendre à mettre un serveur sur les genous). Je ne dit pas que l'idée en soit est mauvaise, ni que ce débat est stérile, mais qu'il y a de réelles contraintes technique derrière qu'il est impossible d'ignorer pour une mise en pratique de toute ces idées. Exécuter des programmes dans un programme en étant capable d'en limiter les ressources, c'est précisement le boulot (l'un des boulots) d'un système d'exploitation multitâches, et c'est d'une sacré complexité à mettre en place. Est-il possible de décrire un scénario tout en permettant de limiter les ressources maximales utilisés, sans transformer le moteur de jeu en usine à gaz monstrueuse ? C'est un sujet d'étude pour pas mal de développeurs et game-designer. Le projet storybricks propose une solution très réaliste au problème de contenu créé par les joueurs, à la fois limpide pour le créateur et facilement intégrable au sein d'un programme informatique capable de surveiller les coût en ressources système, je pense que les personnes intéressés par ce topic trouveront beaucoup d'intérêt dans les articles écrits par son créateur (il y a pas mal de documents écrits en anglais et français par ce mec qui se baladent un peu partout sur la toile) |
|
15/11/2012, 00h31
|
|
Alpha & Oméga
|
Citation :
On le voit sur Second Life: avec des assets créés par les joueurs, le clients à besoin de télécharger un nombre astronomiques de contenu à chaque fois qu'on entre dans une zone, car il est impossible au programme de connaitre les assets qu'il contient à l'avance et donc qu'il doit les récupérer à travers la liaison internet "sur le tas". Résultat: un chargement de zone aux performances lamentables, où il faut parfois plusieurs minutes au programme pour pouvoir afficher tout ce qui est à portée de vue du joueur (et moins la liaison internet de joueur est bonne, pire c'est) De bonnes performances sur un MMOG ne sont possible que si TOUS les modèles graphiques sont présents sur la machine client AVANT que le joueur arrive à une zone qui les utilise (autrement dit, parce qu'on ne peut pas prévoir à l'avance à quel zone le joueur va accéder sans le brider dans ses déplacements, ce qu'on veut éviter sur un MMOG: les assets de tout le jeu, en fait) Il faut donc fatalement "limiter" les modèles, parce que les joueurs n'ont pas tous des disques durs de 150 Téra-octets La seule possibilité pour que les joueurs contribuent de nouveaux assets créé par les joueurs, c'est un système de soumission: Les joueurs soumettent leurs créations aux admins, qui sélectionnent une poignée de nouveaux assets, pas plus par mois, pour l'intégrer aux installations de base des clients. J'ajouterais aussi, qu'interdit l'upload d'asset est une question de qualité: Tant que tu contrôles les assets présents et utilisables, tu t'assures que la qualité graphique, sonore du jeu, reste bonne. Tandis que si tu permets aux joueurs d'intégrer automatiquement de nouveaux assets, tu auras fatalement beaucoup d'assets de qualité médiocre qui nivelleront les contenus-zones créées vers le bas. Imaginez aussi qu'une personne crée des briques inadaptées au jeu, comme des textures avec des représentations pédophiles, ou des objets de space-opéra alors que la thématique du jeu est héroique-fantastique... Bref, dans tous les cas, sur un MMOG où le contenu du jeu serait généré par les joueurs, la création d'assets par les joueurs n'est envisageable qu'avec un contrôle sévère par les admins du jeu sur leur upload tant sur leur forme, leur thème, leur qualité que leur consommation en ressources. Citation :
Il y a du script, et il y a des problèmes de performances liés à ceux-ci. Citation :
Rien que les systèmes Unix intègrent nativement une gestion CPU conçue pour protéger les performances des autres processus par rapport à un processus qui commencerait à se montrer sur-consommateur et qu'il suffit de savoir exploiter à travers son code. Je ne dis pas que tout est simple, mais cela ne semble complexe aux développeurs de jeux que parce qu'ils se penchent sur la question maintenant, à cause du boom des jeux onlines et des MMOGs qui amènent la question des ressources techniques partagées entre différents joueurs, alors que dans d'autres domaines du développement cela fait 20ans qu'on se penche sur la question et qu'on multiplie les solutions. |
|
15/11/2012, 11h40
|
|
[P.H.]
Alpha & Oméga
|
Je ne cherche pas à dire que c'est impossible, juste que ça coûtera du temps et que ça mettra en péril la stabilité du jeu.
Pour avoir déjà écrit à la fois des ordonnanceurs de système d'exploitation (merci la fac !), des moteurs de scripts, et pour faire du développement de jeu vidéos tout les jours au boulot, je peux t'assurer que si, c'est complexe. Extrêmement complexe. A peu près n'importe quel informaticien sait, dans les grandes lignes, comment fonctionne un ordonnanceur de système d'exploitation, c'est au programme de toutes les écoles qui s'intéressent un peu aux systèmes d'exploitation. C'est dans l'intégration de tout ça dans le reste de l'architecture serveur du jeu que la complexité du problème explose. Il suffit de voir comme les développeurs de GW2 ont miséré pour arriver à gérer correctement l'architecture multi-serveurs de leurs jeux : ça merdait vraiment costaud au début, et ça merde toujours pas mal lorsque leurs serveurs sont saturés (même si ça arrive de moins en moins). Pourtant, quand je vois la qualité générale du jeu, je n'ai pas l'impression d'avoir affaire à une mauvaise équipe de dev, loin de là. S'il faut ajouter en plus un moteur de script à une infrastructure pareille, ouille. Mais bon, faut-il vraiment aller chercher si loin ? Un simple moteur de script, ça n'est pas la bonne approche. C'est trop complexe, trop opaque. Trop peu ludique pour le commun des joueurs. Pour rendre la création de contenu par les joueurs, il faut parvenir à rendre ça plus accessible, et plus fun. Je me suis effectivement renseigné sur le moteur de script de second life, j'ignorais cet aspect du jeu. Mais il me semble vu par beaucoup de joueurs comme d'une bizarrerie inaccessible du commun des mortels, un contenu d'"élite". Même s'il semble malgré tout très apprécié par ses joueurs, je pense que dans le cadre d'un jeu vidéo, on peut trouver mieux. As tu jeté un oeil sur l'approche proposé par Story bricks ? Ne penses-tu pas que c'est une approche de la conception plus accessible et concrète, qui accrochera plus les joueurs que de sauvages lignes de code dans un script ? Dernière modification par 'Az ; 15/11/2012 à 21h19. |
|
15/11/2012, 21h10
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|