Le but de cette page est de lister les grosses tâches informatiques concernant le projet khaganat. Ces tâches sont regrouper dans trois thème en rapport avec le projet MMO

• Installer un serveur de jeu.
• Les outils pour éditer les data du jeu.
• Développements spécifiques au MMO khanat.

Et un thème plus global concernant le projet khaganat

• Outil autours du projet

Note importante : Les choix informatiques découlent de la philosophie de notre projet (cf. la charte). RyzomCore sur lequel nous nous appuyons est multi-plateforme. Cepedant notre but est d'avoir une chaîne de production entièrement opérationnelle sur une plateforme libre. La référence pour nous est donc : une machine faisant tourner un linux libre, à savoir la distribution Debian 64bits dans sa version stable, donc squeeze en ce moment.

Note : créer et faire évoluer le monde du jeu ne fait partie de la ToDo Informatique car il s'agit ici d'utiliser les outils pour modifier les data du jeu et non pas les développer.

Pour ne pas se perdre dans la liste de ToDo qui suit, voici classé en fonction de leur prioité les plus importants à notre étape actuelle :

1. ds2dw ( les datasheets )
2. un serveur de jeu V2 opérationnel
3. collada2nel / nel2collada

Le premier serveur de jeu (un Linux sous Debian) a été installé en compilant directement sur le serveur les binaires nécessaires. Pour le second serveur, l'idée est plutôt d'installer proprement les binaires via des paquets Debian. Cela évite de polluer le serveur avec un environnement de développement mais cela permet également de faire évoluer en douceur les binaires via le mécanisme de MAJ de Debian. Les étapes nécessaires pour réaliser cet objectif sont :

1. Création des paquets Debian pour Ryzomzore
2. Mise en place d'un dépôt Debian pour ces paquets
3. Installation et configuration du serveur

L'idée derrière la création de ces paquets est triple :

• Disposer d'un dépôt debian pour installer et mettre à jour proprement le serveur de jeu
• Fournir les binaires du serveur aux personnes intéressées notamment pour tester le évolutions du mode via les outils de modifications des data du jeu.
• Disposer d'un dépôt pour les binaires du client de jeu

Le choix de la distribution de référence pour ce dépôt est la distribution Linux Debian Stable (squeeze en ce moment), ce qui rend le dépôt compatible avec la plupart des distributions dérivées qui (Ubuntu, Linux mint….) forment une base importante des installations linux.

Pour le moment les développements se concentrent sur le serveur et les outils de manipulation des Data. De fait, notre client de jeu reste le même que le client officiel Ryzom, Les joueurs sous systèmes propriétaires (Windows/Mac OS X) ne sont pas lésés.

Création des paquets debian pour les binaires de RyzomCore(Liria)
A faire : - libsquish [1j] (terminé) - libwww [1j] (terminé) - client ryzomcore + libnel [2j] - outils ryzomcore +nel [1j] - serveur ryzomcore [3j]
(25% of 8j) Priority: Normal

Les deux dépendances libsquish et libwww n'existent plus dans les dépôts officiels debian. Il est donc nécessaire de les proposer dans le dépôt. Le paquet du serveur de jeu est complexe à mettre en place, car aucune procédure d'installation officielle n'existe et il implique de configurer une installation apache et mysql :

Création du paquet debian du serveur RyzomCore(Liria)
A faire : - Ajout à cmake du code pour l'installation du serveur - tester les scripts de configuration d'apache et mysql - découper le paquet en plusieurs sous-paquets : . (a) les binaires des services . (b) les data du jeu ( datasheets ) . (c) la base mysql . (c) les applications web (apache)
(0% of 3j) Priority: Normal

Il s'agit de configurer un dépôt Debian pour proposer les binaires du client, des outils et du serveur de jeu.

Dépôt Debian(Liria, Daeldir)
A faire : - Documentation préalable et choix de la solution (1j) - Test de la solution sur sa machine (1/2j) - Mise en oeuvre du dépôt sur le serveur ninm.net (1/2j)
(25% of 2j) Priority: Normal

Une contrainte forte est que le serveur “ninm.net” n'est pas basé sur la distribution Debian. Il faut donc des outils fonctionnant sans les dépendances propres à Debian. Quelques liens important concernant ce sous projet :

• https://wiki.debian.org/HowToSetupADebianRepository
• http://blog.jonliv.es/2011/04/26/creating-your-own-signed-apt-repository-and-debian-packages/
• http://people.debian.org/~calvin/unofficial/
• http://code.google.com/p/debmarshal/
• http://mentors.debian.net/
• http://mirrorer.alioth.debian.org/
• http://joseph.ruscio.org/blog/2010/08/19/setting-up-an-apt-repository/
• http://www.jejik.com/articles/2006/09/setting_up_and_managing_an_apt_repository_with_reprepro/

L'essentiel du travail est effectué en amont dans la création des paquets RyzomCore (installation et configuration). Il s'agit donc ici à proprement parler plus de configurer un serveur au sens informatique : installation d'une distribution linux, configuration des services, etc. Cependant notre cas de figure est particulier car nous avons opté pour une solution basée sur une machine virtuelle

Installation du serveur de jeu(Liria, Daeldir)
A faire : - Création d'une machine virtuelle avec une distribution Debian squeeze 64bits (2h) - Installation des binaires du serveur de jeu (2h) - Test de la VM en local (1h) - Upload de la VM sur le serveur ninm.net et installation (1h) - Configuration réseau sur nim.net pour rediriger les ports vers la VM
(50% of 1j) Priority: Normal

Note : nous disposons déjà de la compétence nécessaire pour cette étape du fait de notre expérience sur le premier serveur ( configuration réseau et redirection des ports, installation de virtualbox, etc…)

L'élément le plus important dans le serveur de jeu est sans conteste les “Data”. Par data, on fait référence à l'ensemble des fichiers de données spécifiant le monde : les quêtes, l'arbre des compétences, la définition des régions, les textes des PNJ, les modèles 3d, etc…

Dans le cadre de RyzomCore ces datas sont regroupées essentiellements dans 2 catégories :

• Les assets graphiques ( téléchargeables ici : http://media.ryzom.com/ ): ce sont les fichiers des modèles 3D des avatar, objets, éléments de décors, animation, ainsi que les images de textures associées.
• Les datasheets ( situés dans code/ryzom/common/data_common et code/ryzom/common/data_leveldesign): ce sont une multitude de fichiers textes (xml) spécifiant chaque éléments du monde (texte des pnj, positionnement d'une tour sur la carte, comportement des animaux, recettes de craft, description des compétences,etc…).

Ces data ne sont pas utilisées telles quelles, mais doivent être transformées dans un format exploitable directement par le client et le serveur de jeu. Ce travail est effectué par la pipeline “build_gamedata” (code/nel/tools/build_gamedata).

• la pipeline graphique figurée par l'étape “01_export.py” de “build_datagame”permet de générer les fichiers NEL exploitables directement par le client et le serveur de jeu. Il s'agit de fichiers au format “.ishape”, “.bank”, “.land”, “.anim”, …. (cf. fr:serveur:gamedata:outils).
• les outils “make_sheet_id” et “sheets_packers” qui compilent les datasheets pour générer une version directement exploitable par le serveur de jeu et le client (fichiers au format “.sheet_packed”) sont exécutés à l'étape “02_build.py” de la pipeline “build_gamedata”.

Problème : les outils pour créer et éditer ces fichiers sont essentiellement des programmes windows :

• 3dsMax pour les modèles 3D coté assets graphiques. la pipeline graphique s'appuie sur 3dsMax pour créer les fichiers graphiques NEL
• George et WorldEditor pour la manipulation/création des datasheets

Avec le passage en open source, la communauté a développé deux outils OVQT et GeorgeQT qui reprennent les fonctionnalités importantes de George et WorldEditor. Cependant même s'ils sont écrit avec une optique muti-plateforme, ils sont essentiellement testé sous Windows vu que la pipeline ne fonctionne que sur cet environnement. Le but est donc de rendre ces outils fonctionnels sous linux et trouver une solution de remplacement à 3dsMax.

Tous les outils de manipulation des data du jeu s'attendent à trouver les datas dans des endroits spécifiques. La pipeline graphique fonctionnant exclusivement sous Windows, ces datas sont réparties sur plusieurs lecteurs logique ( d:, l:, r:, etc… ). Il faut donc repenser l'organisation de ces datas pour linux.

Arborescence des data du jeu(Liria)
2j - Définir une arborescence pour les datas du jeu [en cours de réflexion] - Mettre à jour l'ensemble des fichiers de configuration des outils pour suivre cette nomenclature - Valider le bon fonctionnement de ces outils
(20% of Durée inconnue) Priority: Normal

Note : certains nom de dossiers sont en majuscules, d'autres en minuscules. Il faudrait sans doute revoir cela pour éviter les problèmes sous linux, car la case des lettres compte dans les noms de fichiers à l'inverse du monde Windows.

Toujours dans l'optique d'avoir l'ensemble des outils sous linux, il s'agit ici de rendre accessible à l'utilisateur non informaticien ObjectVewer QT et George QT. Le but est donc de fournir des versions compilées de ces outils et prêtes à l'emploi via un dépôt Debian.

OVQT et GeorgeQT sous linux(Liria)
A faire : - Compiler OVQT et GeogeQT sous linux [1h] - Modifier les fichiers de config pour adapter les chemins à la nomenclature linux [1/2j] - Créer les paquets Debian pour ces deux outils [1/2j]
(50% of 1j) Priority: Normal

Note : Kervala travaille aussi à des paquets ubuntu pour les outils de ryzom. voir avec lui ce qui peut être mis en commun.

Dans la mesure où il n'existe pas d'équivalent de certains outils sous linux, il s'agit de voir comment palier temporairement à ce manque via le recours à Wine. Pour le moment cela concerne WorldEditor, George.

Wine permet de faire tourner une exécutable windows sous linux avec une machine sous architecture intel. La configuration de cette solution n'est pas trivial. Il s'agit donc de proposer une solution clef en main pour l'utilisateur non informaticien.

Les outils Ryzom sous Wine(Liria)
A faire : - Installation de Wine. - Configuration des chemins pour l'accès aux data dans wine [lecteurs R:, L: etc...]. - Configuration des DLL pour pour les applications windows. - Préparation d'archives prêtes à l'emploi avec les binaires Windows et les fichiers de configuration associés.
(0% of Durée inconnue) Priority: Normal

Note : je n'ai pour le moment pas retenu la solution VirtualBox qui requiert l'installation du système Windows et impose donc de disposer d'une licence.

Note : page de téléchargement des binaires windows et librairies associées des outils ryzom (des binaires compilés par la communauté) : https://ryzomcore.atlassian.net/wiki/display/RC/Downloads+for+Windows

S'il existe des outils dédiés pour la manipulation des datasheets (WorldEditor, George, etc…. ), ces outils ne couvrent pas tous les cas de figure et surtout, ils pré-suposent que l'utilisateur connaît pour chaque datasheet sa syntaxe, la liste des champs et leur signification.

Une bonne partie des “wiki” disponibles sur dev.ryzom.com et www.ryzomcore.org implique de manipuler directement ces datasheets via un éditeur de texte. il nous manquait un outil permettant de visualiser ces datahseets, de naviguer dans leur hiérarchie, de les documenter et éventuellement les éditer de manière coopératives. C'est le but du projet “ds2dw”. Ce script synchronise le dossier datasheet avec une hiérarchie de documents wiki permettant de :

• d'afficher avec une coloration syntaxique chaque datasheet
• documenter dans la page wiki le datasheet
• utiliser les liens hypertextes pour accéder aux datasheets référencés dans la page
• éditer directement le datasheet

L'outil est en cours de développement et est disponible via le dépôt pblic https://bitbucket.org/liria/docuwiki-tools. A terme il servira à alimenter le wiki dswiki/

ds2dw(Daeldir, Liria, Lyne, Zatalyz)
A faire : - Générer les docuwiki à partir des datasheets [terminé] - Ajouter les liens vers les datasheets référencées - Mettre à jour les datasheets après édition d'un docuwiki - Mettre en place le site docuwiki associé [terminé] - Ecrire un article de blog pour présenter l'outil (en cours) - Valider avec Lyne sa version anglaise
(30% of Durée inconnue) Priority: High

Note : brouillon de l'article http://pad.khaganat.ninm.net/p/ds-dw Lien invalide !

Le pipeline “build_gamedata” consiste en une série de scripts qui partant des “assets graphiques” et des “datasheets” vont générer les fichiers client et serveur (.bnp, .packed_sheet, etc), c'est-à-dire les fichiers de données nécessaire au fonctionnement du jeu. Ce processus est découpés en 4 grandes étapes

1. Intialisation (0_setup.py): Ce script permet de configurer le pipeline, essentillement les chemins d'accès aux data et les outils.
2. Export (1_export.py): La tâche principale de cette portion du processus et de transformer les modèles 3D de 3DS Max en fichiers exploitables par NEL : .shape, .zone, .anim, .skel, .veget, etc. il prépare aussi certaines données pour l'étape suivante.
3. Construction (2_build.py): traite toutes les données nécessaires au fonctionnement du jeu : calculer l'illumination du terrain, générer le sheet_id, construire les packed sheets, compresser les .tga en .dds, etc…
4. Installation (3_install.py): réunit tous les fichiers (des étapes précédentes) requis pour le fonctionnment du client et du serveur et les assemble en une structure prête à l'emploi

Problème : A la base, la pipeline est une série de scripts en batch windows. Ces scripts ont été réécrit en langage python par kaetemi et donc devraient fonctionner sous linux. Cependant des tests effectués montre qu'ils n'ont jamais été testé sous linux, (i) des corrections sont à apporter aux scripts. Le pipeline fait appel à 3DS Max pour l'étape “Export”, (ii) il faut trouver une solution autre pour la plate-forme linux (cf. point ci-après nel2collada & collada2nel). Enfin un certain nombre de petits programmes utilisés par ces scripts ne compilent que sous windows, il faut (iii) corriger leur source et les porter sous linux.

Adapter les outils et le script build_datagame à linux(Liria)
A faire : - Corriger les scripts python de build_gamedata pour qu'ils fonctionnent sous linux - Lister les programmes utilisés par les scripts et non portés sous linux (autre que 3ds max) - porter ig_elevaton sous linux [ terminé ] - ... (les autres programmes à porter ) ....
(30% of Durée inconnue) Priority: Normal

Note :

• Dépôt bitbucket du portage de ig_elevation sous linux.
• Cf. la page de suivi du ce sous-projet

Un des principaux frein à l'utilisation de RyzomCore est sa dépendance à “3DS Max”. Ce programme est un outil de modélisation 3D propriétaire et fonctionnant sous Windows. Tous les modèles 3D sont actuellement au format 3DS Max, et ce logiciel est requit pour la conversion de ces modèles vers des formats exploitables par NEL.

La première approche à été d'envisager de basculer vers Blender, et de réécrire le plugin d'export de 3D Max pour en avoir un équivalent sous blender (cf. fr:todo:dev:pluginblender). Cette solution a été abandonnée pour une approche plus universelle et plus simple à mettre en pratique : un convertiseur Collada ⇔ Nel (cf. fr:todo:dev:export_import_nel). Cette approche a le mérite de laisser à l'artiste le choix de son outil de modélisation graphique et simplifie le programme d'export qui n'a plus à traiter des mécanismes internes à une application comme l'impose le passage par un plugin.

Titre(Liria)
A faire : - développer nel2info (40%) - info2nel - nel2collada - collade2nel
(15% of 30j) Priority: Normal

Dépôt bitucket des sources du projet : https://bitbucket.org/liria/khanat/commits/branch/nel2info

Un aspect important en Jeu est constitué par le “WebIG”. Il s'agit d'une fenêtre de navigation Web qui permet d'accéder aux applications web déidées du jeu comme le forum, la messagerie, l'encyclopédie, etc…

Cependant ce “navigateur web” est basé sur libwwww, la librairie de référence du consortum W3C pour l'implémentation d'un navigateur. Malheureusement cette librairie n'a plus évolué depuis 2002 et reste encore sur l'ancien standard HTML 4. De plus javascripts n'est pas pris en compte, et les pages affichées sont donc statique.

Il devient urgent d'évoluer vers une solution alternative moderne qui implante les derniers standards des normes web (xhtml, css3, etc…) et surtout permet l'intégration de javascripts voir des plugins.

les alternatives possibles sont aujourd'hui gecko (le moteur de firefox), webkit (le moteur de safari et anciennement chrome) ou blink (le nouveau moteur de chrome). Une première recherche sur le web, laisse envisager qu'il faut compter environ 30 jours pour intégrer le moteur de gecko dans son application et moins pour webkit.

La proposition faite par ryzomcore ici ne me parait pas envisageable. Il s'agit d'embarquer directement le navigateur “Chrome” de google dans le client ryzom. Cette solution si elle reste le plus simple coté informatique va à l'encontre de notre philosophie du libre en relation avec ce qui a trait à la vie privée. Cela revient à dépendre d'une application d'une société privée avec tous les abus qui peuvent en découler sur l'exploitation des données des utilisateurs.

Titre(Liria)
A faire : - Étude des choix possibles (en cours) - Programmation d'une nouvelle fenêtre WebIG avec le moteur sélectionné en gardant l'ancienne fenêtre IG pour validation de la solution. - Suppression de l'ancienne fenêtre IG
(0% of 30j) Priority: Normal

liens important en rapport avec la réflexion sur un successeur de libwww :

• http://www.debian.org/releases/stable/mips/release-notes/ch-information.fr.html#browser-security
• https://code.google.com/p/chromiumembedded/
• http://arstechnica.com/information-technology/2007/07/the-unforking-of-kdes-khtml-and-webkit/
• http://berkelium.org/
• https://developer.mozilla.org/en-US/docs/Gecko/Embedding_Mozilla
• https://developer.mozilla.org/en-US/docs/Gecko/Embedding_Mozilla/Roll_your_own_browser?redirectlocale=en-US&redirectslug=Roll_your_own_browser_-_An_embedding_HowTo
• https://developer.mozilla.org/en-US/docs/Mozilla/Gecko
• http://www.pcinpact.com/news/45759-google-chrome-vie-privee-licence.htm
• http://ubrowser.com/

cf. fr:todo:dev:identification

Titre(Inconnu)
A faire : - tâche 1 - tâche 2 - ...
(0% of Durée inconnue) Priority: Normal

Voir forum/viewtopic.php?f=12&t=256
assigné à lodnexus

Suivi de projet(lodnexus, daeldir)
A faire : - Identifier les outils possibles - Tester les solutions - Organiser une débat pour le choix final - Mettre en place la solution sur ninm.net (daeldir)
(100% of 100%) Priority: Normal