details launcher .pdf



Nom original: details launcher.pdf

Ce document au format PDF 1.5 a été généré par Adobe InDesign CS6 (Macintosh) / Adobe PDF Library 10.0.1, et a été envoyé sur fichier-pdf.fr le 25/06/2015 à 10:42, depuis l'adresse IP 217.108.x.x. La présente page de téléchargement du fichier a été vue 553 fois.
Taille du document: 181 Ko (8 pages).
Confidentialité: fichier public


Aperçu du document


Détails de projet...

...Cahier des charges

Ce document présente tous les détails du projet, il est rédigé au fur et à mesure de son avancement et en fonction des idées
de chacuns des membres du groupe.

Sommaire
Détails de projet... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le moteur de jeu local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serveur Distant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les GameServers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les données des serveurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les types de parties en ligne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les types de parties Campagne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
2
4
5
6
7
8
8

Alleos - Développement RemoteEngin
Ccx - Développement LocalEngin, développement du contenu
StarDuck - Game Designe, développement du contenu
Felyndrah - Scénario

Détails de projet...

1

Le moteur de jeu local
Le moteur de jeu local est développé en AS3 sous la machine virtuelle AIR 18 par Ccx. Merci à Alleos pour son soutien et
son aide dans l’optimisation globale du code.
Ce moteur de jeu local est le coeur même du projet, c’est lui qui donnera naissance à tous les projets présentés dans ce document. Il est programmé pour relier l’uplauncher, le jeu et le serveur distant (RemoteEngine par Alleos, voir la partie Serveur
distant).
La façon dont il est conçu est spécialement pensée pour être propice à une modulation à toutes épreuves (ou presque). Je
vais donc présenter les quelques détails de chacunes de ses fonctionnalités.

Fonctionnalités du moteur de jeu local :
1 °) UplauncherConnection
Afin de synchroniser tous les systèmes (jeu, distant, uplauncher) avec le joueur, l’uplauncher envoie des packets au moteur
de jeu local (diagramme des packets section Le launcher). Lorsque le joueur effectue une action dite ‘‘critique’’ (fermer le jeu
par exemple), le moteur de jeu local envoie au serveur distant si il y est connecté un packet pour l’avertir de la fermeture. Il
envoie également un packet à l’uplauncher pour signaler que le jeu est disponible au lancement.
Au démarrage, l’UplauncherConnection permet de renseigner tous les paramètres de jeu au moteur. Il lui envoie les chemins où se trouvent les données concernant le monde et les fichiers de sauvegarde du joueur à l’aide du système natif LRIPlayer.

2 °) LRIPlayer
Le LRIPlayer est un système natif permettant au moteur de jeu local d’accéder à des données dans des fichiers .sav ou .db.
Ce système entièrement codé et prévu pour le bon fonctionnement du moteur de jeu local constitue un moyen optimisé et
simplifié d’accéder à des données illisibles à l’œil nue. Il peut intégrer un système d’encryptage via le PluginPlayer. Il permet
entre autre de faire une recherche de données dans la base de données locale : la DataBank.

3 °) DataBank
La DataBank est le centre des données. C’est lui qui gère tous les chargements des données et qui les renvoie lorsque les
autres fonctionnalités du moteur de jeu en ont besoin. Il créer les bon objects (voir la liste des classes) selon ce qu’on lui demande. Il donne accès aux fonctions get, set, delete et insert comme une base de donnée SQL normale.
Il permet de charger plusieurs bases de données et gère les conflits d’ID par un renommage automatique. Il permet également de charger des packs de données (DataPack) et d’accéder à chaque variable selon l’identifiant du DataPack.

4 °) PluginsPlayer
Le développement de cette fonctionnalité ne commencera qu’a la fin du développement du moteur de jeu. Il permet aux
utilisateurs avide de programmation d’accéder simplement aux fonctionnalités de l’émulateur via un langage personnalisé
prévu pour l’environnement du LocalEngin. Il restreint l’accès aux fonctions critiques et aux fonctions d’envoie de packet ou
de connections à un serveur distant mais donne également l’accès aux fonctionalités tels que l’activation du mode debug ou les
hooks pour les fonctions évenementielles.

5 °) Les systèmes de caches
Les systèmes de caches sont prévu pour accueillir des données au lancement du jeu lorsque le joueur commence à jouer.
Elles sont déchargées dès lors que le joueur ne les utilise plus et son chargées en prévoyance lorsque le joueur est susceptible de
les utiliser.
MapCache
Au chargement d’une map, sa MapData est parsée et ses triggers sont attribués. Les MapActions s’exécutent au besoin (interaction du joueur, timer ou autre). Toutes les maps reliées aux MapActions sont ainsi préchargées, celà affecte tous les types
de MapActions (dialogues de PNJ, triggers, useItem). Si un joueur possède un useItem qui téléporte sur une map, cette map est
constamment préchargée sous sa forme LRI. Lorsque le joueur quitte une map, celle-ci passe en cache et les précédentes sont
libérées du cache et le cycle reprends au départ (chargement, mise en cache, etc...) sauf pour les maps reliés aux useItems.
ItemCache
Au lancement du jeu, le moteur de jeu ne charge que les items du joueur avec leurs stats respectives. Les items aux stats
aléatoires sont chargés uniquement lors d’une action relié à un item à savoir un combat, un dialogue de PNJ, un trigger, un
endFight_Action ou un useItem.

2

Le moteur de jeu local

MonsterCache
Le MonsterCache fonctionne grâce au MapCache. Il charge sous la forme LRI toutes les données d’un monstre selon le
besoin (entitée ou stats si combat ou non). Les monsters sont libérés du cache uniquement si les maps mises en cache ne possèdent pas ces monstres. Si les maps mises en cache ont dans leurs informations le monstre en question, le grade est de nouveau
calculé.
IACache
Il répertorie toutes les actions du joueur en combat. Il permet à l’IA de constituer une base de donnée par combats afin de
l’aider à casser les stratégie répétitives. Il sauvegarde toutes les actions répétitives jusqu’a 5 tours de jeu. Si une action se répète
2 fois, l’IA s’arrange pour essayer de casser cette stratégie d’une façon simple. Plus le joueur arrive à répéter ces actions, plus le
monstre s’énervera et deviendra agressif envers la cible qui répète ces actions.

6 °) Liste des Objects
Voici l’arborescence des classes Object du moteur de jeu :
• Player : new Player(PlayerInfos:String); Il s’agit de la classe regroupant toutes les informations du joueur local.
• RemotePlayer : new RemotePlayer(RemotePlayerInfos:String); Classe regroupant les informations du joueur distant.
• Map : new Map(MapInfos:String); Classe regroupant toutes les informations de la map locale sur laquelle se trouve le
joueur.
• Cell : new Cell(CellInfos:String); Classe regroupant toutes les informations d’une cellule sur la map locale.
• Monster : new Monster(MonsterInfos:String); Classe regroupant toutes les informations d’une entitée Monstre.
• Item : new Item(ItemInfos:String); Classe regroupant toutes les informations d’un item.
• ItemSet : new ItemSet(ItemSetInfos:String); Classe qui réunit toutes les informations sur un pack d’items.

7° ) Les GameActions
Les GameActions gèrent toutes les interractions du jeu hors combat et hors déplacement. Ils gèrent donc les téléportations
de maps, les dons d’objets, etc. Trouvez la liste des GameActions dans le registre des données à la fin de cette doc. Les GameActions sont sous forme de plugins, donnant ainsi accès aux joueurs la possibilité de créer leurs propres GameActions.

8° ) Les Constantes
Les constantes ne servent pas seulement à répertorier des données fixes, elles servent également de données statics. Elles
servent à sécuriser les connexions pour éviter certaines choses comme par exemple la connexion sur 2 personnages identiques.

9° ) Le mode multiPlayers local
Le mode multiPlayers local est désactivable via les options de serveur dans le worldConfig.cfg. Ce mode donne accès aux
fonctionnalités de l’émulateur qui gère la difficulté des combats en ajoutant des niveaux aux monstres ou en ajoutant des
monstres selon l’endroit où se trouve le joueur. Il permet au joueur de jouer avec plusieurs personnages différents, il lui suffit de
sélectionner les personnages qu’il veut jouer à la selection des personnages sur le launcher. En jeu, le joueur ne possède qu’un
seul personnage qui se déplace mais en combat il bénéficie de tous ses personnages. La configuration du jeu permet de limiter
le nombre de personnages dans le même combat (invocations non incluses). Lorsque le tour de jeu viens à un personnage, le
moteur de jeu envoie tous les sorts au joueur et il bénéficie ainsi des sorts et des caractéristiques de son personnage. Ce mode
est à voir mais si il est faisable il est à développer au maximum.

10° ) Le mode multiPlayers distant
Il s’agit d’un mode identique au mode multiPlayers mais pour les parties en ligne. Le joueur créer ses personnages dans un
mode histoire et celui-ci peut les jouer en même temps sur une partie en ligne. À voir également si le client supporte
ce gameplay.

11 °) Les actions de fin de combat et les triggers (endFight_Actions, triggers)
Comme son nom l’indique, les actions de fin de combat s’appliquent en fin de combat. J’ai besoin de quelque chose de super modulable pour ça. Utilisant la liste des GameActions, il faut qu’il soit personnalisable de sorte qu’il puisse activer plusieurs
actions les unes après les autres en suivant les bons arguments et les bonnes conditions. Ce que je préconise est un parsage des
données avec un fichier par listes de GameActions au même titre que les triggers. Les triggers n’appelleront plus une action
avec une condition et un argument mais directement une GameAction, un fichier listant toutes les actions à executer à la suite.
Celà ne limite ainsi pas mes mouvements au niveau du code et ne les limite pas non plus pour les joueurs.

12 °) Les hooks
Les hooks sont favorable au bon fonctionnement et au bon cheminement de l’émulateur. Ils dispatchent les propriétés
lorsqu’une action se termine. Ce système optimise le système d’events de flash et permet aux développeurs de plugins d’avoir
accès aux évenements du jeu. Ainsi, ils peuvent écouter ces hooks et executer les bonnes fonctions au bon moment. Celà est très
favorable au développement de plugins évenementiels.

Le moteur de jeu local

3

Le launcher
Taille préconisée : 1280 x 800, pas plus.
Pas de redimensionnement automatique.
Optimisation du code pour accueillir des animations et des transferts de données.
Connexion socket en multithreading.
Pas de système d’hôte. Connexion à un serveur stable distant (dans l’idéal).
Graphisme : Nanow, développement : Ccx

Cheminement des fonctionnalités du launcher :
Connexion Internet ?

NON

Bypass du login

ADMIN

OUI

Login + Inscription
disponible

Vérification du rang

CONTROLER

VIP_PLAYER

FREE_PLAYER

Créer un personnage local
Créer un personnage distant
Sélectionner un / des personnage(s) local(ux)
Sélectionner un / des personnage(s) distant(s)
Modifier les données
des personnages locaux
Modifier les données
des personnages distants
Supprimer des personnage locaux
Supprimer des personnages distants
(d’autres comptes)
Créer des données locales
Télécharger des données distantes
Publier des données
Envoyer des données
Créer des parties en coopération
Rejoindre des parties en coopération

Certains modes seulement

Observer des parties en coopération

4

Le launcher

Serveur Distant
Le serveur distant sert à accueillir un système multijoueur pour créer des parties en coopération privées. Il est développé par
Alleos en Java 8.
Le serveur sert de plateforme de communication entre tous les moteurs de jeu local. Celà provoque un ralentissement du
jeu certes mais le moteur de jeu local simplifie grandement les communications entre le serveur distant et le client. Les packets
sont ainsi simplifiés, réordonnés et sans cryptages pour un envoie le plus rapide possible et une optimisation complète.

REALM
Login
version+#+ndc+#+pass
Version incorrect
‘‘lo0’’

Verif login

Correct
‘‘lo1’’

envoie rank
‘‘ra’’+rank

Incorrect
‘‘lo2’’

liste d’amis
‘‘fd’’+idFriend+ |+nameFriend

Banni
‘‘lo3’’

Redirection menu principal

Inaccessible

Mode campagne
Mode en ligne
(Rejoindre une partie)

Rafraîchir la liste
‘‘Sr’’

Envoie de la liste des parties disponibles
‘‘Se’’+idServer+|+nomServer+|+type+|+difficulte+|+etatServer (0 = en attente de joueurs, 1 = en
cours de jeu, 2 = en phase final de jeu)+|+NombreJoueurs+|+NombreJoueurs Max+|+(répéter si
plusieurs...)

Mode en ligne
(Créer une partie)
Envoie d’un ID
de serveur disponible
‘‘Si’’+ID
Envoie des détails du serveur
‘‘Sc’’+idServer+|+nomServer+|+TypeServer+|+difficulte+|+NombreJoueursMax

Sélection serveur
‘‘Se’’+idServer
Réussi
‘‘Sa0’’

Intégration du nouveau Player
au CoopServer

Impossible
‘‘Sa1’’
Serveur plein
‘‘Sa2’’

Serveur Distant

PASSAGE AU GAMESERVER
5

Les GameServers
Les GameServers sont classés par types de parties. Chaque parties ayant ses propres règles et ses propres spécificités, le
realm doit être capable de démarrer n’importe quel GameServer sans distinction du mode.
Les GameServers servent principalement de passerelle de communication entre les joueurs de la partie. Les packets que le
moteur de jeu hôte envoie sont renvoyé à tous les joueurs. Ainsi, un GameServer n’a pas à charger les données du jeu.
Il faut prévoir un système en cas de perte de connexion entre l’hôte et le serveur afin de ne pas stoper la partie complète.
Un changement d’hôte automatique par exemple à l’aide d’un packet disponible manuellement via l’interface du joueur si il
veut changer l’hôte de la partie.
Tout celà implique une stabilité hors norme que sa soit du côté serveur ou du côté client. Un lag de 20 secondes n’est pas
tolérable lors d’un fonctionnement normal (hors lags du serveur) de la partie.

Lancement des joueurs dans
le jeu

BASE GAME

Envoie des détails du serveur aux joueurs
‘‘Sd’’+lien du fichier de config xml contenant tous les détails du serveur+key unique
fournit par l’hôte à la création du serveur
Chargement par le moteur de jeu local des données du serveur
(voir chapitre sur les données du serveur)
Interprétation des données.
Connexion automatique au jeu.

6

Les GameServers

Les données des serveurs
Afin que les données soient interprétées rapidement par les moteurs de jeu locaux, le GameServer doit envoyer le lien à
tous les joueurs de la partie. Ce lien redirige vers un fichier xml dans lequel se trouve tous les liens utile au fonctionnement du
moteur à savoir le lien du fichier rcg (à contrario de lcg, ‘‘Local GameConfig’’, ‘‘Remote GameConfig’’) dans lequel se trouve
toutes les informations de tous les players de la partie et tous les fichiers relatifs aux données du jeu (maps, monstres, mapsActions, etc.)
Dans le fichier rcg, on retrouve les données comme tel :
• Tout ce qu’il faut pour créer une classe Player pour l’hôte;
• Une mapID pour le départ du jeu;
• Éventuellement l’IP et le port du GameServer.
Les fichiers de données sont communes aux fichiers locaux.

Les données des serveurs

7

Les types de parties en ligne
Cette liste sera mise à jour au fur et à mesure que les idées viennent et se développent.

Le mode PvP :
Ce mode est fortement répondu, il sera sous forme d’arène avec des maps spéciales. Plusieurs types de PvP peuvent être
mis en place. Le mode PvP pur et dur dans lequel on se tape sur la gueule sans aucun remords dans une arène en 1 contre 1 ou
plus. Le mode PvP pourra également être configuré avec l’ajout de monstres conférant à l’équipe tuant le monstre ou infligeant
le plus de dégâts (par exemple) des bonus.
D’autres modes PvP comme des tournois communautaires pourront être organisés si le nombre de joueurs est suffisant.
Tout ce qui concernent les évènements communautaires confrontant au moins un joueur à un autre ou plusieurs et ce, pas seulement en combat représente en lui même un mode PvP. On peut ainsi classer des compétitions comme le farming, des courses
d’une map à l’autre ou encore mettre en compétitions 2 joueurs sur leur capacité à résoudre des quêtes.
En bref, tout est possible de ce côté.

Le mode PvM :
Ce pourquoi je suis là, le PvM. Ce mode doit être minutieusement pensé afin de ne pas être barbant. Là, encore une fois
tout est réalisable. On peut donner aux joueurs la possibilité de combattre les monstres qu’ils veulent, on peut également leur
donner la possibilité de monter des groupes pour l’ascension de donjons plus ou moins complexes. Avec une IA suffisament
travaillée et réfléchie, ce mode peut devenir un moyen de réunir la communauté dans un seul et unique but.
Des combats massifs comme des guerres PvM peuvent même être accomplies, des tournois PvM selon la rapidité des
joueurs également. Mettre en compétition 2 ou plusieurs joueurs pour effectuer des combats sans erreurs, chaque actions leurs
conférant des points.
Ce mode est quelque chose qui est parmi des fonctionnalités du jeu l’une des choses qui sont les plus à travailler, surtout du
côté de l’IA.

Le mode Rôle-Play :
Dans ce mode, le PvP et le PvM ont leur place. Le joueur qui créer la partie est ainsi le maître du jeu et c’est lui qui créer les
règles en plus des règles communes de tous les autres modes. Le joueur est ainsi libre de choisir le monde dans lequel sa partie
sera jouée, il décidera du but du jeu (combattre un boss ultime par exemple). Certains mondes seront déjà pré-créer mais les
joueurs pourront fournir leurs propres packs de données.

Le mode Commun :
Ce mode particulier ne proposant ni PvP, ni PvM sert aux joueurs à se rencontrer. Ils peuvent également modifier leurs
personnages (sprites, statistiques, etc...). Appartenir à une guilde qui sera affichée dans les différents modes. Ils ont accès aux
vendeurs d’équipements, de sorts et de bonus afin de rendre leurs personnages uniques et adaptés à leur gameplay.

Les types de parties Campagne
Uniquement 3 modes seront proposés en mode Campagne :
L’histoire unique, il s’agit de l’histoire de base du jeu, notre histoire.
L’histoire de x, il s’agit de jouer en plein anonymat à l’histoire qu’un autre joueur à créer.
Fonder une histoire. Ce mode fournit tous les outils nécessaires à la création du monde de leur rêve.

8

Les types de parties en ligne


Aperçu du document details launcher.pdf - page 1/8
 
details launcher.pdf - page 3/8
details launcher.pdf - page 4/8
details launcher.pdf - page 5/8
details launcher.pdf - page 6/8
 




Télécharger le fichier (PDF)


details launcher.pdf (PDF, 181 Ko)

Télécharger
Formats alternatifs: ZIP



Documents similaires


details launcher
le manuel du soldat americain
le manuel du soldat americain
emote gw2 1
anr traduction lexique en fr
anr traduction lexique en fr

Sur le même sujet..