Aujourd’hui, j’ouvre aux curieux un serveur de test sur un hébergement mutualisé. C’est la version de développement, qui peut contenir encore des bugs. Les modes DEBUG et DEPRECATION sont activés, ne vous inquiétez donc pas pour l’encart rouge et blanc en fin de page, particulièrement sur les pages qui n’ont pas subi de modification.

A l’heure actuelle, ce qui est réalisé en plus de ce qui a déjà été annoncé dans une news précédente, ce sont les reprises de templates des pages des bâtiments, des vaisseaux et des défenses. Il manque encore sur ces 3 pages l’ajout de la liste de construction, une couche de CSS et un bout de javascript, mais elles sont fonctionnelles, la page des recherches suivra d’ici peu. Le login a lui été réintégré avec le nouveau moteur d’affichage, mais son HTML est resté globalement le même. La création de compte n’est pas terminée, vous devrez utiliser un compte de test pour pouvoir tester (login : test, mot de passe : test)

Une version alpha3 sera publiée dans peu de temps, elle intègrera les modifications faites depuis la version alpha2 et déjà présentes sur le serveur de test, avec quelques autres ajouts pas encore terminés dont la création de nouveaux comptes et la page des recherches.

Je vous laisse découvrir ce serveur à l’adresse http://testing.xnova-legacies.org. Vous pouvez donner vos remarques ou les bugs que vous auriez trouvé, plus bas dans cette page.

Bons tests

La version alpha1 vient d’être publiée, c’est une version de développement qui implémente la majeure partie des fonctionnalités annoncées, mais qui n’est pas fonctionnelle dans le sens où tous les anciens appels n’ont pas étés modifiés et que le jeu n’est pas utilisable en tant que tel.

Pour les développeurs, c’est l’occasion de découvrir la refonte. Les nouveaux développements sont intégralement orientés objet, la gestion des planètes et des ressources en sont de parfaits exemples.

Le code se trouve sur Github, sur le dépôt dédié au projet.

Un peu d’actu….

Pour donner quelques nouvelles à propos de l’état du développement de XNova:Legacies, je vous donne ci-dessous la liste des tâches avec la mise à jour de leur état de réalisation. J’y ai ajouté la refonte de la gestion de l’affichage des pages qui n’était pas présente. Je l’ai jugé nécessaire pour simplifier l’avancement et permettre de nettoyer le code “sale” à réécrire dans les versions à venir.

• Support des grands nombres [100% réalisés, testé]
• Programmation événementielle [100% réalisés, testé]
• Gestion des planètes [100% réalisés, testé]
• Mise à jour des ressources [100% réalisés, testé]
• Constructions de bâtiments [100% réalisés, en phase de tests]
• Constructions de vaisseaux et défenses [100% réalisés, en phase de tests]
• Marquage des méthodes obsolètes [100% réalisés]
• Accès aux données, passage sous PDO [90% réalisés, en phase de tests]
• Gestion d’utilisateur [100% réalisés, en phase de tests]
• Refonte de la gestion des templates [100% réalisés, testé]
• Compatibilité ascendante [75% réalisés]
• Documentation de code [20% réalisés]
• Nettoyage du code obsolète [40% réalisés]
• Reprise des templates [20% réalisés]
  • Récap des ressources en haut de page [OK]
  • Overview [OK]
  • Bâtiments
  • Chantier spatial
  • Défenses
  • Laboratoire
  • Flottes
  • Login
• Reprise de l’installeur [0% réalisés]

Le nouveau moteur de templates

Cette nouvelle méthode pour générer des pages s’appuie très fortement sur PHP lui-même. Le code qui sera présent dans les nouveaux templates pourra contenir du PHP et tirer parti de ses avantages, comme l’utilisation de conditions et de boucles, ou bien de permettre de mieux protéger vos pages en échappant les caractères spéciaux du html contenu dans les données affichées, ce qui en majeure partie n’était pas le cas. Plus besoin de développements particuliers pour modifier une page, tout se fait dans le template, vos fichiers sources resteront tels que vous les aurez téléchargés et seront donc faciles à migrer d’une version à l’autre.

Autre particularité, ce nouveau moteur de génération de pages utilisera un fichier de définition de layout, qui permettra à ceux qui souhaitent ajouter une nouvelle fonctionnalité au jeu de ne pas modifier le code source standard. Cette fonctionnalité est inspirée des layouts de Magento, elle peut être comparée aux Partial Views du Zend Framework, c’est une fonctionnalité qui a été reprise de One.Platform et simplifiée.

Mais encore…

Lors de la sortie de la première version beta, un univers de jeu sera mis en place. Il permettra de tester en conditions réelles XNova:Legacies et de corriger les éventuels bugs avant de finir de stabiliser le code pour obtenir une version plus robuste.

Plus tard, d’autres refontes seront programmées. Un nouveau design, les alliances et la galaxie pourraient en être les axes principaux.

Notez bien que cette version ne sera pas portée par One.Platform ni Zend Framework, c’est une version de transition qui rendra l’évolution et la modification de XNova plus simple.

Ajout d’évènements

Ceux qui connaissent la programmation événementielle du Javascript, pourront découvrir la programmation évènementielle sous XNova:Legacies. Ce mode de programmation permet de lancer des routines suite au lancement d’un évènement, par exemple lors de la nécessité de mettre à jour une planète. Les mises à jour des ressources, bâtiments, recherches, constructions de flottes et défenses ainsi que les retours de flottes seront automatiquement lancés quand il y en a besoin. Si vous désirez créer un module qui nécessite une mise à jour supplémentaire, plus besoin de chercher où cette mise à jour est appelée, ajoutez un observateur d’évènement et le tour est joué. Idem lorsque vous avez besoin de mettre à jour la planète (avant un espionnage ou le calcul d’une attaque par exemple), lancez l’évènement planet.update, plus besoin de savoir en détails tout ce qu’il faut appeler, les observateurs s’en chargeront.

Passage de l’accès à la base de données sur PDO

L’extension MySQL n’est plus activée par défaut par PHP depuis la sortie de PHP 5 en 2004 et a de grands risques de ne plus être supportée dans une version future (PHP 5.4+ ou PHP 6). Il fallait donc choisir entre mysqli et PDO, l’interface du second étant plus proche du composant Zend_Db du Zend Framework, il était logique de le choisir.

Cette migration impliquera une modification de l’installeur qui n’est pour le moment plus fonctionnel. Ce problème sera réglé en dernier, juste avant la publication alpha de la version.

Modification de l’architecture de la queue de construction du chanter spatial

Les problèmes de queue de construction avaient étés résolus avec la version 2009.4, pour permettre de factoriser le codes source, la gestion des queues de construction a été rendue plus générique et a été intégrée à la construction de bâtiments.

Refonte de la queue de construction des bâtiments

Il y avait divers soucis lors de l’ajout ou le retrait de bâtiments à la liste de construction, cette refonte capitalise les développements faits pour le chantier spatial et permettent de résoudre les bugs existants, simplement.

Le calcul des ressources a été repensé

Exit l’appel à la fonction eval() qui posait des risques de sécurité, et qui n’apportait pas de grand bénéfice. Désormais chaque bâtiment ou vaisseau producteur disposera d’une classe PHP dans laquelle sa production horaire est calculée en fonction, selon les cas, des données de l’utilisateur ou de la planète où il se trouve. Cette modification, avec la programmation évènementielle, permet également de résoudre les problèmes de calculs inexacts, sur certaines configurations, les ressources augmentaient bien plus que ce qu’elles auraient dû.

Avantage supplémentaire : il sera plus simple d’ajouter de nouvelles ressources et de nouveaux bâtiments producteurs. Les ressources étaient jusque là calculées au cas par cas, dans plusieurs fichiers alors qu’une configuration des ressources était présente. Cette nouvelle méthode de calcul ne présuppose plus qu’il n’existe que 4 ressources différentes qu’il faut calculer l’une à la suite de l’autre selon un algorithme figé. La liste des ressources définies dans la configuration du moteur de jeu sera désormais prise en compte et servira de base aux calculs.

Ce point était un des axes les plus importants de cette version. Comme il a été noté, aucun moteur de jeu de type clone ogame ne faisait les calculs de ressources convenablement, que ca soit les versions de XG Project, XNova, Ugamela ou un de leurs dérivés. Ce point sera désormais réglé.

Le support des grands nombres et très grands nombres

Jusqu’à présent, il existait des limitations dues aux architectures des serveurs (32 ou 64 bit), qui ne permettaient pas de dépasser certaines valeurs sans risquer d’avoir des pertes de précision à cause des arrondis sur les nombres à virgule flottante. Les parties du code modifiées peuvent désormais supporter des nombres pouvant atteindre jusqu’à 65 chiffres. En standard, je laisserai une limitation à 20 chiffres, et laisserai aux intéressés la possibilité de pousser la limitation plus loin en modifiant le schéma des tables de la base de données.

Il est possible de pousser les limitations encore plus loin, mais l’intérêt est limité et les performances s’en ressentiraient. Ceux qui désireront le faire en auront la possibilité assez simplement, à eux de voir si des chiffre si grands sont vraiment nécessaires.

Ce support est conditionné par la présence de l’extension BC Math. Si PHP n’en dispose pas, les calculs utiliseront à nouveau les méthodes de calcul natives et seront donc limitées aux architectures des serveurs. Aucun support étendu n’est envisagé pour ceux qui ne disposeraient pas de cette extension, les performances seraient très limitées et gênantes à l’usage.

Refonte de la gestion d’utilisateur

Dans le prolongement de la modification de la gestion des ressources et des constructions, la gestion des utilisateurs a été modifiée pour passer sur un modèle orienté objet, grâce à la refonte de l’accès aux données.

Refonte de l’accès aux données

Le chargement des données depuis la base de données pour les planètes et les utilisateurs ont étés modifiées. D’une part pour intégrer une vision orientée objet et d’autre part pour permettre à tous de charger, créer, modifier et supprimer des enregistrements sans écrire de SQL, ou d’en écrire très très peu. Ce système est très proche de ce que fait One.Platform, sans en avoir toutes les capacités, mais dans le cas présent seul le plus important a été porté.

Ce point sert de base aux fonctionnalités orientées objet mises en place pour cette version, on y retrouve 3 types de ressources de base qui permettent d’interroger et de mettre à jour la base de données selon les données que l’on traite.

Compatibilité ascendante

La fonction doquery() devient donc obsolète, comme beaucoup d’autres fonctions héritées de la version 0.8-sp1. Tous les appels à ces fonctions seront maintenus pour conserver un maximum de support avec les mods existants, mais redirigeront tous les appels vers les nouvelles méthodes.

Deux paramètres système permettront d’afficher des informations de migration pour les développeurs. Le premier, le mode DEBUG est déjà présent dans les versions 2009.3 et 2009.4, il permet de ne pas afficher les erreurs quand il est désactivé et de ne les afficher qu’en fin de page une fois activé pour ne pas gêner les joueurs et les administrateurs de jeux.

Le second mode se nomme DEPRECATION, il permet indiquer où et quand les méthodes obsolètes sont appelées, c’est un outil intéressant pour ceux qui ont déjà beaucoup modifié leur XNova, qui leur permettra d’être guidés pour mettre à jour leurs mods.

Une API uniforme

Le gros problème de XNova est le manque d’uniformité dans le code source, dû principalement au nombre de développeurs qui ont ajouté leur petite fonctionnalité ici ou là. Pour les développements de cette version, tout a été pensé pour poser une interface uniforme. Grâce à la notation objet et quelques règles de nommage, il devient plus facile de comprendre le fonctionnement et donc de modifier XNova:Legacies.

Modifier XNova:Legacies passera par la création d’un module

Plus besoin de modifier le code source de XNova, pour ajouter ou modifier un fonctionnement du jeu. Il ne sera plus nécessaires (et même déconseillé) de modifier les fichiers sources fournis dans le package de base.

Il existe maintenant 3 espaces de sources : core, community et local, où le premier contient le code source du package de base, le second contient des modules communautaires fournis sur le forum que vous aurez ajouté et le dernier contient votre code source. Le chargement automatique des fichiers chargera en priorité du code source local, puis communautaire, puis par défaut le code source du package standard.

L’avantage pour vous sera de pouvoir copier un fichier provenant du package de base vers le répertoire local puis de modifier ce qui vous intéresse, sans risquer de ne plus pouvoir migrer sur une version future. Il n’y a plus besoin de patch, l’archive de base suffira.

Ceci reste malgré tout limité aux classes réécrites pour cette future version, soit à peu près le quart des fonctionnalités de base, mais au fil du temps tout le code source finira par être migré.

Statut des développements

Je fais la liste ci dessous des développements déjà réalisés et les statuts de ceux qui sont en cours :

• Support des grands nombres [100% réalisés, en phase de tests]
• Programmation événementielle [100% réalisés, en phase de tests]
• Gestion des planètes [100% réalisés, en phase de tests]
• Mise à jour des ressources [100% réalisés, en phase de tests]
• Constructions de bâtiments [100% réalisés, en phase de tests]
• Constructions de vaisseaux et défenses [100% réalisés, en phase de tests]
• Marquage des méthodes obsolètes [100% réalisés]
• Accès aux données, passage sous PDO [90% réalisés, en phase de tests]
• Gestion d’utilisateur [80% réalisés]
• Compatibilité ascendante [50% réalisés]
• Documentation de code [20% réalisés]
• Nettoyage du code obsolète [0% réalisés]
• Reprise des templates [0% réalisés]
• Reprise de l’installeur [0% réalisés]

Le tout est à un état de réalisation de 75% environ avant la sortie d’une version alpha.

Dépôts de sources

Le dépôt de sources est désormais sur Github, vous y trouverez cette version en chantier, vous pourrez y suivre les évolutions au fil du temps.

Ce vaisseau a une capacité de combat supérieure à tout ce qui existait dans XNova jusqu’à présent, mais son coût s’en ressent également:

• Coût en métal : 150.000.000
• Coût en cristal : 300.000.000
• Coût en deutérium : 450.000.000
• Coût en énergie : 100.000.000

Vous avez bien lu, ce vaisseau nécessite une grande quantité d’énergie pour être construit. Chose nouvelle, il en nécessite également beaucoup pour son entretien lorsqu’il n’est pas en mission : autant que la production de 1250 satellites solaires. Mais réjouissez vous. Ce vaisseau, à l’instar de l’étoile de la mort a la capacité de détruire des lunes, et ce avec 4 fois plus de puissance qu’une étoile de la mort.

Voilà la liste des points réglés dans cette version :

• Limitation des systèmes saisis aux limites connues de l’univers, il était auparavant possible de visiter des galaxies ou des systèmes qui n’avaient pas lieu d’exister (système >499 ou <1 et galaxie >9 ou <1)
• Correction du calcul de ressources, ce qui empêchait de faire son graviton avec des satellites
• Ajout de la supernova
• Correction des accès aux pages de l’admin, ces accès sont désormais limités à 3 valeurs sous la forme de constantes définies dans constants.php
• Refonte complète de la queue de construction des vaisseaux et des défenses, certains problèmes sont survenus sur des correctifs précédents, j’ai décidé de tout réécrire et de changer le format d’enregistrement en base. Une perte de données sur la liste de construction est possible si jamais vous migrez votre XNova.
• Changement des probabilités de destructions de lunes, les probabilités maximales de destruction de la lune et de la flotte sont de 50%

Vous trouverez les archives sous les 3 formats habituels (triés par taille) :

Au format Bzip2 (5.9M)
Au format Gzip (6.0M)
Au format Zip (6.5M)

Et un patch (compressé) pour migrer plus simplement vos versions modifiées :

Patch de migration 2009.2 vers 2009.4
Patch de migration 2009.3 vers 2009.4

Attention, pour ceux utilisant un patch pour migrer leur version, la table de planètes doit être mise à jour :

ALTER TABLE game_planets ADD supernova INT(11) NOT NULL DEFAULT "0" AFTER battleship

The bug fix could be foud on the XNova boards

Le correctif peut être trouvé sur le forum de XNova

The core sources of XNova:Next-Gen has been forked into an independent project, designed to bring standard high-level functionalities to various projects, such as User management, Backoffice, CMS functionalities or web applications skelettons. For now this development platform will mainly be used to replace the admin panel of XNova:Legacies and will in the end become its core.

This new project is named One.Platform, you will find a public git repository at Github. It includes the Core module, the User module, a native CMS pages manager and an administration site engine on which the future version is based. The reason why I decided to cut the project in 2 is that what have been done until now can be reused by another project.

This project is based upon the Zend Framework and in order to make it work, you will need to install it (version 1.10+ should work fine, I personnaly use the verison 1.11). Installation instructions are availiable in the files INSTALL and INSTALL.textile in the repository. There is a branch named xnova-legacies which contains the development version of XNova:Legacies, it includes a slightly modified 2009.2 version without installer nor admin panel.

The administration panel can be accessed via the file admin.php, it is a One.Platform Backoffice, in time I’m writing this artcile, you will be able to manage users, configuration options, planets and moons. Everything isn’t finished, but the evolution of this admin panel becomes now easy, taking advantage of the XML configuration files that builds the forms and grids.

Le cœur du code source de XNova:Next-Gen a été déplacé dans un nouveau projet indépendant, créé pour apporter des fonctionnalités standards de haut niveau pour différents projets, comme la gestion d’utilisateurs, un panneau d’administration, des fonctions de CMS ou une architecture d’application web. Pour le moment, cette plateforme de développement sera principalement utilisée pour remplacer le panneau d’administration de XNova:Legacies pour au final devenir son cœur.

Ce nouveau projet est nommé One.Platform vous pourrez le retrouver sur Github. Il inclut le module Core, le module User, un gestionnaire de pages CMS et un gestionnaire de panneau d’administration de site web sur lequel la future version se basera. La raison pour laquelle j’ai décidé de découper le projet en 2, c’est que ce qui a été réalisé jusqu’à aujourd’hui peut être réutilisé par un autre projet.

Ce nouveau projet est basé sur le Zend Framework et pour le faire fonctionner, il sera nécessaire de l’installer (la version 1.10+ devrait fonctionner sas problème, j’utilise la version 1.11). Les instructions d’installation sont disponibles en anglais dans les fichiers INSTALL et INSTALL.textile que vous retoruverez dans le dépôt. Vous y trouverez également une branche nommée xnova-legacies qui contient la version de développement de XNova:Legacies, elle inclut une version 2009.2 légèrement modifiée, sans insallateur, ni panneau d’administration.

Le panneau d’administration est maintenant accessible via le fichier admin.php, c’est un panneau d’admin généré par One.Platform, à l’heure où j’écris ce billet, vous serez en mesure de gérer vos utilisateurs, vos options de configuration, vos planètes et vos lunes. Tout n’est pas terminé, mais l’évolution de ce panneau d’administration devient maintenant plus simple grâce qux fichiers XML de configuration qui créent automatiquement les tableaux et les formulaires.

La prochaine étape se concentrera sur le module user, qui sera la 2nde tranche de développement de XNova:Legacies 2010-alpha0.

Vous pouvez désormais récupérer le trunk SVN du module core de cette manière:
svn co svn+ssh://svn.xnova-ng.org/svnroot/xnlegacies/public/branches/modules/core/trunk

Ou bien depuis son tag :
svn co svn://svn.xnova-ng.org/svnroot/xnlegacies/public/branches/laboratory/gplanchat/modules/core/tags/1.0-alpha0

To return to what we are all here, everything has been redesigned to facilitate simple and rapid modification of the functionnalities of the game without the need of applying neither 1 line of the original source code. Everything is built upon the configuration, if a functionality in the base source code does not work like you wanted : replace it! it is as simple as that.

Accessing to data from the database has never been as simple and safe : get an ID, and load your model, woithout any risk of possible SQL injection. But how do we update, create or delete a database record? Just a line! For the preview 2010-alpha0, the user module will be the first module launched. It is relatively simple and will therefore serve both standard and benchmark for what will follow: 90% of this new source will be shared by an overwhelming majority of functionality or future refactoring.

But all that makes many words and few examples, so here are some previews (may be subject to modification in the final version):

Loading and modifying data of a player from the database:

To load data from a player which, for example, have the ID 8 in the database, the following is enough:
$user = Nova::getModel('user/user')->load(8);

And next? take your newly created variable (here, $user) and use it as like an array, just like you did until now… almost. Yes, because now it is no longer an array, it’s an object. Whath’s the difference? well is that my $ user has now gained virtual accessors and mutators and it even knows how to directly save its data by itself in the database!

$user
->setEmail('player@example.com'); // Updating the field 'email'
->setUsername('Player') // Updating the field 'username'
->save();


Yes, It’s all well and good, but I like it like it was before!

No panic! our $user keeps up appearances and can still be used just like we did before:
echo $user['username'];

But it does not stop with a simple syntax change!

Yes, rather than having functions everywhere, and asking where a particular feature would be, why not combine everything in one place? Well, we do it now! For example: to manage the connection of a player, why not create an automated mechanism?

$user = Nova::getModel('user/user');
if ($user->login($_POST['username'], $_POST['password'])) {
// Our user has submitted the good password, he is now logged in
} else {
// A problem hapened, maybe a passord error?
}


Oh, but how could we retrieve the current user from anywhere now? Simple! Easy! The sessions comes to help us and have also been improved:

$user = Nova::getSingleton('user/session')->getUser();


We now got back our $user, which have logged in in the previous example.

And it goes even further!

Develop and debug your old mods or develop modules for Legacies by enabling debug mode and Deprecation mode and use the source code profiler, simple tools and methods to optimize your code.

In your .htaccess, add the following to enable the two methods mentioned above:

SetEnv DEBUG On
SetEnv DEPRECATION On


The source code profiler is used to count the time taken by a particular treatment, it will return the number of times that it was executed, and various statistics of execution time. It is used with both static methods Nova::profilerStart() and Nova::profilerStop(), respectively, to start a counter and stop t. It both take a single argument that identifies the time counter:

Nova::profilerStart('NOVA.EXAMPLE');
// The treatment to analyze starts from here
for ($i = 0; $i < 200000; $i++) {
echo 'Hello world';
}
// and ends here
Nova::profilerStop('NOVA.EXAMPLE');


Note that the profiler results will only appear in debug mode.