Aperçu de le beta 1, fonctionnalités, systèmes et bien plus encore!

Merci

Je voulais vous montrer le document «officiel», autant que possible, sans avoir à l’éditer. C'est ce que j'ai dit à l'équipe après que nous ayons fini de travailler dessus. Et je veux bien dire notre travail. CSE est un studio hautement collaboratif. Nous parlons, échangeons des idées, ne sommes pas d’accords, nous disputons, et — la plupart du temps — ceci est fait de manière professionnelle et respectueuse. Après tout, personne n'est parfait, n'est-ce pas ?

Merci à CSE !

Je veux simplement remercier toutes les personnes à CSE qui ont lu ce document. Je voudrais également remercier les gens qui ont passé beaucoup de temps sur ce que j'ai écrit avant que le document ne soit présenté à l'équipe entière, suggérant, commentant, questionnant, remplissant les blancs, etc. Et enfin, ceux qui ont passé beaucoup de temps dans la section des commentaires de ce document : une fois qu'il a été présenté à toute l'équipe, vous avez vraiment fait un excellent boulot aussi, et je vous en suis reconnaissant. Comme notre jeu, ce document est ce qu’il est grâce à notre travail commun.

J'ai gardé l'ancien document à sa place afin que nous puissions toujours nous y référer, ainsi qu’aux commentaires que nous y avons tous fait.

Ce document est maintenant pour nous le guide officiel pour la Bêta 1. Dans les prochaines semaines, Je ferai deux autres choses :

  1. Créer une version bien rédigée de ce document afin que nos Backers puissent le lire. Une fois ce document complet, nous le révèlerons petit à petit sur notre site web.
  2. Travailler sur une version «plus stylisée» de ce document, écrite du point de vu nos Backers.

Merci encore à tous, vous avez été super !

Merci à nos Backers !

Le trajet vers la Bêta 1 fut plus long que nous ne l’avions prévu l'année dernière. Nous vous adressons nos plus sincères et humbles excuses. J'ai toujours, et ce depuis l’époque Mythic, cru que les PDG de sociétés doivent assumer leurs responsabilités dans de telles circonstances. C'est ce que je fais encore une fois en faisant mon «mea culpa». Ceci-dit, ce n'est pas suffisant, tout du moins pas dans mon/notre opinion. Les mots ne sont que ce qu'ils sont — des mots. Ils peuvent être sincères, vrais, et plein de sens, mais dans ce cas, ils ne sont tout simplement pas suffisants. Nous devons faire mieux, et nous le ferons.

Pour commencer, en parlant au nom de tout le monde, ici, à CSE, nous vous remercions tous pour votre patience et votre soutien, vraiment. Cela compte tellement pour nous que vous nous souteniez encore, nous envoyez des cadeaux, et ne rendiez pas nos vies plus misérables. Vous n'imaginez vraiment pas combien c’est important pour l'équipe et moi-même de voir l'effort supplémentaire, que certains d’entre vous ont fait dans le but de nous soutenir avec des mots et occasionnellement des gestes. Cela a vraiment tout changé pour le studio, par moment.

De mon côté, j'ai déjà alloué plus d'argent au studio que ce que j'avais prévu à l'origine. J'ai ouvert un studio à Seattle et étendu l'équipe sur place. Nous ne vous avons jamais demandé d'argent supplémentaire pour payer ces dépenses, qui sont considérables. Heureusement, les résultats l'ont également été ! Au moment où vous lirez ceci, nous serons extrêmement proche du premier des tests SNS, revenus à 2100 ARCs/Bots, les systèmes des nouvelles compétences, des animations, et de VFX fonctionneront comme prévu, et l'attention des programmeurs se sera tournée plus que jamais vers le gameplay et non plus le côté technique.

Ce fut une longue route, bien plus longue que ce que nous n’avions prévu, mais nous sommes restés fidèles à nos promesses faites à nos Backers et maintenant nous sommes presque à l’étape suivante des tests. Comme toujours, nous vous remercions pour votre soutien, votre compréhension, et plus que tout, votre patience.

-Mark

Principes Directeurs

Quels sont les Principes Directeurs pour la Bêta 1?

  • Nous devons présenter un jeu qui, bien que n'étant certainement une Bêta 1 comparable aux tests de Bêta «presque finies» ou jeux déjà lancés dans d’autres pays» d'aujourd'hui, devrait être assez aboutie que nos backers soient excités à la perspective du processus de Bêta tests. La Bêta 1 est juste le début de notre processus Bêta, pas la version de test finale pour un jeu avec toutes ses fonctionnalités ou qui s'apprête simplement à être traduit et publié dans un autre pays.
  • Nous devons nous rappeler que la plupart de nos Backers ont attendu plus d'une année supplémentaire pour cette Bêta du fait de la ré-habilitation. Nous devons les récompenser pour leur patience, compréhension, et soutien. Il n'y a rien de plus important que cela.
  • La Bêta 1 devrait être plus orientée sur le côté «fun», autant que possible, pour les joueurs, que l'Alpha ne le fut. Bien que ce soit toujours un test Bêta 1, avoir plus de choses sympa à faire, comme les «Saturday Night Sieges» (Sièges du Samedi Soir) et autres tests/jeux du même genre, contribueront grandement à faire de la Bêta 1 quelque chose à laquelle les non-Backers, autant que les Backers, auront envie de participer pour le reste de l'année.
  • Les test Bêta 1 devront être aussi fiables que possible. Les imprévus arrivent, mais nous ne devons pas lancer des tests avec une version instable juste pour coller à un planning. A moins, bien sûr, que le but du test ne soit de trouver et de corriger l‘instabilité et que nous ayons besoin des backers Alpha, Bêta, et IT pour nous y aider.
  • Nous devons nous rappeler que les serveurs ne seront pas accessibles 24/7 en Bêta 1, donc nous devons avoir des versions accélérées des systèmes tels que la progression, l'artisanat, les constructions, etc. Ceci est détaillé dans mes documents sur l'artisanat, dans d'autres documents, ainsi que dans celui-ci. Cette aptitude doit être modifiable durant un test, si nécessaire.
  • Nous devrions avoir une feuille de calcul centralisée, pas en XML, pour toutes ces variables, car cela facilitera grandement le travail des designers sur ces valeurs, mais également celui des programmeurs, étant donné qu'ils n'auront pas à s'inquiéter de créer des feuilles de calcul, fonctions, etc… séparées.
  • Notes de MJ - Cette section du document reflète les «principes» fondamentaux de nos tests Bêta 1 et de notre société. J'ai utilisé ces termes de nombreuses fois par le passé, et ceux-ci sont l'équivalent des Principes Fondamentaux de Camelot Unchained. Ils sont destinés à servir de guide pour tout ce qui suit.

    Objectif de ce document

    L’objectif de ce document est de dessiner un schéma général du jeu, que nos joueurs peuvent s’attendre à voir de notre part à l’ouverture de la Bêta 1. Il sert également à présenter certains objectifs spécifiques pour l’équipe, alors que nous continuons à développer le jeu durant la Bêta et jusqu’au lancement. Ceci n’a pas pour but d’être une description complète de toutes les fonctionnalités de notre jeu, ou une plongée en profondeur dans tous les détails d’une fonctionnalité, d’un système, ou d’une mécanique particulière, mais plus une vue d’ensemble des choses que nous considérons comme devant être présentes à l’ouverture de la Bêta 1. Ce document a pour but d’être fluide, donc s’il y a des choses que nous devons sacrifier pour la Bêta 1, basé sur leur complexité ou autre, des choses que nous souhaitons remplacer par d’autres, je suis ouvert à toutes discussions à leur sujet.

    Dès lors que nous sommes satisfaits de ce document, une version plus rédigée sera fournie à nos Backers, afin qu’ils puissent voir ce à quoi ils peuvent s’attendre pour l’ouverture de la Bêta 1. Nous ne leur montrerons pas les éléments Bonus (expliqués ci-dessous) pour des raisons de compétitivité et pour «préserver ma santé mentale», étant donné que je vais devoir gérer les questions/commentaires/etc… de nos Backers, résultant même de la version rédigée. De plus, étant des éléments Bonus, ils sont plus bas dans la «chaîne alimentaire» du développement, que certains autres qui ont besoin d’être implémentés.

    Notes de MJ – La clé pour nos Backers ici est que ce document n’a pas pour but d’englober tout ce qui est prévu pour la Bêta 1, et certainement pas pour le lancement officiel. Il a pour but de vous donner une idée très claire de ce à quoi vous devriez vous attendre quand le jeu entrera en phase Bêta 1. Il n’a pas été écrit avec des explications sur chaque élément, détail, etc… étant donné que cela aurait poussé ce document à 100+ pages. Pensez plutôt à ce document comme la vision du Minimum Vital de la Bêta 1. 😊

    Clefs de ce document

    NOIR = Nécessaire pour Bêta 1.

    ROUGE/BONUS = Tout ce qui est en rouge n’est qu’un bonus pour l’ouverture de la Bêta 1, mais qui doit être ajouté au cours de la Bêta 1.

    VIOLET = Questions pour l’équipe de programmeurs. Toutes les anciennes questions qui ont eu une réponse ont été enlevées, seules les questions sans réponse et les nouvelles questions sont encore sur le document.

    BLEU = Question spécifique sur le design.

    Le matériel expurgé dans ce document se réparti dans les catégories suivantes :

    1. Citations/idées attribuées à des développeurs spécifiques. Cette information est dans notre document d’équipe, mais comme ceci est destiné à vous Backers, elle n’a pas sa place ici. De plus, comme certaines personnes risquent de ne pas aimer certaines des idées, je ne veux qu'aucun membre de CSE soit blâmé/attaqué personnellement. Si vous vous sentez l’envie de critiquer CSE/nos idées, blâmez moi (MJ), étant donné que j’ai écrit le document principal et ensuite approuvé tout ce qui est présent ici.
    2. Des éléments que nous ne souhaitons pas révéler pour le moment. Comme beaucoup d’entre vous l'ont remarqué, les idées venant de CU ont trouvé leur chemin dans d’autres jeux, tout comme des idées d’autres jeux ont inspirées CU. Ceci est normal, mais je ne veux pas donner à qui que ce soit une longueur d’avance sur nous.😊
    3. Matériel considéré BONUS pour la Bêta 1.

    Le Patcher
    Patcher

  • UI (Interface Utilisateur) améliorée pour les serveurs et personnages. Tous les bugs de l’UI devraient être fixés, afin que les joueurs puissent savoir quels personnages sont sur quels serveurs, lequel ils ont actuellement sélectionné, etc…
  • Le lien «Getting Started» devrait renvoyer vers le document «bienvenu dans la Bêta 1». Pour le moment il redirige vers le site web principal du jeu, et tous ceux qui peuvent atteindre ce point depuis le patcher sont déjà des abonnés, donc il n’y a pas de raison pour celui-ci de renvoyer vers cette page.
  • Un décompte du nombre de joueurs dans la partie discussion du patcher. Il sera très utile et nécessaire d’avoir un décompte quelque part, qui soit facilement visible pour nous et nos Backers. Nous devrions avoir la possibilité de voir combien de personnes sont dans chaque partie de notre système (chat, patcher, Fledgling, etc…) aussi bien hors du jeu que dans le jeu.
  • Nous allons également montrer le nombre de personne connectées sur chaque serveur dans le patcher sur chaque élément de la liste des serveurs.
  • Nous allons changer la façon dont le patcher met automatiquement à jour tous les canaux et nous la remplacerons par un système légèrement différent. Nous allons mettre à jour automatiquement l’élément actuellement sélectionné si rien d’autre n’est déjà en cours, le bouton «play» soit ajoutant à la file d’attente, soit lançant immédiatement la mise à jour si quelque chose d’autre est en cours.
  • Liens vers la FAQ, guide, Problèmes connus, et autres matériels pour le jeu, nouvel écran de bienvenu à la Bêta, notre explication sur comment obtenir un DXDiag, et quelque nouvelles images pour la Bêta 1.
  • Un bouton d’aide ouvrant un document montrant les problème le plus couramment rencontrés par les joueurs dans le passé, à la place de la FAQ plus grande et moins spécialisée. Les FAQs ont tendance à être longues et je veux celle-ci courte et facile à traduire pour nos équipes s'occupant de la localisation.
  • Un bandeau (ou page) listant le(s) problème(s) le(s) plus important(s) du jour (si il y en a), tels que : Tous les Serveurs sont Hors Ligne», «test sur Wyrmling Prep aujourd’hui», etc… Cela permettra aux joueurs de recevoir les informations importantes que nous communiquons sans avoir à se connecter au jeu, Forums, etc. Nous pouvons également rendre cette page accessible depuis notre site Web, FB, etc. Par exemple les messages que nos serveurs sont hors ligne, si affichés en jeu, ne peuvent pas être vus depuis le patcher. L’idée est que nous devons mieux communiquer avec nos Backers sur plusieurs niveaux, et ceci est une bonne plateforme pour le faire.
  • Pour les personnes utilisant des anciens patchers, ce que nous devons faire est d'envoyer un message au client de mise à jour, qui le déconnecterait et afficherait un message à l’utilisateur, l’avertissant qu’il se ferme pour une mise à jour ou le désactivant temporairement, etc… L’utilisateur pourra alors cliquer «ok» afin de montrer qu’il a bien lu le message, et il se mettra à jour automatiquement.
  • Notes de MJ – Comme vous pouvez le voir dans cette section, nous nous focalisons même sur l’amélioration du patcher pour l’ouverture de la Bêta 1. Nous avons beaucoup d’autres idées pour la période post-Bêta 1, et j’ai dû un peu épurer cette section. Nous ne nous attendons pas à ce que ceci ne ralentisse le lancement de la Bêta 1, bien entendu. Ceci-dit, si cela se révélait être le cas, nous sommes préparés à sacrifier certains des éléments de cette section, afin d’accélérer l’ouverture de la Bêta 1.

    Création de Personnages
    Character Creation

  • Les joueurs doivent pouvoir créer un personnage avec toute combinaison de Royaume/race/classe autorisée que ce soit.
  • Changer l’ordre des points de compétences, afin qu’ils soient rangés par ordre alphabétique. Nous allons également les arranger par ordre d’importance par rapport à leur classe à l’aide d’un simple traitement visuel, et jetterons un œil au principe de «groupes de concept» comme dans «Exalted» ou d’autres jeux de rôle comme points de référence supplémentaires.
  • Toutes les compétences peuvent être changées, même si certaines n’ont pas encore de fonction pour le moment.
  • Nous devons avoir un champ de saisie de chiffre, afin que les joueurs puissent simplement taper les chiffres, ou utiliser les flèches haut/bas.
  • Fixer la mise en surbrillance à l’écran, afin que tous les éléments de texte se ressemblent. Certaines des valeurs entrées par attribut sont obscurcies/non-obscurcies au sein de la même description d'attribut, ce qui fait un peu négligé.
  • Un bouton d’aide pour chaque partie du processus de sélection. Chaque page devrait avoir un fichier d’aide/information qui soit un simple bouton à cliquer, et qui couvrirait la section de la création de personnage dans laquelle vous êtes. Si possible, vous devriez rester dans la création de personnage, plutôt que de devoir aller sur le site web pour chercher les informations.
  • Les joueurs peuvent choisir parmi une petite sélection de Banes/Boons durant la création de personnage. Il y en aura pour la race, la classe, et des génériques. Pour le moment, nous aurons un minimum de 10 Banes&Boons par personnage (en prenant en compte race, classe et général). Si nous pouvons faire plus, tant mieux !
  • Sur l’écran B&B, changer le «points minimum» en «minimum de points nécessaire».
  • Sur l’écran B&B, changer le «points maximum» en «maximum de points autorisé».
  • Nom de joueur unique par serveur.
  • Ajouter un fond d’écran animé différent pour chaque race dans le jeu, comme nous le faisons pour les classes.
  • Les joueurs commenceront avec un équipement approprié pour leur Royaume et classe ; chaque joueur aura également une Vox Magus, étant donné que nous n’aurons pas de classe d’artisan à l’ouverture de la Bêta 1. Comme dit plus bas, nous ne voulons pas que les gens puissent créer des Vox comme ils le veulent, à moins que nous fassions en sorte que les joueurs ne puissent pas constamment les recréer et les placer sur le sol.
  • Ajouter un bouton «Annuler» à l’opposé du bouton «Suivant», afin d’annuler la création de personnage en cours, plutôt que d’utiliser le bouton «Accueil» comme c’est le cas actuellement.
  • Cacher/griser la barre en bas du patcher durant la création de personnage. Je veux faire ceci car voir cette barre peut être déroutant pour certains joueurs, spécialement les nouveaux joueurs.
  • Notes de MJ – Nous ne voulons pas mettre une tonne d’effort dans l’amélioration de la création de personnages pour l’ouverture de la Bêta 1, mais nous voulons tout de même offrir une meilleure expérience que celle offerte actuellement à nos joueurs. Attendez-vous à ce que le système de création de personnages change beaucoup au cours du processus de Bêta. Dépenser énormément d’effort dessus maintenant n’a pas beaucoup de sens, puisque les systèmes/statistiques sous-jacents pourraient changer. Quand nous aurons verrouillé cela et l’aurons confirmé pour le lancement, alors seulement nous travaillerons bien plus sur la création de personnages.

    ÉDITÉ

    Notes de MJ – désolé, cette section est pour CSE uniquement, non pas pour les Backers.

    Les îles protégées

  • Les îles protégées sont des îles «privées», possédées par chaque Royaume. Celles-ci ne sont accessibles qu’aux membres de ce Royaume, ce qui se fait par des portails. Les portails ne sont là qu’en tant que substituts pour le véritable système de transport permettant le déplacement entre les différentes îles, par bateau et autres moyens de transport non instantanés. Les portails ne transporteront pas les joueurs de factions opposées vers la mauvaise île. Les îles protégées ont pour but, comme les portails, d’être des substituts pour ce qui deviendra éventuellement les îles principales de chaque Royaume.
  • Nous espérons que certaines des îles protégées persisteront jour après jour, à moins que nous ayons besoin de faire une remise à zéro. De ce fait, les joueurs ne devront pas compter sur leur persistance tout au long de la bêta, mais la persistance au jour le jour, devrait être la norme pour nous au cours de la Bêta 1. Comme nous l’avons dit durant la campagne Kickstarter, nous allons souvent remettre tout à zéro durant la bêta, particulièrement tant que toutes les classes ne sont pas implémentées.
  • Le nombre d’îles protégées dont nous aurons besoin pour le reste de la bêta, sera déterminé par l’implémentation des derniers systèmes pour la Bêta 1 en ce qui concerne le nombre de parcelles, leur taille, le nombre de constructions, etc… que l’on peut trouver sur une île en fonction de sa taille. Etant donné que nous voulons activer la stabilité des bâtiments pour la Bêta 1, nous allons limiter le nombre de parcelles par île, afin de garder des performances optimales, étant donner que nous avons encore du travail à faire sur l’optimisation. Pendant que nous travaillons dessus, nous agrandirons les îles, afin de tester plus encore les limites du système.
  • Chaque île protégée dispose d’une zone d’arrivée, qui est décrite dans une autre section. Les zones d’arrivée seront déterminées en fonction du type d’île (bâtisseurs, îles de départ, etc…). Les zones d’arrivée les plus compliquées seront celles des îles de départ.
  • Les îles protégées avec zone d’arrivée seront celles ouvertes le plus souvent, afin que notre Brigade de Bâtisseurs puisse construire et changer les îles. Nous allons probablement mettre en place un serveur séparé (pas Hatchery/Fledgling), afin que la Brigade de Bâtisseurs puisse passer plus de temps à construire, sans avoir à se soucier de ce que nous faisons sur le serveur de développement et de test principal. Avoir un groupe de constructeurs dédiés au test de cet aspect du système, est tout aussi important que d’avoir des combattants, testant les systèmes de combat sur les îles contestées. Quand nous serons à la section des îles contestées, je sais que nos combattants seront très heureux de ce que nous leur avons préparé !
  • Ajout d’un nouveau serveur (pas Hatchery ou Fledgling) avec une copie stable soit de Hatchery, soit de Fledgling, afin que les constructeurs puissent bâtir en collaboration sans être entravés par les redémarrages de serveur quand nous ajoutons du code. Nous pourrions limiter l’accès à ce serveur en mettant en place des permissions spécifiques pour ces hommes et femmes, afin que seul CSE puisse l’installer et les constructeurs y avoir accès. Sans la nécessité d’un grand nombre de joueurs, le coût du serveur serait minimal, spécialement avec l’utilisation de systèmes intégrés.
  • Chaque île protégée devrait avoir une petite particularité musicale associée, quand les joueurs entrent dans la zone.
  • Il devrait y avoir un espace autour de la zone d’arrivée ne pouvant pas être utilisé par les Backers pour bâtir, mais assez grande pour que la Brigade de Bâtisseurs puisse construire beaucoup de bâtiments, villes fortifiées, etc…
  • Les îles protégées utilisées pour les bâtiments de joueurs doivent être assez large pour accueillir beaucoup de bâtiments et joueurs. Ceci-dit, du fait du coût matériel (via AWS) qui leur est associé, nous n’allons probablement pas les garder en ligne 24/7. Une fois que nous aurons l’estimation finale du coût, ainsi que de la capacité de chaque île en termes de parcelles, bâtiments, etc… qui peut être créé sur une île, l’équipe de design pourra planifier le nombre d’îles dont nous aurons besoin pour la Bêta 1.
  • Notes de MJ – Les îles protégées sont une part importante de la Bêta 1. Contrairement aux personnages, nous voulons que celles-ci soient persistantes, afin que notre bridage de bâtisseurs n’ait pas à constamment les reconstruire. Elles leur donneront également quelque chose sur quoi bricoler, quand ils ne sont pas en train de combattre. Un sentiment de «retour chez soi» sur leur terrain/dans leur maison commencera à apparaître durant les diverses étapes de la bêta et ensuite quand le jeu sera en ligne. Etant donné que les îles protégées vont être construites, littéralement devant les yeux de nos Backers, le jeu va commencer à ressembler à un véritable monde et non plus à une plateforme pour une démo technique vraiment cool. Bien entendu, ceci aura également l’avantage de rassurer les Backers qui, après quatre ans, ont toutes les raisons d’être nerveux à propos de l’état de développement du jeu.

    Les îles protégées vont également permettre à tous nos Backers de travailler avec, et commenter sur, l’état de notre système de construction, afin que nous puissions l’améliorer et l’affiner durant la Bêta 1. Il est important de travailler sur le système de construction à ce moment du développement du jeu, afin de dénicher tout problème majeur nécessitant plus de temps et d’attention.

    Zones d’arrivée

  • A leur première connexion, les joueurs commenceront dans une zone d’arrivée sur les plus grandes Îles de Départ de leur Royaume.
  • La position d’un joueur sera permanente, quelle que soit l’île sur laquelle il est, quand il se déconnecte, à moins, bien entendu, qu’il soit sur une île hors ligne ou non accessible. Dans ce cas, à sa prochaine connection il se retrouvera dans la zone de départ de son Royaume. Autrement dit, un joueur ne peut pas se déconnecter dans un château/zone ennemie et toujours y être quand le serveur/match redémarre.
  • Chaque zone de départ devrait avoir un embarcadère, un certain nombre de portails, ainsi que quelques bâtiments et murs d’enceinte. Si tout se passe bien, la Brigade de Bâtisseurs se chargera de leur création. L'Île de Départ devrait être plus couverte de structures que les autres. Toute île additionnelle au sein d'un Royaume sera une copie conforme des îles déjà existantes.
  • En ce qui concerne les bâtiments/portails :
  • Pub
    • dB devrait ajouter de la musique d’ambiance classique de pub. Pour le moment nous allons utiliser notre technologie actuelle afin de placer un morceau de musique d’ambiance dans un certain rayon. Plus tard nous allons également rechercher d’autres méthodes afin de lier la musique aux zones.
    • Avoir un PNJ (personnage non joueur) tenancier de pub. Nous entrerons en contact avec les Backers ayant un palier «propriétaire de pub» afin de voir si ils veulent que le PNJ porte leur nom.
      • Cliquer sur le tenancier afin d’accéder à des informations de base à propos des pubs. Cela peut être aussi simple que «les pubs sont des endroits où les gens se réunissent pour discuter, jouer, et plus généralement interagir avec d’autres personnes. Ils peuvent être tenus par des joueurs, ou opérés par votre Royaume.»
        • Nous allons avoir besoin de nouveaux systèmes, afin que les scénaristes/designers puissent ajouter ce texte sans intervention des programmeurs.
        • Quel que soit la solution que nous utiliserons, nous devrons la mettre en place, afin qu’elle soit facilement modifiable par les scénaristes/designers et traduite par les gens qui vont nous aider.
  • Banque
    • Musique d’ambiance de banque.
    • PNJ banquier temporaire.
    • Cliquer sur le banquier afin d’accéder à des informations de base sur comment le système de banque fonctionnera en jeu.
    • Les banques ne seront pas fonctionnelles durant la Bêta 1.
  • Portail
    • Musique d’ambiance pour les portails.
    • VFX pour les portails.
    • Les portails vont uniquement montrer des VFX quand ils sont en fonction : non seulement cela sera moins déroutant pour les joueurs, mais également plus logique et rendra le monde plus réaliste.
    • PNJ gardien de portail temporaire.
    • Survoler la souris sur le portail/gardien, afin d’avoir accès à leurs informations et traverser le portail (s’il n’y a qu’une seule destination) ou cliquer/sélectionner, s’il a plusieurs destinations.
    • Une interface administrateur pour les portails utilisable directement au sein du jeu.
  • Embarcadère
    • Pour les portails, et, un jour, les bateaux, naturellement. Nous ferons ces portails de préférence, spécifiques par Royaume. L’équipe d’artistes va travailler sur des portails différents pour chaque Royaume qui puissent être agrandis ou réduits afin de les distinguer. Par exemple, le plus petit portail pourrait être celui proche du bateau. Les plus grands sont les plus puissants (plusieurs destinations). Les déclencheurs de portail ne sont pas les portails, mais ils font partie intégrante du portail. Par exemple, un bateau peut être un portail, mais le déclencheur est de s'asseoir sur un siège.
  • Les joueurs peuvent donc se déplacer sur l’île de départ et/ou passer un portail vers d’autres îles protégées de leur Royaume.
  • Au centre de la Zone d’Arrivée, il y aura un portail spécial pour aller sur les Îles Contestées.
  • Le portail vers les Îles Contestées ne fonctionnera pas tout le temps. Les Iles Contestées, qu’elles fassent partie de ****** ****** (édité jusqu’à ce que l’on arrive à cette section) ou pas, ne fonctionneront pas 24/7, donc il n’y a pas de raison de laisser le portail ouvert constamment. Nous pouvons également utiliser le portail comme mécanisme de synchronisation/lobby, comme nous en discuterons plus bas.
  • Nous devons pouvoir ouvrir/fermer n’importe quel portail sans intervention des programmeurs. Cela nous permettra de les ouvrir ou fermer en fonction de certaines conditions de test (déséquilibre entre Royaumes durant un test, par exemple). Les serveurs devront tout de même être démarrés par les programmeurs durant la bêta 1, mais nous espérons que cela ne sera plus le cas avant que nous arrivions à la bêta 2.
  • Les portails vers les autres îles protégées, en général, fonctionneront chaque fois que le serveur sera en ligne et ouvert aux joueurs.
  • Les joueurs autres que la Brigade de Bâtisseurs, ne peuvent pas construire au sein de la Zone de Départ.
  • Notes de MJ – Comme les îles protégées, la Zone d’Arrivée est supposée aider à rendre le monde plus vivant. Bien que les choses comme des PNJs puissent sembler quelque peu superflu pour le moment, déjà avoir de vrai PNJ fonctionnels nous aidera dans le futur.

    Îles de construction

  • Les îles de construction sont du même type que les îles protégées (comme l’île de départ), où il n’y a ni JcJ (Joueur contre joueur), ni joueurs d’autres royaumes autorisés. Ce paramètre ne sera pas immuable, mais sélectionnable par les designers, et, si possible, modifiable par CSE en jeu via le portail d’administration. Il pourrait y avoir d’autres îles protégées ajoutées durant la Bêta 1, mais pour l’instant, il n’y a aucuns plans pour en ajouter de ce même type à l’ouverture.
  • Les îles de construction seront disponibles plus souvent que les îles contestées. Cependant, pour mieux gérer les coûts / l’épuisement de nos joueurs, elles ne seront pas autant accessibles que l’île principale protégée. Bien que cela puisse paraître injuste, c’est quelque chose de réellement nécessaire et équitable. Premièrement, les coûts pour maintenir accessible les îles de constructions sont bien moindres, que ceux nécessaires pour les îles contestées. Deuxièmement, nous présenterons ce que nous allons faire pour nos joueurs axés sur le combat dans la section sur ****** ******. C’est du gagnant-gagnant pour tout le monde, comme je m’attend à ce que le temps nous le dise.
  • Elles devront être organisées pour la construction, ce qui signifie que l’île ne doit pas être couverte de profondes et sombres forêts, mais plutôt facile à y bâtir et esthétiquement plaisante, avec des bosquets d’arbres, lacs et espérons-le, des rivières ruisselant à travers l’île. La taille d’une parcelle devra être assez large pour que les joueurs puissent construire une structure décente. Elles ne devront pas ressembler à notre île de construction actuelle. Pour garder les choses équitables et ne pas rendre fou Ben, au point qu’il se mette à s’enfuir dans la nuit en hurlant, toutes les îles de construction devront être en grande partie similaires visuellement au sein d’un Royaume.
  • Il devra y avoir suffisamment de gisements de ressources dispersés tout autour de l’île dans des endroits pratiques. La clé ici est que nous ne voulons pas que les joueur perdent du temps à courir partout, juste pour récupérer des ressources pour construire. Ces gisements de ressources pourront être enlevés, basé sur ce qui adviendra avec les mines et les «Regroupement de Gisements».
  • Construire des «Regroupements de Gisements» où tous les points de récolte se trouvent. Les placer de façon à ce que les joueurs ne soient jamais à plus de deux minutes en courant du plus proche «Regroupements de Gisement. NOTE : Suivant comment progresse notre travail sur les mines et les transitions invisibles entre les zones, nous pourrions nous passer de ces «Regroupements de Gisements» et construire des îles de récolte pour chaque royaume, où les ressources seraient placées. Nous pourrions alors déployer des portails tout autour de l’île protégée, pour que les joueurs puissent les utiliser. Les mines étaient/sont des fonctionnalités BONUS pour la Bêta 1, donc si nous avons besoin de les annuler pour celle-ci, nous le ferons. Je ne pense pas que nous ayons besoin de le faire, mais nous avons été très clair avec nos Backers sur ces éléments.
    • Pour l’ouverture de la Bêta 1, les ressources devront peser très peu, ainsi les joueurs pourront les transporter plus facilement vers leurs parcelles. Le poids des items devra lui aussi être instauré comme une valeur globale, qui pourra être manipulée par les designers, ainsi nous aurons des paramètres tels que enlever / restaurer le poids, modifier tous les poids en %, etc.
      • Les ressources déposées sur votre parcelle, ou celle où vous avez les autorisations pour le faire (voir plus bas), sont persistantes. Les ressources déposées autre part, disparaissent au bout de (x) minutes. Ceci sera lié aux paramètres d'autorisation pour les parcelles.
  • La cartographie des îles de construction devra fournir bien assez d’espace entre les propriétés, afin que les joueurs ne puissent obstruer aucune zone en bâtissant leurs maisons les unes à côté des autres sur la carte. La taille des parcelles, la distance entre elles, etc. seront déterminés, lorsque davantage de la technologie pour la Bêta 1 sera en ligne.
  • Une fois qu’un joueur arrive dans une zone où il peut acquérir des parcelles, il verra les parties de l’île conçues pour les constructions de joueurs sur la carte, et celles-ci seront aussi affichées dans le monde via des marqueurs/aides visuelles . Cette fonctionnalité sera remplacée par un système de conception de carte durant le développement du jeu, mais pour l’instant, nous voulons faire en sorte que les joueurs puissent s’orienter facilement sur ces îles.
  • La stabilité sera activée sur les structures dans Camelot Unchained pour la Bêta 1. C.U.B.E. restera comme il est maintenant, sans la stabilité. Les joueurs sont, bien sûr, libres de construire dans les îles protégées avec le système du jeu, ou d’importer leurs structures depuis C.U.B.E.
  • Pour l’ouverture de la Bêta 1, les joueurs ne pourront acquérir qu’une seule parcelle sur une île protégée par compte. Ils peuvent toujours conquérir des parcelles sur les îles contestées, mais pour limiter le nombre d’îles/serveurs dont nous aurons besoin pour la Bêta 1, nous limiterons la possibilité des joueurs à revendiquer plusieurs parcelles. Cependant, cette limite devra être convertie en une variable, ainsi nous pourrons la changer durant les tests.
  • Notes de MJ : Comme au-dessus, avoir les îles de construction pour la bêta 1 est important. Permettre aux Backers et aux Bots d’utiliser le système et d’essayer de le casser maintenant, plutôt que tardivement, colle parfaitement avec notre philosophie de développement. La plus grande addition à nos plans initiaux est, évidemment, les mines. J'espère que cela sera suffisamment solide pour être inclus dans la Bêta 1, basé sur nos travaux actuels dessus. À défaut, l'idée des «Regroupements de Gisements» correspond parfaitement pour la Bêta 1, et ne fera pas d’elle une plaie à jouer pour nos Backers, au point où ils ne voudront plus se connecter et nous aider à tester les choses.

    J’aimerais aussi réitérer une fois de plus, qu'il y a beaucoup plus d'informations à venir , y compris ce qu’est «****** ******». Je m’attend à ce que ce soit du gagnant-gagnant pour tout le monde, et rendra nos Backers axés sur le combat particulièrement heureux. 🙂

    Parcelles

  • Chaque parcelle aura une limite en terme de «nombre total de blocs». Ceci pourra être repoussé à la *** *** ***. La limite de blocs n’a pas directement de rapport avec le volume de la parcelle ; ce sont deux choses différentes.
  • Le temps de destruction/construction sur les parcelles devra pouvoir être déterminé par les designers via la *** *** ***.
  • Les parcelles ont une limite de hauteur pour la construction. Comme nous avons discuté jusqu’à plus soif, cela aidera à limiter la prévalence de «certains types de tours», ainsi qu'à tester le système de limitation de blocs de construction. Ceci devrait être repoussé à la *** *** ***. Bien que ceci ne soit pas suffisant pour empêcher les abus/le griefing du système de construction, bien entendu, c'est déjà un début. Quand le jeu sera lancé, nous aurons d’autres mécaniques en place, y compris les conditions d’utilisation, qui aideront à décourager la construction de telles tours et autres formes de griefing intra-Royaume.
  • Comme mentionné plus haut, la stabilité sera activée pour la construction au sein de Camelot Unchained, mais restera désactivée dans C.U.B.E.
  • La possession de parcelle est persistante, à moins que celle-ci ne soit abandonnée par le joueur ou remise à zéro par nos soins. En ce qui concerne l’abandon, ceci reste à déterminer en fonction du design et des besoins des joueurs. Le temps pendant lequel une parcelle reste la propriété du joueur est quelque chose qui doit être variable, afin que l’on ne se retrouve pas avec les même problème que Star Wars Galaxies : une tonne de bâtiments vides qui ne font qu’encombrer le paysage et ralentir les performances du système. Ceci est un autre élément qui devrait être repoussé à la ** *** ***.
    • Une fois qu’une parcelle est complètement abandonnée, les blocs s'effondrent. Nous devrons déterminer au cours de la bêta quel est le meilleur moyen de faire cela. Ils serait super de pouvoir les faire se détériorer lentement en temps réel. Ceci dit, si cela est un gros problème en terme de performances, du fait d’avoir des milliers de bâtiments sur une grande île, nous pouvons le repousser au redémarrage journalier du serveur (ceci est uniquement une option pour le moment et n’est absolument pas confirmé) au lancement du jeu. De cette façon, cela n’affectera pas le jeu pendant qu’il est en ligne, a part quand les bâtiments sont attaqués.
    • Nous ne voulons pas de joueurs revendiquant, construisant, abandonnant et remplissant le monde de structures juste pour troller, particulièrement s'ils sont focalisés sur "le moment pénis" (comme nous savons parfaitement que certains le seront), comme mentionné plus haut. Le système de détérioration graduelle de parcelle est quelque chose dont nous aurons besoin pour les futures bêtas, mais qui n’est pas nécessaire pour la Bêta 1.
      • Une des façons possibles de le faire, qui ne pénaliserait pas les performances, serait de -juste de temps en temps (minute, heure, jour, configurable)- appliquer quelques dommages aux blocs au sommet de la parcelle et à quelques autres au hasard (encore une fois, tout peut être configuré)
    • Le système de permission de parcelle devrait :
      • Permettre à des personnes de donner/révoquer la permission de construire sur la parcelle.
        • Seuls des membres de votre Royaume peuvent être invités à construire sur votre parcelle.
        • Nous devons avoir un paramètre permettant à un joueur de donner automatiquement à toute personne dans leur guilde/warband/etc… la permission de travailler sur leur parcelle. La permission par défaut ne devra pas être donnée , pour des raisons évidentes.
      • Donner aux joueurs la possibilité de décider si la personne invitée à la permission de :
        • Construire.
        • Détruire.
        • Déposer des objets dans la parcelle - les joueurs pourraient aisément se troller les uns les autres au sein d’un même Royaume en déposant beaucoup de choses, en particulier durant la bêta.
        • Prendre des objets - comme ci-dessus mais inversement.
      • Les joueurs qui ont reçu la permission de faire des choses sur la parcelle recevront une notification si leurs permissions ont été changées.
    • Les parcelles sur les îles protégées ne peuvent pas être prises par d’autres joueurs, à moins qu'elles aient été abandonnées, ou libérées par nos soins.
    • Votre/vos parcelle(s) apparaîtront sur une carte. Pour le moment, nous ferons les choses simplement avec une sorte de marqueur sur la carte. Dans le futur, cela sera beaucoup plus élaboré, étant donné que cela sera lié aux systèmes de défense/information, intégré aux parcelles. Mais pour la Bêta 1, nous mettrons juste des marqueurs sur la carte.
    • Quand vous revendiquerez une parcelle, vous recevrez un objet, un titre de propriété. Ce titre ne peut être donné à un autre joueur, perdu à la mort, etc...
      • Si vous perdez la possession de la parcelle, car celle-ci a été conquise par un autre Royaume, vous ne perdez pas le titre de propriété. Donc si/quand cette parcelle change de possession, si elle revient au Royaume d’origine, vous serez automatiquement le propriétaire. Étant donné que vous ne pouvez pas posséder plusieurs parcelle au sein de votre Royaume durant la Bêta 1, vous devrez abandonner votre ancienne avant d’en revendiquer une nouvelle. Le nombre de parcelles qui peuvent être revendiquées est clairement un nombre qui doit pouvoir être changé en temps réel par les designers.
      • Si vous abandonnez la parcelle, le titre de propriété disparaît.
    • Le titre de propriété sert d'élément d’interface incluant plusieurs fonctions.
      • Interagir avec celui-ci dans l’inventaire, vous permet de voir des détails à propos de votre parcelle.
      • Options de menu pour le titre de propriété :
        • Voir les informations sur la parcelle.
        • Voir la parcelle sur la carte.
        • Gérer la parcelle (permissions et autres)
        • Se téléporter vers la parcelle (pour Bêta 1 - fonctionne uniquement pour celle dans la zone protégée).
        • Nettoyer la parcelle (efface tout les blocs sur la parcelle).
        • Abandonner la parcelle (cède possession de la parcelle).
        • Nous devrions ajouter l’interface de la file d’attente de construction d’un bâtiment, ainsi que les option de réparation, dans ce menu.
  • Contester la possession d’une parcelle
    • Contester une parcelle non revendiquée devrait être une procédure simple, à déterminer dans les prochains mois, et le temps nécessaire pour la contester doit pouvoir être déterminé par les designers. Pour le moment, tout ce que nous avons à faire est d’utiliser le système actuel, mais également avoir quelques paramètres, comme le temps nécessaire pour contester une parcelle revendiquée, poussé à la ***.
  • La première personne -éligible pour la revendication d’une parcelle- qui se place sur une parcelle, est le seul membre du Royaume pouvant la prendre tant que le processus de revendication/possession est en cours. Ceci aidera à éviter le griefing de la part de groupes essayant de revendiquer une parcelle pendant qu’un autre membre du Royaume est en train de la revendiquer. Le processus/temps nécessaire pour revendiquer une parcelle en territoire allié sera différent de celui nécessaire quand vous essayerez de revendiquer une parcelle dans une zone contestée et/ou qui est déjà possédée par un joueur d’un autre Royaume. Les paramètres suivants devraient être poussés à la *** *** *** et/ou scriptés.
    • Temps nécessaire à la revendication d’une parcelle en territoire allié - les îles protégées de votre Royaume sont considérées alliées.
    • Temps nécessaire à la revendication d’une parcelle en territoire neutre – Les îles contestées sont considérées comme territoire neutre.
    • Temps nécessaire à la revendication d’une parcelle en territoire hostile – Sous-entendu en territoire ennemie.
    • Ajouter un multiplicateur pour une parcelle possédée par un joueur d’un Royaume opposé.
  • Les joueurs d’un autre Royaume peuvent essayer de ralentir/stopper le changement de propriétaire d’une parcelle pendant que le processus est en cours.
    • Si des joueurs sont en groupe, ils peuvent accélérer le processus pour la personne revendiquant le terrain. Afin de rendre les choses plus facile pour la Bêta 1, pour travailler ensemble pour revendiquer une parcelle, les personnes devront être dans la même Warband.
  • Notes de MJ – La possession de parcelle est un autre de ces systèmes ayant besoin d’énormément d’ajustements au cours du projet. Dans un jeu comme le nôtre, où la possession/conquête/construction est un des éléments clés de son attrait, nous ne pouvons nous permettre de rater ce système au lancement. Sans vouloir donner de nom, nous connaissons tous certains jeux ayant eu ce problème au lancement, et cela a nui à leur attrait auprès des joueurs à court et long terme. Donc quelque-soit le système que nous utiliserons durant la Bêta 1, il ne sera pas le système final pour le jeu. Comme toujours, «Ne paniquez pas !» vous n’avez pas besoin de vous inquiéter, le système que vous verrez durant la Bêta 1 ne sera pas nécessairement le même au lancement.

    Nous devons également faire en sorte que la procédure d’appropriation de terrain, ne soit pas quelque chose qui nuira à la fierté intra-Royaume au final. Une des façons dont nous allons le faire, sera d’éviter la «course à la propriété» , comme cela c’est passé dans d’autre jeux. La possession de parcelle ne sera pas une affaire de «premier arrivé, premier servi», étant donné que les joueurs doivent gagner le droit à la propriété au sein de leur Royaume … par des actions !

    Ces droits ne seront pas attribués uniquement en fonction du temps de jeu, ce qui donnerait aux gens avec plus de temps libre pour jouer un gros avantage. A la place, cela sera basé sur vos accomplissements durant votre temps de jeu. Ainsi, un joueur jouant 4 heures et accomplissant beaucoup de choses, aura accès plus rapidement à un titre de propriété, que quelqu’un jouant 8 heures, mais passe son temps assis à discuter. Cela sera la même chose pour les extensions de propriétés. Autrement, les joueurs peuvent aller en territoire neutre ou ennemie et revendiquer des terrains, sans avoir besoin d’un titre de propriété donné par leur Roi. C’est une chose sur laquelle nous avons été très clairs depuis le début de la campagne Kickstarter, et une fois de plus, cela représente notre dévotion et désire de nous tenir aux principes/buts que nous avons présenté il y a quatre ans.

    Bien entendu, ceci est uniquement un document focalisé sur la Bêta 1, donc les choses comme les taxes de propriété, coût de maintenance de bâtiments, et autres dépenses sont toujours prévus. Ceux-ci seront discutés plus en détail avec nos Backers, quand nous nous rapprocherons de leur implémentation en jeu.

    Île(s) Contestée(s)
  • Nous commencerons avec une île contestée uniquement, mais nous en ajouterons plus durant la Bêta 1, comme défini dans le ****** ****** (ci-dessous).
  • La principale île contestée doit être assez grande pour avoir des bâtiments et du RcR (Royaume contre Royaume), mais pas si large que les joueurs doivent courir 30 minutes pour rejoindre le combat. Le temps nécessaire pour rejoindre l’action et la taille des îles, est encore à déterminer, en fonction des systèmes et des contraintes/fonctionnalités du design tel que le ****** ******. J’envisagerais une grande île avec un temps de trajet long, si nous décidons de mettre des portails sur celles-ci, ainsi les gens pourront rejoindre l’action rapidement si nous voulons les activer pour certains tests.
  • Les Îles Contestées ne seront pas en ligne 24/7, et seront uniquement ouvertes pour une certaine durée et/ou évènements. Ceci est, comme expliqué plus haut, afin de garder les coûts de l’AWS gérables et d’éviter que les joueurs ne se lassent.
  • Les Îles Contestées ont une quantité limitée de parcelle pouvant être revendiquées par les Royaumes. Une fois une parcelle revendiquée, les règles normales pour une parcelle s’appliqueront.
    • Les membres d’autres Royaumes sur l’IC (Île Contestée) peuvent détruire les blocs/bâtiments et revendiquer les parcelles appartenant à un ennemi.
  • C’est sur les Îles Contestées que nous verrons les premières versions de la technologie de changement de paysage, quand une faction occupe certains emplacements sur la carte, ou quand une certaine parcelle change de propriétaire. Ceci pourrait devenir une fonctionnalité BONUS en fonction des difficultés techniques.
  • La première Île Contestée ne sera pas conçue pour des raisons esthétiques uniquement, mais plutôt pour les types de gameplay que nous voulons tester au début de la Bêta 1.
  • Les Îles Contestées auront un certain nombre de portails, en fonction de l’endroit où nous voulons faire commencer les joueurs. Ceux-ci devraient pouvoir être mis en place via un tableau, ainsi que par l’outil de création de zone. Si nous voulons un Portail Administrateur, nous devrons pouvoir le faire à travers celui-ci également.
  • Notes de MJ – Il n’y a pas grand chose que je puisse ajouter à cette section, à part dire qu’il y a beaucoup plus d'information à propos de ce que «****** ******» est, et la signification qu’il a pour les tests durant la Bêta 1 et nos Backers. Ceci sera révélé dans les sections à venir. 😊 Désolé d’être aussi taquin, mais la signification de ces deux mots cachés aura un gros impact sur les tests de la Bêta 1 et au-delà !

    ÉDITÉ

    Édité car matériel BONUS.

    Artisanat
  • Il est crucial que l’artisanat durant la Bêta 1 ne se ressente pas comme une corvée, en particulier avec les remises à zéro fréquentes associées aux tests Bêta. Des paramètres importants seront définis pour les Designers, ainsi nous pourrons facilement accélérer/ralentir la cadence de tous les aspects du système d’artisanat. Sa rapidité durant la Bêta, comparé au lancement du jeu, sera déterminée par la longueur des tests spécifiques, ainsi que leurs objectifs et leurs résultats.
  • Les designers devraient être capable de paramétrer combien de Vox (le pluriel reste Vox, mais un groupe de ceux-ci est appelé un Choeur) un joueur peut posséder. Pour commencer, chaque joueur devra avoir son propre Vox, mais seulement un. S’il le dépose sur le sol, il devrait être le seul à pouvoir le récupérer. S’il quitte le jeu sans avoir récupérer le Vox, ce dernier devrait disparaître du jeu et retourner dans l’inventaire du joueur. Ceci est pour éviter les «champs de Vox», que nous avons pu voir durant les tests précédents.
  • Tous les joueurs auront accès au système d’artisanat en Bêta 1, à moins que nous atteignons l’objectif bonus d’avoir une classe d'artisan à part entière pour la Bêta 1.
  • Le Vox Magus

  • Le Vox a besoin d’être retravaillé pour la Bêta 1. Nous devrions y garder le même concept de base, mais il a simplement besoin d’un visuel et de sons plus intéressant en jeu.
  • Nous avons besoin de créer une icône pour le Vox Magus dans l’inventaire du joueur, qui ressemblerait à une boîte. Oui, je sais, les joueurs diront que c’est un Vox en boîte; c’était voulu. 😊
  • Quand le joueur pose le Vox au sol, pourquoi ne pas avoir une animation/effet/bruitage quand la boîte devient le Vox. Cela devrait être quelque chose de vraiment cool, et si nous le faisons bien, ce sera «le sujet dont tout le monde parle» pour les joueurs. Nous devrions jouer cette même animation/effet dans le sens inverse, quand le joueur revient récupérer son Vox.
  • Quand le Vox est entièrement déployé, prêt et en fonctionnement, il devra toujours y avoir des VFX/SFX.
    • J’écrirai un document expliquant comment les cristaux réagiront dans le Vox, basé sur ce que celui-ci/le joueur fait au même moment. C’est une importante partie du concept du Vox, et j’ai besoin de le détailler dans un document séparé.
    • Nous voulons une sonorité plus «fantastique» pour le Vox Magus, plutôt que de Science-fiction.
  • Comme indiqué sur la checklist originale de la Bêta 1, avoir une interface avec des commandes slashs pour celle-ci est acceptable, mais pas du tout désirée. Actuellement, le Backer, et membre du Mod Squad, Mehuge code une superbe interface, qui évitera l’utilisation des commandes slashs.
  • Bien qu’un Vox ne peut pas être récupéré par quiconque autre que son propriétaire, il peut être endommagé par les autres joueurs. Nous permettront peut-être aux joueurs des autres Royaumes de voler un Vox, mais ça ne sera pas quelque chose que nous ferons pour la Bêta 1.
  • Extraction

  • Les gisements devront être éparpillés à travers le monde, mais chaque Île Protégée devrait avoir des matières premières appropriées à leur Royaumes respectifs. Nous devons faire en sorte que les gens n’aient pas à faire des allers-retours entre différentes îles, afin de trouver des matières premières. Ce n’est définitivement pas passionnant durant la Bêta 1.
  • L’île Contestée principale devrait avoir des matériaux spéciaux, afin de récompenser les gens qui s’y rendent.
  • Les joueurs devraient pouvoir s’approcher des gisements, tels que de Métal, Bois, Pierre, Cuir, Tissu et peut-être de Réactifs, et en extraire des matières premières.
    • Nous devons déterminer quelles matières premières seront disponibles au lancement de la Bêta 1.
    • Nous devons ajouter des pioches et autres objets associés, et vous devrez les avoir équipés, afin d’obtenir des matériaux des gisements.
      • Bien que la liste finale soit encore à déterminer, celle simplifiée inclut des choses comme une pioche, scie, etc...
    • Nous avons besoin de bruitages en rapport avec les actions effectuées.
    • Nous avons besoin d’animations pour les actions effectuées.
  • Pour la Bêta 1, nous allons réduire le poids de tous les matériaux ou ajuster la charge/capacité de transport, afin que les joueurs puissent en transporter en quantité pour l'artisanat et la construction. Ceci changera à mesure que nous avancerons dans les différentes phases de la Bêta, afin de coller au mieux à la version définitive. Ces paramètres devraient être ajoutés au tableur principal/à la *** *** ***.
  • Les gisements de ressources devraient être reconnaissables de loin par les joueurs.
  • Nous devrions regrouper les gisements dans des Centres de Gisements, afin d’éviter aux joueurs d’avoir à courir partout sans raison. Nous avons un système très flexible, que nous pouvons utiliser afin de les implémenter.
    • Ceci-dit, il serait acceptable de mettre les gisements près de montagnes, en plus de ce genre de groupement.
    • Nous devrions voir un type de signalisation, indiquant les Centres de Ressources.
  • Lorsque vous récoltez quelque chose d’un gisement, vous devriez avoir une animation basique/un son réutilisable pour tout type de gisement.
  • Les objets récoltés devraient apparaître dans l’inventaire d’un joueur, sous forme de pile avec une icône, un nom (fer brut, cuir brut, etc… en fonction du matériau), la quantité et d’autres informations, en passant sa souris dessus. NOTE : Les éléments de cette section sont sujets au travail déjà en cours sur le jeu.
    • L’information sur les objets devrait être rempli de données pour la Bêta, dont certaines seront cachées au lancement du jeu. Comme beaucoup d’autres choses dans le jeu, nous avons promis de donner à nos joueurs toutes les informations nécessaires, afin d’aider à debugger/tester le jeu durant les phases de test, mais qu’au lancement le jeu fonctionnera différemment.
  • Traitement

  • Cette partie est vraiment un substitut pour la version à venir du système de traitement.
  • Les joueurs mettent des substances dans le Vox Magus. Le Vox les traite, et les recrache traitées.
  • Comme expliqué dans le document sur le traitement, de temps en temps, quelque chose de spécial arrivera. Pour la Bêta 1, nous devrions garder les choses très simples. De temps en temps, le processus accélèrera, des fois, il prendra un peu plus longtemps ; et parfois, il produira plus de produit final.
    • Le traitement des matériaux pour les blocs est confirmé pour la Bêta 1, mais est simpliste dans sa conception. Cela pourrait changer, mais pour l’instant, ce n’est pas une chose complexe.
  • Comme toute autre partie du système d’artisanat, le système de traitement n’est pas prévu pour être chronophage durant la Bêta 1.
  • Façonnage

  • La fabrication d’alliage est prévue d’être une des parties les plus intéressante du système d’artisanat dans la Bêta 1 et après. Ça ne peut être un système purement «n’importe quoi + n’importe quoi = quelque chose» pour la Bêta 1, mais utilisera des recettes +réactifs. Ça sera une bonne approximation, et meilleur que ce que nous avions initialement prévu. C’est l’une de ces choses qui sera bien plus avancée dans la Bêta 1, en parti due au retard.
  • Le système d’Alliage/Réactif donne au joueur un nombre presque illimité de combinaisons avec lesquelles travailler.
    • Pour la Bêta 1, un joueur peut combiner un nombre de substances en un alliage.
    • Afin de donner au joueur plus d'options lors de la création de l'alliage, le système permettra aux joueurs d’ajouter des réactifs à l’alliage, en même temps qu'ils créent ce dernier.
  • Fabrication

  • La partie fabrication de ce système est prévue pour être la moins importante pour la Bêta 1. Ce sera encore une autre élément plus avancé dans la Bêta 1, que prévu initialement, grâce au retard et à de l’excellent travail de la part des programmeurs. Nous avons déjà un système dans lequel nous pouvons «fabriquer une épée à partir d’une poignée + une lame.» Puisqu’il peut y avoir simplement la règle de «vous pouvez fabriquer une arme à partir d’alliage», il nous permet également ce que nous voulons pouvoir faire, plus loin dans le développement. Pour la Bêta 1, si nous faisions le choix de paramétrer les recettes des éléments comme les épées/flèches/etc., pour utiliser toutes les sous-parties élaborées, nous voudrions également modifier les scripts des statistiques d’élément.
  • Systèmes Sociaux et de Groupe

    1. Aperçu

    Les groupes et systèmes sociaux sont une part importante de tout MMORPG, old-school ou pas. Pour la Bêta 1 nous allons nous focaliser sur quelques composants clés de ces systèmes, tout en posant les fondations d’un système bien plus complexe, qui sera implémenté durant le reste de la Bêta. Nous voulons insister sur le fait que nous faisons les choses différemment que beaucoup de nos prédécesseurs, et malgré tout, nous restons fidèles à notre philosophie old-school.

    2. Principes Directeurs

    Le concept de Principes Directeurs pour un système est quelque chose que MJ a utilisé depuis plus longtemps, qu’il n’aime se rappeler. Cela lui a bien servi par le passé, donc, quand il a élaboré sa vision initiale pour cette partie du jeu, voici ce qui était le plus important pour lui.

  • Pas d’appartenance à plusieurs guildes pour un personnage - Nous l’avons dit durant le Kickstarter, et nous allons nous y tenir. De l’avis de MJ, et partagé par beaucoup d’auteurs/posteurs, l’appartenance à de multiple guildes a contribué au déclin des guildes les plus sérieuses dans les MMORPGs.
  • Restaurer la Fierté de Guilde - la taille de l’Ordre ne devrait pas avoir d’importance, nous devons aider à renouer avec le sentiment de faire partie de quelque chose de spécial, lorsque vous êtes dans un Ordre prospère. Cela ne veut pas juste dire donner des récompenses et des niveaux de progression, mais ceci veut aussi dire que nous devons faire en sorte d’éviter les problèmes qui portent préjudice à la fierté de guilde, tel que les gens pillant la banque de guilde.
  • Petit ou grand, vous êtes tous bienvenus - Nous ne pouvons baser ce jeu juste sur le concepte de méga guildes (comme l’ont fait certains jeux), ou même juste de guilde, si nous voulons continuellement attirer et retenir de nouveaux joueurs. Nous devons reconnaître que nos joueurs puissent vouloir jouer en solitaire, avec un petit groupe d’amis, ou dans des Ordres. Nous devons comprendre ceci et le soutenir, et essayer d’adapter les avantages de chaque groupe de façon à ce que les gens puissent profiter de ce jeu, quelque soit leur façon de jouer.
  • Nous devons adapter notre contenu aux Ordres de toute taille - Ceci peut sembler facile, mais ça ne l’est pas. Par exemple, nous ne pouvons pas réserver tout les choses sympa aux Ordres plus grand ou plus prospères. Nous ne pouvons donner des avantages/bénéfices qu’aux plus gros Ordres, ou rendre ceux-ci si difficiles à obtenir pour les Ordres plus petits, qu’ils en deviennent frustrants. La taille devrait compter, mais l’implication/longévité également.
  • Un jeu purement RcR doit faire les choses différemment d’un jeu JcE, et nous devons accepter et embrasser cela.
  • Nous devons créer un sentiment d’appartenance/de famille au sein des Ordres - Donner aux Ordres les outils nécessaires afin de les aider à construire un lien social entre les membres. Si nous pouvons faire cela, les joueurs seront ravis de notre système pour les Ordres, même s’il est moins tape-à-l’oeil que ceux dans d’autres jeux.
  • 3. Types de Groupes

    Camelot Unchained sera lancé avec cinq types de groupes. Ceux-ci seront décrits dans de plus amples détails plus bas, mais dans le but de faire référence et de se familiariser avec les dénominations lorsque vous lirez ce document, ils sont listés ici :

  • Joueur solo – Si vous n’êtes pas sûr de ce que fait le concept de joueur solo dans un document centré sur le groupe, hé bien, rappelez-vous juste ce que MJ avait dit avant même le début du Kickstarter : «Nous voulons être capable de supporter le style de jeu en solo, en même temps que celui de groupe.»
  • Warband – Voyez cela comme des groupes avec des avantages. Les fonctionnalités construites autour des groupes sont orientées vers les joueurs qui souhaitent se regrouper avec leurs amis, mais ne veulent pas se préoccuper de former un Ordre (guilde).
  • Battlegroup – Regroupement de Warbands, qui se joignent ensembles de façon temporaire pour s’entraider en RcR.
  • Ordre – Le plus important groupe au sein de Camelot Unchained. Nous savons tous l’importance des guildes dans les jeux MMORPGs depuis des décennies, et bien qu’il y ait eu un déclin dans leur nombre globalement, nous voulons essayer de renverser cette tendance dans notre jeu. Les guildes étaient une importante partie du succès de Dark Age of Camelot, et avec WAR, MJ et Mythic ont essayé de les amener vers un autre niveau, au travers du concept de «Guilde Vivante». Bien que ce jeu ne soit pas WAR (Pour information, notre budget vaut moins qu’un an de dépense pour ce dernier), nous pensons que nous avons quelques idées innovantes et des fonctions de support, qui stimuleront ceux qui veulent que les Ordres jouent un rôle important dans Camelot Unchained.
  • Campagne – Une alliance temporaire de groupes, qui existe pour atteindre des objectifs, au travers de missions avec une participation de multiples groupes et / ou de foule de joueurs à travers le Royaume.☺
  • 4. Quoi attendre pour la Bêta 1

    Pour la Bêta 1, nous allons nous focaliser sur quelques éléments clés des groupes et du système social : Warbands, Battlegroups, et Ordres, qui sont notre version des groupes, raids et guildes. Il y aura un Produit Minimum Viable en place pour chacun de ces groupes quand la Bêta 1 ouvrira, comme nous l’avions dit. Durant le cycle de la Bêta, nous commencerons à finaliser certaines fonctions pour le jeu final, mais ceci n’arrivera pas avant la fin de la Bêta 3. En attendant, profitez du voyage pendant que nous essayons de créer un des système de groupes les plus élaborés et utiles de son genre. Nous ferons cela sans ajouter des tonnes de fonctionnalités ou de cosmétiques, mais en construisant quelque chose adaptée aux besoins de nos joueurs. Cela sera fait au travers d’un système rendant plus facile la coordination d’attaques en RcR, tout en facilitant les choses allant du jeu solo aux attaques massives (pas l’échange de château par les zergs), qui feront de Camelot Unchained le prochain grand MMORPG RcR.

    5. Fonctionnalités personnelles

    Il y a tellement à dire ici, concentrons nous sur quelques fonctionnalités de notre système social applicable à tous les joueurs, quelque soit la taille de leur groupe, y compris les joueurs solitaires.

  • 5.1 Listes d’Amis/Ennemis/Connexions/blocages
    Nous sommes tous des amis ici, n’est-ce pas ? Non seulement Camelot Unchained aura une liste d’amis, mais nous allons aussi ajouter une liste pour les connaissances, ennemies, et bloqués.

    La liste d’amis en jeu s’explique plus ou moins d’elle même, et vous aurez beaucoup de liberté pour adapter votre liste grâce au système de permissions expliqué plus bas.

    La liste d’ennemies fonctionne de la même façon que la liste d’amis, à part le fait qu’elle liste les membres d’un Royaume opposé. Mais ce n’est pas tout ! Vous pouvez également ajouter des groupes ennemies à votre liste. Vous ne pouvez communiquer avec un ennemi par aucun moyen en jeu, donc vous ne pourrez pas leur envoyer de MP, ou leur envoyer du courrier via cette liste. Ceci dit, vous serez en mesure de voir combien de fois vous avez tué ce joueur ou celui-ci vous a tué. Vous saurez si vous êtes des ennemies mutuels. Vous aurez aussi la possibilité de mettre la tête de vos ennemies à prix plus facilement en les sélectionnant dans cette liste.

    Comme pour la liste d’amis, les joueurs auront un grand contrôle sur cette fonctionnalité.

    La liste de connaissances vous suggérera des joueurs de votre Royaume avec les vous avez groupé par le passé, ou avec lesquels vous avez interagis, que ce soit à travers des échanges commerciaux, avoir combattu ensemble, et plus encore. Cette liste peut être consultée afin de retrouver ce super joueur avec qui vous avez groupé l’autre jour. Vous pourrez les ajouter à votre liste d’amis si vous avez oublié de le faire, et/ou l’inviter dans votre Warband ou votre Battlegroup ! Ceci se rattache également bien à notre système de Récompenses Journalières.

    La Liste de Blocage permettra de bloquer un joueur de votre Royaume, avec options configurables. Vous pourrez bloquer leurs messages texte, vocal, sociaux, ou simplement toute communication.
  • 5.2 Tableau d’Affichage Personnel
    Votre tableau d’affichage personnel est l’espace où vous pouvez poster vos bulletins personnels, messages texte, images et vidéos, ainsi que lire et commenter sur une page avec une vue d’ensemble des messages postées par d’autres. Votre tableau d’affichage vous permettra de voir les bulletins postées par tous les groupes dont vous faites partie et ayant cette fonctionnalité, ainsi que vos amis.

  • 5.3 Archives Personnelles
    Les archives personnelles d’un joueur contiennent un historique des activités auxquelles le joueur a participé durant son temps de jeu. Vous aurez la possibilité de faire des recherches filtrées dans ce registre afin de faciliter la navigation dans les informations disponibles. Il inclura, les joueurs combattu, vaincus, objets créés, matériaux raffinés, ressources collectées, et plus encore.

    Ce registre personnel peut être rendu public ou visible de façon limitée par une série de catégories de permissions. Nous parlerons du système de permissions en détail plus bas, dans la section sur les fonctionnalitées de groupe partagées. Cependant, par défaut ces informations sont privées et uniquement visibles par le joueur.

  • 5.4 Courier Personnel
    Chaque joueur aura une boîte aux lettre en jeu vers laquelle les autres joueurs du Royaume pourront envoyer des messages. Le formatage des messages fonctionnera de la même façon que les bulletins, ils pourront contenir du texte, et des images et vidéos incorporées. Ceci-dit, ils devront être venir de sources autorisées ou être des captures d’écran directement depuis le jeu. Les messages n’auront pas de pièces jointes, vous ne serez pas en mesure d’envoyer de l’argent, des objets, ou des cookies aux pépites de chocolat. Si vous voulez faire des échanges vous devrez établir un contrat ou rencontrer le joueur en jeu.

    Encore une fois, pour être parfaitement clair, aucune communication n’est possible entre différent Royaumes par quelque système fourni par CSE que ce soit, y compris les messages personnels. Vous ne pouvez envoyer de messages qu’au membres de votre Royaume sur le même serveur que vous.
  • 6. Fonctionnalités de groupe Partagées

    Tous nos systèmes de groupe pour la Beta 1 partagent certaines fonctionnalités sociales. Elles sont listées ici afin d’éviter la répétition d’informations identiques pour chacun des types de groupe de la Beta 1 dans les sections qui suivent la 6.1

  • 6.1 Permissions et Gestion des permissions
    Partagé par : Tous les groupes
    Nous avons souvent parlé de fournir au public un grand nombre d’informations à propos du jeu et des joueurs via nos serveurs d’API. Camelot Unchained fournira un niveau de données sans précédent accessibles à des services Web, à partir desquels joueurs et développeurs d’applications tierces seront capables de fournir des outils externes de gestion d’inventaire, des indicateurs détaillées, et bien d’autres choses. A tel point que vous serez même capable d’équiper des objets sur votre personnage à partir de votre inventaire sans même être connecté au jeu. Cette fonctionnalité est d’ores et déjà accessible aujourd’hui via notre API publique.

    Avec ce degré de données accessibles, la confidentialité de tous les joueurs et groupes est de la plus haute importance pour nous. A cette fin, un système de permissions robuste sera construit au coeur de la technologie du système social de Camelot Unchained.
  • 6.2 Rangs
    Partagé par : Tous les groupes
    Afin de faciliter et simplifier la gestion des permissions pour les sous-groupes de joueurs d’un groupe, des rangs peuvent être créés et se voir assigner un ensemble de permissions. Chaque type de groupe peut créer un grand nombre de rangs (dont le nombre dépendra du type de groupe). Chaque rang peut être nommé et, dans certains cas, une icône ou un marqueur visuel peut être assigné comme indicateur pour les membres de ce rang. Ces rangs peuvent être créés ou modifiés par tout membre d’un rang possédant la permission adéquate.
  • 6.3 Chat de discussion
    Partagé par : Tous les groupes
    Quel type de MMO serait-ce sans un système de chat ? Les fonctionnalités évoquées ici à propos du chat, à la fois textuel et vocal, seront limitées à leur rapport aux groupes. Comme la plupart des fonctionnalités sociales que nous construisons pour Camelot Unchained, nous voulons donner aux joueurs autant de contrôle et de flexibilité que nous le pouvons.

    Chaque groupe aura, par défaut, son propre canal privé de chat textuel et vocal, et aura la possibilité d’en créer d’autres. Par défaut, les restrictions de ces canaux permettront à tous les membres du groupes d’y accéder ; cela peut, toutefois, être modifié par tout membre d’un rang possédant les permissions appropriées. Les rangs peuvent recevoir des permissions spécifiques au chat pour activer des fonctions de modérations, désactiver qui peut parler ou pas, et bien d’autres choses encore. Les canaux de chat peuvent également être configurés pour autoriser ou interdire certaines fonctionnalités, telles que souhaitées par le groupe, comme par exemple prohiber l’insertion d’images ou de vidéos dans le chat.

    Bien qu’un joueur puisse être en même temps dans de multiples canaux de chat textuels, il ne peut rejoindre qu’un chat vocal à la fois. Nous voulons faire en sorte que joindre un canal vocal en jeu soit aussi simple que possible. Chaque canal textuel pourra avoir un canal vocal associé par défaut et un joueur peut par le simple clic d’un bouton le rejoindre. Chacune des interfaces de groupe aura également un bouton qui permettra d’un simple clic de rejoindre le canal vocal pour ce groupe !
  • 6.4 Indicateurs
    Partagé par : Joueurs solo, Warbands (Permanent), Ordres, Campagnes
    Pour les récompenses quotidiennes de progression d’un joueur, ainsi que pour nos propre système de métriques internes, nous allons garder trace de toutes les actions significatives réalisées par un joueur et un groupe tout au long de la journée. Beaucoup de ces données alimenteront nos différents systèmes de groupe, y compris les joueurs solo comme des groupes de un. Ces données permettront la mise en place d’une progression de groupe ; plus d’informations à ce sujet plus tard.

    Avec toutes ces données suivies, enregistrées et stockées dans nos bases de données, est-ce qu’il ne serait pas génial que vous puissiez voir ces données vous-même ? Ou créer de chouettes site webs, ou des sortes de «herald», pour visualiser toutes ces données. Bien sûr que si. Une grande partie de ces données sera donc disponible via nos serveurs d’API. Il est toutefois important de noter que toutes les données ne sont pas égales et que bien que certaines portions soient disponibles immédiatement, d’autres plus sensibles du point de vue du gameplay pourraient être retardées, afin de ne pas avoir un impact négatif sur le jeu en cours. En outre, certaines données pourraient être expurgées, partiellement ou complètement, en fonction des permissions de groupe et de joueur.
  • 6.5 Héraldique
    Partagé par : Warbands (Permanent), Ordres
    Quelle meilleure façon de représenter votre groupe que de montrer votre superbe héraldique sur votre équipement ? L'héraldique peut être conçu dans l'UI sociale par un membre possédant les autorisations appropriées. Elle peut être affichée sur votre personnage à travers des capes spéciales, des tabards et des boucliers ! Vous voulez décorer votre château aussi ? Placez votre héraldique sur différents types de bannières et de drapeaux tout au long de votre parcelle.

    Les calques d'éléments héraldiques peuvent être mélangés et correspondre à l'un des groupes dont vous êtes membre, pour l’afficher sur les éléments appropriés. Par exemple, vous pouvez porter une cape et tabard avec votre Ordre héraldique, en même temps qu’un bouclier orné de celui du Warband.

    Différents groupes auront également différents niveaux d'héraldique à leur disposition en fonction du type de groupe, avec les Ordres (Guildes) ayant les options de personnalisation les plus variées, y compris les travaux spéciaux commandés par CSE.
  • 6.6 Distinctions et Réalisations
    Partagé par : Warbands (Permanent), Ordres, Campagnes
    Qui n'aime pas recevoir des étoiles d'or ? Les groupes et leurs membres peuvent se voir attribuer diverses distinctions et réalisations. Ceux-ci peuvent provenir de plusieurs sources différentes, mais ce document ne traitera que de ceux liés au regroupement.

    Les distinctions viendront sous la forme de banderoles de bannière et/ou modificateurs d’héraldiques. Ceux-ci seront affichés sur le profil du joueur en jeu, ainsi que sur le site de suivi des statistiques du jeu, si le joueur a rendu son profil public.

    Le commandement d'un groupe peut créer des distinctions et les attribuer aux membres comme bon leur semble. Disons que vos membres ont vraiment fait du bon travail : vous pouvez les récompenser en leur donnant une étoile d'or sur leur héraldique !

    Les distinctions et les réalisations peuvent aussi être obtenues grâce à l'achèvement de tâches dans une Campagne. Plus de détails sur les Campagnes seront discutés plus loin sur ce document.
  • 6.7 Social User Interface Features
    Partagé par : Warbands (Permanent), Ordres, Campagnes
    La communication est essentielle pour toute taille de groupe qui souhaite travailler ensemble sur tout type d'objectif. La communication instantanée par le biais d'un échange textuel ou vocal, ne suffit pas à coordonner avec un groupe de joueurs qui ne sont pas tous en ligne en même temps. Plusieurs fonctions de l’UI seront construites spécifiquement pour faciliter cette communication supplémentaire.

    Les groupes disposeront d'une interface en jeu, à partir de laquelle vous pourrez visualiser les informations standards, telles que les membres, les classifications, la gestion des autorisations et d'autres outils d'administration. En outre, chaque groupe aura un tableau d’affichage, sur lequel ceux avec les autorisations appropriées peuvent afficher des messages, pouvant être visualisés par le groupe. Les messages peuvent avoir des autorisations définies pour restreindre l'affichage. À mesure que l'UI pour le jeu est développée via des outils Web, vous pouvez publier des images et des vidéos sur votre panneau d’affichage, qui s’y incrusteront et pourront être joué dans le jeu ! Les membres du groupe peuvent également faire des commentaires et discuter de votre publication. Oui, fondamentalement comme certains de ces grands sites de médias sociaux, que tout le monde connaît.

    Les groupes auront accès à des listes de courriels privées, afin d’en composer à tous les membres du groupe ou à des rangs spéciaux.

    Les groupes auront accès à un calendrier en jeu, sur lequel ils peuvent planifier des événements. Les événements peuvent être placés sur le calendrier avec des liens vers une publication spécifique qui traite de ceux-ci. Les autorisations de visualisation des événements peuvent être définies par rang, de sorte que seuls certains rangs peuvent afficher cette publication spécifique.

    L'interface sociale d'un groupe contiendra également une liste de membres très solide. La liste permet de rechercher, de trier et de filtrer les utilisateurs en utilisant plusieurs clés différentes, telles que le nom, la race, la classe, le temps passé en groupe et en ligne, les contributions et plus encore.
  • Notes de MJ : Parler des systèmes/fonctionnalités sociaux pour Camelot Unchained est un peu un terrain miné. Nous voulons nous concentrer sur les fonctionnalités, que la vaste majorité de nos joueurs trouveront avantageux pour leur expérience de jeu, et non celles qui semblent appartenir à un autre type de jeu complètement différent. Pour la Bêta 1, nous croyons que cet accent doit être mis sur un nombre limité de systèmes (trois, dans ce cas), qui seront ajoutés et itérés à travers tout le processus Bêta. Nous espérons également, comme nous le faisons habituellement, d'apporter des fonctionnalités nouvelles et/ou s'additionnant à des systèmes biens connus et «old-school», tels que les Guildes/Ordres.

    7. Warbands

    La taille compte dans les systèmes sociaux, et les Warbands sont notre plus petite taille de groupe. Ils sont plus que de simple «groupes», vu que ceux dans les MMORPGs ont simplement été des regroupements éphémères de joueurs, qui étaient, comme les mouchoirs, inévitablement jetables. Dans notre jeu, bien que les Warbands peuvent être toujours éphémères, vous pouvez cependant les rendre permanents en les nommant. Vous pouvez les voir comme des équipes d'interventions semi-permanentes, des compagnies libres, etc., qui ont un peu plus en commun avec avec les guildes, qu’avec la conception habituelle d’un groupe de MMORPG, mais qui n’ont pas la grande majorité des avantages que possèdent les guildes / ordres, y compris des choses comme la propriété d’une parcelle.

    L’ajout de la nomination/des Warbands permanents en est une importante pour le genre pour de nombreuses raisons, comprenant la capacité pour les joueurs d’avoir un moyen facile de grouper avec différents amis/compagnons de royaume, sans à avoir constamment à créer un nouveau groupe/Warband. Et pour ceux tatillons sur les scores, ceci permet aussi aux joueurs de créer des Warbands qui deviendront célèbres dans leurs domaines, sans attachement forcé à une structure plus vaste comme un Ordre. Il est important de reconnaître que la façon dont les joueurs jouent les MMORPGs en 2017 et après, est différente de celle en 1999, 2001, 2004, etc. Bien que nous développons un jeu «old-school», nous avons toujours dit que nous prévoyons d'ajouter/utiliser des fonctionnalités dans le jeu, qui donneront une meilleure expérience du RcR, et qui ne «rabaissent» pas le genre ou trop dans l’assistanat. Permettre à de petits groupes de personnes de jouer plus facilement avec leurs amis et leur famille - et aussi obtenir la reconnaissance pour ce faire. - répond à toutes ces exigences.

    Pour la Bêta 1, les fonctions pour les Warbands incluront les éléments suivants, en plus de celles couvertes au-dessus :

  • Les joueurs peuvent créer des versions temporaires ou permanentes de Warbands. Celles permanentes devront avoir un nom.
  • Les Warbands permanents auront une taille maximale de «leur liste de membres», qui sera suffisamment grande pour que les gens puissent aller et venir, mais trop petite pour vraiment concurrencer les Ordres. De plus, comme nous l'avons dit plus haut, les avantages pour les Warbands sont assez limités par rapport aux Ordres.
  • Les Warbands peuvent compter jusqu’à 8 joueurs au début de la Bêta 1. Comme nous avons dit durant nos mises à jour, nous allons expérimenter différentes tailles de Warbands jusqu’à ce que ce soit - comme le gruau de Boucle d’or - juste comme il faut.
  • La santé et le statut des membres actifs du Warband sont visibles en jeu en temps réel. Nous allons utiliser ceci, et d’autres fonctionnalités de l’UI durant le processus de Bêta pour s’assurer, comme nous l’avons dit, que les joueurs puissent avoir toutes les informations utiles pour nous aider à tester/débugger le jeu. Il n’y a aucune garantie que cette fonction sera ajoutée de façon permanente au jeu, particulièrement quand nous commencerons le travail sur la «Vision de Soigneur» après le début de la Bêta 1.
  • Un joueur peut être membre de plusieurs Warbands, mais ne peut être actif que dans un seul à la fois. Le statut d’actif est pour des raisons de mécaniques de gameplay : Le joueur apparaît dans le groupe sur l’UI du Warband, ses membres peuvent voir leur santé et statut en temps réel, et les effets de compétence/groupe peuvent affecter ce membre. En tant que membre «inactif» d’un Warband, le membre peut toujours voir et participer aux discussion et peut rejoindre tout Warband dont il est membre à tout moment pour devenir actif, s’il y a une place de disponible.
  • Notes de MJ : l’ajout de la permanence aux Warbands est important pour nos joueurs. Si nous sommes dans le vrai, et que cela n’a jamais été fait auparavant (s’il vous plaît, dites nous si vous connaissez un MMORPG qui a utilisé ce genre de fonctionnalité), c’est quelque chose dont nous pensons qu’elle sera réappropriée par d’autres studios/jeux. Etant donné le genre de jeu que nous développons, nous avons besoin d’avoir le système de Warband, qui soutient et améliore l'expérience que nos joueurs auront au lancement.

    8. Battlegroups

    Les Battlegroups sont notre version du «groupe de Raid» typique dans un MMORPG pour Camelot Unchained. Un Battlegroup est un groupe constitué dans nombre illimité de Warbands. Mais contrairement aux Warbands, cependant, il ne peut pas être rendu permanent : il existe uniquement comme une association temporaire de Warbands pour des raisons d’organisations.

    Le rôle qu’un Battlegroup rempli dans Camelot Unchained, est de permettre de plus larges groupes de joueurs, qui peuvent ou non être affiliés l'un à l'autre par un autre type de groupe, de disposer d’outils de gestion partagés et temporaires de discussion, vocale et de permissions.

    Les Battlegroups peuvent créer et gérer des Warbands temporaires, afin de pouvoir ajouter des joueurs, qui n’ont pas encore rejoint un Warband en tant que membre actif.

    Pour la Bêta 1, les fonctionnalités des Battlegroups incluent :

  • Les joueurs peuvent créer un Battlegroup.
  • Un nombre illimité de Warbands peut être invité dans un Battlegroup.
  • L’UI du Battlegroup sera implémentée pour montrer - au minimum - le nom du Battlegroup, le nom des Warbands membres et le nom des membres de ces dernières (ce n’est pas trop déconcertant à dire, n’est-ce pas ?).
  • Chat de discussion, comme décrit sous la section des fonctionnalités partagées.
  • Système de rang simplifié.
  • Notes de MJ : Les «Raids», comme ils sont les plus souvent connus dans les MMOs, ne font pas partie de Camelot Unchained, car notre jeu consiste à envahir les terres ennemies. Pour cela, nous avons besoin d’une solution pour que les joueurs communiquent efficacement, dans des groupes plus larges qu’une Warband. L’intégration et la connectivité entre les joueurs et nos systèmes de groupe, aideront à distinguer nos système sociaux de ceux des la plupart des MMORPGs, particulièrement les anciens que nous regardons d’un regard affectueux. Comme nous l’avons toujours dit, bien que nous voulons créer un jeu old-school, nous désirons aussi y mettre des fonctionnalités de jeux un peu plus modernes, qui ajouteront de l’intérêt et du plaisir à nos joueurs.

    9. Ordres (Guildes)

    Les Ordres dans Camelot Unchained sont similaires aux guildes dans d’autres MMORPGs. Un Ordre est un groupe avec un nombre limité de joueurs pouvant, entre autre, créer et gérer ses propres Warbands permanents. Pour la Bêta 1, les Ordres sont vraiment en mode Produit Minimum Viable (PMV), car ils seront moins importants que les autres types de groupe pour le moment. D’un autre côté, nous devons mettre en place les fondations pour ce qui viendra après que nous soyons entrés en Bêta 1 et tout au long de celle-ci. Les guildes ont été une part importante du succès des anciens MMORPGs, et, bien que nous ne nous attendons pas à ce que les guildes aient la même importance qu’à l’époque, cela ne veut pas dire que nous ne voulons pas créer un très bon système pour les soutenir. Notre but avec le système des Ordres est, une fois que nous donnerons plus de détails sur celui-ci, est que les gens qui aiment les guildes, se tournent vers nous et disent «ça c’est un bon cochon.» (NdT : extrait du film «Babe»)

    Ceci dit, pour la Bêta 1, nous sommes en PMV pour les Ordres, mais ils devraient inclure les choses suivantes. Pour la Bêta 1, les fonctions pour les Ordres devraient inclure les choses suivantes.

  • Les joueurs peuvent créer un Ordre.
  • Un Ordre aura un nombre de membres limité, à déterminer plus tard, de même que d’autres surprises.
  • Le nom de l’Ordre visible au dessus du personnage.
  • Un joueur ne peut joindre qu’un seul Ordre.
  • Chat, comme décrit dans la section des Fonctionnalités Partagées.
  • Rangs - Les rangs ont une signification à la fois symbolique et visible pour les joueurs, étant donné qu’ils incluent des objets montrant leur rang.
  • Ca n’a pas l’air super excitant n’est-ce pas ? Non, mais gardez à l’esprit que les Ordres seront en mode Produit Minimum Viable pour la Bêta 1. Ceci-dit, étant donné que l’on aime beaucoup nos Backers, et parce que l’on ne veut pas des gens marchant sur nos bureaux avec des torches à la main, criant «Amenez nous la tête de JB et MJ !» nous allons parler un petit peu plus de ce à quoi vous pouvez vous attendre pour les Ordres durant le processus de Bêta.

  • 9.1 Avantages
    Parmis les avantage qu’il y aura à faire partie d’un Ordre, il y aura :
    • Parcelles - Les Ordres ayant atteint un certain niveau peuvent posséder leur propre parcelle. Celles-ci sont les plus grandes, et ont les plus grandes possibilité esthétiques parmis les groupes.
    • Banques - Les banques de guilde ont été amusantes mais problématiques par moments dans les autres MMORPGs. Nous voulons créer un meilleur système pour celles-ci.
    • Magasins - Les Ordres peuvent mettre en place leur propre magasin, pour leur membres, et les non membres puissent y accéder.
    • Héraldique d’Ordre - expliqué plus haut.
    • Système de progression - Nous ne voulons pas rentrer dans les détails sur ceci pour le moment, Mais le système de progression pour les Ordres sera similaire à celui des joueurs. Relisez les Principes Directeurs pour avoir des indices sur la façon dont ceci va fonctionner.
    • Itinéraires de caravanes - Les Ordres peuvent prendre des dispositions afin que des caravanes leur livre de l’approvisionnement, soit auprès de joueurs, soit auprès de Maîtres des Caravanes, en fonction de leur taille.
    • Vêtements - Les ordres devraient pouvoir créer leurs propres vêtements et les enregistrer auprès du Gardien des ordres de leur Royaume. Afin d’enregistrer une insigne, l’Ordre doit atteindre un certain niveau en jeu, et celle-ci doit être différente des autres insignes.
    • Hall d’Ordre - Plus de détails sur cela durant la Bêta 1.
    • Calendriers - plutôt évident, non ?
    • Emails privés - rien à ajouter.
  • Attendez, il y a plus, beaucoup plus ! Ceci dit, nous gardons nos grandes bouches fermées sur le sujet pour le moment, car les voisins ont de grandes oreilles, et n’ont pas peur de déclarer qu’ils ont inventé quelque chose des mois, voir des années après que nous en ayons parlé. D’un autre côté, je pense que ce dont nous avons parlé ci-dessus montre bien assez notre dévouement à faire en sorte que les Ordres/Guildes auront une place importante au sein de Camelot Unchained, maintenant et pour toujours. Mais faites nous confiance, nous avons des choses en réserve qui vont encore une fois surprendre les gens, et cimenter le système d’Ordre que nous avons prévu, comme un des plus intéressants dans un MMORPG, même si nous n’avons pas tous les éléments esthétiques et autres choses présentes dans d’autres jeux avec plus de fonds.

    Notes de MJ : Comme dit plus haut, les Ordres vont bénéficier de beaucoup d’attention de notre part durant le processus de Bêta. Bien que nous n’ayons pas les ressources nécessaires pour essayer de créer un système surpassant certains des super systèmes de guilde présents dans d’autres jeux, nous allons en créer un adapté à notre jeu centré sur le RcR. Nous discuterons de nos plans pour celui-ci au cours de la Bêta 1, et encore une fois, considérez ceci comme le plus basique des PMV et un bonus pour la Bêta 1.

    10. Campagnes (absents pour le début de la Bêta 1)

    Bien que n’étant pas une fonctionnalité pour le début de la Bêta 1, nous incluons les Campagnes dans ce document, afin de donner une vision plus complète des systèmes de regroupement pour Camelot Unchained.

    Les Campagnes sont un système complètement nouveau, conçu pour Camelot Unchained. Elles sont un regroupement temporaire de joueurs, travaillant de concert pour atteindre un ou plusieurs objectifs. Elles sont un groupe flexible, dont les membres peuvent être l'un des autres types de groupes permanents. Cela inclut les joueurs solos, WArbands et Ordres. Les Campagnes existent pour atteindre des objectifs à travers des missions, avec une participation de multiples groupes et/ou de foule de joueurs à travers le Royaume.

    Elles peuvent être créées afin d’organiser des guerres à grande échelle, sièges, ou la construction d’énormes châteaux. Elles peuvent aussi être utilisées pour quelque chose d’aussi simple qu’un groupe d’amis travaillant ensembles, pour fabriquer des items en tant qu’équipe, tout en suivant leurs propres objectifs, et peut-être même s’amuser à faire de petites compétitions entre eux. Elles sont conçues pour encourager la coopération dans le royaume, et permettent des contenus supplémentaires générés par les jeux et les utilisateurs, tout en fournissant des fonctionnalités intégrées sécurisées aux organisations. Elles permettront aux créateurs de Campagne, qui souhaitent organiser de grands événements impliquant de grandes quantités de ressources, d'armements, de châteaux et de matériel de siège, de mettre à disposition ces ressources. De cette façon, ils ne devront pas risquer de mettre leurs actifs dans les mains d'autres joueurs sans garantie de retour dans un «échange de confiance».

  • 10.1 Formation
    Les Campagnes sont créées par les joueurs en parlant à un PNJ dans la capitale pour l’enregistrer. Elles ont un coût, une date de départ, une durée et un indicateur de confidentialité - public ou privé - qui doivent être tous définis lors de la création.

    Une Campagne publique sera visible par tous les joueurs du royaume, et elle y acceptera tous les membres du royaume. Une privée ne sera pas listée, et les invitations devront être envoyées individuellement et/ou acceptées par le commandement de la Campagne.
  • 10.2 Actifs, propriétés et Permissions
    Bien qu'une Campagne ne peut jamais posséder aucuns actifs d’elle-même, il peut y avoir un contrôle temporaire pendant la durée de son existence. Cela comprendra des parcelles, des structures en leur sein, et aussi d'importants items comme le matériel de siège.

    Les autorisations d'accès et d'utilisation de toute propriété prêté, peuvent être configurées par Rangs dans la Campagne.

    Lorsqu'une Campagne se termine, tous les biens et propriétés utilisés par celle-ci sont conservés par les propriétaires d’origine. Cela exclut les objets jetables tels que les épées, les armures, les flèches, etc. Ces types d'items jetables, s'ils sont donnés à d’autres joueurs au cours de la Campagne et non restitués, resteront avec ces mêmes joueurs. C'est pourquoi nous avons le concept d'un magasin et d'une monnaie de campagne, qui seront discutés plus loin, comme moyen de distribuer ces types d'items en toute sécurité.
  • 10.3 Rangs
    Comme les autres types de groupe, une Campagne peut créer des classements personnalisés avec des configurations d'autorisations, définis pour être attribués à ses membres. Les rangs peuvent être attribués à un groupe dans son ensemble, ou individuellement.
  • 10.4 Missions et Contrats!
    Les commandants de Campagne peuvent créer des missions pour les utilisateurs, et donner des récompenses pour l'achèvement et / ou la participation à celles-ci. Une Campagne peut contenir une ou plusieurs missions en même temps, et celles qui ont un objectif à accomplir, peuvent débloquer une mission à suivre à la fin de celles-ci, créant une chaîne de missions. Il y aura de nombreux types de missions qui peuvent être configurés et offerts par une Campagne, mais pour ce document, nous n'en parlerons pas encore.
  • 10.5 Devise, Progression et Magasin de Devise
    Plus de détails sur cette fonctionnalité unique pour un système unique durant la Bêta 1.
  • 10.6 Récompenses, Distinctions et Trophés
    Avec tous ces discours sur les missions, qu’obtenez-vous en les complétant ? Les commandants de Campagne auront la possibilité de distribuer toutes sortes de récompenses, pour la réalisation des missions et pour avoir participé à la Campagne dans son ensemble. Plus d'informations à ce sujet seront révélées au cours de la Bêta.
  • 11. F.A.Q.

    Pour répondre à un paquet de questions inévitables :

  • «Est-ce qu’un Ordre peut créer un Warband permanent, et y inviter un joueur non-membre de l'Ordre ?» Oui.
  • «Ce Warband peut-il avoir un membre permanent, qui n’appartient pas lui aussi à l'Ordre d’origine ?» Oui.
  • «Un joueur peut-il posséder plusieurs Warbands ?» Oui.
  • «Coûtera-t-il quelque chose de créer un groupe ?» Pas pendant la Bêta 1.
  • «Devra-t-on parler à un PNJ pour créer n’importe quel groupe ?» Pas pendant la Bêta 1.
  • «Avez-vous planifié de connecter ceci avec Facebook, Twitter et autres réseaux sociaux ?» Ce n’est pas dans nos préoccupations pour l’instant.
  • «Puis-je être dans plusieurs Ordres ?» Non. Mj pense que c’est l’une des choses qui à porté préjudice à la viabilité et l’attrait des guildes dans les MMORPGs modernes.
  • «Si j’ai un Ordre nommé The Arthurian Knights of Camelot, puis-je empêcher les autres d’utiliser le mot Knights dans le nom de leur Ordre ?» Non. Si vous avez réservé ce nom d'Ordre, les autres ne pourront pas utiliser ce nom entier dans leurs Warbands, Battlegroups ou Ordres, mais ça ne s’applique pas sur les parties composant le nom. Ainsi votre nom entier d'Ordre est protégé, mais les autres peuvent toujours utiliser les mots dans d’autres noms. Sinon, il se passerait l'équivalent de la course à la propriété pour les mots.
  • «Si je réserve un nom d'Ordre, puis-je empêcher les autres d’utiliser notre nom avec des homonymes, comme avec The Syndicate et The Sindicate ?» Oui. Cela impliquera le service client, mais oui, nous imposerons des choses comme ça. En revanche, votre nom sécurisé ne l’est pas pour les abréviations, le langage L33T, etc.
  • «Est-ce que les joueurs seront capables de passer rapidement entre les Warbands, pour profiter d’un avantage tactique durant une bataille ?» Non, cela serait trop facile et trop de l’assistanat pour nous.
  • 12. Pour conclure

    Comme dit plus haut, ce n’est pas la version finale de ce document, et ce n’est pas garanti que ce soient toutes les fonctionnalités que vous verrez au lancement de Camelot Unchained. Durant les phases de tests de la Bêta, des changements auront lieu. Bien que nous n’aurons pas les même ressources que la plupart des autres MMORPGs, pouvons toujours créer de très bons et robustes systèmes sans trop d’efforts, comparés aux autres choses que nous développerons pour le jeu. Et, si rien d'autre, l'utilisation des commandes slash nous permettrons de les obtenir plus tôt et de donner à beaucoup de joueurs à un sens de «déjà qui?» ☺

    P.S. N'oubliez pas de remercier l'homme avec le nom le plus cool dans le monde du jeu, monsieur James Brown (JB, bien sûr), pour son travail non seulement en écrivant ce document (j’ai juste édité/ajouté quelques fioritures), mais aussi en menant le travail de conception sur ces systèmes. Bien plus encore sont à venir !

    À suivre...

    La semaine prochaine!