Conceptualisation du prototype opengl
Introduction
Ixydhrien est le nom de l'univers pour lequel a été développé le projet xvoe initialement nommé Xyndhra.
Le projet a malheureusement été arrêté pour la simple raison du manque actuel de moyens pour produire l'environnement et d'une mauvaise stratégie adoptée pour la gestion générale : infrastructure trop généraliste sans possibilité d'optimisation importante.
Cette page contient des informations à propos de la suite du développement et particulièrement le second prototype nommé Noyarch.
Nouveautés
- Page de téléchargement de Noyarch
- http://www.wox-xion.ch/2008/07/10/noyarch-01/ - première version utilisable en ligne
Comparaisons entre prototypes
Aucun projet réel n'est encore défini sous le nom d'ixydhrien, mais des prototypes vont être élaborés avec le temps tentant de développer un univers propre spécifique et accessible en temps réel.
Le premier prototype a été les bases du projet Xuhnix qui a échoué sur le plan de l'optimisation.
| valeur | note |
|---|---|
| + | fonctionnalité générale et totalement externalisée |
| - | optimisation moindre et nettement insuffisante |
| - | intégration d'opengl insuffisante et impossible dans la mesure où l'optimisation selon opengl n'est pas faisable selon la même structure que java2d |
Axes de développement
- un gameplay minimaliste mais complet
- structure pour l'optimisation et non la généralisation
- utilisation directe d'opengl
Il est évident que l'utilisation d'opengl doit être plus attentivement effectuée pour permettre une optimisation maximale. Soit le projet bascule en c++, soit il reste en java et intègre un binding précis d'opengl (jogl ou lwjgl). S'il reste en java, il faudra mettre en place une méthode de déploiment efficace, jnlp étant un choix intéressant.
C++ ou Java
Évidemment qu'une version c++ peut être bien plus optimisée, mais elle pose des problèmes tout autant imposants : la reconstruction des librairies de base, le portage de xio, et le serveur deviendrait passablement obsolète par la suite, il devra donc ensuite être aussi porté en c++ tandis que le portage de l'éditeur de map posera plus de problèmes.
Une version Java n'a de sens que si elle peut fonctionner. Il semble que la version de Wakfu soit gérable et donc qu'une version Java soit possible. Il faudra par contre arriver rapidement à des résultats concrets permettant de conclure si le développement Java a une valeur réelle ou est utopique.
Ainsi, le prototype xvoe2 sera réalisé en Java selon un binding d'opengl. S'il est utopiste et ne se concrétise pas, le prochain prototype xvoe3 sera probablement développé directement en c++/opengl.
Binding OpenGL
Le choix du binding peut poser problème : jogl ou lwjgl.
Il est imaginable de s'orienter vers un moteur graphique déjà fonctionnel tel que JMonkeyEngine, ou alors de construire le moteur de A à Z en sachant que la plupart des options des moteurs graphiques ne seront pas utilisées :
- 3D iso n'utilisant que des données 2D
- UI limitée à :
- une zone de saisie
- des zones de textes (messaging, paroles et identifiants)
- des blocs de couleurs représentant les stats
3D Iso ou 2D+ Iso
Soit l'univers est géré en 3D via OpenGL et des textures 2D, soit il s'agit d'un affichage dont la profondeur sera gérée avant OpenGL, donc en Java pur.
Gestion des maps en 3D
Soit on définit l'utilisation de maps en 2D isométrique : la projection est une projection orthogonale 2D, la gestion de la profondeur ainsi les positionnements sont faits à la main, on ne peut tirer profit d'opengl que pour l'affichage, et encore - le changement de textures avec opengl est la partie la plus coûteuse en temps d'exécution.
Soit on définit l'utilisation de maps en 3D complète. Les seuls éléments qui restent en 2D sont alors :
- les personnages
- l'interface utilisateur
Le système de map devient alors totalement nouveau et doit être redéfini.