Gwenn parle ici des jeux qui ont pour objectif d'être joués. Sans site web, la promo du jeu est moins importante (sans compter su'il faut un bug tracker, un forum, etc...)
Sans son, un jeu est... fade.
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
En revanche, surtout si vous débutez, sachez découvrir les solutions gratuites voire libres.
Le post est clairement utile, productif, tout ça tout ça, mais, par pitié, enlève le "voire libres". Il n'a aucune raison d'être là, ni d'être associé au "gratuites".
Dans le cadre du jeu vidéo, libre implique forcément gratuit puisque tu ne peux pas vendre un service ou un support ni même de la publicité pour financer le jeu (pour des raisons évidentes). La distinction est quand même faite puisque j'emploie les deux termes séparément, je ne vois aucune raison de grimper aux rideaux pour ça.
Cette information est indirectement liée au sujet même si j'aurais préféré qu'un sujet particulier soit ouvert en ce qui concerne l'actualité en matière de moteur de jeux.
Une nouvelle possibilité s'ouvre aux développeurs : Torque 3D devient disponible sous licence MIT, rejoignant ainsi Delta Engine. Cela attirera certainement quelques développeurs désireux de toucher aux sources (et à titre personnel, je peux désormais faire des modifs plus profondes au moteur et les publier, ce qui était parfois compliqué autrefois).
Je ne suis pas fondamentalement un fan de ce moteur, même si je me suis bien amusé dessus. Mais j'espère que cela permettra à celui-ci d'évoluer (en tous cas, j'y apposerai ma brique) et c'est un geste que je respecte.
C'était en effet attendu, Torque ayant été relégué au rang de moteur de seconde zone face aux ténors UDK/CE3/Unity (ce qui est compréhensible vu le retard du moteur sur certains points). Il fallait un baroud d'honneur pour revenir sur le devant de la scène et cette décision attirera les développeurs (même s'il y a du boulot), du moins la communauté Torque, ce qui n'est pas rien.
En est-il pour autant moins vrai qu'il est plus simple de créer un jeu 3d qu'un jeu 2d ? C'est une phrase que j'ai souvent entendue et qui m'a paru cohérente.
Les shaders en visuel : vital. Aucun artiste n'est capable de programmer un shader, ce n'est pas son job, et à raison de 1 à 5 shaders par objet...</puce>
Il y a des outils pour ça, nvidia et ATI fournissent d'excellents générateurs visuel de shader, l'avantage est que les utiliser permet de s'abstraire de la techno sous jacente (UDK dans ton cas) et donc de s'en servir quand on utilise autre chose sans avoir à réapprendre un nouvel outil.
Citation : Gwenn
La manipulation des animations : quand tu vise avec la tourelle d'un tank, c'est une animation et pour des raisons évidentes, elle ne se fait pas dans Maya mais directement dans le moteur suivant le mouvement du joueur. Dans UDK, il y a un système très avancé de contrôle de l'animation bone par bone, en visuel, avec des contraintes, contrôles, etc, tous chainés... Là encore, pour réaliser un personnage, un tel système est indispensable
Ogre gère bien sur l'animation par bones(motion capture également), le morphing, nodale avec un système hierarchique, et par keyframe si on exporte des anim depuis l'outil de modeling.
Citation : Gwenn
Les systèmes de particules : un FPS basique c'est une centaine de systèmes de particules au bas mot, la plupart avec une bonne vingtaine de paramètres dédiés. Il est parfaitement vital d'avoir un éditeur graphique temps réel pour ça.</puce>
Le scripting : un artiste ne sait pas programmer. Exit les langages textuels : tous les moteurs sérieux font du visuel.
Avec OGRE, à chaque fois que tu fais quelque chose chose, l'artiste doit faire appel à un programmeur. C'est complètement stupide et antiproductif. Les outils que je cite ne sont ni anecdotiques, ni fournis avec OGRE. Il les faut, c'est une impérieuse nécessité, mais OGRE ne s'en occupe pas parce que c'est un moteur 3D, et pas un moteur de jeu.
ça reste une question de besoin, dans une équipe amateur, c'est souvent le programmeur qui va s'occuper du scripting, pour ma part je suis bien plus productif avec une console de script qu'avec des boites à déplacer.
Développer un moteur à partir de middleware open source n'est pas inadapté pour une équipe amateur et présente plusieurs avantage:
-Accès aux sources: pour un développeur sérieux, l'accès aux sources d'un outil est bien souvent une nécessité pour en comprendre le fonctionnement intrinsèque et les subtilité, de même on peut parfois avoir à modifier l'outil pour des besoins précis.
-Perfectionnement personnel: mon moteur de jeu et le jeu font un peu plus de 70 000 loc réparti sur 9 projets en 3 langages différents, soit 7 à 8 fois plus que l'équivalent via UDK, travaillant seul dessus, il est évident que la masse de connaissance acquise et réutilisable(vu que les langages sont java, c++ et ruby, donc utilisable en contexte professionnel) est nettement supérieure, d'un autre coté, l'investissement en temps est proportionnel.
-portabilité, pas seulement sur différents OS mais également il est possible de cibler soi même la catégorie de matériel supporté, contrairement à UDK qui à une config minimal requise(assez conséquente)
-personnalisation: on défini soi même les contraintes du moteur et on le crée en conséquence, vu qu'un moteur ne peut jamais vraiment être complètement générique, il est plus adapté à l'utilisation qui lui est destinée.
Bref tout ça pour dire que le choix fait-main VS moteur-tout-fait reste une question de besoin, l'un n'est pas vraiment mieux que l'autre.
Faire son moteur soi même est bien plus long mais a des avantages non négligeables sous certaines circonstances.
Oui, ça dépend de l'objectif. Si on veut avant tout apprendre, le moteur de jeu est un mauvais choix. Je pense que personne ne dit le contraire.
Oui, il y a des avantages, oui, il y a des outils.
Si on veut au contraire finaliser son jeu, qu'il soit portable, fiable, et qu'il aie une qualité élevée (que ça soit visuellement ou dans le degré de finition du gameplay) le moteur de jeu est une obligation. A ce jour, aucun contrexemple que je connaisse en 3D.
Notons qu'UDK ou Unity supportent une gamme de matériel allant du téléphone au hardcore-PC en passant par la console, le tout avec le même code et contenu. Je pense que sur ce plan, la portabilité est du côté des moteurs de jeu.
Quand on voit un jeu comme Black Mesa qui a pris 7 ans de développement avec un moteur de jeu et quasiment tout le gameplay de faits, on comprend qu'il n'est tout simplement pas possible de faire pareil avec OGRE pour une équipe amateur (et de facto, aucun des FPS amateur de qualité que je connaisse n'a été réalisé sans moteur de jeu).
Oui, ça dépend de l'objectif. Si on veut avant tout apprendre, le moteur de jeu est un mauvais choix. Je pense que personne ne dit le contraire.
Oui, il y a des avantages, oui, il y a des outils.
non tu m'as mal compris, je me suis peut-être mal exprimé, navré.
l'objectif en utilisant sa propre technologie n'est pas l'apprentissage, la finalité n'en reste pas moins la création d'un jeu à part entière, l'objectif est de profiter des avantages sus-cités sans souffrir des contraintes d'un moteur existant.
Citation : Gwenn
Si on veut au contraire finaliser son jeu, qu'il soit portable, fiable, et qu'il aie une qualité élevée
La portabilité a été évoquée plus haut et est nettement avantagée avec une solution personnelle, la fiabilité est relative à la compétence de l'équipe dans l'utilisation de ses outils et le degré de complexité de l'application, des jeux utilisant un moteur existant buggé ça existe et ce n'est pas nouveau, pour en prendre un très connu, mass effect 2, fais avec l'unreal engine souffre de nombreux soucis, c'est excusable vu la complexité du produit.
bref, la fiabilité st la résultante d'une équation à plusieurs paramètre, ce serait simpliste de juste prendre un seul facteur.
Citation : Gwenn
(que ça soit visuellement ou dans le degré de finition du gameplay) le moteur de jeu est une obligation. A ce jour, aucun contrexemple que je connaisse en 3D.
torchlight utilise ogre(pas le seul, mais je reste avec les exemples les plus connus).
Citation : Gwenn
Notons qu'UDK ou Unity supportent une gamme de matériel allant du téléphone au hardcore-PC en passant par la console, le tout avec le même code et contenu. Je pense que sur ce plan, la portabilité est du côté des moteurs de jeu.
ogre/bullet/openal, sont compilable sur pc windows/linux/mac, android, IOS, et qq trucs plus exotiques donc la majorité du matériel également, à moins de vouloir porter sur XBOX ou PS3, l’intérêt reste limité par rapport à la perte des machines plus faibles et linux(vu qu'en tant qu'amateur les marchés de niches sont particulièrement intéressants)
Citation : Gwenn
Quand on voit un jeu comme Black Mesa qui a pris 7 ans de développement avec un moteur de jeu et quasiment tout le gameplay de faits, on comprend qu'il n'est tout simplement pas possible de faire pareil avec OGRE pour une équipe amateur (et de facto, aucun des FPS amateur de qualité que je connaisse n'a été réalisé sans moteur de jeu).
Pourtant une petite recherche sur le web te montrera des tas de projets pas mal avancés du tout, d'autres terminés, il y en a quelques un sur le forum d'ogre qui méritent de s'y intéresser et que donc rien n'est impossible du tout.
Edit, je n'avais pas vu que tu spécifiais FPS, quand je dis jeu je veux dire l'ensemble des genres, pas seulement les FPS.
Je n'ai encore jamais vu un jeu 3D amateur complet et jouable avec la qualité (visuelle et en gameplay) d'un jeu pro qui n'utilise pas un moteur de jeu. Il y en a de très beaux et très bien finis, juste pas avec une solution maison... Je suis surpris que tu débatte là-dessus, ce point me semble assez clair.
Si tu as un exemple d'un jeu amateur qui ressemble à un Battlefield et qui se passe d'un moteur de jeu, je veux bien voir ça.
Pour la portabilité, eh bien j'attends de voir OGRE tourner sur iPhone en 3 clics à partir d'un build PC, sans que le dev aie besoin de se poser la question de la portabilité... Pour moi c'est très clair que c'est à l'avantage des moteurs de jeu.
PS : je parle ici de jeu 3D, quel qu'il soit, FPS ou pas. Mais c'est surtout dans les FPS que le moteur de jeu est vital, oui.
Je n'ai encore jamais vu un jeu 3D amateur complet et jouable avec la qualité (visuelle et en gameplay) d'un jeu pro qui n'utilise pas un moteur de jeu. Il y en a de très beaux et très bien finis, juste pas avec une solution maison... Je suis surpris que tu débatte là-dessus, ce point me semble assez clair.
Si tu as un exemple d'un jeu amateur qui ressemble à un Battlefield et qui se passe d'un moteur de jeu, je veux bien voir ça.
Moi ce qui me surprend c'est que tu mélange pro et amateur alors qu'ici on parle surtout des technologies employées, je vais mettre une image c'est plus parlant vu que je me fais mal comprendre:
Ce qui est clair c'est que la techno n'a rien à envier aux moteurs "modernes", et que donc, il devient évident que UDK n'a pas l’apanage des jeux de qualité au niveau visuel.
Ainsi toute personne pouvant fournir des assets de qualité (et donc complètements indépendants du moteur) aura un rendu qui peut être très impressionant.
Citation : Gwenn
Pour la portabilité, eh bien j'attends de voir OGRE tourner sur iPhone en 3 clics à partir d'un build PC, sans que le dev aie besoin de se poser la question de la portabilité... Pour moi c'est très clair que c'est à l'avantage des moteurs de jeu.
2 en fait, cmake et un script pour le lancer.
donc pour la portabilité, pour m'en préoccuper dans mon moteur, c'est très simple à gérer.
Moi je parle des amateurs. Sors moi le top amateur sur ogre et je compare avec le top amateur sur UDK...
Je tente d'ouvrir un débat et on est vraiment réduit à jouer à "qui à la plus grosse"?
En tant que instigateur d'un topic sur la création de jeu vidéo, mis en post it, j'aurais espéré de ta part un peu plus d'ouverture d'esprit afin de permettre au plus grand nombre d'effectivement se lancer dans le dev de jeu...
Mais plutôt que d'exposer les solutions existantes avec leurs avantages et inconvénients, tu ne fais que promouvoir celle qui te convient en dénigrant les autres.
Je trouve un peu dommage cette partialité.
Moi je parle de ce que je connais. Je bosse sur UDK, j'ai une grosse équipe avec moi, et le rendu est très nettement au dessus de ton dernier screen, techniquement. En amateur. L'équipe est indépendante, chacun a tout ce qu'il faut, les artistes n'ont pas à toucher au code... Et on avait un proto jouable en multi au bout de trois mois de dev. Aujourd'hui, au bout de six mois, on parle d'alpha.
On a une solution clef en main qui va quasiment jusqu'à la distribution (je veux bien admettre qu'on a géré le déploiement utilisateur nous-mêmes) et on se "contente" de faire notre jeu vidéo, ce qui est déjà un travail de plusieurs mois / années. On code la notion de personnage, la notion d'arme, on importe une IHM depuis Flash ou les models depuis 3DS ou Blender avec un simple cliquer-glisser. La gestion de version est intégrée à l'outil, tout le monde bosse sur les mêmes données sans sortir de l'outil.
Moi en tant que chef du projet j'estime qu'on n'aurait aucune chance d'aboutir avec un outil différent. C'est un avis perso, ça n'engage que moi bien sûr, mais je pense que c'est un avis éclairé...
Alors oui, si on est un studio pro, qu'on a trois ans de dev et des experts dans tous les domaines, on peut très bien utiliser OGRE. C'est une technologie mature, performante, ouverte, et très sincèrement tu as raison de dire qu'on peut faire aussi bien avec ça qu'avec UDK. Surtout, les royalties des moteurs rendent souvent ça rentable...
Mais pour une équipe d'amateur, c'est tout simplement tripler la dose de travail, alors qu'elle est déjà colossale, pour un résultat qui risque fort d'être moins bon. En termes de gestion de projet c'est du suicide de choisir une telle solution si un moteur de jeu existe pour ça...
Moi je parle de ce que je connais. Je bosse sur UDK, j'ai une grosse équipe avec moi, et le rendu est très nettement au dessus de ton dernier screen, techniquement. En amateur. L'équipe est indépendante, chacun a tout ce qu'il faut, les artistes n'ont pas à toucher au code... Et on avait un proto jouable en multi au bout de trois mois de dev. Aujourd'hui, au bout de six mois, on parle d'alpha.
Et c'est pour ça que j'insiste sur les points que tu ignores, afin que les gens qui lisent ce topic puissent avoir d'autres points de vue et d'autres solutions que celle que tu préconises qui, si elle est adaptée dans ton cas, et c'est tant mieux, n'en fait pas une solution universelle et ne répond pas forcément aux attentes de tous.
Citation : Gwenn
On a une solution clef en main qui va quasiment jusqu'à la distribution (je veux bien admettre qu'on a géré le déploiement utilisateur nous-mêmes) et on se "contente" de faire notre jeu vidéo, ce qui est déjà un travail de plusieurs mois / années. On code la notion de personnage, la notion d'arme, on importe une IHM depuis Flash ou les models depuis 3DS ou Blender avec un simple cliquer-glisser. La gestion de version est intégrée à l'outil, tout le monde bosse sur les mêmes données sans sortir de l'outil.
Moi en tant que chef du projet j'estime qu'on n'aurait aucune chance d'aboutir avec un outil différent. C'est un avis perso, ça n'engage que moi bien sûr, mais je pense que c'est un avis éclairé...
j'ai également une solution clé en main, un script ANT qui va compiler, packager et déployer les ressources sur le serveur afin de les rendre accessible au launcher, en tant que developpeur, tu connais ces outils je suppose, idem pour le versionning et autre.
Moi en tant que développeur, j'estime que la solution d'utiliser des outils open source est la seule manière de répondre parfaitement à mes besoin, et au vu de mon moteur actuel, je n'ai aucun doute sur l'avenir de mon jeu, il se porte très bien.
C'est mon avis, en tant que programmeur. Professionnellement j'ai travaillé sur de gros projets pour de grosses boites, donc j'espère pouvoir dire sans me tromper quand un projet est réalisable et quand il ne l'est pas.
Citation : Gwenn
Alors oui, si on est un studio pro, qu'on a trois ans de dev et des experts dans tous les domaines, on peut très bien utiliser OGRE. C'est une technologie mature, performante, ouverte, et très sincèrement tu as raison de dire qu'on peut faire aussi bien avec ça qu'avec UDK. Surtout, les royalties des moteurs rendent souvent ça rentable...
Mais pour une équipe d'amateur, c'est tout simplement tripler la dose de travail, alors qu'elle est déjà colossale, pour un résultat qui risque fort d'être moins bon. En termes de gestion de projet c'est du suicide de choisir une telle solution si un moteur de jeu existe pour ça...
C'est en effet le facteur temps le défaut majeur de la solution que j'utilise, il n'en reste pas moins acceptable, après 3 ans(en travaillant seul, donc je ne fais pas que la programmation mais aussi le visuel, et ça prend bcp de temps), j'ai un moteur utilisable qui répond à mes besoins, que je connais parfaitement et donc c'est bien loin d'être du suicide.
Pour test, j'avais fait un petit arkanoid avec mon moteur(donc un genre totalement différent que ce pour quoi le moteur a été conçu), jouable via kinect, ça m'a pris une journée de dev.
Bref chaque solution présente ses avantages et inconvénient, et comme pour toute solution, cela répond à un problème donné, a chacun de choisir celle qui convient le mieux à ce qu'il veut faire, l'une n'étant pas meilleure que l'autre.
Ben ouais mais 3 ans d'implication dans un projet c'est juste énorme, hein. Je respecte complètement le travail que tu fais, vraiment, je suis juste extrêmement sceptique sur la viabilité du modèle pour des équipes amateur. Tu admets toi-même qu'aucun jeu 3D amateur sans moteur n'atteint le niveau de ceux qui en utilisent un, sur le plan visuel.
Maintenant, je note que tu bosses seul et que tu es programmeur. Forcément, on ne va pas avoir les mêmes exigences : la moitié de mon équipe est dans le domaine artistique et n'est clairement pas capable d'utiliser par exemple Git, pour ne donner qu'un exemple. De mon côté c'est une exigence que les 3/4 des développeurs ne touchent pas au code, et clairement je n'ai pas ça dans un moteur "fait maison". Quand je vois qu'exporter un mesh dans le bon format pose problème, je n'ose imaginer ce que ça donnerait si il fallait un outil intermédiaire...
Toi tu es programmeur, mais le jour où tu devras pour ton projet recruter des graphistes, tu risque d'être assez surpris par leurs attentes à eux.
Ben ouais mais 3 ans d'implication dans un projet c'est juste énorme, hein. Je respecte complètement le travail que tu fais, vraiment, je suis juste extrêmement sceptique sur la viabilité du modèle pour des équipes amateur. Tu admets toi-même qu'aucun jeu 3D amateur sans moteur n'atteint le niveau de ceux qui en utilisent un, sur le plan visuel.
Pas tant que ça, tu citais 7 ans pour une équipe avec un moteur existant.
Comme tu l'as dis précédemment, ogre est un outil mature et performant, son unique retard, à savoir DX 11 est actuellement comblé.
Citation : Gwenn
Maintenant, je note que tu bosses seul et que tu es programmeur. Forcément, on ne va pas avoir les mêmes exigences : la moitié de mon équipe est dans le domaine artistique et n'est clairement pas capable d'utiliser par exemple Git, pour ne donner qu'un exemple. De mon côté c'est une exigence que les 3/4 des développeurs ne touchent pas au code, et clairement je n'ai pas ça dans un moteur "fait maison". Quand je vois qu'exporter un mesh dans le bon format pose problème, je n'ose imaginer ce que ça donnerait si il fallait un outil intermédiaire...
Naturellement, mon exigence ne se situe pas au niveau du visuel mais bien de l'expérience de jeu, je compte bien offrir quelque chose de différent qu'un autre clone de jeu existant.
Je pense que les possibilité de game play doivent primer sur le visuel pour offrir une expérience intéressante, c'est pour ça que je préfère les RTS, jeux de role, city builder.
Les mesh ne posent pas de soucis, y a des plugin ogre pour max, blender, maya, t'exporte ça comme n'importe quel format et tu récupères ton .mesh et la material, il y a même possiblité d'ouvrir une fenêtre de rendu ogre depuis l'outil de modelisaition pour vérifier que le résultat est bien celui attendu.
Si git est trop compliqué(j'utilise mercurial, c'est le même style), y a svn: commit, update, c'est quand même accessible au commun des mortels.
Citation : Gwenn
Toi tu es programmeur, mais le jour où tu devras pour ton projet recruter des graphistes, tu risque d'être assez surpris par leurs attentes à eux.
Vu que je fais aussi tout le visuel de mon jeu, je pense que je connais quand même les attentes que l'on peut avoir pour importer ses assets, c'est pour ça que j'ai crée un système de script déclaratif(c'est du XML) très simple pour la création et utilisation des resources: un nom, un chemin de fichier, et si on veut on spécifie les options dont on a besoin, et c'est utilisable dans le moteur.
Ben encore une fois on a juste pas le même objectif pour nos jeux. Toi tu admets que le visuel ne t'intéresse pas, ça se voit, c'est pas un drame, c'est un choix mais faut aussi admettre que sur le plan visuel on ne voit jamais de travaux amateur aboutis en se passant de moteur de jeu.
Le truc, c'est que le moteur de jeu n'a aucun impact sur le gameplay, en revanche il favorise considérablement la création visuelle et audio. C'est gagnant sur tous les points.
@shakhal je tiens à préciser que je suis un grand fan d'ogre, et que je ne changerai pas de technologie de si tôt Cependant, Gwenn marque un point, le développement peut s'avérer bien plus lent et compliqué avec Ogre.
Bien sur tout est relatif, une fois que la maitrise d'ogre est quasi totale, la productivité peut égaler celles des game engines préfaits, mais avant de se lancer dans un jeu il faut pas mal d'experience dans le moteur, alors qu'avec de bonnes notions de programmation et quelques tutos on peut obtenir un bon résultat sur UDK ou Unity3D.
Bref, tout les gouts sont dans la natures, mais je pense que pour une équipe amateur qui veut un développement rapide et beau, les games engines "tout en un" sont les mieux placés, mais si on veut un contrôle total, Ogre ou ses homologues sont un choix. C'est vrai que c'est tellement plus gratifiant de pouvoir connaitre l'interieur de cette mécanique Je pense donc que vous avez tout deux raisons, et qu'il en faut pour tous (Gwenn l'a bien précisé d'ailleurs).
Ben encore une fois on a juste pas le même objectif pour nos jeux. Toi tu admets que le visuel ne t'intéresse pas, ça se voit, c'est pas un drame, c'est un choix mais faut aussi admettre que sur le plan visuel on ne voit jamais de travaux amateur aboutis en se passant de moteur de jeu.
Ce n'est pas parce que ça ne m'intéresse pas que la technologie que j'utilise en est dépendante, mais si ça m'intéressait je passerais plus de temps sur les assets pour avoir un résultat de plus haut niveau, rien ne me limite la dedans vu que la techno sous jacente en est capable techniquement, c'est un choix tout comme celui de ton projet est de reprendre un type de jeu populaire et peu innovant avec de joli graphismes, chacun ses priorités.
Citation : Gwenn
Le truc, c'est que le moteur de jeu n'a aucun impact sur le gameplay, en revanche il favorise considérablement la création visuelle et audio. C'est gagnant sur tous les points.
si tous les points sont "visuel et audio", d'accord, si pas, tu peux relire les arguments que j'ai donné dans mon premier post à savoir la compatibilité multi os, le support de machines moins puissantes, la personnalisation du moteur afin de faciliter la création d'un type de jeu donné, l'accès au source des lib pour les modifier si nécessaire...
puis audio,... avec openal tu as nativement la spatialisation audio et le support de nombreux format ainsi que les extensions EAX, je vois pas trop ce qu'on peut améliorer la dedans.
Ce qu'on peut améliorer, c'est d'avoir un système complètement clef-en-main avec tout ce que tu veux. Tu veux du TTS ? De la reco vocale ? C'est déjà dans UDK. Tu veux de l'atténuation propre avec de la reverb ? C'est déjà dans UDK. tu prenais le son comme exemple, voilà déjà ce que je peux en dire sur un moteur particulier.
Maintenant, outre l'attaque perso sur "populaire et peu innovant" que je ne relève pas, tu ne saisis apparemment pas l'idée que... Le gameplay n'est pas imposé par le moteur de jeu. Tu as autant de liberté sur le gameplay avec UDK qu'avec OGRE, ou presque (je veux bien admettre qu'un Minecraft sera difficile à reproduire).
Le moteur de jeu doit s'effacer complètement, c'est son but. Qui peut prétendre que Dungeon Defenders ou Planetstorm soient des jeux peu innovants ?
Ce qu'on peut améliorer, c'est d'avoir un système complètement clef-en-main avec tout ce que tu veux. Tu veux du TTS ? De la reco vocale ? C'est déjà dans UDK. Tu veux de l'atténuation propre avec de la reverb ? C'est déjà dans UDK. tu prenais le son comme exemple, voilà déjà ce que je peux en dire sur un moteur particulier.
Tous ces effets, et bien plus sont géré nativement via les extension EAX d'openAL, ça existe depuis 10 ans. pour le vocale, c'est géré nativement chez moi via une autre lib open source(bien que je ne m'en serve pas vu les contraintes de bande passante).
Citation : Gwenn
Maintenant, outre l'attaque perso sur "populaire et peu innovant" que je ne relève pas, tu ne saisis apparemment pas l'idée que... Le gameplay n'est pas imposé par le moteur de jeu. Tu as autant de liberté sur le gameplay avec UDK qu'avec OGRE, ou presque (je veux bien admettre qu'un Minecraft sera difficile à reproduire).
Ravi que tu ne la relève pas car ce n'en était pas une, le FPS st un genre sur représenté et à la mode, tout le monde veut faire le sien, c'est un fait pas une critique, puis c'est pas un drame, comme tu dis.
je vais tâcher d'être plus précis vu qu'apparemment tu me comprends mal:
Citation
la personnalisation du moteur afin de faciliter la création d'un type de jeu donné
J'espère que ceci étant clarifié, tu ne craindras plus que je ne saisisse tes propos.
Indépendamment de ce que tu pense du FPS, le fait est qu'un moteur comme Unity3D ou UDK te permet de faire à peu près n'importe que jeu vidéo. Que ça soit un FPS cartoon à la Borderlands, un Diablo, un arena-shooter en 2.5D, un RTS, un jeu de football ou un GTA, en passant par les jeux de voiture.
Tous les styles graphiques sont possibles. Tous les gameplays sont possibles. Je ne comprends pas pourquoi tu semble convaincu que tu as plus de liberté : dans ton propre jeu, que fais-tu qui soit impossible dans UDK, concrètement ? Bon, l'aspect MMO clairement, et encore, mais plus ?
Indépendamment de ce que tu pense du FPS, le fait est qu'un moteur comme Unity3D ou UDK te permet de faire à peu près n'importe que jeu vidéo. Que ça soit un FPS cartoon à la Borderlands, un Diablo, un arena-shooter en 2.5D, un RTS, un jeu de football ou un GTA, en passant par les jeux de voiture.
Tous les styles graphiques sont possibles. Tous les gameplays sont possibles. Je ne comprends pas pourquoi tu semble convaincu que tu as plus de liberté : dans ton propre jeu, que fais-tu qui soit impossible dans UDK, concrètement ?
Bon je vois que même en utilisant des mots simples et en mettant en gras les passages important, ça passe pas, c'est pas grave...
Citation : Gwenn
Bon, l'aspect MMO clairement, et encore, mais plus ?
on peut faire des mmo avec UDK en étant amateur(donc sans payer la licence pour toucher au code source)?
Le moteur réseau de l'UDK est pas fait pour ça. Y a possibilité de faire du DLL Binding, mais si j'ai bien compris le passage c'est uniquement dans la licence code source.
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
Clairement le MMO c'est très difficile, sauf à se contenter de 64 joueurs par map, ce qui est vite pénible. Notons que ça a été fait dans Global Agenda.
Le MMO c'est un "genre" à part de toute façon. MMO amateur 3D qui marchent aujourd'hui, connait pas, j'attends qu'on m'apporte des exemples si jamais il y en a
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."
"J'aimerai faire un jeu, mais pas un gros jeu hein. Un petit truc simple du style MMO."