Recherche exploratoire : le logiciel idéal

Dans le cadre de mes études et de mes projets, je fais une recherche sur le logiciel idéal pour la création de jeux vidéos en tout genre.

L'idée première de ce topic est de recenser les caractéristiques d'un tel logiciel. Dans un deuxième temps, je voudrais effectuer une comparaison entre les logiciels existants. Connaitre leur points forts et leur points faibles, d'abord d'un point de vue purement technique et ensuite de manière plus subjective. C'est à dire que je souhaite aussi connaitre l'avis personnel des utilisateurs de ces logiciels, savoir ce qu'ils attendent de ces logiciels, ce qui pourrait être amélioré et ce qui leur parait inutile voire dérisoire.

Il est fort probable qu'aucun logiciel actuel ne soit perçu comme LE logiciel idéal. Mais certaines aspects, pour ne pas dire caractéristiques, doivent certainement se retrouver dans les logiciels les plus populaires.

Et maintenant quelques précision sur la manière dont je souhaite que ce sujet soit dirigé.
La description d'un logiciel existant doit comporter une liste de caractéristiques (plateformes supportées, principe de compilation ou interprétation, niveau d'abstraction) et un avis personnel sur les points forts/faibles du logiciel. N'hésitez pas aussi à fournir des liens WEB ou des références d'ouvrages qui traitent du logiciel ou d'un même sujet.

Je garderai dans le deuxième message, un résumé condensé des discussions qui auront lieu autour du sujet. Ainsi qu'une liste des caractéristiques du fameux logiciel idéal.

Lorsque que j'estimerais que le sujet aura été suffisamment approfondi, j'écrirai un document de synthèse que je vous transmettrai par la suite.

Merci de noter que ce sujet est sérieux, aussi toute divagation ou tout flood est fortement prohibé. Je vous remercie par avance de votre participation et de vos contributions.

Ce message recense la synthèse des discussions qui ont lieu dans ce sujet.

Vide pour le moment ^^

je connais que deux language, le GML et XNA
Donc XNA:
http://creators.xna.com/fr-CA/
kit de developement pour xbox 360, windows, zune et zune HD sur C# (donc un compilateur)
la plus pars des grosse fonction sont déja intégré (AA, pixel shader 2.0,3.0, etc...)
mais les fonction simple comme les collision et l'animation sont a faire
ce qui fait que comparé à GM les bugs sont quasi impossible.
je n'ai pas encore testé la 3D, mais au vu de certaines production c'est très puissant.
autre truc qui est bien, avec un abo premium, on peut vendre nos production sur le Xbox LIVE
et il gère les png transparant OMG
seul bémol, c'est récent et la documentation est pas encore hyper poussé

C'est donc plus une plateforme de développement orienté jeu qu'un véritable studio de développement pour jeux vidéos ?

Citation :

ce qui fait que comparé à GM les bugs sont quasi impossible

C'est ce n'est pas vrai. Les bugs ne dépendent pas toujours du langage utilisé mais de la façon de s'en servir.

je sais, mais dnas gm ca vien réellement des fonctions, le même truc qui plante sous GM, plantera pas sous XNA (j'ai testé avant de parler quand même^^)

En effet, c'est très intéressant comme sujet, difficile de dire précisément ce qui est important. Personnellement il y a deux éléments majeurs qui facilitent le développement de jeu pour un logiciel. Son API en premier lieu, elle doit, sans bloat, être facile à prendre en main avec des fonctions bien visée pour le développement de jeu(détection de collision, pathfinding, moteur physique) afin de bien répondre à ces besoin, je crois que tout ce qui est environnement dans le jeu doit être géré également par l'API. Bien évidemment le plus important c'est surtout d'éviter le plus possible le code "boilerplate". Le deuxième élément que je considère très important c'est le paradigme utilisé et comment il est implémenté de façon à rendre le développement facile, dans le cas de GM(où à peu près tout relève de la programmation événementielle), c'est de là, à mon avis, que viens une bonne partie de sa puissance. C'est sur qu'il y a d'autre choses, mais c'est pas mal ça.

GM n'est pas vraiment évènementiel.. il est orienté objet mais surtout procédural. Il a son type bien a lui. Il va très bien pour faire des petits jeux mais rendu dans de gros trucs on se complique la vie à utiliser Game Maker... Aucune abstraction des données, pas de méthodes dans nos objet juste des "user event". Je ne dis pas que c'est impossible de faire de quoi de gros en GM mais je dis que le C++ devient beaucoup plus intéressant ici puisqu'il permet de faire tout de manière plus structuré et abstrait.

Citation :

ce qui fait que comparé à GM les bugs sont quasi impossible

Je ne vois pas de lien. Des bugs quasi impossible en C#! Tout dépant du programmeur et une infime partie du framework utilisé

Sinon le logiciel idéal... Je parlerais plus en terme de librairie ou framework venant avec leurs éditeur de niveaux etc..

un exemple: http://www.horde3d.org/

je parle de bug du à la structure même de GM, pas de la programmation^^(enfin faut dire que le débugeur de GM est merdique aussi)
genre mon dernier, il détecte la collision, mais pas l'objet qui la cause, bref le other marche pas, sans parler de fonctions qui s'actualise pas
J'ai rien contre gm, je l'utilise encore et toujours, juste que certain truc sont assez ****** niveau bug interne

Wargamer a écrit:

je parle de bug du à la structure même de GM, pas de la programmation^^(enfin faut dire que le débugeur de GM est merdique aussi)
genre mon dernier, il détecte la collision, mais pas l'objet qui la cause, bref le other marche pas, sans parler de fonctions qui s'actualise pas
J'ai rien contre gm, je l'utilise encore et toujours, juste que certain truc sont assez ****** niveau bug interne

Hey bien je n'ai jamais aucuns de ses bugs Et pourtant j'ai utiliser GM à fond. Tu dis que le other marche pas... Il fonctionne très bien. Je crois que tu l'utilise aux mauvais endroits... il sert dan le cas du with(objet) pour avoir accès à l'objet qui a le code du with et aussi dans les event de collision d&d.

je l'utilise au bon endroit, je suis pas si con xD
if place_meeting(x,y,bob)
other.vie-=1;
résultat: mon perso perd 1 de vie au lieu de bob
sweeet
sinon ay aussi les bugs de compilation, voir du logiciel lui même qui arrive plus a interpréter ses propre lignes(tu dois attendre genre 1h pour que ca revienne)

Wargamer a écrit:

je l'utilise au bon endroit, je suis pas si con xD
if place_meeting(x,y,bob)
other.vie-=1;
résultat: mon perso perd 1 de vie au lieu de bob
sweeet
sinon ay aussi les bugs de compilation, voir du logiciel lui même qui arrive plus a interpréter ses propre lignes(tu dois attendre genre 1h pour que ca revienne)

C'est ca que je disais au mauvais endroit... Le other fonctionne quand il est utilisé dans un script à l'intérieur d'un event de collision programmé via l'interface de gm . Il sert aussi dans le cas suivant(code dans un objet player par exemple):
with(bob)
{
bob.x += 1;//x de chaque bob += 1
other.x += 1;//chaque bob incrémente le x de player de 1
}

other sert à accéder à l'objet qui contient le with dans ce cas.

quand tu écris:

if place_meeting(x,y,bob)
other.vie-=1;

c'est normal que le other modifie ton player surtout si ce code n'est pas dans un event collision ! Le other ne sert à rien ici... pour avoir l'objet qui est en collision il faut faire instance_position ou instance_meeting je me rapelle plus(je ne suis pas chez moi), mais elle retournne l'objet au lieu d'un booléan disait s'il y a collision.

donc:
if place_meeting(x,y,bob)
{
var obj;
obj = (instance_meeting(x,y,bob));//instance_position?
obj.vie-=1;
}

Bien des programmeurs ont l'habitude mettre la faute sur le logiciel ou la lib au lieux de se demander si ce n'est pas de leur coté le problème.

M'enfin bref Game Maker fonctionne ultra bien Je ne rejette pas qu'il y a quelque bugs. Mais il y en a pas des majeurs..

moi je n'en connait pas des masses :

- Game Maker
- TheGameFactory
- Dark Basic
- Pure Basic

Après, on tape dans le C et les libs d'affichage...

Il n'y a pas de logiciel idéal, juste un compromis entre la facilité d'utilisation, la rapidité et les possibilités offertes.
C'est pour ça qu'on ne peux pas classer les logiciels de créations :

RPG Maker est très renfermé, mais permet de faire aisément des RPG difficilement faisable sous GM.

GM est plus libre, facile d'emploi, mais reste plus lent qu'un langage direct (je veux dire par là un langage qui n'est pas une interprétation, d'une interpretation etc.

On peux fait encore plus de choses en C++, mais c'est plus dur, prend un temps fou, mais c'est aussi plus rapide.

L'extrémiste que je suis rappelle qu'on peux tout faire en asm : c'est über compliqué, mais qu'est ce que c'est rapide!

Il faut juste savoir ce que l'on veux. Si l'on veux se lancer dans des projets 'lourds' (3D, très jolis, avec plein d'IA etc.), on peux oublier GM natif (sans DLL, et encore, même avec...), il faut passer à des langages plus compliqués.
En revanche, pour un jeu d'arcade, voir TOUT jeu en 2D, Game Maker reste un excellent compromis : Tout est prévu, les fonctions permettent de faire certaines choses très rapidement, et le moteur est amplement suffisant.

Mieux vaut le fabriquer soi même

Mais je suis d' accord avec M@d, il n' existe pas et n' existera de logiciel parfait... en quoi que se soit d'ailleurs

Si on sait fabriquer soi même un très bon logiciel, il vaut mieux utiliser son talent pour directement créer un jeu dans la langue qui aurait servie à faire le logiciel ^^

(et la boucle fut bouclée)

Dans ce cas que se passe t-il si tu programme un compilateur :gniah:

M@d_Doc a écrit:

Il n'y a pas de logiciel idéal, juste un compromis entre la facilité d'utilisation, la rapidité et les possibilités offertes.
C'est pour ça qu'on ne peux pas classer les logiciels de créations :

RPG Maker est très renfermé, mais permet de faire aisément des RPG difficilement faisable sous GM.

GM est plus libre, facile d'emploi, mais reste plus lent qu'un langage direct (je veux dire par là un langage qui n'est pas une interprétation, d'une interpretation etc.

On peux fait encore plus de choses en C++, mais c'est plus dur, prend un temps fou, mais c'est aussi plus rapide.

L'extrémiste que je suis rappelle qu'on peux tout faire en asm : c'est über compliqué, mais qu'est ce que c'est rapide!

Il faut juste savoir ce que l'on veux. Si l'on veux se lancer dans des projets 'lourds' (3D, très jolis, avec plein d'IA etc.), on peux oublier GM natif (sans DLL, et encore, même avec...), il faut passer à des langages plus compliqués.
En revanche, pour un jeu d'arcade, voir TOUT jeu en 2D, Game Maker reste un excellent compromis : Tout est prévu, les fonctions permettent de faire certaines choses très rapidement, et le moteur est amplement suffisant.

Je suis semi d'accord avec toi. Il est parfois beaucoup plus simple et facile de faire un jeu en C++ qu'avec Game Maker. Je m'explique. Par exemple dans le cas de super gros MMORPG révolutionnaire comme il en a des dizaines ici, il faut des outils puissants et efficaces. Surtout, il faut un langage permettant l'abstraction des données, l'héritage etc. Game Maker se retrouve à être ultra simple pour des petits jeux puis il devient une grande limitation pour les gros projet. Game Maker ne fournit aucune abstraction des données et les objets ne peuvent pas n'ont plus avoir leurs propres méthodes comme dans les langages orientés objet. Un MMORPG c'est compliqué à créer alors comment créer du compliqué avec un outil simple qui laisse de coté les propriétés "complexes" des lanages objets?

L'assembleur... il n'a pas sa place dans ce monde à mon avis. C'est se compliquer la vie pour rien! Et bien souvent un compilateur C++ va produire du code asm plus performant qu'un simple programmeur aurait produit.... à moins que le programmeur connaisse l'asm à fond. Et bien si c'est le cas il gagnera 1-2% de performance après avoir passé 100 fois plus de temps à coder son truc qu'avec un bon langage traditionnel tel le C++. M'enfin c'est ridicule. Aujourd'hui l'asm sert par exemple à l'écriture de driver et à l'écriture de fonctions que l'on veut performantes( regarder le code source de SDL ). M'enfin bref dans le cas d'un jeu c'est ridicule et mal pensé de programmer en asm et de plus tu risque de te décourager si tu t'embarque dans la prog de gros jeux.

On a du mal se comprendre : j'adore l'asm, mais c'est une solution extrême et pas sensée du tout. J'adore l'asm, et je fais péter le champagne quand je finit un truc à la tetris, alors un mmorpg... lol
Et à part pour coder des routines assez lourdes, l'asm ne s'utilise presque plus de nos jours. (mais c'est plus fun que le sudoku, niveau casse tête :p )

Oui bien sûre je ferait comme toi coder des petits jeux en asm dans l'unique buts de m'amuser à le programmer et à me casser la tête :fier: Mais comme je dis seulement pour m'amuser et pas pour des projets sérieux XD

Dans l'idée, j'essaye d'esquisser les contours d'un framework de développement de jeux vidéos. Donc un logiciel plus orienté programmation que GM mais qui évite d'avoir à recoder des librairies ou à se plonger dans de la documentation et de perdre du temps.

En gros, je souhaite rassembler tous les points positifs pour proposer un prototype de logiciel qui serait plus qu'un éditeur de niveau (ce que GM est plus ou moins grossièrement) mais qui laisserait assez de flexibilité pour le développeur. C'est à dire pas de bibliothèques fermées et la possibilité d'étendre ou de redéfinir à peu près tout.

C'est ce que je suis en train de programmer un moteur en C++ avec son éditeur. Je ne dis pas que c'est le programme idéal mais bon il n'a pas de limite coté programmation comme tout moteur en C++..

https://cbna.forumactif.com/vos-projets-f11/red-hammer-engine-t9214.htm

Je ne sais pas si on peux avoir toute les qualité en une seule application.

Je vais faire la liste de tous se que je pense être bien.


-Un language proche du c++.
-mais une interface pour facilité le chargement des ressources (sprite, son)
-un editeur de room/condition initial adaptable (2d/3d/...)
-Des fonctions standard (modifiable) utile (affichage, chargement, collision, evenement, math,...)
-Déconstruire un peu le systeme de gm (system de room, de collision, d'affichage) qui parfois aurait-on envie de supprimer dans certains cas.
-fonctionnalité optionnel à (moteur physic, moteur 3D, collision)
-rapide ^^ (programme compiler)
- Et puis optionnellement un editeur de sprite, model interne (je rêve un peu)
- Et puis une forte communauté.


L'indéal pour moi, Ce n'est pas de crée un nouveau langage mais utilisé le C++ et crée un IDE qui automatise certains aspect mais nous laisse le loisir de décidé, et des lib standard a inclure si on le souhaite.

pour moi qui connait pas beaucoup de logiciel des création de jeux vidéo.

Rpg maker: rapide, facile , beaucoup de ressources interne et sur le net.
Mais limité dans le genre de jeu et ajout de systeme compliqué par les script.

Game maker : rapide, facile, adapté pour les jeux d'arcade en 2d, moins limité que Rpg maker mais relativement lent et limité tous de même dans le langage.

Voila.

Bref, un game maker open source, i.e. qu'on pourrais modifier tout ce que ce cher mark a programmé...

oui exact.