Discussion :

[yahiko]

Bonjour à tous,

J'ai le plaisir de vous présenter un projet sur lequel je travaille depuis quelques semaines. Il s'agit d'un moteur de combat au tour par tour du nom de Saber Engine.

Il s'agit pour le moment d'un moteur sous la forme d'une API en langage C et en JavaScript. Ce moteur peut donc en théorie être intégré à un projet de jeu en offline ou en mode Web.

Ce moteur s'appuie sur divers travaux antérieurs et sur le constat qu'il s'agit d'un besoin récurrent au moment de développer un RPG et pour lequel il n'existe qu'assez peu de ressources facilement utilisables.

Saber Engine a donc pour ambition de permettre aux développeurs d'intégrer facilement un module de combat dans leur jeu en intégrant l'API à leur projet et en modifiant les paramètres en fonction des besoins du jeu en question.

Actuellement, je travaille sur différents projets pour implémenter ce moteur de combat au sein du jeu. Ces projets sont les suivants :
Projet Osaka de Kannagi : Ce projet utilise l'API en langage C.
Projet Sélandia de Iparcos : Ce projet utilise l'API en JavaScript.
Projet Space Quest d'Avogadron : Ce projet utilisera l'API en JavaScript. Il ne s'agit pas d'un RPG contrairement au deux projets précédents mais le moteur devrait pouvoir s'adapter néanmoins à la logique du combat spatial qui sera également du tour par tour.

Dans la mesure où il s'agit d'un middleware et non d'un jeu final, je n'ai pour l'instant pas de visuel très excitant à montrer d'autant plus que les projets précités sont encore en cours de développement voire de conception.

Voici tout de même une maquette façon fil de fer laissant entrevoir le déroulement d'un combat :

En l'état actuel, le cœur du moteur est développé, même s'il reste encore pas mal de tests à réaliser pour m'assurer du bon fonctionnement de la mécanique. Une des tâches les plus laborieuses est de s'assurer que les versions C et JavaScript de l'API restent en phase.

A noter qu'il existe une documentation technique expliquant les principes du moteur de combat et le mode d'utilisation de l'API. Cette documentation est pour le moment réservée aux responsables des projets avec lesquels je travaille pour y intégrer Saber Engine. Quand le moteur sera dans un état suffisamment abouti, j'envisage sans doute de rendre publique une partie des spécifications du moteur.

Dans les grandes lignes, Saber Engine possède actuellement les fonctionnalités suivantes :

1. Gestion de la notion d'équipe
2. Gestion de l'Active Time Battle (eg. Final Fantasy VI, Chrono Trigger)
3. Gestion du Charge Time Battle (eg. Grandia, Final Fantasy XXII)
4. Paramétrage via un fichier JSON

Feuille de Route

Il reste évidemment de nombreuses fonctions que je souhaite ajouter à ce moteur, notamment pour répondre aux besoins spécifiques des projets en cours dans lesquels est impliqué Saber Engine :

1. Gestion des actions multiples par personnages
2. Gestion de la position
3. Gestion des effets (eg. empoisonné, paralysé, etc)
4. Paramétrage des règles de dégâts via des scripts externes
5. Portage sur Unity (en C#)

Si vous êtes intéressé par ce moteur de combat dans un de vos projets, n'hésitez pas à me contacter en message privé. Je ne manquerai pas de vous répondre.

Au plaisir !

[Vetea]

Vraiment très sympa !!

J'adore le concept "Tour / Tour" ! J'en reviens toujours au premier Heroes of Might and Magic.
J'ai aussi développé un jeu de Rôle - Tactique en VB, Rol'An'Go, avec ce système de Tour / Tour, assez complexe à mettre en oeuvre en fin de compte.
Car il faut aussi développé un moteur de Pathfinding type A*, performant !

N'étant pas un afficionado des technologies modernes, je salue toutefois ta démarche de moteur pour ce type de gameplay.
Bon courage !

[Kannagi]

Je parlerait pas de technologie moderne concernant son moteur , ce qui est bien c'est que c'est original d'habitude on a plus l'habitude de voir des lib graphique alors une lib fait pour le gameplay c'est rare.
En tout cas pour ma part je sert de beta testeur a vrai dire

[yahiko]

J'adore le concept "Tour / Tour" ! J'en reviens toujours au premier Heroes of Might and Magic.

Oui, je suis aussi un grand amateur de la série des Heroes of Might and Magic. Je ne compte plus le nombre d'heures perdues sur la licence.
Cependant, pour le moment, le moteur n'intègre pas encore la dimension tactique. Même si c'est un développement que je prévois une fois les fonctionnalités du cœur seront finalisées et stabilisées.

La cible prioritaire est de couvrir les caractéristiques des RPG classiques :

J'ai aussi développé un jeu de Rôle - Tactique en VB, Rol'An'Go, avec ce système de Tour / Tour, assez complexe à mettre en oeuvre en fin de compte.

Je viens de le télécharger, je le testerai prochainement

N'étant pas un afficionado des technologies modernes, je salue toutefois ta démarche de moteur pour ce type de gameplay.
Bon courage !

Dans la mesure où Saber Engine est une API, c'est-à-dire une bibliothèque de fonctions appelables par un programme tiers, il n'y a pas vraiment de barrière technologique pour l'utiliser.
De plus, étant disponible soit en langage C, soit en JavaScript, cette bibliothèque est à priori portable sur n'importe quelle plateforme que ce soit OS ou navigateur.

En tout cas pour ma part je sert de beta testeur a vrai dire

Il faut bien que chacun y trouve son compte :p
Tu n'es pas vraiment perdant dans l'histoire ^^

[tristan_m]

Bonjour,

Je félicite votre démarche!
Implémenter une API plutôt qu'un projet complet, et faire un partenariat avec des projets existants est une excellente idée.

J'ai par contre quelque interrogations sur la faisabilité d'un tel projet.
Pour les RPGs, les combats sont au coeur du jeu. C'est donc une partie qui se veut très spécifique à chaque jeu.

• Tel jeu va voir une barre de limit break, tel autre jeu une barre de fatigue, tel autre une barre de magie.
• Dans tel jeu il y a une animation spéciale quand l'ennemi est à la moitié de sa barre de vie, dans tel autre le combat se termine quand l'ennemi n'a perdu que 10% (un boss qu'on ne peut tuer que plus tard dans le scénario), et encore dans un autre il y a une limite de temps.
• Tel jeu va implémenter des attaques combinées impliquant plusieurs personnages.
• Des évènements particuliers, ex: Le joueur a infligé 7777 dégâts, a tué son 1000ème adversaire.
• Le jeu a besoin d'un nouvel effet, ex: zombie.
• etc...

L'originalité est vraiment de mise, voire obligatoire, je pense.
Pour que le jeu ne soit pas juste un énième RPG, il doit sortir des sentiers battus.
Donc il me paraît extrêmement difficile de faire une librairie commune sans restreindre le jeu ou sans rendre l'API très complexe (et même là, il y aura forcément des cas non gérés).
Avez-vous prévu une API suffisamment ouverte/évolutive pour que le jeu soit totalement libre?
Est-ce plutôt une API de prototypage?
Est-ce que le parti pris est volontairement de proposer une API avec un ensemble limité, mais éventuellement élévé et/ou avancé, de fonctionnalités?

Concernant la présentation du projet, puisqu'il se destine à des développeurs plus qu'à des joueurs, peut-être que des exemples d'utilisation de votre API pourraient être pertinents?

Bon courage pour la suite!

[yahiko]

Merci pour ton commentaire plein d'intérêt, c'est agréable.

Pour répondre à tes interrogations, je commencerai par dire que comme tout outil (framework, éditeur ou studio de développement), il a ses limites et n'est valable que dans un certain domaine.

Pour le moment Saber Engine se focalise sur l'implémentation de l'Active Time Battle et du Charge Time Battle, présents dans de nombreux titres des années 1990 qui sont deux systèmes que j'ai déjà pas mal étudié.

Ce qui ne veut pas dire que le moteur est enfermé dans un carcan rigide. De nombreux degrés de liberté sont/seront permis via un paramétrage de diverses variables et des scripts interprétés externes au cœur du moteur étendent/étendront les fonctionnalités de Saber. Cette technique est très commune dans le domaine du jeux vidéo par ailleurs.

De plus, comme je l'ai dis, le moteur pourra s'enrichir de nouveaux modes, comme par exemple le mode tactique. Cela se fera progressivement.

Mon objectif et le but premier de Saber Engine étant d'abord de faciliter la réalisation des projets RPG (ou autres) utilisant un système de combat au tour par tour, qui peut ne pas être trivial à implémenter, et demande souvent quelques semaines (intensives) de développement en partant de zéro. A ce titre, à l'heure actuelle mon travail est de faire en sorte que Saber contribue à l'aboutissement des projets dans lequel il est utilisé.

Si à l'avenir, un projet sérieux venait à avoir des besoins non couverts par Saber, cela pourra être une source d'évolution intéressante pour le moteur. Je suis donc dans une logique d'évolution par paliers avec comme première priorité de satisfaire aux besoins de mes partenaires. Saber Engine est au service des autres projets et s'adaptera si cela est nécessaire.

Enfin, concernant ta demande d'exemple d'utilisation de Saber, comme je l'ai dis dans ma présentation, la documentation technique est pour le moment réservée aux responsables des projets partenaires. D'autant plus que comme le moteur en encore en phase de développement, beaucoup de changements au sein de l'API peuvent encore se produire. Je préfère communiquer sur ces questions techniques d'implémentation quand le moteur sera stabilisé.

En espérant avoir répondu à tes questions,

Merci encore pour ton intérêt,

Au plaisir.

[tristan_m]

Bonjour,

Merci pour votre réponse.
Donc si je comprends bien, vous souhaitez proposer une version "de base", et si celle-ci ne remplit pas tous les besoins, vous offrez une solution sur-mesure (partenariat) avec les projets concernés?
C'est assez inhabituel pour un projet amateur :
Pour le développeur c'est partir dans l'optique d'un projet sans fin (il y aura toujours des demandes de nouvelles fonctionnalités), avec un niveau de support élevé,
et pour le jeu, le risque de voir disparaître le développeur au milieu du développement est plus important qu'avec un développeur rémunéré.

Mais si vous tenez bon, ça tient la route, de mon point de vue.
Le challenge le plus intéressant étant de conserver une API facile à utiliser au cours des paliers successifs.

3 langages à supporter me semble beaucoup par contre (même 2 en fait), surtout si, comme vous le dîtes, vous tenez à ce que toutes les fonctionnalités soient présentes avec chacun d'eux.
Personnellement je trouve que le portage d'une fonctionnalité est moins intéressant que son développement.
De surcroît s'il faut le faire 2 fois, dans des langages aux contraintes différentes, avec la perspective que ladite fonctionnalité puisse ne jamais être utilisée dans ces langages.
L'avantage étant par contre de devoir se replonger dans l'implémentation 2 fois de plus, et donc de potentiellement découvrir des bugs, des simplifications/optimisations possibles, etc...

Je vous renouvelle donc mes encouragements!

[yahiko]

Donc si je comprends bien, vous souhaitez proposer une version "de base", et si celle-ci ne remplit pas tous les besoins, vous offrez une solution sur-mesure (partenariat) avec les projets concernés?

Pour éviter toute ambiguïté, je dirais qu'il n'y a et n'y aura qu'un seul moteur du point de vue fonctionnel (si on fait abstraction du versionning évidemment).
Ce qui pourra se produire, est qu'en cas de demande intéressante et sérieuse de la part d'un projet qui ne trouverait pas son bonheur avec Saber Engine, je suis tout à fait disposer à le faire évoluer et à l'améliorer. Ces évolutions et améliorations devront par contre s'intégrer au noyau ce qui fournira une version n+1 du moteur.

C'est assez inhabituel pour un projet amateur :
Pour le développeur c'est partir dans l'optique d'un projet sans fin (il y aura toujours des demandes de nouvelles fonctionnalités), avec un niveau de support élevé,
et pour le jeu, le risque de voir disparaître le développeur au milieu du développement est plus important qu'avec un développeur rémunéré.

Les demandes venant de nouveaux projets pourront être acceptées ou refusées selon si elles s'inscrivent ou non dans la logique d'évolution du moteur.
Concernant le risque de voir disparaître le développeur (en l’occurrence bibi ^^), il existe, mais il existe tout autant sinon davantage pour un développeur devant créer de toutes pièces un module de combat spécifique à un jeu. Si jamais je venais à abandonner le support du moteur, les projets partenaires ont de toute façon le code source du moteur et peuvent le modifier à leur convenance (tout en respectant les mentions d'auteur). Ils auront de plus une documentation technique, ce qu'ils n'auraient sans doute pas eu si cela avait été du développement spécifique.

3 langages à supporter me semble beaucoup par contre (même 2 en fait), surtout si, comme vous le dîtes, vous tenez à ce que toutes les fonctionnalités soient présentes avec chacun d'eux.
Personnellement je trouve que le portage d'une fonctionnalité est moins intéressant que son développement.
De surcroît s'il faut le faire 2 fois, dans des langages aux contraintes différentes, avec la perspective que ladite fonctionnalité puisse ne jamais être utilisée dans ces langages.
L'avantage étant par contre de devoir se replonger dans l'implémentation 2 fois de plus, et donc de potentiellement découvrir des bugs, des simplifications/optimisations possibles, etc...

Il y a évidemment un coût à supporter au fait de maintenir le moteur sous deux langages distincts. Mais ce n'est pas insurmontable en s'imposant de la rigueur et de la méthode dans les modifications. Il va sans dire qu'un outil performant de versionning est dans ce cas plus qu'indispensable.

J'essaie aussi d'homogénéiser aux maximum le nommage. Cela va au-delà du simple nommage des fonctions. Par exemple, dans la programmation orienté objet, le contexte d'exécution d'une méthode est en général appelé this. C'est le cas en TypeScript, surensemble typé de JavaScript qui me sert justement à générer la version JavaScript.

Code typescript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
class Battle {
    turn: number;
    ...
    constructor(turn: number) {
        this.turn = turn;
        ...
    }
    ...
}

En langage C, qui n'est pas un langage orienté objet comme chacun le sait, j'ai adopté une convention de nommage qui me permet de transposer le code d'un langage vers l'autre avec le minimum de changements.

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
typedef struct Battle Battle;
 
struct Battle {
    int turn;
    ...
}
 
battleInit(Battle* this, int turn) {
    this->turn = turn;
    ...
}
...

L'identificateur this n'étant pas un mot réserve en langage C, contrairement au C++, je l'utilise en tant que paramètre explicite simulant le passage du contexte.

Avec quelques petites astuces du même style, en utilisant par exemple le préprocesseur et les macros du côté C et les interfaces côté TypeScript, on parvient à faire du code très similaire de part et d'autre.

De plus, cela comporte quelques avantages, dont certains que tu as relevé.
Tout d'abord, ayant à écrire et à relire à minima deux fois le code, cela augmente de fait les chances de détecter les bugs. Ce qui est déjà en soit un atout important dans la mesure où le code n'est pas une séquence linéaire d'instructions mais comporte de multiples branchements et quelques références croisées.

Cela permet aussi de mettre l'accent sur la qualité et la lisibilité du code. Ce qui est sur le long terme toujours un bon investissement. Un moteur s'inscrivant davantage sur le long terme qu'un module de combat spécifique, c'est plutôt un point positif donc.

Cela m'oblige également à restreindre l'utilisation des certaines constructions trop spécifiques à un langage. Par exemple, TypeScript est un langage orienté objet supportant l'héritage ce qui n'est pas le cas du langage C. Je m'interdis donc cette construction côté TypeScript, ceci pour faciliter la transposition. On peut de toute façon très bien s'en passer dans l'absolu. L'héritage n'étant qu'une facilité fournie par le langage (TypeScript en l'occurrence) pour la réutilisation de code.

Le seul aspect où le code diffère sensiblement entre les deux langages concernent l'accès aux fichiers dans la mesure où JavaScript est exécuté dans un environnement asynchrone, ce qui n'est pas le cas à priori de l'environnement standard d'exécution du langage C, où je reste sur du mode séquentiel.

Merci en tout cas pour les encouragements.

Au plaisir

[yahiko]

Bonjour à tous,

Il y a eu quelques évolutions assez significatives depuis la présentation du moteur de combat Saber il y a un mois.
Deux des projets dans lesquels Saber est impliqué ont suffisamment avancé pour permettre d'illustrer un peu mieux les potentialités du moteur de combat.

Maquette de la barre Charge Time Battle dans le Projet Osaka

Maquette du multi-action dans le projet Sélandia

Évolutions

1. Le moteur fournit des fonctions pour simplifier l'affichage de la barre Charge Time Battle (CTB).
2. Les personnages peuvent réaliser plusieurs actions par tour. Il existe non seulement une notion de priorité sur les personnages mais aussi sur les actions.
3. Evolution du moteur en une approche totalement événementielle. Le comportement du moteur est entièrement personnalisable par l'application appelante.
4. Prise en charge de scripts externes en JavaScript (à la fois pour la version JavaScript du moteur que pour la version en langage C) permettant de définir la résolution des actions sans avoir à recompiler l'application.

Feuille de route

1. Définition d'une API de scripting
2. Généralisation du scripting à tous les événements du moteur
3. Définition extensible et à l'exécution des personnages
4. Prise en charge du Free Turn Battle (façon jeu de dames ou d'échec)

Plus globalement, je suis assez satisfait de la tournure que prennent les choses.
D'une part les versions JavaScript et C sont toujours en phase. Cette contrainte n'en est finalement pas vraiment une puisqu'elle me permet d'avoir en quelque sorte deux environnements de tests pour éprouver les évolutions du moteur.
D'autre part la collaboration avec Kannagi et son projet Osaka pousse le moteur à fournir une API aussi complète et "user friendly" que possible, et les besoins assez spécifiques du projet Sélandia oblige le moteur à être le plus ouvert possible.

Actuellement, je pense qu'il doit être possible d'utiliser Saber pour implémenter des combats en pseudo temps réel à la façon de Star Wars: Knight Of The Old Republic ou encore Mass Effect.

Voilà pour les nouvelles.

A noter que si vous êtes actuellement en cours de conception d'un RPG ou d'un jeu impliquant des combats au tour par tour et que vous êtes intéressé par Saber, n'hésitez pas à me contacter par MP, je ne manquerai pas de vous répondre.