Bonjour,
voici l'adresse d'une discussion dédiée aux jeux vidéos en Flash :
Jeux vidéos en Flash
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
Jeux vidéos en Flash
Bonjour,
voici l'adresse d'une discussion dédiée aux jeux vidéos en Flash :
Jeux vidéos en Flash
Bonjour,
ça faisait un moment que je n'étais pas passé sur ce forum; mais je me permet de réagir quand à ce qu'à dit Bob25 il a quelques temps:
Alors là désolé de te casser ton image idylique du programmeur dieu et du game designer feignasse mais tu es à 2000 km de la réalité.Envoyé par bob25
ceci dit parmi ces jeunes un peu trop enthousiastes il y a deux catégories à sauver:
-les game-designers qui rebutent au début car ils savent tout faire sauf développer, dessiner, modéliser, écrire un scénar, paperasser, démarcher...
Malgré ce premier aspect peu engageant il est toujours pratique d'avoir un ou deux designer enthousiastes et motivés sous la main pour leur déléguer tout ce qui est facile mais que vous n'avez pas le temps de faire: découpage des maps dans l'editeur, texturing et uv, copier-coller des 21549821 dialogues du scénario, positionner les 500 lampadaires et les 2000 arbres sur le circuit, enregistrement des bruits, site en cms...
Mais ne leur parlez pas de prog ni de quoi que ce soi de compliqué qui fait mal à la tête: vous allez leur casser les c... s'ils ont choisi un boulot de feignasse ce n'est pas pour rien
Voulant moi même devenir un jour GD pro (et me contentant pour l'instant de faire mes armes sur un projet perso), le vrai GD sait : développer, dessiner, modéliser et écrire un scénar; plus exactement, un vrai GD est un touche à tout ayant suffisement de notions pour pouvoir comprendre tout ce que peuvent raconter les différents intervenants avec qui il travaille.
Là tu confond le kévindouzant "Je ve fer 1 je et jamen lé idé" et le GD... totalement à côté de la plaque...
Ensuite pour " paperasser, démarcher", c'est le rôle du chef de projet; pas du GD; même si les roles se confondent des fois dans les petites équipes.
Enfin tout ce que tu cites comme étant le travail du GD n'a rien à voir avec le vrai travail d'un GD; mais ceux mélangés des level designer et des infographistes.
Mais de tout le tissus d'aneries que tu as sortis, ce qui me choque le plus c'est de dire que le GD a choisi un boulot de feignasse... Surtout dans le domaine amateur; où 99.9% du temps il sert de bouche trou multifonction, d'infographiste, de programmeur de secours et de leveldesigner; quand c'est pas de mod 3d. Et plus encore dans celui de pro où le GD a un travail d'encadrement et doit être en permanence sur le dos des autres pour faire en sorte que le boulot soit fait comme il doit l'être (sans compter les docs de x centaines de pages et les storyboards que se tape le GD...).
Alors si tu veux savoir ce qu'en pense la "feignasse" que je suis; je passe environ 35 à 40h par semaine sur mon projet à faire tout ce que le developpeur n'a pas du tout envie de faire, parce que coder c'est amusant mais le boulot de chinois derrière... Sans façon.
En tout cas c'est avec ce genre de discours que tu ne fais que renforcer l'idée qu'un jeu c'est d'abord de la programmation. En vrai, la programmation est une étape cruciale d'un projet de jv; mais ne représente qu'une infime partie du travail à réaliser; sauf à vouloir refaire tron ou tétris.
Ceux là n'ont besoin de personnes pour les aider puisqu'ils ne font qu'apprendre à programmer. Au final ils feront un jeu vide de contenu et sans intéret aucun puisqu'il s'agira d'un énième clone de tron.
Ce seront par la suite d'excellents programmeurs cherchant des "chinois" pour faire le contenu de leur jeu; ou alors ils s'arreteront à faire des jeux laids graphiquement et sans contenu puisqu'il faut mieux être seuls que mal accompagnés.
Là je suis d'accord, de toute manière on les reconnait au premier coup d'oeil...
Y a une différence entre ceux là et les pfda? EN règle général, une remarque sur le fait que les fangames sont illégaux suffisent à s'en débarasser.
Ah là là, l'égo démesuré des codeurs nioubies
Enfin perso je dirais qu'il est toujours intéressant de les conseiller. Ils se vexent mais l'info fini toujours par arriver au cerveau... SInon ils ne sont pas fait pour ce métier.
Je te contredirais en citant l'histoire d'un certain Monsieur S. qui après avoir attendu pendant 5 ans que son mmorpg lui tombe tout cuit du ciel sans rien faire a un jour décidé de changer de projet. A cet occasion j'ai voulu travailler avec lui; puis un jour suite à une remarque comme quoi s'il continuait de bosser comme il le faisait son 2e projet deviendrait lui aussi un PFDA s'est faché tout rouge et est parti apprendre à coder.
Dans 3 semaines il présentera une démo jouable de son MMoRPG au Festival du Jeu Vidéo...(il se reconnaitra et je vais encore me faire taper).
De mon côté je présenterais à ce même FJV un projet de RPG de qualité presque professionnelle codé en C# et utilisant FMOD, TV3D 6.5 et des script XML et avec une équipe d'une quinzaine de personnes derrière...et qui pourtant est passé pendant 2 ans pour un PFDA sur ce forum; et sur lequel je bosse comme une chinoise depuis plus de 3 ans. Comme quoi....
Pub en passant pour le PFDA en question n'est ce pas : http://www.pentacles-mayhem.com
pour en revenir au post initial, voici ma petite expérience et mes rares réflexions.
Tout d'abord, je n'ai absolument aucune compétence dans le domaines, ni programmeur, ni musicien, ni graphiste.
J'ai longtemps joué à un jeu de plateau (bloodbowl) et je voudrais y jouer sur ordinateur, en réseau, avec mes copains déciminer aux quatre coins de la france et d'ailleurs. Du coup, j'ai cherché si ça existait. A part un très vieux jeu, très limité et un autre en java mais ne respectant pas les règles officielles, je n'ai rien trouvé. Si ce n'est, il y a 5 ans de ça, un type qui programmait ça dans son coin. Je 'ai contacté pour savoir comment ça avançait et si je pouvais aider (explication des règles, communication, traduction ...). Pendant quelques mois le projet avançait puis, il mourut. Un an plus trad, à force de mels et de cris de désespoirs, il repartait légèrement mais ce fut le chant du cygne.
En 2005, j'ai décidé de tout reprendre en main. L'ancien développeur (pascal) m'a aidé à monter un nouveau site, forum et j'ai commencé le recrutement. Pour ne pas répéter les erreurs du passé, j'ai demandé à ce qu'on ai une véritable documentation et que le développement soit très ouvert. Victorz a pondu un document de référence qui présentait le projet sous tous ces aspect https://projects.nekeme.net/svn/tbt/...doc/propal.pdf et quelques personnes nous ont rejoint. Démarrage en fanfare, graphistes de talent, mais là encore ça c'est essoufflé au bout de quelques mois. Depuis, on incorpore toujours de nouveaux venus mais la plupart font un petit tour et s'en vont. Seuls 2-3 programmeurs restent vraiment impliqués.
Sur un projet libre comme celui là http://www.towbowltactics.com/, la question de la motivation est essentielle et je n'ai pas trouvé de solution miracle. C'est dommage parce qu'on perd beaucoup de temps, à tout réexpliquer aux nouveaux venus et qu'en plus, un code qui n'évolue pas, ça n'est pas franchement attirant.
Ceci dit on a eu deux grandes chances
- que victorz ponde rapidement un document de référence, sérieux et efficace. Ce fut le véritable déclencheur de la renaissance
- que plusieurs dessinateurs talentueux nous rejoignent. La plastique est trop souvent le parent pauvre des projets libre ce qui ne les rends pas vraiment sexy.
Un autre élément important à joué, l'organisation du travail. Je ne me suis pas donné de titre (chef de projet ou autre) et j'ai demandé à ce que toutes les discussions soient publiques. Tout le monde à joué le jeu et contrairement à nombre de projets amateurs, nous n'avons aucuns titres et donc aucun ego froissé. Ca permet aussi à tout nouveau venu de s'impliquer facilement puisqu'il peut savoir précisément où en est le projet et quelles sont les problématiques en jeu à un moment T.
Mais, outre le problème de motivation, on est confronté à une difficulté encore plus grande, l'IA. En 2 ans, je n'ai trouvé aucune personne apte à coder une IA, même minimale pour ce jeu. Soit les compétences sont rares, soient ceux qui les possèdent ont peu de temps libre ou guère envie de les mettre à disposition du libre.
Malgré tout, le projet avance et je ne désespère pas d'arriver à un produit fini. Et j'espère prouver que grâce au libre, sans aucune compétence spécifique, on peut réussir à faire un jeu de qualité qui réponds à nos attentes.
PFA ?
Salut,
que signifient PFA et PFDA ?
Moi je dirai que ça veut dire Projet Fini d'Avance. Mais peut être que c'est pas ça
Presque, c'est projet foutu d'avance.
Afin d'éviter tout débordement, je vous prierai de limiter l'utilisation de ces termes trollesques sur ces forums.
Désespoir
Salut,
Merci pour PFA, c'est moche qu'il y en ait eu tant qu'on ait inventé un sigle pour les désigner. Les Projets Foutus d'Avance, je n'en connaissais pas dans le jeu vidéo, mais dans la réalité il en a : recherche du lieu et de la date du Big Bang, mise en équation de l'univers, mise en équation de l'humain.
Dans le jeu vidéo, je pense que c'est le décalage entre les moyens nécessaires et les moyens disponibles qui rend un projet infaisable. Si on s'y mettait à tous, aucun projet ne serait foutu d'avance.
Le problème c'est que la plupart du temps c'est ceux qui sont à la base du projet qui s'y mettent le moins.
akd> tu as compris de travers j'ironisais sur le fait que parfois du point de vue des dev les game designer servent à rien alors qu'en fait c'est pas vrai... même dans les cas de lanceurs de projets pas viables qui font du game design il ya moyen de faire des trucs avec eux quand même enfin bon je me basais sur 1 ou 2 que je connais j'ai peut etre généralisé 1 peu vite
excuse-moi si mon propos t'a offusqué
Ne t'inquiète pas je n'étais pas offusquée, je considère plutot mon post comme un recadrage.
Il est vrai que tu as présenté la vision habituelle des programmeurs. La critique était donc un peu 'facile'
(moi aussi je m'excuse d'y avoir été un peu fort ^^"")
j'ai surtout voulu plaisanter sur les visions contradictoires entre game designers et codeurs je ne prends pas vraiment parti
mais j'avoue que je ne connais pas grand chose au gamedesign je ne travaille qu'épisodiquement sur des jeux et c'est sur des tres petites productions et j'ai eu la plaisanterie un peu facile et j'ai parlé à tort donc je m'en excuse voilà
Ah, là je ne peux pas laisser passer ca. Tu étais en colère, mais quand même. Le travail d'encadrement c'est plutôt le chef de projet qui s'en occupe, voire les leads pour une grosse équipe, mais chacun restant dans sa branche. Je considère le Game Design comme une branche à l'égale des dèv, des graphistes, des musiciens, etc...
Idem ici, ceux qui apprennent à programmer sont peut-être de futurs GD, non ? Mieux, certains codeurs ont parfois de brillantes idées scénaristiques. Depuis quand un "petit jeu" ou un "jeu basique" est-il forcément laid et/ou vide de contenu ? C'est que moi aussi j'en ai ma claque de ces termes désobligeants. Les FPS et autres MMORPG full 3D avec un monde énorme ne sont pas les seuls jeux intéressants.
Mon projet personnel, qui consiste en un moteur de Point&Click, se veut "basique" mais n'en sera pas, pour le moins, laid et/ou vide de contenu.
Merci donc de remuer 7 fois tes doigts dans la poche la prochaine fois avant de taper de telles choses
Tiens une fille intéressée par la programmation des jeux vidéos ?
Il y a deux niveaux d'encadrement :Ah, là je ne peux pas laisser passer ca
-> Celui du chef de projet qui consiste à surveiller l'avancement par rapport au planning, gérer les risques et faire respecter les budgets.
-> Celui du GD est différent : il consiste à surveiller le bon avancement d'un point de vue contenu du projet (respect des règles de gestion du Gameplay, immersion du joueur, qualité des rendus 3D).
Le boulot du GD se situe à la fois en amont et en aval de la production, et normalement les parties les plus importantes sont réalisées avant le démarrage du projet en lui-même.
Tout le monde peut avoir des idées de scénario. Par contre les concrétiser de manière à pouvoir faire un jeu derrière en ayant une base de réflexion stable est plus complexe. Je rapelle qu'un GD a une connaissance large de la création d'un jeu et pas seulement des connaissances en programmation.
Tu l'as dit : ton projet est un moteur Point & Clic. Qui fera de ce moteur un jeu? Et avec quels graphismes? Quel maniabilité pour le développeur (qui sera l'utilisateur final de ton moteur)?
C'est malheureux mais bien souvent les programmeurs (surtout une fois qu'ils ont passés beaucoup de temps sur la partie prog pour faire un truc qui tient la route) ont tendance à bacler ou sous-estimer l'importance des graphismes et de l'ergonomie.
Ca ne veut pas dire que c'est une généralité; ni qu'il faut forcément faire des MMoRPG full 3D pour faire un bon jeu; tout dépend le public visé, le style que tu veux donner à ton projet; l'impact visuel que tu veux qu'il ai (et même avec de la 3D tu peux faire des choses "différentes" je pense entre autre au style Feuille de certains jeux de Nintendo) et tes gouts personnels.
( pour moi un moteur n'est pas un jeu, mais un des éléments qui permet d'en faire un, m'aurait-on menti?
@Mat. M : je suis découverte xD (je tiens à préciser que je suis aussi une programmeuse à la base; bien que ça soit en informatique de gestion ...)
Pour commencer un projet en temps que developpeur, sans aide exterieure, ce que je conseille est de faire le moteur en "volant" les graphismes et sprites d'autres jeux, puis de montrer le resultat a l'affichage, pour recruter de vrais graphiste. Ca evite de faire perdre du temps a des graphistes qui realiseront des illus et autre modeles 3D qui seront perdu car un programmeur a visé trop haut.
Dans un moteur, le langage de scripting ou la partie specifique au GD est souvent baclée; il faut se rappeler qu'un GD n'est pas sensé aller trifouiller le code et lire la doc des pointeurs refcountes pour developper les jeux; les developpeurs sont aussi sensés fournir le framework.
Les developpers sont souvent des gens qui n'en font qu'a leur tete; je veux dire, ils se mettent a ecrire un moteur 3D car c'est ca qui botte tout le monde (et parce que c'est a la mode) et ensuite ils osent appeler ca un moteur de jeu, alors que tant reste a faire.
Peut etre que le meilleur projet de depart serait de faire un moteur suffisemment flexible pour realiser un pong ET un tetris avec le meme moteur; et de reflechir alors aux outils que l'on met a disposition pour les scenaristes en herbe pour integrer leurs idees.
Coder un tetris c'est a la portee de tous les developpeurs qui souhaitent faire un moteur; etre capable de distinguer le moteur et les regles du jeu est quelque chose que les gens ne prennent jamais en compte.
Qui fera de ce moteur un jeu :
En premier lieu : Moi. Je m'y emploie en ce moment même en utilisant des sprites et images de fond trouvés sur le net (je dessine très mal). Une fois que le moteur sera capable de rejouer un jeu comme "Monkey Island" ou "Day of the tentacle", je considèrerai qu'il est prêt à servir.
A partir de ce moemnt là, je chercherais des graphistes, un scénariste (j'ai un début de scénar, mais comme tu l'as dit je n'arrive pas à le concrétiser ou à le finir
Plus tard : Tout un chacun qui le souhaitera, il est prévu qu'il pourra être utilisé par tout le monde. Je m'attends bien entendu à des trucs ultra-moches et vites faits... Mais j'espère aussi des inventivités et créativités sympas
Ah, et bien figures-toi qu'ayant passé pas mal de temps sur ce forum, je me suis vite rendu compte que les programmeurs ont assez peu d'idée innovante (en matière de jeu ou de scénar) et que ceux qui en ont sont de mauvais programmeurs
Dans ce sens, le jeu sera créé avec une application fenêtré, sans ligne de code. Et tout sera sauvé au format XML. Pour le moment, l'appli externe n'existe bien entendu pas, mais le fichier XML est en cours d'organisation.
Oui, non... Je voulais dire que le jeu que je vais créer à partir de celui-ci sera basique aussi (point&click, niveau technique, c'est pas non plus le truc méga dur)...( pour moi un moteur n'est pas un jeu, mais un des éléments qui permet d'en faire un, m'aurait-on menti?
screech> Je suis d'accord avec toi, dans la limite des droits bien entendu. En ce qui concerne le GD, j'espère bien que même un codeur n'aura pas à mettre le nez dans le moteur. Il suffira d'un fichier XML, des images et des sons et hop !
Mindiell>je suis assez d'accord un cuisinier apprend generalement d'abord à faire les recettes du bouquin avant d'inventer les siennes...je me suis vite rendu compte que les programmeurs ont assez peu d'idée innovante (en matière de jeu ou de scénar) et que ceux qui en ont sont de mauvais programmeurs
là par contre je suis pas tout a fait d'accord il me semble bien qu'un game designer est parfois compétent pour etre chef de projet (cela depend aussi de sa formation)Je considère le Game Design comme une branche à l'égale des dèv, des graphistes, des musiciens, etc...
Screetch>oui c'est pas faux cette confusion est pénible même si elle est excusable car il y a quelques années encore le moteur de rendu et le moteur du jeu était souvent développé par les mêmes personnes.Les developpers sont souvent des gens qui n'en font qu'a leur tete; je veux dire, ils se mettent a ecrire un moteur 3D car c'est ca qui botte tout le monde (et parce que c'est a la mode) et ensuite ils osent appeler ca un moteur de jeu, alors que tant reste a faire.
mais aujourd'hui ce n'est plus possible (trop de boulot donc nette séparation des taches)
il me semble que ça s'est toujours fait certaines bornes d'arcade faisaient 50 jeux avec un seul moteur, mais ça donne généralement toujours des jeux de seconde zone on sent un fort manque d'originalité dans le gameplay. Aujourd'hui ça n'a pas tellement changé les mod d'hl ou ut ou bien les jeux fait avec virtools ont ce défaut les joueurs sentent que c'est toujours le même moteur derrirère.Peut etre que le meilleur projet de depart serait de faire un moteur suffisemment flexible pour realiser un pong ET un tetris avec le meme moteur; et de reflechir alors aux outils que l'on met a disposition pour les scenaristes en herbe pour integrer leurs idees.
quand aux débutants il ne faut surtout pas chercher à commencer par un moteur générique car cela demande une solide expérience.
pour reprendre ton exemple, si tu veut faire un moteur de jeu 2d qui soit aussi bien capable de faire un tetris qu'un pong, il faut que tu aies déjà codé un tetris et un pong séparément. (tu t'apercevras que ces deux type de jeux n'ont rien à voir l'un est basé sur des collisions rectangulaires et l'autre sur de l'interpolation de mouvement et des collision entre groupes carreaux statiques comme le pixel perfct
Il faut commencer par un petit moteur qui fait peu mais qui le fait bien.
ouais c'est un vaste probleme...Coder un tetris c'est a la portee de tous les developpeurs qui souhaitent faire un moteur; etre capable de distinguer le moteur et les regles du jeu est quelque chose que les gens ne prennent jamais en compte.
la logique où l'on démarre à l'envers: on commence d'abord par imaginer un scénario de règle du jeu, et ensuite seulement on choisit les bons outils, les bons algo, etc, elle est possible aujourd'hui car la diversité des outils laissent une grande liberté.
dans le temps on pouvait pas faire ça car on était trop limité par des questions de performances et puis il fallait inventer et chercher pas mal de choses, on inventait les gameplays à partir de ce qu'on arrivait à faire avec les machines
mais maintenant on peut. alors bon c'est super on voit apparaitre des jeux de plus en plus scénarisés MAIS... (il y a un mais ça serait trop beau sinon) il faut déjà une solide expérience avant de travailler comme ça car pour choisir les bons outils il faut les avoir déjà utilisé avant séparément.
donc cette methode de travail n'est pas pour les debutants, c'est reservé a des designer et des codeurs qui ont de bonnes années d'experience derriere eux. la société id software (je vous conseille de vous interesser a leur travail ce sont eux qui ont cree une bonne part des bases des jeux 3d) a passé des années à travailer sur des moteurs de shoot stupides sans scénario et avec toujours les mêmes règles basiques. leur premier moteur qui a permis d'introduire la notion de scénario et de généricité (je vous laisse deviner lequel) n'a pas ete leur premier projet. pareil pour Epic ils en ont fait des pacman avant de creer l'unreal engine...
il y aurait tellement d'autres choses à dire pour ceux qui débutent car il y a plein de pièges à eviter de de trucs à savoir...
peut-etre que ce par quoi tout débutant devrait commencer c'est par développer une petit lib d'affichage mathematique pour bien tracer et débugger tous les calculs, un truc simple qui affiche des lignes, des points, des vecteurs, des cases, des polygones, etc... c'est à la portée de tous et ça permet de s'assurer qu'on maitrise les concept mathematique avant de les utiliser
Eh bien bravo et bon courage cela fait plaisir de voir que ce n'est pas réservé qu'aux "mecs"
Tu verras les JV c'est très passionnant à programmer
A part ça, je crois que tu es la première fille sur cette partie obscure du forum (déjà qu'une fille programmeuse j'en ait pas vu beaucoup sur ce forum, alors en plus dans la rubrique 2D/3D/Jeux
Quoique, je me souviens d'un des premiers jeux PS2, Shadows of Memories, un très bon jeu d'ailleurs, et bien le chef de projet était une femme
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