[Projet en cours] Un éditeur de jeu (Démiurge)

compte supprimé · Le 13/03/2007, à 21:43

le seuls deux editeurs de ce type sont:
FPS creator: pas vraiment probant.
rpg maker: no comment.

Barbatruk_tho · Le 13/03/2007, à 21:51

Jean-Luc : j'ai bien saisi la différence entre le jeu et l'éditeur de jeu. D'ailleurs un des posts précédents explique que le second utilise le premier via des scripts.
Ayant pas mal utilisé le TESCS et donc arpenté le site de Wi-wi (d'où je me suis dit que ça serait un excellent outil si ça existait sous une forme ou une autre sous Linux), j'ai toujours rencontré l'expression "éditeur de jeu" (et je crois qu'on utilise le terme aussi dans la communauté Aurora).
S'il existe une distinction technique pointue, tu te doutes bien qu'elle n'a pas atteint mes oreilles d'allergique à la programmation. A dire vrai je n'aurais même jamais pensé que les développeurs de jeu professionnels s'embêtraient à utiliser un tel outil. Je ne sais pas pour JefLord ou Link31, mais je n'ai pas pensé à autre chose que l'outil décrit trois messages plus haut.
A ce sujet je crois que le débat avait effectivement lieu entre l'éditeur de FPS imaginé par JefLord, et l'éditeur de RPG décrit par Link31. Mais je pense qu'lls pensent tous les deux à un éditeur de monde (pas un éditeur de jeu au sens "tout reprendre à zéro") ; donc je ne pense pas non plus qu'il y ait de confusion entre le deux.

Cela dit c'est une précision qui a son importance, du fait même qu'on l'ignore (enfin qu'on l'ignorait).

EDIT : Pour le TESCS et Morrowind : je viens de comprendre ce que tu veux dire. Mais il existe aussi des TC (conversions totales, qui utilisent uniquement les ressources du jeu [Outils d'édition de terrain, textures, modèles 3D, musiques, scripts, scénarios, sons] telles quelles ou en les modifiant et proposent un jeu différent de The Elder Scroll).
L'idée de base est donc de concevoir un outil qui permette, via un outil central et une base alliant moteur graphique et physique, de construire un ensemble, qui puisse ensuite être lancé comme un jeu. Il faudrait donc "presque" construire un jeu, mais sans les textures, meshes, sons et "monde", etc...
On peut donc imaginer d'avoir non pas un jeu derrière, mais des blocs de ressources diverses (qui ne nécessitent cependant pas d'avoir des compétences en programmation).

Cela dit, si je me fie à la seule idée que j'avais au départ (et qui est celle d'un néophyte en programmation, quitte à me répéter), un outil de ce type aurait probablement une "facture" propre qui serait le point commun à toutes les déclinaisons possibles.

Par contre, si j'ai bien compris, RPG maker et FPS creator seraient des éditeurs... de jeu?

Dernière modification par Barbatruk_tho (Le 13/03/2007, à 22:16)

jean-luc · Le 13/03/2007, à 22:36

Barbatruk_tho a écrit :

Jean-Luc : j'ai bien saisi la différence entre le jeu et l'éditeur de jeu.

OK

EDIT : Pour le TESCS et Morrowind : je viens de comprendre ce que tu veux dire. Mais il existe aussi des TC (conversions totales, qui utilisent uniquement les ressources du jeu [Outils d'édition de terrain, textures, modèles 3D, musiques, scripts, scénarios, sons] telles quelles ou en les modifiant et proposent un jeu différent de The Elder Scroll).

Je viens de vérifier : http://everything2.com/index.pl?node_id=81507 en fait c'est l'inverse. Ils enlèvent toutes les ressources pour ne garder que le moteur de jeu (graph, IA etc..) et mettre les leurs. C'est ce que tu veut faire, j'ai bien compris.

un outil de ce type aurait probablement une "facture" propre qui serait le point commun à toutes les déclinaisons possibles

tout a fait je vois mal faire un FPS et un JDR avec le même outils, ou même seulement 2 JDR très différents.

L'idée de base est donc de concevoir un outil qui permette, via un outil central et une base alliant moteur graphique et physique, de construire un ensemble, qui puisse ensuite être lancé comme un jeu.
On peut donc imaginer d'avoir non pas un jeu derrière, mais des blocs de ressources diverses (qui ne nécessitent cependant pas d'avoir des compétences en programmation).

Le problème c'est qu'avant de faire l'éditeur de monde, il faut un moteur de jeu (càd le jeu sans les ressources).

J'ai un peu réfléchi à ce problème. Dans le cas d'un FPS, vu tout ce qui existe et qui est relativement complet, le mieux c'est de se joindre à un projet déjà existant. Dans le cas d'un JDR c'est déjà plus chaud (a priori il n'y a rien de complet). Il faut peut être voir avec arkhart qui semble t il était bien partie et avais déjà un éditeur de monde (au moins un début).

Un truc qui pourrais être interessant (mais pas compatible avec ton idée) serait de partir d'une base de partir avec comme base le jeu "wesnoth" :

Avantages

° y a une bonne base pour commencer
- le moteur graphique existe
- "" sonore aussi
- l'IA aussi en partie
- l'interface aussi
- un éditeur de carte
- il y a déjà des scénarios
- et des règles

° c'est en 2D donc accéssible à tous
° il y a une base de joueurs

Inconvénients
° c'est pas un jdr, il y a donc du travail d'adapation à faire (ie programmation) notamment:
- des cartes plus grandes
- du temps réel à introduire
- toute l'IA concernant le roleplay

Mais je pense que l'un dans l'autre, si l'on veut faire un jdr rapidement, c'est une bonne base

jean-luc · Le 13/03/2007, à 22:43

Barbatruk_tho a écrit :

Par contre, si j'ai bien compris, RPG maker et FPS creator seraient des éditeurs... de jeu?

D'après ce que j'ai compris c'est des moteurs de jeu+un éditeur, un peut comme si on vendait morrowind+TESCS sans les graphismes, sons et scénario

Barbatruk_tho · Le 13/03/2007, à 22:58

Ce thread ne fait que discuter d'une idée, il n'y a pas de projet ni de groupe derrière (sauf pour JefLord qui programme quelque-chose d'un peu différent, apparemment).

Pour le reste, l'idée n'est pas vraiment de faire quelque-chose de rapide, mais plutôt de créer une sorte d'outil "tronc" qui permettent d'ouvrir le développement de jeux pas trop moches à plus de monde que les seuls programmeurs expérimentés (et donc de faciliter l'essor des jeux sous Linux). Les jeux de rôles 2D sont à mon avis dépassés dans ce cadre, il ne répondent pas au même besoin, celui que viserait l'instrument dont on parle (ce qui n'enlève rien à l'intérêt du projet d'une déclinaison de Wesnot par ailleurs).

Dernière modification par Barbatruk_tho (Le 13/03/2007, à 23:01)

Jef_Lord · Le 14/03/2007, à 01:16

jean-luc a écrit :

J'ai l'impression que vous faite une confusion entre un éditeur de jeu et un éditeur de monde/niveaux/scénarios

Personnellement, je ne fais aucune différence entre les deux. Après tout, un mod n'est qu'un jeu dont on bidouille un peu les règles, modifie les ressources, etc... Bref, au final qu'est ce qu'on obtient ? ... Un nouveau jeu
Pour ce qui est de l'outil, si je veux créer un "Editeur de jeu FPS" je vais évidemment créer dans un premier temps un moteur de FPS (graphique, physique, medias, etc...) qui sera éditable via un outil graphique permettant de personnaliser le moteur à sa convenance. Si je veux faire un "Editeur de jeu RPG", je ferais exactement la même chose.
Qu'il s'agisse de "tuner" un moteur existant ou bien de tout générer "from scratch", peu importe, le résultat est le même: créer un nouveau jeu facilement

Renart · Le 14/03/2007, à 19:16

Une plate-forme de création de jeu pour non prog peut-elle vraiment aboutir a qq chose de neuf ? gare a une simple synthèse d'un peu tout...
Un tel effort de programmation ne vaudrait-il pas le coup d'en faire un vrai jeu ?
J'ai des idées de scénarii, pleins (ex mg), et des sons customs (suis ingé-son, pas prog !)...

Barbatruk_tho · Le 14/03/2007, à 19:54

Renart a écrit :

Une plate-forme de création de jeu pour non prog peut-elle vraiment aboutir a qq chose de neuf ? gare a une simple synthèse d'un peu tout....

L'idée n'est pas forcément de faire quelque chose d'hyper original. On a vu pires modèles que le TESCS et Aurora, quand même...

Renart a écrit :

Un tel effort de programmation ne vaudrait-il pas le coup d'en faire un vrai jeu ?

Justement, non. L'idée est d'aider à l'essor des jeux, grâce à un outil permettant d'en créer plusieurs. Un jeu de plus en dev', ça n'a pas du tout la même portée, même si c'est intéressant en soi. Relis le thread, je pense que ça transparaît quand même au fil des posts...

Link31 · Le 15/03/2007, à 19:56

Eh bien, il y a eu des tas de réactions depuis la dernière fois que je suis passé.

Apparemment, certains ont du mal à cerner le concept. Je vais essayer de résumer un peu tout ça :

API graphique API sonore API réseau
(OpenGL ou Direct3D (OpenAL, DirectSound...) (fournie par le système d'exploitation)
pour la 3D, SDL... pour la 2D) || ||
|| || ||
|| || ||
|| || ||
\/ || ||
Moteur 3D || \/
(si présence de 3D) || Bibliothèque de fonctions pour le réseau
(Ogre3D, Irrlicht, || (SDL-net...)
Crystal Space...) || ||
|| || ||
|| \/ ||
\=============> Moteur de jeu <=================/
(Morrowind sans les ressources, Sauerbraten sans les ressources,
Freespace2 SCP, RPG_RT (moteur de RPG Maker)...)
||
||
\/
Éditeur de jeu
(éditeur de scénario dans un RTS,
éditeur de missions (FRED pour FS2...)
éditeur de mod (TESCS)
RPG Maker...)

Légende : A ===> B signifie B utilise A.

Ce que l'on veut créer : un moteur de jeu et un éditeur de jeu qui utilise ce moteur.

Le but est de créer un moteur de jeu adapté à chaque genre de jeu (quitte à en créer plusieurs, une fois qu'on sera habitué au maniement du moteur 3D et des autres bibliothèques ça ne devrait pas être trop difficile). Puis de créer un éditeur de jeu qui permette d'utiliser toute la puissance du moteur de jeu, qui offre le maximum de possibilités pour que tous les jeux ne se ressemblent pas (contrairement à un RPG Maker par exemple), tout en réduisant autant que possible le recours à la programmation (les utilisateurs les plus exigeants pourront toujours utiliser un peu de programmation avec des greffons).

C'est très ambitieux, je suis d'accord. Mais qui ne tente rien n'a rien. Et un projet libre, même mal engagé, s'améliore de jour en jour grâce aux contributions et aux rapports de bogue. C'est un peu comme un caillou rugueux, plein de bogues, qui serait peu à peu lissé jusqu'à un devenir un galet bien lisse (la version 1.0 ). Le tout est de se lancer, après on n'aura plus quelque chose à créer de toute pièces mais simplement quelque chose à améliorer, et c'est beaucoup plus facile. C'est pourquoi je pense que ce projet est réalisable

Pour essayer de répondre aux quelques messages précédents :
- Non, ce n'est pas tout à fait comme un moteur de jeu existant, qui tolèrerait les mods. Ce genre de moteur est avant tout adapté au jeu de départ, et offre généralement peu de flexibilité. Au contraire, le but dans le cas de ce projet est de créer un moteur de jeu qui offre le maximum de possibilités. Même si le moteur ne sera pas 100% adapté à chaque jeu, il sera 85% adapté à un très grand nombre de jeux qui l'utiliseront. Les concepteurs du jeu n'auront plus à inventer des moyens détournés pour faire ce qu'ils veulent, le maximum de fonctions sera intégré au moteur, et même si il sera ainsi légèrement plus lourd pour les jeux qui ne les utiliseront pas toutes, il sera plus polyvalent.

- Non, ce n'est pas la peine de créer un nouveau jeu complet, auquel le moteur serait serait probablement plus adapté, mais adapté à lui seul. Même si le jeu propose un système de mods, on retombe sur le problème évoqué juste ci-dessus, à savoir des limitations inspirées par le jeu originel. Et le but est de stimuler la création de jeux sous Linux (et sur les autres plateformes). Pour ce qui est des jeux uniques à gros moyens, il y a déjà de très bons jeux dans ce commerce, ça n'a pas grand intérêt dans l'immédiat d'en ajouter un de plus.

Dernière modification par Link31 (Le 15/03/2007, à 19:59)

Kuri · Le 24/03/2007, à 11:55

Woaaa tomber sur ce topic un samedi matin, la tete dans le cul, bein ca laisse reveur ca reveil

je suis ... nan j ai pas d autres mots pour l instant ... reveur .

je suis ni graphiste, ni programmeurs, je n ai pas non plus une imagination debordante, mais je suis fortement interesse par cette idee qui est, c est vrai, lumineuse!

tous mes encouragements pour ceux qui ont les competences pour se lancer dans ce projet, peut importe sur quel plan (idees/progs/graphisme...)

traker · Le 24/03/2007, à 12:22

Pourquoi ne prenez-vous pas exemple sur FPSCREATOR?
Un trés bon logiciel permettant de créer des jeux solo ou multi a la Quake, biensure c'est un soft Win32 mais vous pourriez en faire un Linux, en vous inspirant du dit Logiciel.

Voir demander a l'editeur s'il pense sortir une monture Linux?

Y a un grand nombre de reply mais concrétement votre projet en est ou?
Avez-vous commencé votre cahier des charges, (les options , le moteur....................)

Bonne continuation a tous

Miles Prower · Le 24/03/2007, à 16:28

Les FPS c'est réducteur je trouve, et y'en a déjà une bonne dose dans les dépôts

Jef_Lord · Le 25/03/2007, à 03:24

traker a écrit :

Pourquoi ne prenez-vous pas exemple sur FPSCREATOR?

J'ai déja évoqué l'idée plus haut dans le topic

traker a écrit :

Voir demander a l'editeur s'il pense sortir une monture Linux?

De mon point de vue, les chances sont nulles: FPS Creator repose entièrement sur DirectX.
La prochaine version reposera elle sur DirectX10, l'exclusivité Vista. Je vois mal l'équipe se fouler à faire une version OpenGL

traker a écrit :

Bonne continuation a tous

Merci

Dernière modification par Jef_Lord (Le 25/03/2007, à 03:24)

Link31 · Le 25/03/2007, à 16:56

Miles Prower a écrit :

Les FPS c'est réducteur je trouve, et y'en a déjà une bonne dose dans les dépôts

Ça résume très bien mon point de vue

Gatsu · Le 30/04/2007, à 16:17

Ce topic est entrain de mourrir. C'est dommage.
Je l'ai découvert il y a 3 mois et je trouve que c'est une excellente idée.

De mon coté, j'ai cherché un prog qui se rapprocherait du TESCS en libre, et apparemment il n'y a rien.
Donc 2 options sont possibles :
1/ attendre
2/ se sortir les doigts du c**, se cracher dans les mains, se retrousser les manches et essayer de faire bouger les choses par soi-même.

J'ai choisi l'option 2, et franchi les 3 premières étapes facilement

Je me suis donc lancé dans la prog avec pour objectif (à très long terme) de recréer une sorte de TESCS multi-genre en libre.
Ca permettra à certains game-designers de démarrer leur projet, sans se lancer dans la prog pure et dure
-> http://forum.ubuntu-fr.org/viewtopic.php?id=105385

Actuellement je me débrouille à peu près en C (arg! les pointeurs de tableau à 2 dimensions), je termine la SDL, ensuite je m'attaque au C++ et à GTK. Je suis encore loin d'être tiré d'affaire

Tout çà pour faire un petit up, et pour dire qu'il y a quelqu'un que çà intéresse

Pour savoir à quoi ressemble le TESCS c'est par ici -> http://morromods.wiwiland.net/IMG/7z/tutonuts.7z

Link31 · Le 30/04/2007, à 19:36

Le topic oui mais l'idée non. Je garde ça dans un coin pour quand j'aurai du temps.

Barbatruk_tho · Le 30/04/2007, à 19:56

Ben oui l'idée doit pas être toute neuve de toute façon

Ujoux · Le 30/04/2007, à 22:58

Je n'ai pas encore lu tous les posts (et pourtant y'a que 3 pages ) mais je voulais quand même réagir.

Créer des jeux n'est pas à la portée de tout le monde, encore moins pour les jeux en 3D.

J'avais moi aussi plein d'idées de jeux, de concepts mais j'ai du me rendre vite à l'évidence: c'est dur.
Ce serait encore plus dur de développer un éditeur de jeux multi-genres de qualité car il faudrait arriver à satisfaire le minimum de fonctionnalités pour chaque genre, autant jouer à l'euromillions si vous voulez mon avis

Sinon si vous cherchez un moteur 3D performant et cross-platform, je vous conseille Ogre3D http://www.ogre3d.org , il a déjà été cité mais j'en remet "une couche" car pour avoir analysé (sans utiliser réellement certes) pas mal de moteurs, Ogre est pour moi l'avenir et une grande opportunité pour les jeux sous linux.

Voilà, en espérant ne pas avoir cassé vos rêves, mais il faut quand même dire les choses telles qu'elles sont

Barbatruk_tho · Le 30/04/2007, à 23:01

Ujoux a écrit :

Je n'ai pas encore lu tous les posts (et pourtant y'a que 3 pages ) mais je voulais quand même réagir.
Voilà, en espérant ne pas avoir cassé vos rêves, mais il faut quand même dire les choses telles qu'elles sont

Hé... Malheureusement mieux vaut lire le thread avant de poster un avis, ça évite d'enfoncer les portes ouvertes...

miq75 · Le 01/05/2007, à 01:51

Salut a tous

- je découvre ce topic, et mon message va être long, je m'en excuse.
- je suis programmeur, en doctorat en train de créer un truc (entre autres) un peu dans le même style que ce que vous voulez faire mais dans le cadre des board games étendus (échecs, go, mais aussi belote et monopoly...)

- mes commentaires
-- Bonne idée, mais très difficile (je ne sais pas à quel point possible, n'étant pas du tout spécialisé dans le type de jeux qui vous intéresse)
-- C++ comme langage me paraît un bon choix (rapide et puissant, et les objets seront extrèmement utiles mais faites bien attention à la portabilité)
-- Link31 dans le post 66 résume bien où il me semble que vous en êtes, ne perdez pas son schéma de vue.

La difficulté maintenant me paraît être la suivante : Quelles sont les spécificités de votre moteur de jeu ?
1) Qu'il puisse gérer RPG et FPS. Utilisez le même moteur, c'est a peine plus complexe mais comme ça vous pourrez créer sans aucun problème des jeux intermédiaires entre les deux. C'est en partie le but recherché, non ?
2) Il faut définir précisément les capacités et limites de ce moteur :
Un exemple, le problème du déplacement (en 3D, vite vu, juste à titre d'exemple, a ne pas prendre en l'état) :
grosso modo je vois 3 modules à créer :
-la gestion du déplacement au sol (avec une option qui permet de saut, une autre le saut acrobatique, une autre qui affecte le sens de la gravité - affectée par défaut mais modifiable...)
-la gestion du déplacement aérien (mode ghost des fps, ou encore le jeu descent, avec une option pour traverser les murs)
-la gestion du déplacement au mur (style alien versus predator ou tremulous)
L'utilisateur du moteur de jeu pourra alors choisir dans son jeu le(s)quel(s) il voudra utiliser, et n'aura à s'occuper (presque) que de ça au niveau "définition du jeu"

Il faut
-établir le spectre des problématiques posées :
type de déplacement,
type de caméra,
type de gestion du sujet du jeu - (personnage style jdr ou personnage style rpg(avec des réglages pour les classes) ou raquette de casse brique, ou pièce de tetris),
type d'objets physiques en interaction
type de moteur de scripts
type de gestion des entrées (clavier, souris, télécommande, webcam...)
type de joueurs machines
type d'objectifs
type de score
type d'objets abstraits en interaction (délai, ...)
...
...
...
-pour chacune de ces problématique, établir la liste des modules possible, leurs distinctions, leurs options, leurs interactions entre eux

Tant que vous n'avez pas établi cette liste correctement, n'allez pas plus loin, ce serait du temps perdu (je parles d'expérience). Pour ce faire, imaginez les jeux que vous voulez pouvoir permettre, décortiquez les, analysez les et découpez les -sans oublier le moindre petit bout du jeu- en modules unitaires. ATTENTION : C'est CETTE LISTE LÀ qui qualifiera votre outil. De cette liste dépendra en effet les possibilités de jeux développée et donc tout l'intérêt de votre application. Gardez bien en tête que cette liste pourra toujours être étoffée plus tard, a condition cependant que les briques de base aient été bien dissociées.

-établissez un "langage de description d'un jeu". (Par exemple définir comment on passe d'un mode de déplacement au sol à un mode de déplacement au mur sera relatif au jeu, il faut donc permettre toutes les relations de ce type ) Programmer un jeu reviendra à (c'est un peu trop imagé) remplir le formulaire de définition du jeu.

-établissez une architecture générale pour que la combinaison de ces modules donne un jeu, et coder cette architecture.

-écrire ces modules un par un, en commençant par tout ceux nécessaires pour coder un fps bidon, puis quand ce jeu tournera, élargissez la liste des modules codés, et tentez de faire un jeu totalement à l'opposé du précédent au niveau moteur, puis complétez la liste des modules.
Vous verrez que vous penserez à d'autres modules au fur et a mesure, et plus ça ira, plus vous aurez une application complète et intéressante.

Bon courage, il y a du travail. (vous risquez de devoir modifier vos problématiques souvent, et ça impliquera souvent de refaire beaucoup de choses qu'on croyait bien ficelées avant... Mais le jeu en vaut largement la chandelle...)

Un autre conseil, organisez vous, centralisez bien, choisissez des décideurs et suivez les même si vous n'êtes pas toujours d'accord avec leur vision des choses car sinon ça partira en queue de pouêt très rapidement, vu la complexité de la tâche.

Sinon un dernier point :
Je sais que l'objectif de départ est de faire une application qui permettrait à des non programmeurs de développer des jeux. Mais vous allez tomber dans une équation terrible : facilité de codage du jeu / variété des jeux possibles. Cette équation admet 2 solutions :
-soit on limite fortement la variété des jeux possibles pour faciliter au maximum la programmation, et cela réduit d'autant l'intérêt de l'application. Cela revient pour le créateur du moteur de jeu à définir un pseudo langage, donc forcément limité.
-soit on sacrifie la simplicité du développement d'un jeu, et le créateur devra faire un minimum de programmation dans un langage courant (programmation que l'on peut lui simplifier par un usage massif de méthodes-outils), mais il aura un univers de possibilités bien plus vaste, car quand une méthode-outil ne fera pas ce qu'il souhaite exactement, il pourra en refaire une à son idée.

A mon humble avis (et c'est l'optique dans laquelle j'ai démarré et dans laquelle je me suis encore plus enfoncé au bout d'un an de développement dans mon doctorat ou un problème similaire se pose) privilégiez TOUJOURS la variété des possibilités de création, au prix parfois de la simplicité d'usage.

Au risque de me répéter (dans un message déjà trop long) : Bon courage.

miq75 · Le 04/05/2007, à 19:35

Salut,

je n'arrête pas de penser à vous.... (et c'est contre productif pour mon travail actuel...) Aussi, je me vois dans l'obligation de re-poster...

Barbatruk_tho: Ton idée est vraiment très bonne, ce serait dommage de la laisser perdre. Y a t'il une communauté qui se développe autour ? D'autre forums, un site ?

Jef_Lord: Ton site avance ? Tu devrai en faire un sur le modèle wiki, avec des liens dans tous les sens mais une page par problème/aspect du programme, c'est ce qui permettrait le mieux de faire avancer le tout de manière organisée. Sur un forum, l'évolution est linéaire de part la nature même du support. Hors on a besoin de résoudre de nombreux problèmes transverses.

sinon, j'ai commencé à faire ce que je savais faire : réfléchir aux composants du moteur de jeux.
Voilà une ébauche :de la liste des modules à prévoir : (il faudra aussi prévoir un langage d'effets indivisibles sur le jeu pour les mettre en rapport avec les commandes / interactions associées - par exemple avancer de 1 pas, activer un objet...)

Modules de déplacements possibles:
--- déplacement au sol simple (style doom)
--- gère les 4 directions (av / ar / straf gauche / droite) / 2 rotations (gauche / droite)
--- gère la possibilité de courir
--- gère la possibilité de bondir
--- gère la possibilité de se coucher / ramper
--- une option sens de gravité à défaut vers le bas, mais qui pourrait changer éventuellement
--- déplacement à plat aux sols/murs/plafons (style alien dans avp)
--- comme pour le déplacement au sol, mais
--- options pour la possibilité de bondir : retombe vers le sol, ou retombe vers la paroi la plus proche
--- étudier un mode boussole, qui éviterai de tourner en rond à cause d'un renfoncement dans le mur
--- déplacement type escalade aux murs sols plafons (style tomb raider)
--- gère les directions 4 directions de 'glisse' sur le mur
--- doit être utilisé avec un modèle évolué de représentation de personnage
--- déplacement dans l'espace (style descent)
--- gère les 6 directions (av / ar / straf gauche / droit / haut / bas) / 6 rotations (haut / bas / gauche / droite / assiette gauche / droite)
--- gère la résistance des murs : mur non traversables / qui ralentis / sans aucune gène

Modules de représentation de personnages / comportement contacts:
--- massif (style rpg)
--- juste une petite animation de pas
--- contacts avec les murs par la distance du centre du personnage
--- basé sur un squelette (style tomb raider ou jeux de combats)
--- correspond (je suppose) à un graphe dont les branches sont les positions actuelles et les arcs les étapes animées
--- contacts fins avec les points d'articulation du squelette

Modules de sortie d'information:
--- caméra (au moins une nécéssaire)
--- définie par une position de camera
--- position et direction absolue à la pièce
--- fixée à un point d'articulation (avec éventuellement un décalage) (ça inclue aussi les différentes vues possibles des simulateurs de vols par exemple)
--- gestion de la distance de vue
--- outils magiques ? (genre transparence des murs proches ?)
--- gestion du champ de vue (180°, ou plus, ou moins)
--- gestion du spectre vu / fausse couleurs (genre vision nocturne ou vision de proximité)
--- possibilité de mettre en micro camera dans un coin si ce n'est pas la caméra principale (rétroviseur dans un jeu de course)
--- carte / radar
--- absolue ou relative
--- spécifie la liste des éléments détectés
--- gère la distance de détection de ces éléments
--- avec une variante uniquement directionelle (genre senseur de proximité à la tremulous chez les aliens)
--- intégration à la vue de la caméra
--- micro map opaque dans un coin
--- en surimpression
--- interface visuelle (comme un menu quoi, qui permettrai de gérer son personnage et les objets qu'il utilise...)
--- intégration à la vue de la caméra
--- micro menu opaque dans un coin
--- en surimpression (transparent ou opaque)
--- avec ou sans camera calculée (menu de démarrage du jeu ou sélection d'équipement durant la partie)

Module d'objet de jeu:
--- Objet transportable
--- effet de l'objet (là, j'ai peur que du code soit souvent nécessaire / penser à un objet du genre agenda, il sera à associer avec une interface visuelle...)
--- avec critères de tris dans les sacs ou pas
--- type de ramassage:
--- ramassage immédiat au contact (style fps)
--- ramassage sur commande avec pointage (style rpg voleur)
--- ramassage sur 'transaction' (style rpg commerce)
--- type de réapparition:
--- spontanée (genre fps)
--- sans (genre rpg)
---Objet non déplaçable
--- effet de l'objet
--- interactions possibles (gestion de positions possibles (on/off, étage 1, 2, ou 3...)
---Objet déplaçable:
--- critères de déplacement (direction / poids, ...)

Modules de bots (permet de commander un personnage joué par une machine):
--- programmation du comportement : Là c'est plus complexe : prévoir un format de définition de bots, et quelques bots types de base (véhicule de course, tireur de fps, combatant de jeu de baston, perso de jdr). Ainsi, sur un format ouvert, s'ajouterons les bots au fur et à mesure de leur créations pour d'autres jeux.
--- réapparition:
--- spontanée (genre fps)
--- sans (genre rpg)
--- penser à des bots amis qui suivent ou on peut intervertir le perso au fur et a mesure
--- Question : Qui contrôle ces bots : un serveur si c'est un jeu en réseau (cf modules d'entrée d'information ), votre machine si c'est un jeu en local. Dans tout les cas, l'interface des bots devra être la même pour le moteur de jeux que celle des modules d'entrée d'information, du moins durant le jeu (pas pour les menus)

Modules de gestion du sac à dos:
---simple
--- une liste
---complexe
--- une arborescence, différents sacs, des critères de tri...

Module d'entrée d'information (permet de commander un personnage joué par un humain):
---clavier/souris
--- gérer l'association des touches/boutons (cf interface visuelle)
--- gérer la liste des touches/boutons utilisées par le jeu
--- gérer les options de réglages
--- gérer l'option de déplacements relatifs ou absolus
---joueur réseau
---Ce que vous imaginerez (là ça peut devenir très fort : imaginez un portage sur la wii)

Module de gestion des décors:
--- total par niveau
--- charge une fois pour toute le niveau
--- chargement continu ?
--- en fonction de la position du personnage, déchargement de certaines données au profit d'autres
--- enregistrement des altérations de décors (objets ramassée dans un jdr)
--- chargement intermédiaire
--- la map est immense et découpée en zones
--- chargement de la zone courante
--- enregistrement des altérations de décors (objets ramassée dans un jdr)

Modules de fin de partie :
--- atteindre un point géographique
--- éliminer les adversaires
---nombre de fois
--- temps écoulé
...

Bon je vous laisse, il me faut partir. Je reprendrai cette ébauche à l'occasion. (de préférence ailleurs que sur ce forum, hein Jef_Lord )

Link31 · Le 04/05/2007, à 19:58

Je me rends bien compte que faire un éditeur de jeu parfait dans tous les domaines tout en laissant un maximum de liberté à l'utilisateur est très difficile...

Que pensez vous d'un système de greffons ? Sur une base commune et solide (le moteur 3D+gestion de caméra+son+réseau...), avec un langage de script, on pourrait créer des greffons de façon à rendre immédiatement accessibles des concepts plus précis (concept : par exemple, ce que vient d'énumérer miq75). On n'entrave pas la liberté de l'utilisateur, qui peut toujours revenir au langage de script pour modifier un concept ou en créer un autre. Et surtout, et c'est le plus important, n'importe qui pourra créer un script et en faire profiter les autres. De cette façon, créer un jeu deviendra extrêmement facile : il suffira de récupérer tous les scripts qui codent pour l'aspect que l'on souhaite donner à son jeu, avec une liberté quasi-totale dans son choix. Et cette liberté pourra s'agrandir de jour en jour, à chaque fois qu'un nouveau script sera disponible.

Ce genre de moteur, si il est bien programmé et rapide, en offrant le maximum de possibilités, pourrait être quelque chose d'extrêmement puissant. Une façon de créer des jeux plus facile que ce qui s'est fait jusqu'à maintenant

Qu'en pensez-vous ?

Barbatruk_tho · Le 04/05/2007, à 20:00

Salut Miq75,

Merci beaucoup pour ton intérêt. Le problème c'est qu'il ny a pas de groupe de travail réel derrière cette idée.

Evidemment un vaste projet libre de création d'un tel projet serait effectivement une très bonne chose. Mais faut quand même avouer que l'outil dont on parle est quelque chose de particulièrement lourd et énorme. Je ne sais pas combien de temps ni combien de programmeurs ont travaillé chez Bethesda Softworks pour aboutir à Morrowind et à son TESCS...

A titre personnel, je ne peux rien faire, je n'ai malheureusement pas les compétences pour programmer. Après l'idée n'est pas de moi, c'est quelque chose qui existe depuis longtemps je pense (au moins sous Windows), peut-être que ça finira par inspirer une équipe. Ca pourrait être un projet d'étude passionnant pour des étudiants en informatique? Ou même une base pour créer un petit studio pro, je suis certain que même payant un tel soft ferait un petit carton sous Linux.

Mais bon, on verra bien.

miq75 · Le 04/05/2007, à 23:19

Je suis tout a fait d'accord avec vous

Mais pour aller plus loin, maintenant, il faut faire ça sur un wiki dédié, on doit sortir du cadre du forum ubuntu.

Dès qu'un tel wiki existera, il faudra énumérer, classer les problèmes et les résoudre un par uns, Ça prendra du temps mais ça devrait être réalisable, et je pense que le jeu en vaut la chandelle. Tous les projets commencent avec une poignée de programmeurs...

Même si je ne peut pas m'impliquer dans le codage pour l'instant (faute de temps, doctorat en cours), je veut bien vous aider à définir les modules et l'architecture principale du moteur de jeu. (Comme je l'ai déjà dit je fais un travail très similaire pour ma thèse)

A+

Gatsu · Le 04/05/2007, à 23:33

Bonjour tout le monde

@ miq75
J'ai bien lu ta liste de module à prévoir et je me permets d'y apporter quelques modifs :

Modules de déplacements possibles : ajout d'un type
---Déplacement de type nage :
---Directions : Avant/Arrière (strafe Gauche/Droite ?)
---4 rotations : Gauche/Droite/Haut/Bas
---Mode plongée -> même principe que déplacement dans l'espace mais ralenti

Modules de représentation de personnages :
oublie le style massif (RPG) je ne sais pas réellement ce que tu veux dire par là, mais une gestion à la tomb raider est suffisante.
---Plusieurs styles de caméra switchable en jeu (ou blocage à partir de la création du monde/jeu):
---Vue à la 1ère personne : 2 bras + outil/arme
---Vue à la 3è personne : 2 gestions de caméras
---Mode poursuite : caméra toujours à l'arrière du perso et zoom +/-
---Mode fixe : caméra fixe par rapport au décor et zoom +/-
---Mode visée : arme à distance

Module de gestion des décors : je réduirais le choix à 2 types
---total par niveau : maps de FPS et décors en intérieur pour RPG
---chargement par zones : en extérieur carte géante découpée en cases avec préchargement des cases voisines -> moins d'accès disque qu'un chargement en continu.

Module de fin de partie :
---Quêtes/missions accomplies

De mon côté je me suis demandé comment sauvegarder le monde créé et comment y accéder à partir du jeu, et j'avais lu quelque part qu'il y avait une bibliothèque qui gère SQL (j'arrive plus à mettre la main dessus).
Ce qui serait pas mal, je pense, pour gérer un jeu du style de morrowind, qui en fait ajoute plug-in sur plug-in à n'en plus finir à partir d'un monde existant.
A ce propos j'ai refais le graphique de link31 -> http://bebefoetus.neuf.fr/ubuntu-fr/diagramme.odg
(Corrigez-moi si c'est n'importe quoi)

Sinon de mon côté, j'attaque la POO et c'est fascinant !

Voilà @++

EDIT:
Pour ma participation à un tel projet, il faudra attendre que j'aie un niveau suffisant (mois?, années ?)

Dernière modification par BebeFoetus (Le 04/05/2007, à 23:35)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 13/03/2007, à 21:43

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#52 Le 13/03/2007, à 21:51

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#53 Le 13/03/2007, à 22:36

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#54 Le 13/03/2007, à 22:43

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#55 Le 13/03/2007, à 22:58

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#56 Le 14/03/2007, à 01:16

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#57 Le 14/03/2007, à 19:16

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#58 Le 14/03/2007, à 19:54

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#59 Le 15/03/2007, à 19:56

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#60 Le 24/03/2007, à 11:55

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#61 Le 24/03/2007, à 12:22

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#62 Le 24/03/2007, à 16:28

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#63 Le 25/03/2007, à 03:24

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#64 Le 25/03/2007, à 16:56

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#65 Le 30/04/2007, à 16:17

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#66 Le 30/04/2007, à 19:36

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#67 Le 30/04/2007, à 19:56

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#68 Le 30/04/2007, à 22:58

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#69 Le 30/04/2007, à 23:01

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#70 Le 01/05/2007, à 01:51

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#71 Le 04/05/2007, à 19:35

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#72 Le 04/05/2007, à 19:58

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#73 Le 04/05/2007, à 20:00

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#74 Le 04/05/2007, à 23:19

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

#75 Le 04/05/2007, à 23:33

Re : [Projet en cours] Un éditeur de jeu (Démiurge)

Pied de page des forums