Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
L'Unreal Engine et le Cry Engine sont gratuits. C'est le top de ce qui existe, c'est documenté parfaitement, où est le souci ?
http://udk.com/documentation
http://freesdk.crydev.net/dashboard.action
"Parcours du combattant", deux clics de souris, c'est peut-être un peu excessif non ?
Question par rapport à ces gros SDK :
Unreal il a pas mal d'outils: mattinnée, unreadEd etc ...
il demande un peu de temps pour maitriser quand même , y compris ses scripts.
Arriveras tu à importer facilement tes personnages et animations ?
Idem avec Far Cry.
Si le but c'est juste du modding c'est un bon choix.
Si c'est un jeu différent du FPS , je sais pas si ce sera facile ce jouer et changer la logique en place ?
Le script Unity 3D est simple je trouve y compris le framework de gameplay à comprendre, tu peux faire tout genre de jeux avec si t'as compris comment utiliser les collision ; la physique et le framework.
Si c'est pas du modding , et pas de réutilisation des textures / modèles livrés avec le SDK :
seras tu capable de générer des textures de grande qualité avec bonnes couleurs / luminosité, y compris des personnages pour créer un jeu rivalisant avec les grosses productions ?
Là aussi je dirais une simple méthode :
- voir quel jeux on veut faire (à quelle échelle : indie, AAA ??)
- on est seul ou en équipe
- Quel moteur/techno est le plus approprié
- essayer et au bout d'un mois faire le bilan : problèmes/facilités et qu'est ce qui a pu être réalisé !
Ils sont gratuits dans le cadre de quelle utilisation?
Je suis intrigué pour le coup, quelles sont les conditions de redistribution?
Ce qui suit est hors sujet mais... Wow...Envoyé par seeme
Tu as réussi?
Parce que bon, dans le meilleur des cas, j'imagine qu'il soit possible de savoir au bout de combien d'appels ça a planté, mais au delà... et l'adresse binaire d'une fonction, pour retrouver à quoi ça correspond dans le source, je serai curieux de savoir comment faire?
Je connais bien (de nom) le désassembleur IDA, mais même lui il me semble qu'il faut un certain nombre d'informations sur le source du programme pour avoir un truc compréhensible, de mémoire. (bon, ça fait très longtemps que j'ai pas touché d'asm, j'ai jamais appris à l'école non plus, et j'ai jamais été plus loin que le crack - mea culpa j'étais ado - d'un jeu simple donc on peut juste estimer que j'ai des notions d'asm et 7-8 instructions qui me restent en mémoire)
Et j'admet que je ne pensais pas que l'on puisse poser des questions sur du code ASM à en entretien... vais p'tet me remettre aux désassembleurs/débogueurs moi ^^'
Par curiosité, c'était quoi le poste ciblé? Dans quel domaine la boîte en question bosse?
On s'écarte un peu des moteurs 3D avec le désassembleur , c'est plus "in house"
ou custom ,même si utilisé par id Software ou autres qui optimisent quand ils créent "leur" moteur 3D (tables de cosinus précalculés, certains calculs en nombre après la virgule restreints , avantages des rotations sur les bits de l'assembleur etc ...)!
En fait la le topic aurait mieux fait de s'appeller :
"Quel moteur 3D utilisez vous ou avez vous utilisé et quels sont ses avantages/inconvénients"
Sujets maintes fois abordés dans divers forums( devmaster etc ...)
Le moteur parfait existe pas, et faire un jeu 3D c'est surtout une question de motivation, remise en cause (délais, problème d'un moteur 3D), compromis etc ...
J'ai déjà vu des jeux super graphiquement sur de simple moteurs 3D qui tombent à l'eau car un des deux gars de l'équipe le codeur n'est plus dispo ,
contraintes de la vie réelle (copine, job, boulot etc ...) par rapport au projet !
Un jeu super fait par un seul gars avec Ogre 3D :
http://www.ogre3d.org/forums/viewtop...b2a85491849c36
Ca lui aura pris quelques années (3 ans je crois ou plus ??) à faire tout seul !
Mais le résultat est à la hauteur, il a fini par faire appel à un artiste 3d une fois ça tournait pour améliorer les graphiques et c'est vrai que le résultat et super par rapport au début !
Quand j'ai vu des bouts de code il a partagé, c'était assez complexe, et énorme en termes de code et encore on a vu qu'une infime partie rien que pour certains parties de la logique de IA et collisions !
Ca prouve bien le fait de rester motiver avant tout, et faire peut être d'abord un prototype qui marche, rajouter des chose au fur et à mesure.
Et choisir le moteur en fonction de ses possibilités( type de coding) et outils qu'offre le moteur 3D (terrain, workflow, facilité d'import etc ...) !
http://udn.epicgames.com/Three/ActorX.html, ou tu peux bosser en FBX (idem que Unity).Arriveras tu à importer facilement tes personnages et animations ?
Ca marche même mieux qu'Unity, du moment qu'on respecte les règles de la profession (bosser sous Max).
Il n'y a pas de logique en place, c'est un moteur, pas un jeu. Si tu veux une caméra orthogonale fixe en vue de côté pour faire un jeu de plate-forme, tu l'auras.Si c'est un jeu différent du FPS , je sais pas si ce sera facile ce jouer et changer la logique en place ?
Shadow Complex est un jeu Unreal Engine. Tu peux faire un Tetris en vue de dessus et en 2D si tu veux.
UnrealScript est gentil et facile (mais pas de NativeClasses dans la version gratuite, à remplacer par la fonctionnalité permettant d'attaquer tes propres DLL). CryEngine accepte le C++ dans sa version free (gros point positif).
Gnh, on parle de développement ici. Ce n'est pas le moteur qui fait l'artwork. Après un game-artist trouvera tout ce qu'il cherche comme fonctionnalités/outils : http://udn.epicgames.com/Three/Mater...UserGuide.htmlseras tu capable de générer des textures de grande qualité avec bonnes couleurs / luminosité, y compris des personnages pour créer un jeu rivalisant avec les grosses productions ?
Un peu bizarre cette propension à vouloir bifurquer sur des toolkits plus cheap comme Unity, ou un moteur comme Ogre. Avec les outils adaptés, c'est bien plus simple. Le parcours du combattant, c'est plutôt justement ces outils de milieu/bas de gamme, qui se veulent accessibles, mais en réalité compliquent plutôt les choses - à la fois au niveau de l'import des assets (Unity fait planter mon Max!), de la documentation, et des fonctionnalités de base (le networking dans l'UDK, c'est finger-in-the-nose).
C'est très difficile de faire un beau trou rond dans un mur avec une perceuse pas chère de chez Carrefour.
La seule question c'est la thunes : vais-je gagner + de 50.000€ avec ce jeu, suis-je prêt à provisionner les royalties pour Epic ou Crytek si je sors de la licence free.
Il me semble que le site de Unity dit bien que c'est un outil pour créer du casual gaming, aussi il n'est pas le même objectif ni donc le même potentiel que l'UDK.Je ne suis personnellement pas un grand fan d'unity, mais bref
Si je prend la vidéo présentée en galerie sur le site d'unity, je trouve qu'en ce qui concerne les rendus non réalistes, unity s'en sort bien mais sur le réaliste, clairement.. non. Pour moi unity prend une orientation développement web et tablette (prototypage aussi), ils ne cherchent pas à se positionner face à des monstres comme l'udk que tu citais (si je suis méchant je dirais aussi que même sur le non réaliste, y a de la marge par rapport à un little big planet par exemple).
Voilà un lien vers l'article:
http://unity3d.com/support/documenta...lGamesBusiness
Le problème de l'UDK et de CE3 est qu'ils sont trop orientés vers un seul style de jeu.
Dans les deux, par exemple, et après de nombreux essais, des journées entières de recherches, je n'ai toujours pas réussit a faire des véhicules qui fonctionnent comme je le souhaite, et pourtant ce dont j'ai besoin est largement plus simple que ce qu'ils proposent.
Or, j'apprend la semaine dernière que, visiblement, il ne faut pas utiliser les véhicules de l'UDK pour faire ce que je veux, c'est impossible...
Avec Unity ça m'a prit quelques minutes en lisant la doc et j'avais ce que je voulais. Mais problème, le code réseau d'Unity est réduit au minimum, et tous ceux qui codent du réseau en jeu vidéo savent que c'est loin d'être simplement une affaire de synchronisation d'état et de remote procedure call.
Donc d'un coté j'ai pas les véhicules, de l'autre j'ai pas le multijoueur. Difficile pour un jeu de combat spatial en ligneAlors qu'est ce qui cloche ? Est-ce que c'est mon projet ?
La réponse est clairement non. Le code des véhicules de l'UDK est trop orienté et les sources trop fermées, quand au réseau d'unity ils ne se sont pas donné les moyens d'en faire un vrai système pour les jeux en ligne. Ces deux problèmes sont résolubles sans perte de FPS drastique. Encore faut-il que les développeurs s'en donnent les moyens.
http://udn.epicgames.com/Three/Vehic...icalGuide.html
L'idée même de "moteur" signifie "pouvoir overrider tout pour en faire ce qu'on veut".SVehicleSimBase
Much of the simulation work for a vehicle is handled inside a SVehicleSimBase object. This is broken out as a separate object so that you can create a game-specific SVehicle-derived base class for all your vehicles, but still re-use code for different vehicle types.
Je suis bien d'accord que UKD a du code trop mis en place.
A coté Unity ou d'autres tu peux changer dans n'importe quel sens la physique ou faire toit même certaines choses.
Et puis suffit de jeter un oeil aux forums de Unity (showcase) pour voir le nombre de jeux que les gens arrivent à commencer et certains vendent !
Pareil pour d'autres moteurs plus ouverts que les gros SDK, qui restent plus simples, tout n'est pas déjà codé aussi !
UT3 : y'a des vidéos de plate forme 3D ou combat à l'épée, mais bon c'est un
peu sortir la grosse artillerie pour tuer une mouche
Ca marche même mieux qu'Unity, du moment qu'on respecte les règles de la profession (bosser sous Max).
Désolé j'ai un boulot , mais je n'utilises pas de logiciels pirates, surtout si je dois
vendre un jeu sous Steam ou autre et qu'on me demanderait les licenses !
3DSMAX c'set trop trop cher , et pas mal de Indies utilisent Blender qui est totalement gratuit et super complet (ou d'autres programmes cheap) !
Le plus cher que j'ai acheté il y a un an a été Zbrush !
Et je comptes pas remettre autant surtout si je ne vends rien.
Même Unity PRo , je ne l'achèterai que si je vendais qq chose avec la version Free, si je veux plus et pas payer une Pro version j'irai vers d'autres moteurs 3D !
Le mieux, si t'es 3DSMAX e tqeu tu as la license et veux à tout prix rester dessus et SI tu as un vrai projet de Jeu :
tu essaies, tu commences et d'ici un mois tu nous dit qu'est ce qu'il en a été finalement ?? quelles sont tes conclusions ?
J'ai essayé de me mettre à UDK ... Doc par ci par là, pas sur ce que je voulais , fallait fouiller plus ... j'ai essayé de trucs, bref ... je me suis même rabattu sur un simple 3D Game Studio et là ça a été rapide pour mettre des peronnages qui chassent celui du jouer en vue 3° personne et sur un terrain avec des objets 3D !
Y'a d'énormes différences entre ce que dit un moteur 3D et quand tu passe à la pratique !
Un moteur idem ventait , super facile , tout est faisable , même en script :
Je l'ai acheté : pas trop cher , indie style 160 Euros.
Mais bon quand tu te rends compte les super scènes crées sous le super editeur avec super outils de terrain , quand t ufasi un loadWorld()
ça ne loade que le terrain et que les noms de entités :
à toi de loader les entités (characters, lights etc ...) dans une boucle de recherche , et que tu croyais il faisait ça t'es super déçu
Idem pour le framework y'en avait pas finalement : à toi de gérer
l'update par frame de toutes les entités !
C'est faisable et certains le font , mais c'est super lourd quand on attend un moteur presque standard sue ce coté framework !
Et le script c'était Lua, et c'était limité , t upouvais pas tout faire !
La prochaine version va évoluer sur ces points ... j'attends de voir et achèterai pas aussi vite ou avant avoir bien créer quelque chose !
Donc méfiance des fois avec les annonces ou c'est facile etc ...
J
Créées un véhicule 3D à toi, importes le et fait le rouler sous UT3 avec sa propre inertie etc ... et montres nous après on se dira OK ; faut voir le travai ldemandé derrière ? la facilité d'intégration (import 3D , réglages, physique , code) ?
Mais je dis pas de ne aps utiliser UT3 ou l'autre, sur IndieBD.Com tu trouveras
de très bons projets Indie utilisant UT3 par exemple :
Un jeu de tanks , et un remake de terminator qui est bien sûr un FPS (simple modding dans ce cas) , mais super bien réalisé (caméra qui bouge comme jamais , effets de particules etc ...) !
Les moteurs sont là, suivant ta persévérance, et tes capacités , objectifs
choisis en un , et vois jusqu'où tu peux aller.
La boite est une boite de jeu vidéo, le code concernait une transformation géométrique sur un jeu ps3/360. En fait c'était pas si compliqué, on voyait assez vite qu'il y avait un adressage vers un pointeur null (et j'ai fait 1 an d'asm x86 donc encore quelques restes).
C'est bien joli de citer les vantardises des moteurs, mais entre les annonces et la pratique y'a un gouffre.
Je le redis clairement, et on me l'a confirmé sur le forum officiel, il est impossible de faire les véhicules que je souhaite avec les véhicule de l'UDK. La physique des véhicules ne le permet pas.
Voila exactement ce que je cherche comme mouvement[/URL] et ce n'est pas faisable avec les véhicules de l'UDK, alors qu'avec Unity ça se fait en 10min max.
Le code de SVehicleSimBase n'est composé que de variables et de code C++, aucune fonction à surcharger, aucune doc, rien. C'est le coeur du système des véhicules et on ne peut absolument rien en faire. Et toutes les classes sont natives, ce qui en dit long sur la totale inutilité du truc pour l'UDK. Tout est dans les sources fermées.
Pour ce qui est des moteurs de "jeu" courants (Unity, CE3 SDK, UDK, SHiva, NeoAxis et les autres), on se fout totalement de leurs capacités quand on est amateur. Même si on est pro mais indie - petite équipe, petit budget - le fait d'avoir l'un plutôt que l'autre n'influera pas vraiment sur le résultat final.
Tout simplement parce qu'un projet de jeu amateur/indie basé sur ces technologies ne va jamais être limité par elles.
En pratique, comme d'hab, les limitations les plus courantes sont la motivation et le temps disponible (ou l'argent, c'est un peu pareil d'ailleurs).
On va prendre un exemple : une petit équipe d'amateurs veut faire un Action-RPG.
S'ils choisissent l'UDK, ils vont facilement pouvoir créer une map, les déplacements du héros façon TPS, éventuellement un peu de script. C'est la force d'UDK. À côté de ça la doc est mal branlée et souvent obsolète (il y a peu d'exemples existants), l'import d'assets est assez mal foutu (oui oui, même avec 3DSMax), UnrealScript ne permet pas tout.
S'ils choisissent Unity, ils vont facilement pouvoir coder un peu n'importe quoi, mettre en place le pipeline de création d'assets ; d'une manière générale la doc (y compris les exemples existants) est beaucoup plus fournie. À côté de ça le rendu des ombres est moins bon, y'a pas de Kismet...
Bon, très bien. Sauf que tout ça c'est du détail : le plus important pour un jeu, c'est quand même le contenu. Et une équipe d'indie aura énormément de mal à en créer suffisamment, et pour ça, le choix du moteur n'aura qu'une influence minime (à la rigueur ça permettra d'importer des assets plus ou moins compliqués, mais dans les faits les différences ne sont pas énormes).
Conclusion, Udk ou Unity, même combat.
D'ailleurs regardez les rares jeux commerciaux indies réalisés sous l'UDK (The Ball, InMomentum, etc.) : vous trouvez vraiment qu'ils justifient l'utilisation de ce moteur, et qu'ils n'auraient pas pu être réalisés sous Unity, le Cry SDK s'il existait à l'époque de leur sortie, ou même le vieux Source Engine...?
Erf, ElGat0, je t'aurais bien mis deux points mais le forum ne le permet pas
Je rajouterais que même une bonne équipe indie voulant développer un jeu "AAA" ne serra pas limitée par l'aspect optimisation du moteur. Prenons par exemple des jeux réalisables par disons 5 personnes en deux ans avec ce genre de moteur : Counter strike, Portal, Left 4 Dead (me demandez pas pourquoi ils sont tous sous source engine). Ces jeux sont faisables en amateur, mais avec les bons outils.
N'importe lequel de ces jeux pourrait être développé avec les moteurs les plus cités. La qualité des outils, de la doc, et la modularité deviennent les principaux soucis et peuvent faire toute la différence.
Quand je lis que d'après certains il ne faut plus chercher à optimiser, que de toute façon les cartes graphiques aujourd'hui sont capables d'avaler n'importe quoi, j'hallucine quand même pas mal.
* D'abord le goulet d'étranglement, aujourd'hui, c'est souvent le CPU qui a pour tâche de préparer le rendu. Alors, pour calculer vos bouncing boxes et autres, vous n'allez pas utiliser les instructions SIMD sous prétexte que trois lignes d'assembleur vous tueraient ? Pourtant, si on compte 40ns sans elles pour multiplier un vecteur par une matrice, avec 100k multiplications (4ms) vous avez déjà bouffé 30% de votre budget CPU pour une frame.
* La carte graphique peut avaler n'importe quoi ? Pourtant on ne peut toujours pas envoyer plus de 2000 batches par seconde sur une bécane décente. Alors, on envoie tout dans la tronche du moteur on espérant que lui s'occupera de batcher ou bien on comprend comment il le fait et on lui facilite le travail ?
* Développer en C# ne demanderait qu'à faire attention au GC... Oui, enfin, un octree en C# va quand même vous faire sentir les 10 octets de surpoids ajouté à chaque objet, ça jouera sur la localité des références. De même que, lors des mises à jour de l'arbre, le compteur de références implique de multiplier le coût de certaines opérations par cinq. Certes on peut très bien utiliser le C# pour des développements 3D et obtenir un résultat bluffant, je l'ai déjà fait. Mais la limite est plus vite atteinte et ça se voit sur la config minimale que les clients peuvent utiliser.
* Le mobile est là. Des CPU bien moins puissants, des GPU beaucoup plus limités, des batteries qui s'épuisent vite.
Bref... Évidemment, si on fait un jeu bien en-dessous des capacités actuelles des cartes, pas de souci. Si on fait un jeu au top mais en se satisfaisant d'un maigre 30fps sur les bécanes récentes (parce que de toute façon le dév n'a testé que sur sa propre bécane) et que l'on se fiche des machines réelles des clients ("désolé que vous ayiez dépensé 10€ pour notre jeu qui ne tourne qu'à deux fps mais sur notre SLI octocore refroidi à l'azote liquide ça tourne plutôt bien"), bon... Dans ces cas-là on n'a pas besoin d'optimiser. Pour le reste, en revanche...
Tous les gros jeux sont bien sûr optimisés à fond :
que ce soit coté level (BSP, culling , terrain LOD), st surtout coté Modèles 3D de la scène : LOD, distance affichage à partir duquel on les affiche, système de régions etc ... etc ...
Y compris coté ombres, on peut paramétrer de simple ombres (style Blob projection) àa des plus poussées et sur quoi on les veut dans certains jeux : personnages, herbe, décors (poussées , simples etc ...) ....
Y'a même des LOD coté IA quand les ennemis sont loin, on les anime pas et l'IA reste plus basique jusquqe à ce qu'on les aperçoive !
Faut arrêter de dire n'importe quoi, si on avait pas besoin d'optimiser, alors on aurait des personnages avec des cheveux en 3D et physique , tous les vêtements en Physique 3D aussi, et que des trucs super arrondis (bien que la tesselation le permet) !!
Bref ... l'optimisation permettra, je penses surtout LOD (on peut faire 3 niveaux, des jeux en font même jusque à 5 !), existera toujours car ça permete de gagner énormément de puissance :
On ne va pas pas appliquer des move /rotation de tous les polygones d'un personnage qui ferait 15000 polygones quand il serait au premier plan en détail ??? s'il n'avait pas de LOD, tu appliquerais les calculs même quand il serait pas trop visible : bonjour les performances :
tu en aurais 3 , 4 maxi dans le jeux et suivant la complexité du décor avant que ça rame super !
Bon topic intéressant, et pouruqoi on répondrait pas plutot à la question finalement plutot que de dire qui est le meilleur ?
J'utilises 3D Game Studio depuis la version A6 ; on est à A8 :
Bad points :
-il est très orienté coders quand même , chaque béta c'est surtout ajout de fonctions de programmation 3D
- Il est un peu pénible coté import, pas aussi direct que Unity 3D, il faut passer par une autre appli en plus de l'éditeur de world livré dans le package.
- interface dépassée ,style vieilles fenêtres windows
- pas de tarrain editro , ni vegetation
- Shaders pénible à appliquer : faut les choisir, avoir les fichiers, et mettre 2,3 lignes de code en plus
- Pas de deffered lightening
- BSP dépassé et pas optimisé dans la version standard commercial
Good points :
- Script super Facile à coder
- on peut attacher des actions (script) qui peuevent appeller des méthodes aussi à n'importe quel objet 3D
Tu creés : SoldatEnnemiAction() : t'as plus qu'à placer ton soldat dans la scène, lui attribuer l'action via une liste de sélection( auto générée) et tu peux juste le dupliquer partout après !
- bon import des modèles FBX (mais y'a une règle à suivre concernant le centre de gravité)
- on peut arriver à importer des lightmaps depuis Blender (mais là aussi faut pas mal magouiller , pénible !!)
- Shadows, fullscreen shaders dans la version commerciale (160 Euros en gros )
- Beucoup de possibilités : code livré pour les éditeurs; interfaçage avec .Net possible.
- performance pas mauvaises pour petit jeux et moyens :
En y mettant des textures , modèles 3D de qualité et du travail voilà ce qu'il est possible de réalisé (jeu fait avec la version A8) :
Bref, je l'utilises car le protoypage va super vite, on peut créer rapidement.
Bref c'est vraiment Indie, kids des fois, des seniros l'utilisent, certains c'est même pour des simulations pour des clients.
Pour conclure, petit moteur, facile à utiliser, mais il manque des outils( terrain, vegetation), workflow pas terrible si on est pas habitué et au final
on peut réaliser de bons jeux (steam ou autre) !
Le prochain je vais utiliser ça risque d'être Unity 3D qui est similaire coté simplicité et script framework, j'avais testé et l'import passait bien depuis du FBX ou Blender et vu le nombre de jeux qui sont réalisés et la qualité des plugins créés , c'est un très bon choix !
Surtout si je vises du Apple mobile , plein de jeux ont fait leur preuve avec ce moteur sur le Apple Store.
Seul bémol , le prix de la Pro, je dirais à prendre qu'une fois que l'on a réussi à vendre un jeu avec la version Free par exemple.
Ou alors si on est passionné et le veux à tous prix ??
Après y'en a d'autres de qualité comme :
Essenthel Engine (mais j'ai pas envie de faire de C++)
Ogre 3D avec des jeux tels que TorchLight et autres jeux aventures 3D, course futuriste; Salvation Prophecy etc ...
(Là aussi c'est que le moteur visuel et là aussi C++ j'ai pas envie, vaut mieux avoir une team)
etc ...
@Acropole : la vidéo que tu postes comme exemple de ce que tu juges impossible à réaliser en utilisant l'UDK, c'est une démo utilisant l'UDK. Y'a un moment où faut peut-être te remettre en question. "Moteur 3D" ça ne veut pas dire "logiciel servant à faire des jeux complets juste en cliquant sur des icônes" : ce genre de soft ça n'existe pas, ça ne peut pas exister. Si tu ne sais pas appeler une rotation sur un quaternion, ou pourquoi on utilise une matrice 4x4 pour définir une transformation, tu vas galérer pour faire un jeu.
"Etes-vous satisfaits des moteurs de jeu que vous utilisez?" - OUI EVIDEMMENT!!!. On a quand même une chance incroyable de ne pas être obligé de faire comme il y a 7-8 ans, à savoir, commencer from scratch sans moteur. Que ce soit des moteurs classiques comme UDK/Cry/Id Tech4/Ogre, ou des solutions plus orientées "fun" et prototypage comme Unity et d'autres, on peut pas dire que ce soit compliqué de trouver chaussure à son pied. En aucun cas un "parcours du combattant".
Quand je lis des "j'ai pas envie de faire du C++" ou "je ne veux pas acheter Max" sur un sujet sur le développement de jeu vidéo, je m'esclaffeMieux vaut changer de hobby dans ce cas-là
Tu n'as pas bien lu ce que j'ai écrit jeroy. J'ai dis que c'est impossible à faire avec le système de véhicule de l'UDK, pas avec l'UDK tout court. Je sais reconnaître la map Deck-17 sur laquelle j'ai joué des heures sur UT 2004.
Le problème c'est que ne pas pouvoir utiliser le système de véhicules de l'UDK pour faire un véhicule sur l'UDK me parait aberrant. On marche sur la tête !
Je sais aussi très bien me remettre en question mais au bout d'un moment, après des jours de galères, quand on m'apprend sur le forum officiel qu'en fait c'est impossible, ou pour l'import FBX qu'ils ont mis à jour vers la version 2011 sans prévenir personne et que ça n'importe plus les collisions avec l'ancien plugin, je me rend compte que se remettre en question sans jamais remettre en question les autres mène dans une impasse. D'où la nécessité de cette discussion.
Explique moi pourquoi il est impossible de contrôler les rotations des véhicules dans l'UDK par script ? Absolument aucune fonction ne permet de le faire, dans aucune classe. Tout se passe dans le SimObject qui est 100% natif, donc non modifiable et dont on ne peut même pas lire les sources pour comprendre ce qu'il fait.
Bref, je ne vais pas discuter de ça, je sais que ce n'est pas possible et je sais qu'en aucun cas ça nécessiterait un supercalculateur refroidit à l'hélium liquide pour gérer des véhicule qui tournent différemment en fonction de scripts au lieu d'être codés en ASM par Carmack, Einstein et Chuck Norris réunis.
De plus, vu les dizaines de milliers de lignes de code en UnrealScript, il est clair que les questions d'optimisation bas niveau sont à des années lumières des problèmes de modularité des moteurs auxquelles je fais allusion.
Et merci d'éviter de supposer que mon niveau en code est proche du zéro absolu. J'ai suffisamment d'expérience dans le domaine pour savoir de quoi je parle. J'ai déjà codé mon propre moteur 3D en C++ avec shaders OpenGl, GUI, système de fichier perso avec import depuis 3ds max. Il n'est pas question non plus de faire un jeu en cliquant sur trois boutons.
Apparemment le sujet tourne plus sur les jeux 3D,en fait le sujet c'est moteur 3D ou moteur de jeux vidéo ? x)
Si on parle de moteur de jeux on peut faire du 2D est la aussi faut 'optimisé' le code(surtout si on fait du software avec la SDL par exemple).
Pour le jeux 3D la difficulté je pense ce trouvera plus sur le contenu que la qualité ,rien n’empêche de faire un jeu low poly,on aura pas besoin optimisé a fond par contre faire un RPG 3D low poly , il y aura beaucoup a codé et a créer.
Mais bien sur je parle en tant que jeux amateur possible a faire,je doute que faire un jeu de qualité pro en amateur soit faisable ,(et j'ai envie de dire pk on parlait finalement ? =X ).
Ca me rappelle un clone bien connu de Super Mario qui parvient à ramer sur des machines modernes.
On peut aussi regarder du côté de WPF par exemple, qui n'est pas du tout optimisé (il suffit de regarder les appels envoyés au GPU) et que l'on peut facilement mettre à genoux.
Heureusement en 2D ça reste encore assez simple : du batching, une structure pour l'ordre de rendu, etc. Mais c'est définitivement nécessaire dans la mesure où les GPU ont évolué en fonction des besoins en 3D, qui sont très différents des besoins en 2D (peu de sommets par primitive notamment, abandon du stipple sur Open GL ES, etc).
@Acropole
En général ce qui se trouve dans des scripts n'est pas sensible en termes de performances : une fonction exécutée cinq fois par seconde n'a pas besoin d'être optimisée.
@Jeroy :
Quand je lis des "j'ai pas envie de faire du C++" ou "je ne veux pas acheter Max" sur un sujet sur le développement de jeu vidéo, je m'esclaffe Mieux vaut changer de hobby dans ce cas-là
De quelle planète tu débarques ?
J'étais là aux débuts où fallait galérer avec DirectX c'était énorme rien que le code pour initialiser l'application.
Et désolé : Blitz 3D : c'est du basic , des gens on vendu des jeux avec , ils n'avaient pas 3DSMAX et ne faisaient pas de C ++.
Idem Avec Unity 3D , un paquet de Indies vendent des jeux sur AppleStore, ils utilisent juste le Script de Untiy ou du C# pour certains et certains utilisent Blender qui fait autant la modélisation que l'animation (et gratuit) !!
As tu été sur les forums de vrais moteurs 3D : Unity 3D, Blitz3D, BlitzMax, TrueVison 3D (même s'il est dead), 3D Game Studio, Dark Basic Pro , Monkey Engine par le créateur de Blitz3D ?
Y'a pas que le C++ ! Et y'a pas que 3DSMAX surtout vu le prix exorbitant de la license pour une indie ou surtout pour le loisir , on va pas verser des sommes exorbitantes si on est pas sûr de vendre quelqeu chose ou si 'est un hobby justement !
En plus tu dis change rde Hobby : justement c'est un hobby : on fait ce qu'on veut , on peut choisir un moteur 3D permettant de tout faire en script (sauf si tu es un pur coder). Et on est libre d'utiliser Blender 3D, FragMotion,
Silo 3D, Zbrush .... Y'a pas que 3DSMAX lol
Y'en qui ont une license officielle de Maya et n'utilisent que ça , d'autre c'est SoftImage, d'autres c'est Modo , d'autres c'est BLender etc ...
et avec les format Fbx et Collada de plus en plus répendu au sein des moteurs 3D pour l'import, tout outil de modélisation/sculpture/modeling qui sait exporter à un de ces formats suffit !
Ca me rappelle des personnes braquées et fanatiques d'un moteur 3D, qui s'adaptent pas, quand le moteur vieillit et ont finalement perdu leur temps et produit aucun jeu, à la place de savoir s'adapter (comme dans la vie)
changer de moteur 3D pour au final produire un jeu (voire vendre) !!
A t'entendre tu débarques et pour toi faire un jeu vidéo se résume à :
C++ et 3DSMAX impérativement
Ah la la l'ignorance et l'arrogance .....
Essaie d'abord ces moteurs 3D qui existent, vas sur les forums, demnade quels ont les outils possible en dehors du moteur 3D (modeleur, dessin (gimp) etc ... etc ..) avant de lâcher n'importe quoi !
La prochaine fois il vaudrait mieux cibler un moteur 3D style :
"Unity 3D vous plait il , parlez de votre expérience"
car sinon on récolte un peu de tout , entre le gars qui a jamais essayé et ne sait pas de quoi il parle et n'es même pas au courant des jeux vendus avec tel moteur 3D , ou ceux qui y connaissent strictement rien en terme de techniques ou ce qui croient en un monde fermé et restreint
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager