Topic: [FR] Journal de Développement #2  (Read 1687 times)

0 Members and 1 Guest are viewing this topic.

[FR] Journal de Développement #2
« on: July 22, 2014, 01:41:09 PM »

    Offline Sendoku

  • 5 Dragonballs
  • Honor: 9 / 2
  • Posts: 565
    • View Profile
  • A new era is coming.
  • I am a: Swordsmaster
PS : je m'excuse pour les possible fautes d'orthographe mais si je devais tout corrigé en plus de traduire ça me prendrai un temps fou, j'aimerais d'ailleurs m'excuser si je traduis mal quelque chose, il y a beaucoup de termes technique et ce n'est vraiment pas simple


Salutations,

Voici le très demandé Journal de Développement #2.

Ce Journal de Développement sera plutôt technique puisque nous avons reçu pas mal de questions à propos de notre serveur et d'autre questions technique sur des sujets parlant de développement ainsi que sur le AMA.
En espérant que ce ne sera pas trop ennuyant pour qui que ce soit.

À un grand niveau, le serveur possède deux partie principales: réseau et simulation (bien sûr, il y en a d'autre comme la database, mais ignorons ça pour l'instant).

Pour le côté du réseau, il y a la pool de threads(j'ai beau avoir cherché il n'y a pas de traduction à ces termes d'informatique) du réseau qui entretien toute les connexions et entrées des joueurs, la simulation est le noyau du game play.
C'est là où est le monde, et tout les objets du jeu (joueurs, npcs, etc) sont, aussi bien que la game logic.

La simulation se compose de plusieurs sous-systèmes, dans notre liste initiale, nous avons noté plus de 40 sous-systèmes.
Des plus simples comme les inventaires, les mail, aux plus complexe comme la détection de collision.
Et je suis presque sûr qu'il y en aura de plus en plus.

Tout ces sous-systèmes communiquent entre eux via des events.
On peut s'inscrire à chaque type d'events.
Dans notre dernière vidéo Sneak Peek où vous voyez un simple combat, c'était en gros un test d'une continuité d'event combat parmi un nombre de sous-système. ( je comprends rien x) )

Voici une étape rapide sur comment différent sous-systèmes ont travaillé ensemble dans cet exemple: Quand le joueur attaque le monstre, ça envoie un event auquel le combat manager s'est inscrit.

Le combat manager commence le combat logic entre les deux objets.
Chaque round d'attaque ça enverra des events qui seront renvoyés au joueur comme les mise à jours des dégâts et LP/Points de vie.
Quand le monstre meurt, un event est encore envoyé pour indiqué que le joueur a tué le monstre.
Le player manager s'étant inscrit à cet event peut récompensé le joueur avec des points d’expérience, tandis que le drop manager s'étant inscrit au même event pourra récompensé le joueur d'un drop de zenys, ou 7 dragon balls ;)

Similairement, le quest manager peut s'inscrire à cet event pour mettre à jour la progression de la quête du joueur (si tué ce monstre fait partie d'une quête).

Avoir des sous-systèmes ne rend pas seulement les choses plus maniable, ça nous donne aussi la possibilité de les faire marcher en parallèle où c'est possible.
Ça nous permet aussi de déplacé un sous-système à un différent procédé ou un différent hébergeur, qui rend le serveur plus extensible.
D'ailleurs, la détection de collision ou le manager de proximité pourrait être surchargé lorsque nous avons de plus en plus de joueurs.

Je ne dis pas que ce design est parfait (il ne l'est pas), mais c'est avec ça que l'on a travaillé jusqu'à maintenant.
Je suis sûr que notre design sera cassé, changé, et improuvé durant nos progrès.

Il y a aussi des choses que nous avons implanté simplement pour les bénéfices du développement.
Dès simple choses comme l'auto-login et auto-sélection de personnage, aux choses comme un serveur spécial où l'on peut terminé le serveur de jeu, faire des changements de code, recompilé et redémarré, tout ça pendant que le client reste connecté et sans devoir le redémarré.

Bien sûr, certaine sauvegardes du monde ne sont pas préservés après un redémarrage (pas pour l'instant de toute façon puisque ça ne sert à rien), mais ça aide beaucoup lorsque l'on test certains endroits du serveur.
Cette courte vidéo montre tout ça :



Les deux joueurs pouvaient voir leur mouvements, jusqu'à ce que le serveur du jeu soit arrêté.
Les deux clients sont resté ouvert sans savoir ce qu'il s'est passé.
Quand les serveur ont été rallumés, tout est retourné à la normale.
Vous pouvez aussi voir que les positions des NPC ont été reset quand le serveur a été rallumé, puisque leur sauvegardes n'ont pas été préservés.

Je suis aussi dans le progrès d'écrire quelque test clients pour que nous puissions faire des profils en avance ainsi que des test de résistances, et je posterais une vidéo de tout ça lorsque j'aurais le temps.

Mis à part écrire le code de serveur actuel, nous devons aussi faire beaucoup de rétro-ingénierie pour voir comment le client marche.

Beaucoup de monde pensent que puisque nous avons le code source de l'ancien client et les libraries, ça devrait être simple.
Et bien, l'ancienne code source nous aide bien sûr, Mais le fait est qu'il y a beaucoup de protocoles, structures de paquet, data tables, etc ont été changés.
Certain d'entre elles nous ont pris plus de temps pour les faire marché.

Sans surprise, nous avons aussi trouvés que même le client TW a une différente construction que le client HK en terme de protocoles et de structures de paquet, et ils sont incompatible entre eux.
Pour l'instant, le client va juste crash si vous envoyés ne serais-ce qu'un byte de data incorrecte, et il y a aussi aucun moyen simple de le débug sans la source, en assumant que vous ne comptés pas l'assembleur de code comme source ;) Et puisque nous avons tout écrits de A à Z et n'avons pas recours en un DBO/NTL code existant, cela rend le process plutôt long.

Pour résumé, notre but est certainement gros et ambitieux, mais nous sommes content avec ce qu'on a fait jusqu'à maintenant.
Et encore une fois, merci à vous pour votre patience.

J'aimerais aussi dire quelque mots à propos des autre projets de DBO existants.
Je pense personnellement qu'ils sont tous super, et en tant que développeur, il n'y a rien d'autre d'excitant que de voir d'autre personnes s’intéresser à la programmation.
Différents projets auront différentes directions et différentes façon de faire les choses, mais au final nous partageons tous le même but : Ramenez DBO à la vie.
Je souhaite sincèrement que l'on peut tous se respecter les uns les autres, respectez le travail de chacun, et respectes les différences.

Bien, je pense que c'est tout pour l'instant.
J'espère que je pourrais faire d'autre posts comme ça plus souvent.

Merci à tous !
Pigeon.
« Last Edit: September 14, 2014, 09:14:21 PM by LinkvsSangoku »


[FR] Journal de Développement #2
« Reply #1 on: July 22, 2014, 07:58:09 PM »
    • View Profile
  • Low-Class
En tout cas on peux voir qu'ils travaillent beaucoup et qu'ils donnent leurs maximum , sinon merci à toi Sendoku pour cette superbe traduction , continue comme ça !  ;D

[FR] Journal de Développement #2
« Reply #2 on: July 31, 2014, 12:51:43 PM »

    Offline Noki

  • 2 Dragonballs
  • Honor: 5 / 1
  • Posts: 75
    • View Profile
  • I am a: Martial Artist
Bravo pour la traduction! Tu a dû travailler très fort ! C'est très bien traduit !
« Last Edit: July 31, 2014, 12:55:15 PM by Noki »

[FR] Journal de Développement #2
« Reply #3 on: July 31, 2014, 06:22:53 PM »

    Offline Sendoku

  • 5 Dragonballs
  • Honor: 9 / 2
  • Posts: 565
    • View Profile
  • A new era is coming.
  • I am a: Swordsmaster
Je penses être largement capable de traduire, ce qui est long c'est plutôt de trouver une traduction cohérente en fait.


[FR] Journal de Développement #2
« Reply #4 on: August 18, 2014, 05:39:19 AM »

    Offline gothen01

  • 1 Dragonball
  • Honor: 0 / 0
  • Posts: 30
    • View Profile
  • JE PROTEGERAI MON PTIT FRERE JUSQU'AU BOUT
*MDR sendo!!* t'es aussi charismatique que doflamingo.

 


SimplePortal 2.3.6 © 2008-2014, SimplePortal