|
Alpha & Oméga
|
Citation :
Les règles du poker elles sont inscrites dans le marbre. Tu peux travailler l'enrobage mais globalement un jeu de poker x utilisera les mêmes règles que le poker y. Et sur du poker en ligne (contre d'autres joueurs uniquement), il y a 0 équilibrage (sauf si tu essayes d'arnaquer les joueurs). Donc oui je pense qu'un TD intéressant/agréable à jouer est bien plus difficile à réussir techniquement qu'un jeu de poker à succès. Tu peux réussir à gagner de l'argent avec un jeu de poker basique couplé à une grosse campagne pub. Avec un TD basique tu te crouteras même avec une grosse campagne pub. |
05/06/2014, 16h42
|
développement de jeux
| Suivre |
|
|
Partager | Rechercher |
|
[B K]
Alpha & Oméga
|
Bonjour,
Je reviens sur le topic, et je vous remercie pour toutes vos réponses. Je prends en considération toutes vos remarques. Beaucoup sont sensés, pleines de bon sens et surtout très protectrices pour moi même, ce dont je vous remercie. Cette idée un peu folle est peut-être vouée à l'échec (et surtout elle n'est pas encore lancé), mais elle ne se formalise pas nécessairement autour de "Ghim, es-tu capable ou non de gérer une équipe et de sortir un jeu". De même, la question de l'argent n'est pas un risque unilatéral. Si je parle d'un budget c'est que j'ai dans l'idée de monter un tour de table pour le financer. Je vais relire avec attention toutes vos réponses, et vos liens. Je suis friand du plus d'infos possibles que vous pourrez m'apporter afin de me décider ou non sur le projet, sur sa méthodologie, son support. Cependant, et de toutes évidence, je mise sur une équipe réduite et un projet "simple" comme première étape. Enfin, je comprends votre conseil sur "apprend à connaitre les outils", je vais donc explorer Unity pour voir sa manipulation. Je vais regarder les autres prog proposés et notamment ceux disponibles gratuitement pour me faire une idée 
|
|
05/06/2014, 17h24
|
|
Alpha & Oméga
|
Cela fait des années que le fil des faiseurs est ouvert. Il y a une mine d'information sur ce fil. Je te conseille fortement de passer une journée ou deux à remonter les archives pour y trouver tous les liens qui t'aideront pour ton projet. Il y en a certains qui sont juste incontournables et qui te feront gagner du temps/éviter certaines erreurs et d'autres qui t'éclaireront sur certains aspects de cette industrie.
|
|
05/06/2014, 17h46
|
|
Prophète
|
Citation :
Citation :
Mais de toute façon ce n'est pas le sujet, j'avais uniquement amené cet exemple pour illustrer mon propos. Citation :
Citation :
Les règles du tower defense, même si moins inscrites dans le marbre restent toujours les mêmes. Je place des tours pour me défendre contre des hordes de méchants. C'est le next step du "comment programmer un jeu video" après pong et space invader... Après je pense qu'on digresse, le but n'est pas de comparer un TD à un jeu de poker. C'est un débat sans fin, car c'est techniquement très différent. Je suis d'accord avec toi que le GD d'un jeu de poker est plus facile à mettre en place mais tu ne m'enlèvera pas de l'idée que la réalisation est bien plus compliquée, niveau programmation. Notamment rien que le fait que c'est massivement multijoueur, instancié = programmation réseau Qu'on soit clair, je ne parle pas de "jeu à succès", ou quoi que ce soit, uniquement de technique. Mon point, et je persiste, c'est qu'avec un game design et un cahier des charges défini en amont et clair. Et l'équipe qu'il veut engager, dans un contexte pro, avec une paie à la fin du mois ( même pour les stagiaires - obligatoire après 3 mois si ça n'a pas changé depuis le temps) ben si en 1 an ils sont pas capables de pondre un tower defense peut importe les améliorations ou les innovations par rapport au genre de base. C'est pas la faute de Ghim, c'est que son équipe est incompétente et devrait penser sérieusement à la reconversion. Surtout avec unity  un tower defense basique en 2d avec unity c'est quoi? 2 semaines de code (en comptant large)? On est dans un contexte "pro" là, à temps plein donc, 8h par jour..Et même des stagiaires, stagiaires code ça veut dire que ça programme pendant ses études, supposément capable d'aligner quelques lignes de codes sans problèmes. On leur demande pas de refaire Skyrim non plus... Dernière modification par Slade ; 05/06/2014 à 18h12. |
|
05/06/2014, 17h46
|
|
Alpha & Oméga
|
Je partais plus dans l'optique où son studio aurait une deadline de 4 ou 5 mois pour un TD. Cela m'étonnerait beaucoup qu'un jeune studio arrive jamais à dégager 200K de bénéfice pour rentabiliser un unique TD développé sur 18 mois... Et pour rentabiliser un TD, il doit être obligatoirement mieux que "basique".
Je me trompe peut-être mais il ne me semble pas que l'OP parte sur du AAA ce qui sous entend qu'en 18 mois de studio, ils devraient sortir entre 4 ou 5 produits minimum pour rentabiliser les 200K d'investissement. Dans cette optique, il faut une équipe compétente mais surtout qui travaille rapidement donc exit les stagiaires/amateurs comme main d'oeuvre première. |
|
05/06/2014, 18h14
|
|
Empereur
|
Citation :
Une appli de poker, si on n'a pas à gérer la dimension sécurité client/serveur, avec ma partenaire, on la met en place en 2 semaines maximum. Et le temps de travail que j'annonce suppose notamment la réalisation graphique de l'interface ainsi que le polish. Un tower defense ce serait impossible d'en réaliser un de vendable sur cette période. Et je peux facilement parler de tower defense puisque notre chiffre d'affaire des 2 dernières années, nous l'avons principalement réalisé avec un jeu de ce type. Un tower defense aujourd'hui c'est pas du tout un mini jeu à la pong hein. Enfin pour le voir il faut déjà en réaliser un qui soit vendable pour s'en rendre compte. Un tower defense à la manière de ce qui se faisait sur les portails flash en 2006 ça rapporte rien du tout, et faire un tower defense qui va rapporter ne serait-ce que quelques dizaines de milliers d'euros c'est plutôt beaucoup de travail... Notre tower defense dans sa version flash, rapporté à des semaines par personne, c'est grossièrement 30/35 semaines de travail. donc huit mois pour une personne solo, entre quatre et six pour 2 personnes. Et nous travaillons très vite au regard de ce que nous réalisons. La version iOS de ce même tower defense qui aura réclamé une réécriture complète du code, une refonte graphique et sonore du jeu, aura demandé en plus 40/45 semaines cumulées de travail . Donc 10 mois de travail pour une personne solo ou 5 à 6 mois pour 2 personnes. Tu dis que les gens sur ce sujet sont pessimistes. Non sur ce sujet pas mal d’intervenants sont des professionnels du secteur qui partagent leur sentiment en ce qui concerne la demande de l'OP : c'est à dire le montage de zéro d'un projet de studio de développement de jeu vidéo. Si nous disions sur cette discussion : ouais lance toi, un jeu tu le fais en 3 mois tu verras c'est facile de faire des jeux, fonce... Nous serions de très mauvais conseil. Réaliser du jeu vendable, et mieux du jeu rentable, c'est difficile et rares sont ceux qui y parviennent dès leur première réalisation. |
|
05/06/2014, 19h32
|
|
Alpha & Oméga
|
Citation :
Pour quelqu'un qui n'a jamais fait de jeu c'est clairement pas forcément acquis, et même si c'est le cas, juger de ce qu'est un gd exploitable quand on a pas connaissance des nécessités de la production c'est pas forcément donné non plus. Citation :
Mais bon, perso c'est pas les devs qui ne savent pas coder qui m'inquièteraient. C'est vraiment niveau management, comment leader tout ce beau monde quand on ne sait pas bien où on va, comment on y va, en combien de temps on devrait pouvoir s'y rendre, et comment être un apport au projet et non une charge. En principe t'es salarié, t'avances. En pratique, des équipes qui n'ont pas la flamme (et parfois pour de très bonnes raisons), y'en a, et des boites qu'ont jamais rien sorti avant de couler, y'en a aussi. Une blinde. Donc bon.. Après en fait, moi j'dis ça, c'est qu'un conseil. Bon, au passage Ghim, tu peux peut être jeter un œil sur ce portrait de Wax, qui raconte comment il a monté sa boite et l'a fait survivre à travers diverses péripéties (jeu rêvé plombé malgré soutiens financiers, vague de licenciements, puis gros remontage de pente), + un bon descriptif du feeling qu'il y a à leader une équipe de JV; ça pourrait être instructif. Accessoirement les autres portraits peuvent te donner une idée de ce qu'on attend de chaque corps de métier et des conditions de travail. C'est un peu le but du projet.. ^^ |
|
05/06/2014, 20h08
|
|
Alpha & Oméga
|
C'est bien là tout le problème; un porteur de projet qui ne connait pas techniquement son domaine, c'est un fail assuré.
|
|
05/06/2014, 20h21
|
|
Alpha & Oméga
|
Citation :
|
|
06/06/2014, 00h53
|
|
Alpha & Oméga
|
Citation :
Quand tu engages par paquets de 10 tu as plus de latitude pour te planter, le nombre aplani les écarts de niveau. Tes salariés se jaugent les uns les autres et tu as de quoi comparer donc tu as des retours sur leur rentabilité. Quand tu embauches à l'unité ou par 2, les erreurs de casting tu les payes plein pot. Imagine que tu doives engager un webmaster sans connaître ce métier. Tu vas le tester en lui demandant de faire un formulaire ? De faire un site web ? De parser le DOM d'une page pour y récupérer des éléments et les renvoyer en json ? Les deux premiers tests ne servent à rien si tu n'es pas capable d'analyser la méthodologie/code derrière, n'importe quel péon te fait une page/site web de nos jours. Et le troisième test, si tu n'es pas du métier aucun espoir de comprendre même la demande. Il faut un minimum connaître un métier pour engager un bon profil sinon autant tirer au sort... |
|
06/06/2014, 07h47
|
|
Empereur
|
Je reviens un peu sur la façon dont un projet est souvent géré en matière de jeu vidéo.
Personnellement pendant des années j'ai fait de la direction de projet sur du développement classique pour le web. Élaborer un cahier des charges, et ce même pour de grosses applications métier devisées pour des montant à 5 ou 6 chiffres, c'est un exercice aisé et évident. Lister les fonctionnalités d'une application, modéliser les interactions humain/machine, appréhender les modèles de données, etc... Tout ça peut se faire sans problème en amont. Pour un jeu c'est presque mission impossible, du moins on peut le faire mais si pour une application traditionnelle c'est un bon garant de succès, pour du jeu pas du tout. Cela pour une raison simple, on peut documenter autant que possible un projet de jeu en amont de son développement, il est impossible de garantir sur le papier la dimension "fun" du projet. Et par conséquent, le développement de jeux suppose bien davantage d’itérations de développement qu'un projet logiciel classique. Un jeu ce n'est pas juste une liste de fonctionnalités qui marchent sans bug, un jeu c'est surtout une expérience ludique. C'est tout à fait possible que 2 développements différents respectent à la lettre un document de game design, que ces 2 développements soient exempts de bug et de crash, mais que l'un soit un bon jeu et l'autre un produit sans intérêt. C'est à dire l'un vendable et l'autre non. C'est pourquoi en pratique les documents initiaux de game design sont bien souvent inutiles à partir d'un certain stade d'avancée du projet. C'est surtout le cas pour les petites équipes qui ont une approche souple (si ce n'est agile) des projets. Ces derniers évoluent alors trop vite pour qu'il soit rentable de maintenir des documents de game design à jour pour certaines équipes. En ce qui nous concerne ma partenaire et moi, nous n'utilisons même pas de document de game design formalisé. Sur nos projets je prends en charge le game design, j'ai des documents persos qui tiennent plus du pense bête et de l'archive en vrac que d'une bible de game design. C'est Grenouille qui code les projets, elle n'a jamais entre les mains un document qui présente l’intégralité du jeu, tout simplement parce que j'adapte au fur et à mesure le design à la réalité du développement et à l'analyse que nous pouvons faire de ce qui fonctionne ou pas (d'un point de vue ludique pas fonctionnel). Un tel mode de fonctionnement suppose d'avoir en permanence une excellente vision du projet et donc un recul sur le produit. En l'occurrence, le testing ne sert pas juste à débusquer des bugs, mais sert essentiellement à vérifier où va le projet et s'il va être réussi (s'il est amusant/fun/addictif/...) Et cela étonnera peut-être certains, mais la dimension fun d'un jeu est d'autant plus difficile à trouver que le jeu est pauvre en fonctionnalités, faire un bon jeu casual n'est pas du tout plus facile que faire un bon jeu gamer. Je dirai même que c'est plus simple de faire un jeu gamer en fait, mais le jeu gamer représente davantage de travail en revanche (du fait du volume de contenus attendu par ce type d'acheteur). Pour revenir sur ce que j'écrivais plus haut, il y a truc que j'ai pu constater dans des équipes régulièrement : des développeurs qui se contentent souvent d'un jeu qui est ok d'un point de vue fonctionnel et qui rechignent à repenser intégralement un aspect du jeu pour que non seulement il soit fonctionnel mais également efficace d'un point de vue ludique. C'est là selon moi l'un des principaux écueils de la production de jeu : parvenir à ne pas s’essouffler au fil du temps face à un projet qui formellement est fonctionnel mais qui n’entraîne pas une expérience ludique suffisamment bonne. |
|
06/06/2014, 13h35
|
|
Alpha & Oméga
|
Citation :
 C'est pour ça que les early access / beta tests deviennent la norme, on a besoin de feedbacks extérieurs. C'est effectivement là où le jeu de poker n'est pas forcément représentatif. Surtout si vous n'avez pas eu en charge la commercialisation. Mon ancien directeur de studio disait : "Avoir une idée, c'est marquer un point. La concrétiser en un jeu c'est 10 points. La vendre et la rentabiliser c'est 100 points". Il n'avait pas tort, 6 mois après le studio fermait avec des ventes totalement insuffisantes sur notre dernier jeu qui avait pourtant convaincu des tas d'investisseurs  Et un petit crowdfunding (même si financièrement tu n'as pas l'air d'en avoir besoin) peut t'aider pas mal à réaliser un early proto pour voir si tu t'en sors et à avoir un aperçu de la demande du marché sur ton produit. |
|
06/06/2014, 13h54
|
|
Prophète
|
Citation :
Citation :
Citation :
De la prog ça fait 15 ans que j'en fait, en basic, en c, en c++ en java, en python, en php en javascript que ce soit des jeux ou des projets web. Que ce soit des rpgs, des sim city like, doom like, remake de risk, et même un proto de mmorpg 3d que j'avais présenté ici herdelia, y'a 8 ans de ça! Je commençais le réseau à l'époque. Ça fait 2 ans que j'ai 24h de temps libre par jour parce que je vis d'un projet web que j'ai monté. Alors t'es mignon tout plein mais tu va pas me juger comme ça en ayant aucune idée de qui je suis. hein? Il me semble pas avoir dit à qui que ce soit que j'étais le meilleur et que vous êtiez tous nuls, alors t'es gentil tu fais pareil et tu me montre un minimum de respect. Citation :
"c'est pas compliqué de faire si ou ça. moi je l'ai pas fait, mais c'est facile je suis sûr..." Il y a pas de room de poker avec une seule variante de jeu. T'as du hold'em avec sans limite, du omaha, du stud etc.. avec tournois, sit&go cash game, knock out, etc.. etc.. Des dizaines de règles de plus à coder. Sans compter qu'un jeu de poker sans sécurité client serveur c'est un peu bancal. Donc si tu veux comparer un jeu de poker de base compare le avec un tower defense de base "jeux flash de 2006" pour reprendre tes dires. Et je pense que là on est loin de tes 30 semaines de dev. Mais encore une fois, c'est une comparaison useless. Ça sert à rien de débattre dessus. C'est pas le même type de jeu, c'était un exemple pour illustrer mes propos. Ça aurait pu être n'importe quel type de jeu, le but était de montrer que utiliser Unity et en sortir un produit fini n'est pas particulièrement compliqué, même sans y avoir jamais touché. Citation :
Citation :
Citation :
L'aspect rentabilité. Ça dépend de plein de points qu'on ne connaît pas. Les particularités des jeux en tant que tel et d'un million d'autres facteurs pour lesquels je ne suis pas assez compétent à ce niveau là pour me prononcer. Citation :
Sur ce, je pense que je vais arrêter là. Je voulais apporter un point de vu différent C'est fait. Si c'est pour me faire prendre de haut, ça m'intéresse moyennement. Dernière modification par Slade ; 06/06/2014 à 18h15. |
|
06/06/2014, 17h28
|
|
Empereur
|
Bien le quote war ?
Moi je te juge sur rien, et ne suppose rien du tout à ton sujet. C'est toi qui à la base fais une comparaison débile et qui prends la mouche quand on te met le nez dedans. C'est toi qui mets sur le tapis une comparaison entre une appli sans relation client serveur et ton appli de poker. Je te cite hein : Citation :
Je peux en rajouter si tu veux. Coder une appli de poker ne suppose aucun gamedesign, aucun équilibrage, quasi aucun traitement graphique, aucune mise en place d'aucun moteur de collision, de pathfinding... etc etc. Et surtout une application de poker, ça ne suppose aucun fun chez l'utilisateur. Il n'y aucune itération de développement sur la dimension ludique. Une appli de poker, ça à juste besoin d'être fonctionnel au même titre que n'importe quelle appli métier. Faire une appli de poker ça n'a rien à voir avec faire du jeu vidéo, ce n'est pas les mêmes contraintes, pas les mêmes enjeux, ça n'a juste rien à voir. Une appli de poker c'est pas un jeu vidéo tout simplement. On est nombreux à te répondre que tu es à coté de la plaque, mais non, le problème c'est ma condescendance... Super. Surtout que ici celui qui suppose et juge le travail des autres, c'est bien toi. Ça va, pas de soucis de me dire qu'on a merdé parce que la version flash de notre tower defense a du être recodée en Objective C pour des raisons contractuelles ? Ah oui merde on aurait du coder notre version flash en Objective C directement, oh wait... Notre éditeur voulait un jeu recodé en langage natif, il nous a payé pour, donc on l'a fait. Tu vois tu m'aurais posé la question pour comprendre pourquoi on a du recoder, ça aurait été plus constructif que juste écrire : "Ça c'est surtout que t'as mal géré ton coup". Et c'est moi "qui juge des gens qu'il ne connait même pas" ? Pour ceux qui se demandent pourquoi il y a eu 2 versions de ce tower defense, je peux prendre le temps de le préciser. Une version flash, vendue aux portails flash. Cette version nous a rapporté grossièrement 32 000 USD depuis sa release. Puis une version iOS qu'on a nous commandée et payée d'avance. Dernière modification par MonsieurChance ; 06/06/2014 à 19h53. |
|
06/06/2014, 19h45
|
|
Prophète
|
Citation :
Citation :
Citation :
Et si tu fais une application de poker en 2 semaines, rassure-toi ce ne sera pas vendable non plus... Citation :
Je trouve ça un peu fort de dire que ce n'est pas un jeu vidéo. T'élargis ça à tous les jeux de cartes? Parce que y'en a un paquet. Parce que le fun vient de la stratégie et pas des réflexes et/ou contrôles différents c'est pas un jeu vidéo? C'est drôle parce qu'un TD c'est pas non plus là où le joueur est le plus sollicité. Citation :
Je te requote au cas ou tu as oublié: Citation :
C'est vachement ouvert à la discussion. Citation :
Mais de toute façon tu me lis en diagonale, tu me reproche de comparer les TD de 2006 et de dire que c'était facile et ton argument c'est qu'à côté de ça une room de poker en 2 semaines sans réseau c'est plié. Ben oui. Tout comme un TD de 2006. Mais comme tu l'as si bien dit un TD de 2006 n'a aucun interêt et une room de poker sans archi client-serveur non plus. On peut peut-être maintenant fermer cette parenthèse inutile. Ce que j'essaye de faire depuis un certain temps, mais ça à pas l'air possible on dirait... je m'auto quote: Citation :
Citation :
Citation :
Citation :
Si tu as eu le contrat pour le refaire c'est bien. Mais tu peut pas vraiment inclure ça comme appuie au fait que ton développement à été plus long. C'est un cas personnel et un choix que vous avez eu. Je suis venu discuter au sujet des outils + délais + équipe + jeux prévu et dire que c'était faisable et ça fait maintenant 2 pages qu'on compare 2 types de jeu différents.. Non seulement c'est pas constructif mais en plus ça commence à être fatiguant... Dernière modification par Slade ; 06/06/2014 à 20h52. |
|
06/06/2014, 20h42
|
|
Empereur
|
Je reformule une nouvelle fois alors :
Développer une application de poker en ligne n'a rien à voir avec le développement d'un jeu vidéo. Ce n'est pas parce que les gens sont susceptibles de s'amuser en utilisant une room d'Omaha que la mise en place de cette room a quoi que ce soit à voir avec le développement d'un jeu. Une room de poker c'est une appli métier comme une autre. Tu fixes ton cahier des charges en amont, tu codes les specs, et hop c'est terminé. Un jeu vidéo ne se réalise pas comme ça, tout simplement parce que la dimension "fun" ne se décrit pas dans un cahier des charges et qu'un jeu vidéo se réalise via des itérations successives durant lesquelles le projet est appelé à totalement changer entre le premier proto et la version release. Une appli de poker et un jeu vidéo ont des cycles de développement qui n'ont rien à voir. Moi à la base j'ai pas besoin d'essayer d'expliquer ça, mais il se trouve que TU as fait cette comparaison (en réponse à Toro qui précisait que selon lui l'OP devrait faire un tower defense dans sa situation à lui). Là tu cherches à présenter les choses sous l'angle qui t'arrange et te positionne en disant que cette discussion est fatigante. Bin nous sommes désolés de devoir expliquer en quoi cette comparaison que TU as faite est à coté de la plaque. En gros tu es fatigué de nous lire te reprendre sur ce que TU as écrit...  Edit pour en dessous : Oui bin justement ta réponse comportait plein de trucs que plusieurs personnes ont essayé ensuite de reprendre en tentant d'expliquer en quoi ce que tu écrivais était à coté de la plaque. C'est pas personnel hein, c'est juste que tu écris des trucs que d'autres considèrent comme faux, ils prennent la peine d'essayer de l'expliquer, mais comme tu n'es pas d'accord tu affirmes que ce serait fatiguant à lire ? Super ta participation en fait... Dernière modification par MonsieurChance ; 06/06/2014 à 21h20. |
|
06/06/2014, 21h07
|
|
Prophète
|
Citation :
M'enfin... hein... Citation :
Citation :
Edit pour au-dessus: Je savais pas qu'il y avait une échelle de type de jeux, les classant par difficulté de développement universellement accepté et qui me mettrait "à côté de la plaque". Ben oui c'est fatiguant à lire parce que j'ai essayé de terminer le débat hors-sujet rapidement mais apparemment c'est pas possible. On est pas d'accord on est pas d'accord ça sert à rien de s'éterniser 10 ans là dessus... Dernière modification par Slade ; 06/06/2014 à 21h30. |
|
06/06/2014, 21h12
|
|
Alpha & Oméga
|
Oui. Bon. C'est moi ou on est un peu sur du détail pas très constructif ?
J'veux pas vous embêter mais enfin, disons que peut-être on peut s'en tenir là. |
|
06/06/2014, 21h15
|
|
Alpha & Oméga
|
En effet cela va finir par une discutions privé si ça continue
 Du coups je ne puis que vous conseillez de construire un peu plus les réponses ou de passer par les MP. Sinon on va devoir sortir le gros marteau ça serait dommage pour si peu
|
|
09/06/2014, 12h02
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|