Le moteur de Serious Sam passe à l'open source

Le moteur de Serious Sam passe à l’open source

Quake 3 > All

Avatar de l'auteur
Kevin Hottot

Publié dans

Logiciel

14/03/2016 2 minutes
40

Le moteur de Serious Sam passe à l'open source

Croteam vient de publier les sources de son Serious Engine, le moteur de jeu développé pour le premier volet de la saga Serious Sam. De quoi permettre à bon nombre de développeurs de disposer à peu de frais d'un moteur robuste pour leurs expérimentations.

Il n'est pas rare que les studios de développement libèrent une partie de leurs technologies afin d'en faire profiter le plus grand nombre. On se souviendra ainsi qu'en 2005 John Carmack « himself » avait annoncé lors de la QuakeCon la publication des sources de l'id Tech 3, le moteur de Quake III Arena, sous licence GNU GPL v2.

Depuis plusieurs moteurs ont ainsi été « libérés ». L'id Tech 4 de Doom 3 a vu ses sources publiées sous licence GPL v2 en novembre 2011, OGRE, le moteur utilisé pour Torchlight II est lui aussi publié sous licence MIT, tout comme Torque depuis septembre 2012, connu pour son utilisation dans Tribes 2.

Croteam, le studio croate à l'origine de Serious Sam vient d'ajouter un nouveau membre à la liste des moteurs dont les sources ont été ouvertes : le Serious Engine. Ne nous emballons pas, il n'est ici question que de la version 1.10 du moteur, celle utilisée pour le tout premier volet de Serious Sam sorti en 2001. Ne vous attendez donc pas à pouvoir profiter de toutes les possibilités de la version 4, employée pour The Talos Principle.

Les sources du Serious Engine 1.10 sont disponibles sur GitHub et sont publiées sous licence GPL v2, à l'exception de deux éléments : zlib et le SDK de LightWave qui requièrent une attention particulière avant d'être réutilisés. CroTeam précise avoir retouché son moteur afin d'en assurer le fonctionnement sous Windows 7, 8 et 8.1 dans leurs variantes x64.

Écrit par Kevin Hottot

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Commentaires (40)


Hvala


“Hé maman, t’a vu? Je suis un vrai ptit bucheron”



Il auraient au moins pu liberer celui de SS2, voire 3


+1  Comment se faire de la pub à 0 frais en sortant un moteur d’il y a 15ans opensource.


c’est bien sympa d’ouvrir les sources, mais il nous faut aussi la doc. Par exemple, j’ai regardé un peu et j’arrive pas à savoir où se trouvent les fichiers concernant l’IA.








gokudomatic a écrit :



c’est bien sympa d’ouvrir les sources, mais il nous faut aussi la doc. Par exemple, j’ai regardé un peu et j’arrive pas à savoir où se trouvent les fichiers concernant l’IA.







Mais surtout, est ce que ca tourne sur FreeBSD ? ;)



BSD rullz the world








gokudomatic a écrit :



c’est bien sympa d’ouvrir les sources, mais il nous faut aussi la doc. Par exemple, j’ai regardé un peu et j’arrive pas à savoir où se trouvent les fichiers concernant l’IA.





en meme temps l’ia de serious sam ça doit se resumer à un truc du genre :



while(1) { monster.run(player.position); }



Le cas échéant, on se démerdera avec une machine virtuelle.


Justement, peut être que gokudomatic veut juste remplacer ce bout de code par une vrai AI !!








PtaH a écrit :



Mais surtout, est ce que ca tourne sur FreeBSD ? ;)





<img data-src=" />



tu ne te rappelles pas des taureaux qui tournent au lieu de te foncer dessus?

De plus, je peux témoigner, vu que je suis en plein développement d’un doom-like, que des trucs qui semblent évidents ne le sont pas tant que ça. J’ai un mal fou à faire détecter les trous et à les éviter. Parce que bon, foncer sur le joueur, ça va juste faire tomber le monstre dans le premier trou venu. Et le but n’est pas non plus de mettre des murs invisibles partout.


Est-ce qu’il tourne sous Free BSD ton Doom-Like ? <img data-src=" />


Bien sûr. <img data-src=" />

Mais j’ai pas essayé. J’utilise pas ce genre d’OS exotique.


Des IA comme on n’en fait plus malheureusement…<img data-src=" />


il manque toujours un élément crucial pour faire un visage réaliste, la sueur, dans beaucoup de nouveau jeux, les perso on dirait qu’ils vienne tout juste de sortir de la douche&nbsp;<img data-src=" />



je veux dire par là, que ça matifie la peau.


“Depuis plusieurs moteurs ont ainsi été&nbsp;« libérés ». L’id Tech 4 de Doom 3&nbsp;a vu ses sources publiées sous licence GPL v2&nbsp;en novembre 2011, OGRE, le moteur utilisé pour Torchlight II&nbsp;est lui aussi publié sous licence MIT, tout comme Torque depuis septembre 2012, connu pour son utilisation dans Tribes 2.”



&nbsp;Petite rectification, OGRE 3D est un moteur de rendu graphique Open Source qui depuis sa création n’a jamais eu vocation de faire spécifiquement des jeux.

L’équipe fournit un moteur graphique et cela s’arrête là, après il existe des plugins pour y coupler du son, un moteur physique, …



Mais ce n’est pas l’équipe de Torchlight qui a pondu le moteur,&nbsp; ils l’utilisent simplement :-)


Haaa Serious Sam ;-).. du coup j’ai ressorti Total Annihilation des cartons pour m’en taper une petite partie en&nbsp;skirmish contre 3 IA… toute une époque ;-)


aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&nbsp;



Rien d’autre à dire








gokudomatic a écrit :



c’est bien sympa d’ouvrir les sources, mais il nous faut aussi la doc. Par exemple, j’ai regardé un peu et j’arrive pas à savoir où se trouvent les fichiers concernant l’IA.





IA et Serious Sam, sérieux ?

Tu es d’humeur joueur aujourd’hui.





cadeau voici le code :

while (!me.active) {

me.active = me.isSeriousSamVisible()

}

while (! me.isDead())

if me.inAmmoRange(seriousSam) {

shoot(me.direction(seriousSam))

}else{

me.moveTo(seriousSam)

}



“HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!!! ”

Beheaded Kamikaze - Serious Sam



et s’il y a un ravin entre l’IA et moi, avec un pont 10 m plus loin, il fait quoi?


Du A comme dans “AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA !!” ?








ced5729 a écrit :



en meme temps l’ia de serious sam ça doit se resumer à un truc du genre :



while(1) {&nbsp;monster.run(player.position);&nbsp;}





beheaded kamikaze forever



Et OGRE est open source depuis sa création, en 2001.


sauf que SS n’est pas un jeu 2d quadrillé. De plus, j’ai essayé ça et le résultat était plus proche d’une poursuite dans benny hill au ralenti (surtout quand il tourne sur lui-même) qu’un vrai chemin optimisé. Et il tombait quand même par moments. Donc l’IA n’est pas si simple que vous le dites.


Ah, il me semblait que le code de l’IA de Serious Sam est désormais le modèle du genre. <img data-src=" />





AAAAAAAAAH yourself ! <img data-src=" />








gokudomatic a écrit :



sauf que SS n’est pas un jeu 2d quadrillé. De plus, j’ai essayé ça et le résultat était plus proche d’une poursuite dans benny hill au ralenti (surtout quand il tourne sur lui-même) qu’un vrai chemin optimisé. Et il tombait quand même par moments. Donc l’IA n’est pas si simple que vous le dites.







J’ai pas souvenir que les monstres cherchent particulièrement à éviter les trous en fait. Dans mes souvenirs ils butent sur un mur invisible au bord du ravin qui leur signale de ne plus avancer et tombent s’ils sont poussés (ou en fonction des distances de freinages pour les taureaux et les Kleers par exemple).



Et l’algo de calcul de chemin est super basique, parce qu’il me semble qu’il est assez facile de coincer les monstres sur une plateforme en se plaçant dans un angle qui fait qu’il ne vont pas penser à passer par le pont.





Bon après, c’est des souvenirs un peu vagues, j’ai pas touché au Serious Sam d’origine depuis la sortie des rééditions HD.



Pour la 2D, c’est un faux problème, a la fois parce que pour la plupart des mob, il ne se déplace que sur le sol donc si l’on ne considère qu’il n’y a qu’un seul plan par axe de hauteur, ça s’applique sans réfléchir plus que ça, et même si il y a plusieurs plan, en faite, ça ne change pas tant que ça (tu adapte ça à un mesh plus qu’à un quadrillage simple). Et dans enfin, même si c’est en 3D, l’algo fonctionne quand même, il est générique et n’est pas dépendant de ce genre de problème, il fonctionne même en 4 dimension.



As-tu vraiment jouer à Serious Sam, l’IA est un copié collé de celle de Doom, elle est même moi développée, dans Doom elle devait choisir une cible qui pouvait être autre chose que le joueur. C’est pas pour rien que la déplacement de base c’est le strap sur le coté en tournant.








gokudomatic a écrit :



sauf que SS n’est pas un jeu 2d quadrillé. De plus, j’ai essayé ça et le résultat était plus proche d’une poursuite dans benny hill au ralenti (surtout quand il tourne sur lui-même) qu’un vrai chemin optimisé. Et il tombait quand même par moments. Donc l’IA n’est pas si simple que vous le dites.







Si l’IA était quelque chose de simple ça fait longtemps que ça se saurait, c’est sans doute l’un des domaine les plus pointu de la programmation.



Je sais pas avec quoi tu développe mais il vaut mieux utiliser un moteur complet, genre unity3D. Il a des fonctionnalité pour gérer des formes d’IA mais c’est chaud de tout bien faire interagir avec la physique souhaitée et l’IA quand on teste en amateur. <img data-src=" />



S’il n’y avait vraiment qu’un seul plan par axe de hauteur, ce serait effectivement copier-coller de doom et ce serait vraiment simple. Mais j’ai souvenir qu’il y a des plateformes dans SS. Je pense notamment au niveau avec les maisons dans les arbres et des ponts partout. Mais peut-être ont-ils rusé sur cela.








after_burner a écrit :



Si l’IA était quelque chose de simple ça fait longtemps que ça se saurait, c’est sans doute l’un des domaine les plus pointu de la programmation.



Je sais pas avec quoi tu développe mais il vaut mieux utiliser un moteur complet, genre unity3D. Il a des fonctionnalité pour gérer des formes d’IA mais c’est chaud de tout bien faire interagir avec la physique souhaitée et l’IA quand on teste en amateur. <img data-src=" />





Avec Godot, et c’est un choix surtout politique (libre, toussa). Et il a un système de recherche de chemin en 3d, mais comme je disais, il calcule des chemins vraiment bizarres.









gokudomatic a écrit :



Avec Godot, et c’est un choix surtout politique (libre, toussa). Et il a un système de recherche de chemin en 3d, mais comme je disais, il calcule des chemins vraiment bizarres.







Ok <img data-src=" />, je connaissais pas.



Comme je t’ai dit, tu peut quand même considérer non plus un plan 2D euclidien, mais plutôt une surface aux formes complexes avec des “branche” qui peuvent se superposer, l’algo fonctionne très bien dessus et au pire tu calcules une distance euclidienne dans le modèle 3D pour la base heuristique.



edit : en faite, ça fonctionne sur un graph quelconque, une grille 2D est juste un graph bien particulier.


Si j’ai bien compris, tu parles du système utilisé dans HL1, avec son graphe de nœuds/waypoints. C’est peut-être ce qu’ils utilisent dans un terrain plein de couloirs et ponts. Mais pour les espaces ouverts, ça ne marche pas. Peut-être SS utilise un type de recherche de chemin spécifique par niveau.


et c’est un peu son plus gros problème. Il est trop méconnu pour vraiment décoller.


Je ne sais pas trop. Je ne suis pas sûr.



Mais voilà comme je vois les choses (dans la façon simple, mais ça peut être rafiné). Tout d’abord tu places les noeud de ton graph, ceux-ci sont tous les bords d’objet infranchissable(coins des murs…) le mob et le joueur. Maintenant, de ces noeud, tu place un arc entre chaque nœud qui est possible de passer directement (sans croiser donc un mur infranchissable).

Maintenant, tu applique la première partie de l’algo de l’A* avec une distance euclidienne en 3D en partant du joueur sur tout les nœuds. Il ne te reste plus qu’à appliquer le reste en considérant le graph que tu as construit (Dijkstra s’applique aussi, mais il est un peu lourd).



Tu peux gagner du temps en précalculant les noeuds, les arcs et leur poids associés au terrain. A voir si c’est intéressant, mais tu peux aussi limiter la taille des arc et mettre des nœud intermédiaires (ça peut peut-être simplifier le calcule dans le cas d’un A* je pense), tu peux encore plus affiner ce dernier point en considérant que les arcs associé au joueur ne sont, eux, pas compressibles (quelque soit la distance, l’arc d’un noeud vers le joueur existe dès qu’il est possible). Ensuite, et ça je pense que c’est fait dans plein de jeu, tu limites la recherche de chemin, si au bout d’un certain temps il ne trouve rien, tu arrêtes la recherche et tu fais déplacer ton mob par le chemin qui a donner le meilleur résultat, ça permet de ne pas se bloquer quand le chemin est trop complexe ou inexistant (on vois par exemple dans SS les mob qui se colle sur le mur en contrebas lorsqu’ils n’arrives pas a t’atteindre).

Sinon, toujours dans les nœuds et les arc, tu peux aussi avoir différent niveau de granularité, avec par exemple un niveau “global” qui ne considère que les “portes” (l’entrée d’un pont par exemple) des pièces comme des noeuds et des chemin prédéfini d’une porte à une autre dans la même pièce.



Bon, le pathfinding dans les jeu vidéo, c’est une problématique récurrente. Ce que je te donne là, c’est ce que je ferais personnellement sans documentation.


Ce que tu décris ressemble bien à ce que fait le Source Engine dans HL1. Mais sa grosse faille est qu’il est inadapté pour les grands espaces ouverts, ce qui constitue les 90% de SS. Pour une simple plaine vide, il faudrait mettre un quadrillage de noeuds sur des km^2, et outre le fait que c’est laborieux à générer, ce n’est pas vraiment performant. J’ai lu qu’il y a une version améliorée de l’algorithme qui est adapté à des volumes au lieu de simples noeuds. Et c’est ce qu’utilise godot, bien que le résultat soit pas toujours terrible.



Personnellement, et vu que j’avais déjà implémenté l’IA de doom pour les monstres volants, je me tatais dans l’idée de simplement mettre un senseur de trou à proximité de l’IA. Et quand le senseur ne détecte pas de collision, il part en sens inverse. En ajoutant à cela le pathfinding intégré de godot qui donne la direction générale, ça pourrait le faire. Mais pour être efficace, il doit avoir au moins 5 senseurs pour couvrir les divers angles possibles pour tomber dans un trou. Et personnellement, j’ai un bad feeling de mettre des tas de senseurs juste pour un monstre. S’il y a 100 monstres dans le terrain, ça fait au moins 500 senseurs qui bossent à chaque frame, souvent pour rien. Doom n’avait pas ce problème vu qu’une simple fonction (x,y) donnait la hauteur.


Mais un ravin, ça doit être considéré par l’IA comme un mur infranchissable ? Godot doit bien avoir l’équivalent d’un mur pour l’IA qui n’est pas un mur pour le moteur physique, non ?



Sinon, pour le cas des grandes plaines, j’essayerais un peu l’équivalent de la tesselation autour du joueur pour les noeud (affine le chemin sur des distance proche, donner des chemin tenant compte d’un modèle très grossier du terrain sur des distance lointaine quite à passer à 4m du ravin on s’en fout).







Le développement de jeu, je ne connais pas du tout. Une IA doit-elle absolument être aussi régulièrement mise à jour ? Ne peut-elle pas juste décider dans combien de temps il faut qu’elle mettent à jour son comportement en fonction de différent critère comme la distance du joueur, son état d’alerte… ?








tazvld a écrit :



Mais un ravin, ça doit être considéré par l’IA comme un mur infranchissable ? Godot doit bien avoir l’équivalent d’un mur pour l’IA qui n’est pas un mur pour le moteur physique, non ?





C’est possible. J’ai créé de tels murs pour faire des tests (je voulais qu’ils restent confinés dans une région). Mais je n’ai pas envie de devoir implémenter dans le level design des murs pour tous les trous. C’est source de problèmes sans fin. Les monstres qui volent ne doivent pas être bloqués par le mur. Ils doivent aussi pouvoir aller sur une plateforme mobile, mais seulement quand elle est présente. Que d’exceptions à gérer.







tazvld a écrit :



Sinon, pour le cas des grandes plaines, j’essayerais un peu l’équivalent de la tesselation autour du joueur pour les noeud (affine le chemin sur des distance proche, donner des chemin tenant compte d’un modèle très grossier du terrain sur des distance lointaine quite à passer à 4m du ravin on s’en fout).





En effet.







tazvld a écrit :



Le développement de jeu, je ne connais pas du tout. Une IA doit-elle absolument être aussi régulièrement mise à jour ? Ne peut-elle pas juste décider dans combien de temps il faut qu’elle mettent à jour son comportement en fonction de différent critère comme la distance du joueur, son état d’alerte… ?





L’optimisation est indéniablement primordiale. Chaque opération économisée quand c’est acceptable est intéressante. Donc c’est vrai que certaines tâches lourdes, tel que le calcul de trajectoire, ne se font que toutes les x secondes. Mais l’IA doit de toutes façons constamment recalculer sa vitesse et faire le déplacement à proprement dit, incluant les glissement contre les murs en cas de collision.

Mais ceci mis à part, dans godot et contrairement à la majorité des moteurs de jeux, il y a des objets fournis par le framework qui font leur petite cuisine à chaque frame. Vu que c’est compilé en C, c’est le plus performant, mais ça peut vite devenir un piège à débutant en terme de performance. Les senseurs dont je parlais en sont un exemple. Un seul senseur est très performant pour détecter s’il y a collision, mais 500 le sont nettement moins. Et malheureusement, dans mon algorithme j’ai besoin que tous les senseurs soient actif pour réagir rapidement à la présence d’un trou. Car tomber ne serait-ce qu’une seule fois n’est pas acceptable.









gokudomatic a écrit :



C’est possible. J’ai créé de tels murs pour faire des tests (je voulais qu’ils restent confinés dans une région). Mais je n’ai pas envie de devoir implémenter dans le level design des murs pour tous les trous. C’est source de problèmes sans fin. Les monstres qui volent ne doivent pas être bloqués par le mur. Ils doivent aussi pouvoir aller sur une plateforme mobile, mais seulement quand elle est présente. Que d’exceptions à gérer.







Hum… L’exception ici, c’est plutôt les monstre volant, et eux doivent justement ignorer les murs “de ravin”. Mais sinon, oui, effectivement, je vois un peu le problème des plateformes mobiles. Cela demande de rendre le mur “de ravin” franchissable lorsqu’il ne représente qu’une certain épaisseur , ça doit être possible de faire ça, mais long.







gokudomatic a écrit :



L’optimisation est indéniablement primordiale. Chaque opération économisée quand c’est acceptable est intéressante. Donc c’est vrai que certaines tâches lourdes, tel que le calcul de trajectoire, ne se font que toutes les x secondes. Mais l’IA doit de toutes façons constamment recalculer sa vitesse et faire le déplacement à proprement dit, incluant les glissement contre les murs en cas de collision.

Mais ceci mis à part, dans godot et contrairement à la majorité des moteurs de jeux, il y a des objets fournis par le framework qui font leur petite cuisine à chaque frame. Vu que c’est compilé en C, c’est le plus performant, mais ça peut vite devenir un piège à débutant en terme de performance. Les senseurs dont je parlais en sont un exemple. Un seul senseur est très performant pour détecter s’il y a collision, mais 500 le sont nettement moins. Et malheureusement, dans mon algorithme j’ai besoin que tous les senseurs soient actif pour réagir rapidement à la présence d’un trou. Car tomber ne serait-ce qu’une seule fois n’est pas acceptable.





Je considère que le gain dû au langage n’est pas une source d’optimisation fiable. Le gain en effet n’est qu’un simple facteur multiplicatif qui est ridicule à coté de la loi de moore qui est exponentielle. Ce que tu fait un C aujourd’hui sera possible dans quelques années avec un langage de script. Le vrai gain de performance est effectivement plus dans l’algorithme qu’il faut le chercher.

C’est effectivement un problème. Mais j’ai du mal à voir ce qui différencie finalement ce problème à celui du moteur de collision qui lui fonctionne très bien. J’ai toujours l’impression d’avoir juste un cas particulier de mur dont son existence est “conditionnelle”.



https://github.com/recastnavigation/recastnavigation



J’utilise ça pour mes projets, c’est top <img data-src=" />