Jeu de programmation - Utopia

Salut les zestueux !

Aujourd’hui je viens vous présenter le nouveau projet dans lequel je me suis lancé, avec une petite présentation personnelle avant ça.

Présentation

Je m’appelle Jérôme, j’ai 24 ans et je suis actuellement développeur dans un petit studio de jeux vidéos basé sur Lyon, cependant c’est aussi ma passion depuis très longtemps.
Côté technique, je programme en C++ depuis bientôt dix ans, après quelques détours par d’autres langages (notamment Lua, C, C#, etc.).

Projet (historique)

Le projet dont je vais vous parler a été commencé en 2009, à l’époque où j’avais des étoiles dans les yeux, l’impression que tout était simple et où je sous-estimais les tâches.

C’est donc tout naturellement que je me suis lancé dans un jeu de type MMO.

L’idée était la suivante: faire un jeu de gestion dans l’espace, avec gestion d’une base planétaire, production d’une flotte spatiale, et affrontement avec les autres joueurs via les vaisseaux spatiaux.

Avec une petite particularité: Tout est programmable.
Autrement dit, les vaisseaux spatiaux n’obéissent pas à une IA générique implémentée par le développeur du jeu, mais bien implémentée par le joueur.

Le jeu et son idées ont intéressé pas mal de monde à l’époque, au point d’intéresser un graphiste professionnel qui nous avait fait un site web, ainsi qu’un ingénieur son qui nous a même composé quelques musiques.

Le problème, en plus du fait que personne dans l’équipe n’avait la moindre idée sur comment lancer le projet réellement, c’est qu’au détour d’un essai de programmation en utilisant un moteur de jeu, j’ai été frustré de ne pas comprendre le fonctionnement de ces moteurs au point de décider d’en créer un, pensant que ça allait seulement retarder le projet de quelques mois.

C’est donc tout naturellement que huit ans plus tard…

Projet (présent)

Aujourd’hui, après cinq années de travail sur mon propre moteur de jeu, avoir acquis en connaissances, compétences et maturité, j’ai décidé de relancer cette idée de jeu de programmation, mais en version faisable.

Du coup l’idée, c’est de reprendre le jeu à la base, c’est à dire faire un jeu de combat de vaisseaux spatiaux qui soient contrôlés par des IA écrites par les joueurs, et ensuite d’étoffer.

Mais avant, et surtout, l’idée est d’en faire un jeu communautaire, c’est notamment pour cette raison que le jeu sera open-source et disponible sur GitHub, que les idées à apporter au jeu pourront être apportées par n’importe qui et soumises au vote du public.

Et également, que le développement du jeu sera effectué en live sur Twitch.

Voici le lien du twitch, quelques sessions de développement ont déjà été effectuées et sont disponibles en replay (je vous déconseille la première session, car mon micro et ma webcam n’étaient pas DU TOUT adaptés ).

https://www.twitch.tv/sirlynixvanfrietjes

Actuellement, le développement est assez technique, le travail se fait surtout sur le réseau (mise en place d’une architecture de base pour le serveur, de la gestion des packets, etc.) donc ça peut en rebuter certains, n’hésitez pas à revenir d’ici une live ou deux, lorsqu’il y aura enfin du concret à montrer (un client graphique en somme).

Évolution

Comme je l’ai dit, le but principal est de sortir un jeu reprenant le concept de base, en charcutant bien des idées qui avaient été développées à la base et en les ramenant après si possible.

Voici une liste de ces idées potentielles: - Permettre à un non-programmeur de jouer, notamment via la programmation graphique (type blueprint d’UE4/éditeur de trigger de Warcraft 3) - Faire un marché au script, un joueur pourrait vendre/louer ses scripts à d’autres joueurs pour qu’ils se tapent dessus, mais gare aux backdoors ! - Rendre les vaisseaux modulaires, on peut imaginer que des processeurs donnent accès à plus de mémoire pour les scripts, qu’on puisse monter les armes de son choix, etc. - Autoriser d’autres moyens que le combat pur et dur pour gagner une partie.

Je reviens sur cette dernière idée, on peut imaginer qu’un vaisseau ait beaucoup de moteurs/boucliers mais aucune arme, avec une IA dont le seul objectif est de s’écraser sur le plus gros vaisseau de la flotte ennemie.

On peut imaginer un vaisseau brouilleur (doté de boucliers et d’antennes) dont le seul but est d’empêcher le dialogue entre les vaisseaux ennemis en brouillant les fréquences, ou en les spammant de messages (un petit Denial of Service !).

On peut imaginer plein de choses, l’objectif c’est pas que ce projet soit juste le mien, mais aussi le vôtre

Vidéos

Je suis actuellement en live si ça vous intéresse.

Il y a également un serveur Discord sur lequel se trouve un canal dédié au projet si ça vous intéresse (command !projets dans #bots).

Sur ce, je dois y aller, vous êtes déjà dix à m’attendre !

Comment l’IA fonctionne ? L’IA est lancée sur le PC du joueur ? Ou elle tourne sur le serveur ?

Tu as aussi un compilateur mis à disposition par une équipe ayant un jeu similaire et publié depuis quelques années déjà. Ça peu peut-être te donner des idées pour la partie IA.

L’IA tourne purement côté serveur

Merci pour le lien, je prends en compte

Hello !

Je vous annonce que le prochain stream se tiendra ce soir vers 18h, et il portera sur les débuts de l’application client (et donc, du graphique !).

Normalement ceci sera régulier (donc chaque mercredi/18h il y aura un stream de développement d’environ trois heures), je suis en train d’essayer de caler une deuxième date dans mon emploi du temps (probablement le week-end pour l’instant).

À noter qu’à partir de 2018 je pourrais certainement faire un stream le jeudi en plus du mercredi.

N’hésitez pas à me donner des conseils pour rendre le Twitch intéressant d’ailleurs.

Dernière précision: le code source du projet devrait être disponible sur GitHub à la fin de cette session.

Tu peux peut-être t’inspirer de Screeps, si tu ne connais pas déjà ?

Désolé pour la réponse tardive. Oui je connais Screeps de nom, et quelques autres jeux de programmation.
Par contre je ne sais pas trop quels éléments en retirer

Sinon, le prochain live sera bien demain à partir de 18h. Au stade actuel le réseau semble bien fonctionner (des gens me rejoignent en plein milieu de stream sur mon serveur, si ça c’est pas cool ), je vais donc me consacrer à son amélioration, notamment la mise en place de l’interpolation.

Je précise que demain ça fera huit ans très exactement que le projet initial aura été présenté sur OC, c’est l’occasion de fêter l’anniversaire dignement !

Le live de l’anniversaire s’est assez bien passé, malgré une fatigue de ma part et des difficultés à mettre l’interpolation en place, on peut néanmoins remarquer que le jeu dispose maintenant d’un chat en temps réel que vous avez été une dizaine à venir tester au beau milieu du live:

Le prochain stream aura lieu ce week-end, soit samedi après-midi soit dimanche soir, ce n’est pas encore décidé (je mettrais une mise à jour la veille en guise de statut Twitch).

Merci du soutien que vous apportez au projet en tout cas, ça fait plaisir

Hello Lynix, je suis ton sujet à la fois ici et sur OC. Je préfère échanger avec toi ici

Pourquoi le lua ? Pourquoi lui plutôt qu’un autre langage de script. Je me demande d’une part car la doc ne me semble pas aussi facilement accessible que d’autres langages de script (comme le python par exemple) et aussi car ta décision a l’air vraiment ferme sur ce choix.

Bon courage pour ce projet, je le testerai avec plaisir dans quelques temps, j’ai hâte d’y jouer !

Alors effectivement j’ai une décision assez arrêtée sur le langage de script, même si je me suis souvent posé la question dernièrement du langage à utiliser.

Les raisons derrière ce choix sont:

• Lua est un langage très facile à prendre en main car sa syntaxe est très simple.
• Lua est très léger en occupation mémoire, pratique quand le serveur va justement devoir instancier plusieurs milliers de VM Lua.
• Lua possède une implémentation extrêmement performante, LuaJIT.
• C’est un langage avec lequel j’ai beaucoup d’affinité (je ne peux pas nier que ça joue aussi).

Je trouve la documentation du langage très accessible, je ne connais pas la documentation de Python mais je ne pense pas que celle de Lua soit particulièrement à plaindre, à l’inverse des tutoriaux peut-être.

Mais mon choix n’est pas si arrêté que ça, notamment, j’avais envisagé de passer sur Ravi, un dérivé de Lua 5.3 qui rajoute un système de type et passe par LLVM pour la compilation.

Cependant:

1) Je trouve la syntaxe de Ravi abominable lorsqu’il s’agit de rajouter les types:

1
2
3
4

local a: number[] = @number[] { 1,2,3 }
local t = { @number[] { 4,5,6 }, @integer[] { 6,7,8 } }
local a1: number[] = @number[]( t[1] )
local a2: integer[] = @integer[]( t[2] )

2) LuaJIT est nettement plus performant que Ravi actuellement dans la plupart des cas.
3) Si je décide de changer d’avis dans le futur, passer de Lua à Ravi sera nettement plus facile que l’inverse.

Quant à Python, disons que je ne suis pas un grand fan de ce langage, je n’ai pas grand chose à lui reprocher objectivement parlant, mais je ne le connais pas aussi bien que Lua (j’ai aussi des reproches à faire à Lua ne vous inquiétez pas).

La question de savoir si d’autres langages de scripts seront supportés est toujours en suspens, j’ai peur de l’impact que ça peut avoir en terme de division de communauté :-/

Merci en tout cas de l’intérêt que tu portes à ce projet ! Et n’hésite pas à participer au code si tu en as l’envie

J’aurais dû dire "j’ai ouïe dire à de nombreuses reprises que la documentation n’était pas très accessible", bien peu connaisseur moi-même, la question avait surtout pour but d’avoir ton point sur la question de "quel langage de script adopter pour mon jeu ?". Merci

Je partage ton avis pour le support de plusieurs langages, outre les grandes difficultés que cela pourrait engendrer, le "creuset" de création autour de la communauté s’en trouverait aussi assez divisé. A mon avis là où avec un seul langage il serait sûrement plus aisé à rassembler et gérer une communauté autour de celui-ci (notamment vis-à-vis de la documentation par exemple), plusieurs langages diviseront les efforts voire apporteront l’inverse d’une synergie.

Au plaisir de participer…un jour ! Mes connaissances sont bien insuffisantes pour le moment malheureusement.

EDIT (inutile de poster un 2ème message derrière) :

Pour te citer sur un sujet similaire sur OC

Pour y arriver: Le code source du jeu est intégralement disponible sur GitHub et les contributions sont encouragées. Certaines idées du jeu sont disponibles sur un site ouvert où tout le monde peut proposer ce qu’il veut. Un canal dédié au projet est disponible sur le Discord du groupe NaN (groupe de programmeurs) Le développement du jeu est en grande partie diffusé en temps réel sur la plateforme Twitch

Une licence libre pour le code me ravit ! Je me demande du coup, qu’en est il des créations graphiques, musicales (j’avais vu ceci quelque part) ou littéraires par exemple (celles directement intégrées au jeu packagé j’entends) ? Qu’acceptes-tu de la part de la communauté ? Licence similaire copyfree uniquement ? Autre ? Bref, encore une fois qu’elle est ta vision des choses  ?

Je suis assez d’accord, et c’est pour ça que je suis assez tiraillé sur la question, et que je préfère un langage unique que plusieurs langages.
De toute façon, un programmeur sera amené dans sa vie à utiliser plusieurs langages, donc c’est presque un faux problème.

Alors je ne me suis pas encore posé vraiment la question, pour ce qui est des musiques il faut que j’en parle au musicien (que ça risque de surprendre d’apprendre que le développement d’Utopia a été démarré pour de bon ).

Pour ce qui est des créations graphiques/auditives/etc., je pense respecter le choix de l’artiste, il n’est pas impossible que j’achète par exemple des modèles sur des sites de vente pour les intégrer au jeu, avec du coup l’obligation d’encoder le modèle d’une façon à ce qu’il ne soit pas retrouvable librement (donc avec un format de mesh propriétaire etc.).
Donc si un artiste souhaite faire un modèle pour le jeu qui resterait au niveau du jeu, je respecterais son choix, tout comme s’il souhaite que son modèle soit distribué librement sous une certaine licence.

Pour ce qui est des créations littéraires, c’est autre chose. Il faut savoir qu’en 2009 (au premier lancement du projet) on avait lancé un wiki pour que chacun puisse contribuer au lore de l’univers (car il y a vraiment un scénario, un univers, je ne le mets pas en avant actuellement tout simplement), et il y avait du très bon dessus.
C’est un concept que je pense réintroduire, et là par contre il faut que je puisse les utiliser pour les intégrer en jeu (par contre on peut imaginer un chiffrement asymétrique pour les protéger: ça évite que des fouineurs puissent y avoir accès ).

En fait l’une des idées du jeu c’est aussi de pouvoir explorer la galaxie à la recherche d’une histoire manquante, le personnage incarné par le joueur est en effet en quelque sorte "amnésique"

Mais on est encore un peu loin d’avoir un jeu où ça devient intéressant d’intégrer le scénario prévu, mais dans pas si longtemps je ne serais pas contre de rouvrir un wiki collaboratif pour étaler un peu l’univers du jeu.

À voir du coup

J’espère avoir répondu à tes questions.

Faux problème si on ne s’adresse qu’aux programmeurs effectivement. Je pense aussi aux programmeurs du dimanche qui touchent pas 36 langages, s’il y en a plusieurs, s’intégrer à la communauté peut peut-être se retrouver plus difficile que se concentrer sur un seul langage comme le lua qui est en fin de compte bien courant dans le jeu vidéo en somme. Qui sait ? C’est juste une pensée comme ça.

Des sources accessibles ne signifie pas qu’on a le droit de les utiliser ou les modifier, c’est un faux problème (ou un autre problème en tout cas), toute la différence entre opensource et libre en fait, c’est plutôt une question de droits délivrés par l’auteur (on a toujours la source d’un livre que l’on achète, son texte, ça ne donne pas pour autant les droits sous-jacents à une licence libre) et c’est pourquoi je me pose la question car, je suppose, si tu sors une release, il y aura bien du code et du contenu artistique packagés ensemble. Le code sous licence libre copyfree se package très bien avec du propriétaire sur une licence propriétaire et se pliant aux conditions de la licence propriétaire, c’est là tout le sens de ma question. Je suppose que si tu ne souhaitais rendre le jeu disponible qu’en échange d’argent sonnant et trébuchant, tu n’aurais pas choisi une licence libre copyfree (dis moi si je me trompe !) donc si tu souhaites distribuer aussi le jeu gratuitement, les différents "choix de l’artiste" doivent être compatibles avec cette volonté. Mélanger tout ça est possible mais réclame une réflexion à la base poussée et une relation claire avec les contributeurs sur ceux qu’ils peuvent apporter a priori. C’est vraiment un problème récurrent autour des projets collaboratifs qui nécessite souvent de se régler dès la base pour trouver une cohérence et éviter des dissensions un jour.

Hâte de découvrir le lore existant alors un système de wiki a déjà fait ses preuves. En revanche, j’ai du mal à te suivre sur ce que tu protègerais ("on peut imaginer un chiffrement asymétrique"), en jouant, le joueur a bien accès au lore d’une certaine façon ?

(A propos, j’ai déposé une idée sur le site que tu as fourni, je la vois sur mon compte mais ne la vois pas apparaître).

Je disais faux problème dans la mesure où un programmeur s’adapte justement facilement à un autre langage, et aussi que Lua est un langage vraiment très facile à apprendre.

Oui le jeu sera gratuit, parce que le thème est suffisamment de niche pour que ça soit du suicide commercial et parce que mon objectif en faisant ce jeu est avant tout de réaliser un vieux rêve, pas d’engranger de l’argent.
Après, évidemment, je ne vais pas cracher sur une source de revenu financière, et gagner de l’argent "à la sueur de mon front" est une idée assez glorifiante.
Donc la seule chose que j’ai envisagé jusqu’ici, financièrement parlant, c’est de vendre des cosmétiques, des effets, des modèles de vaisseau, et autres. Rien n’ayant un impact en terme de gameplay (j’ai une sainte horreur des pay2win, coucou EA).

Mais du coup, si un modéliste (par exemple) souhaite vendre son modèle à travers le jeu, je n’ai rien contre.
Mais très honnêtement on est encore très loin de ce genre de questions.

Une des idées du jeu, comme je l’ai dit, c’est de redécouvrir une histoire perdue à l’aide, notamment d’exploration.
Quand je t’ai parlé de chiffrement asymétrique, j’imaginais une façon d’avoir tous les médias intégrés au client mais chacun encrypté avec une clé détenue par le serveur, faisant donc en sorte que tant que le joueur n’a pas atteint un endroit spécial, le serveur ne lui permet pas de décoder le contenu.
Dans le cas d’un texte, on s’en fout car c’est suffisamment léger pour que le serveur puisse l’envoyer à chaque fois, mais si on décide d’intégrer d’autres ressources (des images, vidéo, extraits sonores, etc.) alors ça deviendra utile.
Mais concrètement c’est surtout un détail technique pour éviter qu’un joueur n’ait qu’à fouiller son dossier de jeu pour découvrir toute l’histoire.

Oui effectivement, j’ai découvert que je dois valider chaque idée soumise, il faudrait que j’arrive à désactiver ça
J’ai mis en ligne ton idée

Pour reprendre mon premier message, Leekwars a réussi grâce à son langage qui était proche du java/C/javascript/python… Tout le monde était familier avec la syntaxe du leekscript.

Donc le choix du langage est essentiel. Le lua est un peu a l’opposé de cette syntaxe/logique et en nombre d’adepte.

J’ai eu l’occasion de faire plusieurs addons en lua pour des jeux. Je ne m’y suis jamais vraiment habitué. Peut-être l’environnement du jeux qui ne favorise pas l’image du lua. Je trouve le lua particulier dans son utilisation et sa logique qui nous ralentit dans la conception du code.

Peut-être que ton jeu va me faire changer d’avis. J’ai hâte. Et j’espère qu’il y aura des versions alpha tout au long du développement.

D’accord à ton niveau, il y a les systèmes de dons qui peuvent fonctionner (liberapay pour rester en France, ou autre), ça rapporte rarement de quoi gagner sa croute mais qui sait ? Tout à fait logique pour les assets que l’utilisateur peut ajouter au jeu (ça apporte l’information que c’est envisagé, super  !) mais ma question était surtout vis-àvis des assets de base packagés au jeu, car en fin de compte, c’est d’eux que dépendra les conditions de l’ensemble si je suis bien ta réponse initiale. C’est là que c’est un peu flou, ça l’est surement encore un peu pour toi aussi.

Aaaaah ! J’avais pas du tout compris ainsi ! Effectivement, ça peut ralentir mais en soi, tu n’empêcheras ceux vraiment tenté de fouiller les commit ou les plus avancés de spoiler sur la toile, je pense que quelqu’un souhaitant conserver la surprise fera attention, n’est-il pas ?

Ah merci beaucoup !

Si tu considères que Java, C, JS et Python sont proches, je ne vois vraiment pas ce qui fait que Lua en est éloigné par contre.

Par exemple, ce code en Leekscript (tiré du tuto sur les conditions):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

var myCell = getCell();
var enemyCell = getCell(getNearestEnemy());

if (lineOfSight(myCell, enemyCell)) 
{
    debug("J'le vois chef ! J'le vois !");
}

if (!lineOfSight(myCell, enemyCell)) 
{
    debug("Ou est t-il passé !? Il se cache ce poltron !");
}

et son équivalent Lua (pur):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

local myCell = getCell()
local enemyCell = getCell(getNearestEnemy())

if (lineOfSight(myCell, enemyCell)) then
    debug("J'le vois chef ! J'le vois !")
end

if (not lineOfSight(myCell, enemyCell)) then
    debug("Ou est t-il passé !? Il se cache ce poltron !")
end

Ça reste la même logique, les blocs ne sont plus délimités par {} mais par un mot-clé spécifique (then/do) et end, le not s’exprime par un … "not" (comme Python pour le coup).

Je trouve justement que Python a une syntaxe beaucoup plus éloignée de tout le reste que les autres, notamment parce que les espaces blancs ont une importance capitale dans le code (là où les langages "classiques" s’en moquent), et où tu peux spécifier les arguments dans un autre ordre que la déclaration de la fonction.

Bref tout ça pour dire que je trouve finalement que Lua est assez proche des langages classiques, mais il faut reconnaître qu’il existe des points où Lua est un cas particulier un peu particulier, surtout au niveau:

1. De l’opérateur de comparaison "!=", qui s’exprime "~=" en Lua
2. Des commentaires courts qui se font avec -- et commentaires longs avec --[[ ]]
3. Du fait que les tableaux n’ont pas d’indice commençant à zéro mais à un.
4. Les variables sont globales par défaut et il faut utiliser le mot-clé local pour les rendre globales
5. Accéder à une variable inexistante en Lua n’est pas une erreur et renvoie le type nil

Les deux premiers points peuvent se contourner facilement en éditant le lexer de Lua ou même celui de LuaJIT, pour rajouter "!=" et "/* */" en commentaire (// est utilisé depuis Lua 5.3 pour une division entière par contre), et les trois autres points sont une spécificité du langage, et je dirais qu’on s’y habitue, simplement.

L’avantage de Lua étant surtout qu’il est vraiment facile à prendre en main, et reste assez puissant en prime.

N’hésite pas à argumenter cette position, je t’avoue que j’ai du mal à voir ce qui peut te ralentir dans ce langage du coup.

Il faut aussi relativiser dans la mesure où Lua est un langage un peu particulier dont la tronche change d’un programme à l’autre (je trouve que faire un addon pour WoW est particulièrement horrible et scripter GMod est assez bien fichu par exempel, pourtant c’est le même langage).

Je distribue très régulièrement des démos client aux personnes qui suivent le développement sur Twitch, ça permet de suivre l’évolution en temps réel de façon interactive (par exemple hier j’ai ajouté la physique et on a tous pu se bumper dedans ).

Mais à partir d’un moment, je ne sais pas encore exactement quand, je vais passer sur un système où le serveur tourne sur mon dédié et où chaque joueur pourra utiliser un launcher capable de détecter une nouvelle version et de la télécharger automatiquement (chose qui est déjà en place).
Mais ça va attendre au moins le prototype 3 (prévu pour mi-décembre).

Pour les assets de base, c’est la même logique, si j’utilise un modèle gratuit et dont la licence me permet de le redistribuer, alors je le laisse dans les assets dans un format facilement décodable. En revanche si le modèle est payant et que la redistribution sous format non-propriétaire est interdite (ce qui est systématique quand c’est payant), alors même stratégie que celle décrite plus haut, j’encode ça dans mon propre format propriétaire.

Attention qu’ici il ne s’agit pas de code mais de data, donc ça n’a pas forcément sa place sur GitHub, avoir un code ouvert ne signifie pas que l’entièreté de la base de donnée du serveur sera disponible également, précisément pour protéger certaines choses.
Quant aux assets (les données type graphique), je peux du coup les fournir déjà chiffrés avec la clé de déchiffrage bien au chaud dans la base de donnée

ok

ok, c’est bien plus clair ainsi

J’en profite pour faire un rapide point sur ce qui a été fait dernièrement: l’ajout des armes et de la vie.

Le développement avance à bon rythme, même si l’aspect WIP est encore très présent (que ça soit au niveau des graphismes, des contrôles ou même d’un ballon de foot spatial ! ).

En ce moment je travaille surtout sur l’intégration de l’extrapolation, une technique de synchronisation entre le serveur et le client prenant en compte la physique, et c’est compliqué.

Je précise aussi qu’exceptionnellement le prochain stream aura lieu non pas mercredi mais jeudi à 18h, et qu’il risque d’il y avoir deux stream ce week-end au lieu d’un. !

Salut à tous !

Hier soir s’est achevé le dernier live Twitch de développement de l’année, qui reprendra après une pause de deux semaines (reprise la première semaine de janvier).

Pour l’occasion, deux choses ont étés faites: - Le serveur d’Utopia tourne maintenant de façon permanente, vous pouvez vous connecter à n’importe quel moment sans problème - Un scripting côté client est maintenant disponible ! Tous les contrôles ont été migrés sur un script .lua qui sera chargé par le jeu (et rechargeable avec un appui sur la touche F5).

Le client est téléchargeable ici !

Le scripting peut faire de nombreuses choses avec une API documentée, n’hésitez pas à bidouiller.
Vous pouvez notamment afficher les sprites de votre choix, décider des mouvements du vaisseau, positionner la caméra, faire un scan et récupérer la position/rotation de toutes les entités du serveur, etc.

Vous pouvez également télécharger une petite lib faite par DragonJoker à l’occasion:https://github.com/DigitalPulseSoftware/Erewhon-Game/releases/download/v0.16/Scripts.zip

Je précise que le scripting tel quel est fait à l’arrache, et que l’API va totalement changer quand ce sera fait sérieusement. Sans oublier que le scripting tel quel est uniquement client-side, alors qu’il est principalement voulu server-side (mais le scripting-client side existera pour scripter vos propres contrôles/interface).

J’attends vos retours !

Je suis d’assez près ce projet, et j’attends avec impatience que le scripting soit assainit et granit d’une doc est-ce que tu aurais une idée d’une vague date à partir de laquelle l’API de scripting serait refaite?

C’est justement la tâche actuellement en cours La nouvelle API est orientée sur des modules, que tu pourras changer lors de la conception de ton vaisseau, avec une classe centrale représentant ton vaisseau de façon plus abstraite. (dans des soucis de simplicité).

Une fois qu’elle sera un peu plus mature, je mettrais en place une petite documentation pour l’utiliser, comme j’ai fait pour le scripting client (mais en un peu plus construit ).

Quant au scripting client (qui sera refait intégralement), je ne sais pas encore quand je vais m’y atteler, je pense qu’on va avoir pendant un moment une notion de court-circuitage (où le fait qu’un joueur prenne le contrôle d’un vaisseau annule son script serveur), c’est moins urgent de l’avoir.

Donc pour répondre à ta question, ça devrait venir assez vite, dans le courant du mois de février je pense avoir quelque chose de relativement stable.

J’en profite aussi pour souhaiter la bonne année, vous remercier du support que vous faites au projet, je pense que je ferais un message récapitulatif bientôt.

J’en profite aussi pour annoncer que le prochain live aura lieu dans trente-cinq minutes, justement sur les scripts serveur