Kowy Maker – Carnet de bord

Aujourd’hui je vais vous parler d’un tout nouveau truc pour Kowy Maker dont j’ai eu l’idée récemment

Avec le passage à Java, un problème s’est opposé à moi (« Mer il et fou » me direz-vous) : La gestion des ressources graphiques pour le jeu.

En effet, sous Flash, j’avais accès aux fichiers SWF, bien pratique du fait qu’on pouvait mettre du code dedans et aussi gérer le « point d’origine » de l’image (c’est à dire le point aux coordonnées [0;0], ce qui permet de positionner le SWF comme on veut). Or, avec Java je n’avais plus accès à tout cela, du fait que j’utilise principalement le format PNG pour les images, et j’avais besoin de ce « point d’origine » pour bien positionner les « tiles » (les briques qui permettront de modéliser le monde dans le jeu).

J’ai donc plusieurs solutions:

• Envoyer les infos supplémentaires sur les tiles au client via le serveur: Cela permettrait un certain contrôle sur les infos, mais peu pratique dans le sens où cela provoquerait une quantité de données à envoyer plutôt volumineuse à long terme.
• Utiliser un fichier XML à part, qui contiendrait les infos sur chaque tile: Ca reste un solution, mais le problème se pose si on veut ajouter de nouveaux tiles, on devrait alors éditer à chaque fois ce fichier :/
• Packager la ressource graphique dans un fichier .jar contenant une classe Java gérant cette ressource: Trop lourd pour ce que je veux.
• Utiliser un format spécial pour les ressources graphiques: Ca me permet de rajouter toutes les infos voulues, en plus de permettre d’ajouter de nouveaux tiles facilement (juste en copiant-collant le fichier), mais cela inclue l’utilisation d’un logiciel fait-maison pour voir et éditer le fichier (mais le format de l’image reste le PNG, dont les données seront contenues dans le fichier)

Au final, j’ai choisi de prendre la troisième solution, elle me semble la plus logique, et ouvre pas mal de possibilités en plus sur la gestion des ressources

Ainsi, les ressources graphiques du jeu (ainsi que les maps et pas mal d’autres trucs, sauf les fichiers de config) utiliseront un format spécial pour Kowy Maker que j’ai nommé : Kowy Maker Resources File Format (sexy non?)

Les fichiers ressources du jeu auront alors l’extension .kmr (Pour « Kowy Maker Resource ») et commenceront pas un entête contenant une signature de 5 bytes définissant le type de ressource (tile, personnage, effet, etc…)

Ensuite, afin de gérer ces formats, j’ai créé « Kowy Maker – Specification », une librairie Java qui sera utilisée dans tous les softs de Kowy Maker (Client, serveur, éditeur), qui contiendra toutes les spécifications relatives à Kowy Maker: Protocole réseau pour les paquets, formats des fichiers ressources, quelques classes Java utilisées par tout Kowy Maker, voire plus si je trouve d’autres trucs à mettre dedans.

Le code source des spécifications se trouveront dans le repo Github: https://github.com/KowyMaker/Specification

PS: Je rappelle aussi que vous pouvez trouver les builds « snapshot » du projet (ainsi que tous mes autres projets), sur mon Jenkins: http://ci.kokaelkiwi.tk:8080

Cordialement,
Koka El Kiwi

Bon, ça fait un petit bout de temps que le blog était pas tenu à jour, ben c’est le moment de le faire

Voilà, j’annonce que Kowy Maker va subir un gros changement: Le client sera codé en full Java !

Pour info, le client était sensé être, au départ, codé en ActionScript 3.0, langage qui m’a donné l’envie de commencer ce gros projet qu’est Kowy Maker! Mais avec le temps, j’ai pu m’initier à d’autres langages de programmation (principalement le Java avec lequel est codé le serveur, un peu de C, un chouïa de Python et encore moins, de C++).

Or, lorsque je reprenais le développement du client de Kowy Maker, je ne retrouvais plus l’envie de le coder, du fait que mon langage de programmation préféré est le Java, et les syntaxes des deux langages de programmation sont totalement différentes, en plus du fait que Java est, selon mon point de vue bien évidemment, plus évolué que l’AS3 (notamment par le fait qu’il soit Open Source).

De ce fait, lorsque je codais le client, je n’éprouvais pas vraiment de plaisir, du moins pas autant que quand je développe le serveur.

J’avais donc deux solutions:

1 – Rester sur l’ActionScript:

• Cela me permet de gagner de l’expérience sur ce langage de programmation
• Plus simple pour gérer le côté graphique de la chose, sachant que Flash a plus pour but de créer des applications graphiques que des applications de types « Outils » (Allez faire un serveur en ActionScript…Je sais même pas si c’est possible tiens)
• M’empêche de prendre du plaisir à coder le client, du fait qu’étant habitué à Java, la majorité de la syntaxe AS3 m’énerve (ainsi que le fait que ça ne soit pas aussi complet que Java)

2 – Coder le client en Java:

• Je garde le côté « portatif » du jeu, sachant que Java peut aussi se lancer en navigateur via une Applet
• Moins simple à gérer côté graphique, je pense donc prendre la librairie LWJGL pour utiliser OpenGL dans le jeu et ainsi utiliser un peu de 3D pour faire le rendu (mais ça reste de l’iso hein!)
• Je prend plus de plaisir à le coder, du fait que j’adore Java (et j’assume totalement, pour ceux qui me dirait que Java « cay nul » )
• Du fait d’utiliser OpenGL, se dire que moins de PC pourront supporter le jeu, m’enfin bon, on est en 2011, maintenant la plupart des gens on un PC assez puissant pour faire tourner un peu de 3D quand même…

Donc voilà, j’ai préféré privilégier le fait de prendre du plaisir à faire ce projet au détriment de l’expérience que m’apporterai le fait de coder le client en AS3, j’ai donc opté pour l’utilisation de Java pour le client.
Voilà pour les explications, je vais maintenant dire les conséquences que cela aura sur le projet.

Tout d’abord, je vais devoir passer pas mal de temps à redéfinir entièrement l’organisation du client, aussi bien au niveau du code que du côté graphique.
En effet, depuis le début du projet (c’est à dire il y a 2/3 ans), j’ai noté sur des feuilles toute l’organisation du client: comment les graphismes seraient gérés, comment seraient créés les fichiers contenant les graphismes du jeu, etc…
Je vais donc devoir repenser tout cela, tout en essayant de garder les mêmes possibilité qu’offrirai un client en AS3.
Donc voilà, j’espère que certains ne seront pas déçus ^^
Si vous avez des questions, posez les sur le forum sur ce post

Cordialement,
Koka El Kiwi

Aujourd’hui, je vais vous parler du versionning de Kowy Maker (vous vous en doutiez pas, hein? Allez avouez que c’est une surprise )

Alors, le versionning c’est quoi?

Pour ce projet, il s’agit du déroulement de la création du projet par étape.

En gros, je débuterai par la v0.1 qui contiendra des fonctions de base pour le client et le serveur, pour ensuite sortir des Mises à Jour au fur et à mesure des fonctionnalités que j’aurai intégré au projet.

Ainsi, les mises à jours se feront comme ceci: 0.1 > 0.2 > 0.3 > … > 1.0

La 1.0 étant la version contenant TOUTES les fonctionnalités décrites dans la page du site les affichant : http://www.kowymaker.com/features

Le « planning » des mises à jour prévues (comprenez ici ce que chaque nouvelle version apportera) est déjà faites, mais ne sera jamais publiée (afin de garder un peu de suspence, hihi :p)

…

Bon aller, j’suis sympa, je vous donne donc le planning des deux premières versions (0.1 et 0.2):

• v 0.1:
  • Fonctions de base d’affichage côté client (et de gestion de map), idem côté serveur.
  • Présence d’un système basique d’interface
  • Présence d’un début de système de tchat
• v 0.2
  • Système de maps multiples, avec plots sur les bords pour changer
  • Ajout de l’éditeur de maps
  • Ajout des tiles/éléments (en gros, les blocs sur les cases, genre l’herbe, la terre, pierre, etc…)
  • Ajout des cases scriptées

Bon voilà, un peu de spoil pour cet article, je crois que ça compense du manque d’infos depuis longtemps ^^

Cordialement,
Koka

Pour commencer ce Carnet de Bord, je vais vous expliquer comment marche le futur serveur de Kowy Maker

Attention, ce qui va suivre est destiné à des personnes connaissant la programmation Java.

Au départ, le serveur devait s’articuler en multi-thread (avec java.io.*), le script que j’ai utilisé comme modèle étant un tuto de developpez.com

Mais, après avoir discuté avec BillFR par MP sur le forum officiel de DOFUS (par rapport aux fonctionnalités que je voulais apporter à Kowy Maker), il me conseillât d’utiliser plutôt java.nio.* car la solution multi-thread pourrait surcharger l’ordinateur hébergeant (si le serveur accueille un grand nombre de joueurs).

Ayant cherchés sur Internet comment marchait java.nio.*, je me suis rendu compte que l’utiliser allait être plus compliqués que prévu (je comprenais rien en fait), j’ai donc opté pour un framework pour java.nio.* qui existait alors: Netty

Celui-ci permettant d’utiliser plus simplement Java Nio, j’ai donc commencé à écrire le serveur dessus, et je dois dire que ça marche très bien

Ainsi, la base du serveur est presque prête, il « suffit juste » d’ajouter le support des commandes envoyées par le futur client (qui seront en XML).

Voilà pour l’épisode 1, je vous parlerai du client dans le prochain épisode =)

Sinon, pour les infos, en ce moment, je code plus le serveur ainsi que le forum (que je viens de ré-installer), je me concentrerai sur le client après.

Cordialement,

Koka

Bon, bah…Juste pour dire que j’ouvre le Carnet de Bord…Ah oui, une présentation de celui-ci…

Et bien, ce Carnet de Bord est là pour vous permettre de suivre l’évolution de Kowy Maker, aussi bien les Mises à Jour que pour des notes de développement…

C’est une interface entre le/les développeur(s) et les utilisateurs, ce qui vous permettra d’encourager le projet en postant des commentaires

Mais pour tout ce qui est suggestions, discussions à propos du projet, c’est sur le forum que ça se passe

Bref…Enjoy now

Cordialement,
Koka