Voir la version complète : Quelques questions sur le homebrew en général
Voici quelques réflexions sur le homebrew que j'ai eu tout d'un coup comme ça:
- il n'y a pas de jeu de sport homebrew (genre tennis, foot...)
- il n'y a pas de jeu de course typique années 80. Vous savez, ceux comme Pole Position ou Outrun.
- il n'y a pas de jeu de flipper
- il n'y a pas de point and click
- il n'y a pas de visual novel (comme tous ces jeux hentai)
- il y a peu de jeux à deux ou plus
Je conçois bien que le foot c'est compliqué à coder (22 joueurs + gestion des règles + physique du ballon... arg!), que pour les jeux de flipper l'obstacle c'est la conception des tables, que les point and click requièrent énormément de boulot.
Cependant, pourquoi n'y a-t-il pas de jeu de tennis homebrew ou de jeu de course 80's? (à moins que je n'ai raté un épisode) ça ne devrait pas être trop complexe, si? (quand je vois les jeux de tennis 8 bits...) Niveau GFX, ça ne devrait pas demander trop de boulot non plus. Corrigez-moi si j'ai faux, mais le code des visual novel doit être assez léger non? Il n'y a que du texte et des images fixes à afficher et des choix simples à faire. Bon évidemment là, c'est le scénario qui se doit d'être béton, ainsi que l'ambiance. Il n'existe pas un moteur de visual novel mis à disposition des scénaristes et gfxistes en herbe?
Y a-t-il des homebrew jouables à plusieurs en coopération/deathmatch? Je ne m'étonne pas que tous les jeux faits-maison soient pour un joueur, les codeurs ayant rarement 2 GBA et 2 linkers. C'est difficile de gérer un deuxième joueur en code? Mais malgré tout, existe-t'il des jeux jouables à plusieurs?
Voilà c'étaient mes questions et réflexions :) On peut en discuter si vous trouvez ça pertinent :)
je pense qu'en effet il existe déjà trois/quatre jeux multijoueurs, et qu'une personne du forum est partit pour en faire un (en versus)
par contre, je ne vois pas du tout ce qu'est un visual novel...
Tembargo
20/04/2006, 19h14
Vous inquiétez pas j'arriveeeeuuh pour le multijoueur :D J'ai deux ds, donc je pourrais tester facilement ;)
Transgirl
20/04/2006, 20h16
Vous inquiétez pas j'arriveeeeuuh pour le multijoueur :D J'ai deux ds, donc je pourrais tester facilement ;)
Genre ! Tas deux DS !?
:o
Espece d'arnaqueur ! C'est la mienne la deuxième >_<
ouais mais en fait non... regarde son avatar, il parle en ton apparence, en fait, ce sont les deux tiennes...
(... tu ne veux pas l'aider en béta testeuse pour ces jeux multi ?)
Transgirl
20/04/2006, 20h31
ouais mais en fait non... regarde son avatar, il parle en ton apparence, en fait, ce sont les deux tiennes...
(... tu ne veux pas l'aider en béta testeuse pour ces jeux multi ?)
:lol: Mais bien sûr que si, de toute façon je peux pas dire non, sinon j'aurais jamais ma supercard :ph34r: :p
Je m'incruste dans ce gentillet conflit de couple ^^ pour ajouter ma graine.
- il n'y a pas de visual novel (comme tous ces jeux hentai)
Ah ben si, j'en ai quelques un moi, mais je trouve ça tellement chiant. Les jap en pondent par kilo des homebrew comme ça, avec des dessins vraiment tres beau.
Pour les jeux de tennis, mon avis, c'est que si tu en fais un, tu vas forcement trouver un editeur derriere alors il y a du en avoir, mais ils ont fini dans les magasins. En effet, les gros editeurs sortent des jeux de tennis sur les consoles de salon, et qui fait les adaptations de licenses sur les portables... ben c'est des petits studios.
Et puis les developpeurs de jeu homebrew preferent faire des jeux arcades parce que c'est fun, plus rapide à faire et bien adapté au concept de console portable, j'allume, je joue 10 minutes et je range dans ma poche.
Voici quelques réflexions sur le homebrew que j'ai eu tout d'un coup comme ça:
- il n'y a pas de jeu de sport homebrew (genre tennis, foot...)
- il n'y a pas de jeu de course typique années 80. Vous savez, ceux comme Pole Position ou Outrun.
- il n'y a pas de jeu de flipper
- il n'y a pas de point and click
- il n'y a pas de visual novel (comme tous ces jeux hentai)
- il y a peu de jeux à deux ou plus
Je conçois bien que le foot c'est compliqué à coder (22 joueurs + gestion des règles + physique du ballon... arg!), que pour les jeux de flipper l'obstacle c'est la conception des tables, que les point and click requièrent énormément de boulot.
Cependant, pourquoi n'y a-t-il pas de jeu de tennis homebrew ou de jeu de course 80's? (à moins que je n'ai raté un épisode) ça ne devrait pas être trop complexe, si? (quand je vois les jeux de tennis 8 bits...) Niveau GFX, ça ne devrait pas demander trop de boulot non plus. Corrigez-moi si j'ai faux, mais le code des visual novel doit être assez léger non? Il n'y a que du texte et des images fixes à afficher et des choix simples à faire. Bon évidemment là, c'est le scénario qui se doit d'être béton, ainsi que l'ambiance. Il n'existe pas un moteur de visual novel mis à disposition des scénaristes et gfxistes en herbe?
Y a-t-il des homebrew jouables à plusieurs en coopération/deathmatch? Je ne m'étonne pas que tous les jeux faits-maison soient pour un joueur, les codeurs ayant rarement 2 GBA et 2 linkers. C'est difficile de gérer un deuxième joueur en code? Mais malgré tout, existe-t'il des jeux jouables à plusieurs?
Voilà c'étaient mes questions et réflexions :) On peut en discuter si vous trouvez ça pertinent :)
hello, je vais moi aussi dire ce que j'en pense (c'est pas forcement la veritée mais c'est un raisonnement comme un autre)
- il n'y a pas de jeu de sport homebrew (genre tennis, foot...)
(en dehors des jeux d'atletisme ou tu flingue tes touches pour rien <_<) un jeu de tennis ou de foot c'est quand meme enorme a coder et c'est vraiment pas a la portée de tout le monde et si le jeu n'est pas bien codé et les choix mal defini qui irai jouer a ce jeu ?
puis un jeu de sport ou de bagnole c'est vraiment pas du tout amusant a coder ou a gfxer (y'a vraiment que pour du commercial qui tu peut trouver une motivation)
- il n'y a pas de jeu de course typique années 80. Vous savez, ceux comme Pole Position ou Outrun.
manque d'interet peut etre, la gba est trop puissante pour ca j'oserai presque dire :D a quoi bon se faire chier a simuler une route de ce style la alors que tu peut mettre du mode 7 ... faut voir aussi qu'il y a beaucoup de "jeunes" qui n'ont pas connu cette epoque.(moi y compris)
- il n'y a pas de jeu de flipper
pas tres joyeu non plus, limite tu peut faire un plateau pour tester tes talent de gestionneur de collision mais de la a faire un jeu entier :/
- il n'y a pas de point and click
ca ca peut etre marrant a coder mais c'est tres tres long et il te faudrai soit reprendre les gfx d'un jeu deja existant et donc faire un portage (et comme ce genre de jeu est tres tres long tu perd desuite espoir) soit trouver un gfxman motivé)
- il n'y a pas de visual novel (comme tous ces jeux hentai)
pervert va OO y'en a bien assé en flash ;)
- il y a peu de jeux à deux ou plus
question de technique, tout le monde ne sais pas gerer ca et en + tout le monde n'a pas 2 gba et le courage de linker 2 fois et tester et retester son prog.
enfin bon il y a beaucoup de codeurs mais dit toi que entre un tetris, shoot, puzzle et un autre style de jeu (tennis, foot, action, combat ...) y'a un gigantesque gouffre technique, tout le monde ne sais pas tout faire, les bons codeurs il testent la gba puis:
- soit ils migrent vers une autre console des qu'ils ont epuisé tout le potentiel technique de celle ci
- soit ils continuent a coder pour du commercial.
- soit ils en ont marre de pas etre reconnu et arretent tout simplement (ca faut pas le faire les gars faut persister !!)
ps au cas ou: je me considere pas etre un bon codeur.
[edit]pss: c'est pas parcque l'on fait un tetris, shoot ... que l'on sais pas coder autre chose !! je dit ca dans la globalitée le prennez pas mal (je rectifie, comme on prend souvant mes propos de travers :()
(en dehors des jeux d'atletisme ou tu flingue tes touches pour rien <_<)
ils peuvent être très bon ces jeux :) ( un de mes genres préféré ^^ )
Pour les jeux de sports j'en ai trouvé un sur gba, il est vraiment bien fait. Vous pouvez le télécharger ici (http://www.pdroms.de/file_details.php?fn=711)! En l'essayant on voit la difficultée technique, rien que le déplacement des joueurs, c'est pas tout simple à faire :S
Pour les jeux de tennis c'est la même histoire, passer du pong à un rebond réaliste tout en perspective... Comme dis nesgba le gouffre est énorme.
puis un jeu de sport ou de bagnole c'est vraiment pas du tout amusant a coder ou a gfxer (y'a vraiment que pour du commercial qui tu peut trouver une motivation)
Genre... :ange:
Le problème que j'ai remarqué, c'est que souvent les codeurs ont envie de faire tout tout seul, et ils n'évaluent pas le travail que demandent certains types de jeux, et qu'ils feraient mieux de travailler avec d'autres personnes (mais ce serait con de partager sa gloire intersidérale avec un autre gars qui a rien foutu par rapport à lui, hein, avoue? :ph34r:).
Donc au final, le codeur fait des trucs qui ne le motivent pas (comme les gfx en pixel ou les niveaux) et c'est pour ça qu'au final il abandonne :(
Ca c'est valable pour tout type de jeu, pas seulement ceux-ci, rares sont les jeux vraiment terminés et "pros" - même basés sur un jeu existant - du style Arkanoïd ou 1942, ah ça oui :) (par contre, les démos, ça foisonne).
Prenons le cas d'un Mario. Un personnage auquel on applique la gravité, qui bouge à gauche et à droite avec les touches, gère les collisions avec le décor... c'est simple, et on a l'impression d'avoir un Mario en quelques jours pour un débutant. Maintenant prenons un VRAI Mario style Mario World (qui n'a pas l'air plus compliqué à première vue):
1) Gestion des objets (objets animés telles que les plate-formes mobiles, les blocs avec les primes qui sortent, les ennemis, bosses, ...)
2) La gestion de la carte, avec les différents chemins et des événements qui peuvent se produire (chatêau qui s'écroule, entrée libérée, le navire coule, ...), ou les cut-scenes, ou encore les tuyaux ou les portes menant vers d'autres salles, ...
3) Les éléments qui influent dans la progression tels que les switch palaces, les états spéciaux de Mario (ex: il est paralysé, pourtant le jeu continue de tourner), le plan qui s'incline en fonction du poids au premier boss, le défilement scripté dans certains niveaux comme Vanilla Dome 2, etc.
Et ce n'est qu'un aperçu (j'ai pris Mario parce que beaucoup de gens pensent que c'est le jeu le plus simple à faire). Donc autant tu trouveras 497'163'285 démos de Mario comme décrite au début, autant les vrais Mario complets, tu les comptes sur les doigts d'une main coincée dans un broyeur de documents hi-speed.
Ce qui nous amène donc aux raisons finales : premièrement, les types de jeux que tu as cités demandent beaucoup plus de temps et de travail avant d'être présentables (contrairement justement à un Mario qui est plus rapidement jouable), donc pas d'encouragements pour les programmeurs, donc démotivation. Deuxièmement ils ne peuvent pas (ou difficilement) être réalisés que par un seul programmeur, et troisièmement ils sont rarement jugés intéressants par les programmeurs eux-même ni par leur public ^^
Et il faut aussi préciser que les jeux amateur ne sont que rarement terminés parce qu'il n'y a plus de défi une fois que le moteur est fait. Tu es heureux, tu vois que t'as pu faire un Rayman-like, mais après tu vas pas t'embêter à le finaliser en y rajoutant tous les éléments de l'original puisque tu sais que tu y arriverais en bossant (mais t'as pas que ça à faire non plus), donc ton but est atteint :) Il reste plus qu'à se lancer un autre défi ^^
Et il faut aussi préciser que les jeux amateur ne sont que rarement terminés parce qu'il n'y a plus de défi une fois que le moteur est fait. Tu es heureux, tu vois que t'as pu faire un Rayman-like, mais après tu vas pas t'embêter à le finaliser en y rajoutant tous les éléments de l'original puisque tu sais que tu y arriverais en bossant (mais t'as pas que ça à faire non plus), donc ton but est atteint :) Il reste plus qu'à se lancer un autre défi ^^
100% Agree
C'est pour ça que je ne me fixe pas comme but " d'y arriver " mais de pousser au maximum vers un look'n feel commercial, ça m'oblige à aller au delà du simple moteur
Et il faut aussi préciser que les jeux amateur ne sont que rarement terminés parce qu'il n'y a plus de défi une fois que le moteur est fait. Tu es heureux, tu vois que t'as pu faire un Rayman-like, mais après tu vas pas t'embêter à le finaliser en y rajoutant tous les éléments de l'original puisque tu sais que tu y arriverais en bossant (mais t'as pas que ça à faire non plus), donc ton but est atteint :) Il reste plus qu'à se lancer un autre défi ^^
il est vrai qu'en général, une fois le moteur programmé on est très content du résultat
après, on continue à être motivé et on fait des niveaux pour le moteur ou bien on a eu la (mal)chance de penser à d'autres projets pendant qu'on faisait le 1er et on veut se jeter sur le 2e projet :)
une fois le moteur fait, il faudrait tout refiler à un autre gars, qui te finalise le jeu ^^
y'en a un qui pourra dire : oh il bouge, grâce à moi
et l'autre : c'est beau,c'est moi qui ai fait les niveaux
il est vrai qu'avoir la gloire sur soi tout seul pour un projet est des fois ( à tort ) plus plaisant que de devoir la partager ( je veux pas faire de binômes en projets d'info, je veux que le programme soit entièrement de moi :-' )
j'ai aussi ce problème de "je veux tout faire tout seul"
mais au final, vaut mieux un bon jeu bien fini à plusieurs qu'un mauvais jeu mal (pas) fini tout seul
Et il faut aussi préciser que les jeux amateur ne sont que rarement terminés parce qu'il n'y a plus de défi une fois que le moteur est fait. Tu es heureux, tu vois que t'as pu faire un Rayman-like, mais après tu vas pas t'embêter à le finaliser en y rajoutant tous les éléments de l'original puisque tu sais que tu y arriverais en bossant (mais t'as pas que ça à faire non plus), donc ton but est atteint :) Il reste plus qu'à se lancer un autre défi ^^
je pense que dans "tout" les types de jeux il y a cette notion, des que tu as terminé le moteur de jeu tu as envie de passer a autre chose comme tu le dit, ou mieu, te rajouter une difficultée pour te remotiver un petit temp en esperant le terminer avant que la lassitude ne reprend le dessu (passer du mode 0 au mode 4 par exemple ^^) mais je pense pas que ca change des masses que se soit amateur ou pas mais dans l'autre cas peut etre que si tu le prend comme un travail ca passe deja mieu.
ca vous arrive pas ca ?: apres avoir fait une grosse release tu touche plus a ton jeu pendant des semaines, comme si tu avais attein un but. >_<
pourquoi ne cherche tu pas un graphiste brunni ? tu pourrai faire de grandes choses doué comme tu est :ange:
[edit] 3 fois quoté sur la meme phrase :thumb_yel
j'ai aussi ce problème de "je veux tout faire tout seul"
mais au final, vaut mieux un bon jeu bien fini à plusieurs qu'un mauvais jeu mal (pas) fini tout seul
Mais quelle satisfaction de finir un bon jeu tout seul ^^
Nesgba : HOOOOO SI je connais parfaitement "l'abandon temporaire" :p
Mais quelle satisfaction de finir un bon jeu tout seul ^^
c'est le saint graal du développeur ^^
Dr.Vince
21/04/2006, 00h32
je suis entièrement d'accord avec tout ce que vous avez dit les gars.
mais, car il y a un mais, c'est souvent les portages qui ne sont pas terminés pour les raisons que vous avez cités ci-dessus
Les deux portages que j'ai commencé, bah j'ai vraiment du mal à les terminer car y a plus grand chose qui m'intéresse en eux.
il faut donc priviliégier, je pense les petits jeux qui eux sont terminables assez rapidement.
et on peut également rajouter la raison suivante : le manque de graphiste "motivé" pour faire certains homebrew qui peuvent demander beaucoup de travail
Justement: ce qui est bon pour les programmeurs ne l'est pas forcément pour les joueurs. Prenons un cas simple: un jeu en 3D sur GBA - sans vouloir offenser ceux qui l'ont fait, je parle des jeux commerciaux en général ;) - c'est techniquement impressionnant pour un codeur, mais dans la majorité des cas ça ne vaut rien pour le joueur parce que c'est pas jouable (problèmes de collisions, framerate, environnement limité, rendu très approximatif, etc.) :(
je suis entièrement d'accord avec tout ce que vous avez dit les gars.
mais, car il y a un mais, c'est souvent les portages qui ne sont pas terminés pour les raisons que vous avez cités ci-dessus
+1
Donc le mieux c'est de faire quelque chose de nouveau, même basé sur un jeu existant que tu aimes bien comme Gradius par exemple, mais avec de nouveaux niveaux, et pas forcément des ennemis identiques à l'original, tu te feras moins chier à reproduire leur comportement v_v
Et pas forcément besoin d'un grapheux motivé, si vraiment tu es nul en gfx tu fais une recherche "avion" sous google images, et tu y colles en arrière-plan des fonds mixés & remastérisés de Donkey Kong Country, Magical Quest et Gunstar Heroes, avec la musique de Mega Man X par exemple, et c'est parti ^^
Sans oublier le problème des les consoles next-gen: pour bien exploiter la console, il faut faire de la 3D, et pas simple: il faut bien utiliser tous les 130 mille polygones de la DS, voire trouver si possible une astuce pour en afficher 500 mille. Et ça pour un amateur ça mène rarement plus loin qu'une démo parce qu'autant les petits objets à 10 polygones tu peux les faire à la main, autant ceux à 50'000... :ph34r:
Tembargo
21/04/2006, 19h09
Justement: ce qui est bon pour les programmeurs ne l'est pas forcément pour les joueurs. Prenons un cas simple: un jeu en 3D sur GBA - sans vouloir offenser ceux qui l'ont fait, je parle des jeux commerciaux en général ;) - c'est techniquement impressionnant pour un codeur, mais dans la majorité des cas ça ne vaut rien pour le joueur parce que c'est pas jouable (problèmes de collisions, framerate, environnement limité, rendu très approximatif, etc.) :(
+1 :)
Comme dans tous les domaines, à vouloir trop en faire on oublie le principal ^^
Les exemples les plus flagrants sont dans le cinéma. Je ne citerai pas trop d'exemple, de peur qu'on me lance des pierres.. Mais heu.. genre.. Narnia!? Matrix2,3.. Beaucoup de moyens et de travail pour un résultat médiocre..
et ben moi j'suis pas d'accord avec la fin de la discussion, NA ^^
"Donc le mieux c'est de faire quelque chose de nouveau, même basé sur un jeu existant que tu aimes bien comme Gradius par exemple, mais avec de nouveaux niveaux, et pas forcément des ennemis identiques à l'original, tu te feras moins chier à reproduire leur comportement
Et pas forcément besoin d'un grapheux motivé, si vraiment tu es nul en gfx tu fais une recherche "avion" sous google images, et tu y colles en arrière-plan des fonds mixés & remastérisés de Donkey Kong Country, Magical Quest et Gunstar Heroes, avec la musique de Mega Man X par exemple, et c'est parti "
Je suis anti ça.
Pour moi, faire un jeu, c'est exprimer sa créativité, ça ne se résume absolument pas à faire du code. Un jeu c'est une oeuvre d'art, ya de la musique, des graphs, des scenari, une mise en scene et ... du code pour emballer tout ça et que ça fonctionne. Alors faire un jeu repompé, non, faire un truc existant en rechangeant les niveaux, tres peu pour moi. Elle est où l'originalité dans le gamedesign, celle artistique et emême celle dans le code...?
Faire un jeu c'est pas juste tapper des suites de lignes dans un IDE, regarde, on peut faire un jeu de carte, un jeu sur papier, un jeu de société, ya pas de code, c'est fun et c'est un vrai jeu quand même. Le jeu video, il est numérique, mais c'est un jeu avant tout.
Et puis, faut respecter la créativité des autres (repompage de gfx et musique) et savoir exprimer la sienne également, c'est un domaine artistique également le dev de jeu.
Apres si ton kiff c'est de faire des moteurs tres performant, ok, mais bon, c'est pas la même chose.
"Comme dans tous les domaines, à vouloir trop en faire on oublie le principal "
Et à ton avis le principal c'est quoi... de refaire un truc que des mecs ont dejà super bien fait et qui etait révolutionnaire en leur temps alors que maintenant, tu ne reinventes rien ?
Le problème que j'ai remarqué, c'est que souvent les codeurs ont envie de faire tout tout seul, et ils n'évaluent pas le travail que demandent certains types de jeux, et qu'ils feraient mieux de travailler avec d'autres personnes (mais ce serait con de partager sa gloire intersidérale avec un autre gars qui a rien foutu par rapport à lui, hein, avoue? :ph34r:).
Sur ce point je suis parfaitement d’accord avec toi. Mais faire un programme perso c’est une branlette intellectuelle et le faire à plusieurs beurk.
Donc au final, le codeur fait des trucs qui ne le motivent pas (comme les gfx en pixel ou les niveaux) et c'est pour ça qu'au final il abandonne :(
Perso j’avais fait un jeu (que je trouvais super) mais quand j’ai présenté ca à des grapheux, j’étais content quand ils ne me rigolaient pas au nez en me disant que c’est un jeu ridicule.
Et c’est sur ça tue sur place un projet. Et pourtant tout était prêt il ne manquait plus que des grapheux et game designer/scénariste.
edit : j'avais pas fait un jeu mais une demo pour recruter des grapheux et autres dsl pour l'imprécision.
tu te contredis pas un poil dans tes trois dernières phrases yopyop ?
en clair: tu l'as fait ou pas ce jeu ?
il a eu de beaux dessins ?
ils ont ris ou pas ?
ils aiment ou pas ?
ps: le repompage de jeux émulé peut être intéressant, pour apprendre le code (je suppose)
tout le monde n'est pas artiste (ben voui...) et donc, autant céder à la facilité d'importer...
tu crois vraiment que si je faisait un jeu, là, maintenant, avec des carrés à la place des "futurs vrais sprites" un mec qui sait faire du dessin le trouverais intéressant pour lui ?..
puis après... quand tu vas voir un autre type qui manipule mieu le son que toi, paskeu tu as "mis en attendant mieux" des "nip", "mup" et autres "bmip" ... qu'il faut modifier..
ca fait sérieux ?..
boaf.. je pense que pour faire un jeu amateur, il ne faut pas être plus de trois, une personne par domaine, comme ca, deux juges par domaines...
puis après, il faut faire trois jeux pour que tout le monde ai pus créer son jeu :p
Japi> On n'a pas tout à fait le même point de vue ^^
Toi tu as de la chance, tu sais faire le code, les gfx et le son, mais je peux te dire que c'est très rare. Et un codeur n'a pas forcément envie de réunir une équipe pour son projet, parce que le plus souvent c'est juste un challenge, un test ou un trip (et il faut la trouver, l'équipe, et qu'aucun d'eux ne se désiste en plein projet!).
Et au moment où il se rend compte que son projet mériterait d'être terminé et qu'il cherche une équipe, c'est souvent trop tard :( (en plus y'a tellement de trucs à leur apprendre)
Wapata> +1. Dans un projet amateur, avoir plusieurs codeurs, c'est le plus souvent une source d'ennuis. Déjà parce qu'il n'y a pas de "boss" (tu n'oserais pas gueuler dessus le gars qui t'aide gentiment sur son temps libre... :hum:), et chacun a ses propres idées, donc c'est l'anarchie.
Heureusement, tu peux subdiviser le projet, comme par exemple déjà confier la création des objets/ennemis à un autre codeur, ou bien l'écran titre, mais qu'il ne touche pas à ton moteur :p
Je t’en laisse seul juge. (http://yopyop156.ifrance.com/rpg.gba)
Mais disons que de mon point de vu le projet est fini (dans la dernière version il y avait même le moteur de combat), j’avais même commencé l’éditeur de niveau.
Pour les graphistes, ils n’ont pas ri, ils ont juste eut du mal à voir le potentiel du jeu (et je les comprend)et donc ils n’ont pas accepté de s’investir dessus pour rien.
(Et j’ai quand même fait l’effort de ne pas mettre que des carrés tout moches. :ph34r: )
Brunni : +1 pour tes deux propositions.
yopyop
Je t’en laisse seul juge. (http://yopyop156.ifrance.com/rpg.gba)
Mais disons que de mon point de vu le projet est fini (dans la dernière version il y avait même le moteur de combat), j’avais même commencé l’éditeur de niveau.
Pour les graphistes, ils n’ont pas ri, ils ont juste eut du mal à voir le potentiel du jeu (et je les comprend)et donc ils n’ont pas accepté de s’investir dessus pour rien.
(Et j’ai quand même fait l’effort de ne pas mettre que des carrés tout moches. :ph34r: )
Brunni : +1 pour tes deux propositions.
yopyop
Franchement il n'y a rien dans ta démo :p (pour attirer le graphiste)
Une map vide, deux maison, un puit, deux arbres et une princesse qui parle même pas dans un autre écran....
Pas de menu, pas de NPC, pas de monstre, etc...
rrr méchant grapheu va. (un codeur en plus tsss)
yopyop
edit tut tut tut y a un NPC le petit vieux. En plus il y a une mission : si tu lui parle pas tu peu pas sortir NA. Et la demo que je leur présenté été plus avancé.
Je dirais qu'il y a tout justement niveau code. reste que les graphs
Moi je trouve ça nikel, t'as un moteur de rpg fini en gros, et si les graphistes à qui tu l'as presentée non rien repondu, c'est parce que c'est dur de voir le potentiel d'un moteur quand on ne sait jamais demandé comment faire un jeu.
Si tu presentes ça comme un moteur, et pas comme une demo de jeu, alors ptet que les gens vont le regarder en temps que tel et alors, ils verront le potentiel de ton code., enfin je pense.
Toujours est-il que tout est là, ya le déplacement, les colisions, les dialogues, l'interactions avec des persos, reste à creer un univers, une histoire et faire des dessins. Ya le squelette, reste à donner une âme.
Je dirais qu'il y a tout justement niveau code. reste que les graphs
Merci gentil codeur :wub: .
Pour la presentation c'est vrai que c'etait une erreur mais bon... Je pensais que les grapheux fan de jeux etaient comme nous desireux de faire un bon rpg.
reste à creer un univers, une histoire et faire des dessins. Ya le squelette, reste à donner une âme.
La partie la plus chiante pour un codeur je crois et c'est sans doute pour ca que peu de homebrew avoutissent.
yopyop
Yopyop, ils sont de toi les dessins au crayon de papier qu'on peut voir dans le topic sur DsemuMe ou bien ton avatar ?
Pkoi pas justement donner ton style particulier à ton jeu, lui donner un aspect décalé, frais et nouveau avec ton style qui est unique et justement différent des productions bien (trop?) classique du rpg qu'on voit partout ?
Enfin, je sais bien la somme de travail que ça représente et reussir seul est un véritable challenge... helas.
EDIT: je vais aussi rajouter quelque chose. Ok, PA c'est un site sur le jeu, avec une communauté de dev français sur les consoles portables qui tournent pas mal du tout.
Ok, on presente nos projets avec plaisir et les gens sont tjrs là pour nous soutenir.
Mais pkoi on passerait pas ce cap en essayant d'en faire un lieu de rencontre pour les créatifs d'ici et d'ailleurs de façon à monter des equipes et faire de belles choses.
Comme expliqué mainte fois dans ce topic, on a tous envi de sortir notre demo perso parce que c'est un peu un reve, mais finallement, pour avoir recemment pu travailler avec d'autres gens sur des projets, je me suis vraiment rendu compte que (evidemment c'est pas un scoop) c'est 100 fois mieux, pour le projet, pour l'ambiance, et aussi au final pour nous, on est d'autant plus content du resultat tous ensemble, parce que c'est comme une aventure qu'on a partagé, et puis le resultat est mieux.
Je dirais qu'il y a tout justement niveau code. reste que les graphs
Dans sa démo tu trouve qu'il y a tout ? Attend, je veux bien que l'on s'encourage entre codeur, mais là c'est exactement ce qu'on disais plus haut, un peros qui bouge et qui se cogne contre les mur ça ne fait pas un moteur !
Pour moi, faire un jeu, c'est exprimer sa créativité, ça ne se résume absolument pas à faire du code. Un jeu c'est une oeuvre d'art, ya de la musique, des graphs, des scenari, une mise en scene et ... du code pour emballer tout ça et que ça fonctionne.
Comme Brunni je dirai : tant mieux pour toi si t'as le choix v_v
Moi je sais pas dessiner, ni l'envie d'apprendre, mon paint shop pro ne me sert qu'à modifier la luminosité, redimensionner et enregistrer sous un autre format...
Quand au son, c'est encore pire, c'est à peine si je sais modifier le volume ou couper dans le morceau...
Bosser ce genre de trucs, je trouve ca SUPRA CHIANT, si je devais absolument passer par la, autant lacher l'affaire direct...
Bosser avec d'autres ? franchement, y'a trop de lacheurs, faut trouver les bons et ils ne courent pas les rues...
ben si tu ne peut rien faire tout seul ni en groupe... t'as raison, autant lacher l'affaire direct...
bon.. je vais diriger une équipe de trois personnes ca vous tente ?
je sui drigateur, apréciateur, et inovateur...
ben si tu ne peut rien faire tout seul ni en groupe... t'as raison, autant lacher l'affaire direct...
bon.. je vais diriger une équipe de trois personnes ca vous tente ?
je sui drigateur, apréciateur, et inovateur...
hehe, tu sais, peut-etre qu'on délaisse trop le role de manageur d'equipe, creatif dans les homebrews ^^
Chez un petit studio de dev de jeu que je connais, ya un gars qui s'occupe que de ça, relationnel, gamedesign, gestion de l'equipe et des planings et c'est un taff à pleins temps.
Pour en revenir à ce que j'ai dit la page d'avant, c'etait surtout pas pour me faire mousser, loin de là, juste que je pense qu'un bon jeu, c'est un tout, du fun, du style, de la technique et de l'originalité. Evidemment, dur de faire ça seul, mais dans la vie, c'est tjrs plus marrant à plusieurs. ;)
Pour le rpg de yopyop, je vois :
-une gestion de map
-une gestion de colision
-une gestion de l'interactivité avec des persos
-une gestion de salle
-une gestion d'un systeme de dialogue avec fenetre de texte multiligne
-une gestion des couches avec le perso et les elements du decors, (le perso devant ou derriere l'arbre)
-une gestion d'objets du décors
ben dsl, euhh, il manque quoi?
Dans sa démo tu trouve qu'il y a tout ? Attend, je veux bien que l'on s'encourage entre codeur, mais là c'est exactement ce qu'on disais plus haut, un peros qui bouge et qui se cogne contre les mur ça ne fait pas un moteur !
En même temps un jeu c'est rien de plus. Peut être faut il ajouter un automate à état fini qui gère les missions du jeu. Et la il y était cf le petit vieux. En plus tout (ou presque) est dirigé par les données donc un éditeur suffi pour le modifier se que j’ai essayer de leur expliquer.
C'est vrai que c'est pas facile a voir dans cette demo pour un gars qui code pas mais bon c'est un jeu amateur et les graphistes n'attendent quand même pas un jeu totalement fini?
Wapata : rien n'est faisable seul et sans personne motivé ben le projet va directement à la poubelle comme 99% des homebrew et j'y fait pas exception dsl.
Yopyop
Pour le rpg de yopyop, je vois :
-une gestion de map
-une gestion de colision
-une gestion de l'interactivité avec des persos
-une gestion de salle
-une gestion d'un systeme de dialogue avec fenetre de texte multiligne
-une gestion des couches avec le perso et les elements du decors, (le perso devant ou derriere l'arbre)
-une gestion d'objets du décors
Et je te fais facilement la même chose sans moteur !
De plus :
- Il n'y a rien a faire
- Il n'y a qu'un perso qui parle
- Il n'y a pas de menu
- Il n'y a pas d'inventaire
- Il n'y a pas de monstre
- Il n'y a pas combat
- Il n'y a pas d'objet
- Il n'y a pas de stats
>> Tout ce qui fait un RPG
Alors franchement il ne faut pas s'étonner si les graphistes ne le prennent pas au sérieux en voyant ça...
ok, d'accord.
(à part le "facilement" ^^ ya quand même du taff)
Je suis sur que Yopyop va nous rectifier ça vite fait bien fait. ^^
Et je te fais facilement la même chose sans moteur !
C'est justement ca le truc c'est qu'il y en a un et si les graphistes ne font pas un minimum confiance aux codeurs c'est certain que les choses n'avance pas.
edit par exemple perso si j'etait un game designer j'aurrais sauté sur GOD c'est un moteur qui a bon potentiel si les perso sont ajoutés (en plus le path finder est la donc c'est pas long a mon avis).
De plus :
- Il n'y a rien a faire
Si parler au perso avant de sortir de la maison :ph34r:
- Il n'y a qu'un perso qui parle
Suffisant pour montrer que tous peuvent parler.
- Il n'y a pas de menu
- Il n'y a pas d'inventaire
- Il n'y a pas de monstre
- Il n'y a pas combat
- Il n'y a pas d'objet
- Il n'y a pas de stats
>> Tout ce qui fait un RPG
Alors franchement il ne faut pas s'étonner si les graphistes ne le prennent pas au sérieux en voyant ça...
Pas dans cette demo mais quand meme il faut que je fasse quelque chose pendant qu'ils font leur sprites.
yopyop
Ouch, le topic qui part en vrille ^^
Faisons dans l'ordre:
- quand je parlais de jeu de tennis amateur, je pensais à des trucs cons comme "Tennis" sur GB n/b: simpliste et 32 Ko.
- oui le mode 7 peut servir aux jeux de course, mais alors il n'y a plus de reliefs dans les pistes :p
Bon la première discussion est close :D
Maintenant la deuxième partie.
Il ne faut pas se faire d'illusion: un graphiste et un musiqueux sont nécessaires à la réalisation d'un bon jeu. Pourquoi?
- pour avoir plusieurs points de vue sur ledit jeu.
- pour ne pas avoir de rips ou de gfx/musiques moches.
- pour se remotiver en cas de coup dur.
Les jeux où le codeur (non gfxiste/musicien) bosse seul sont rarement finis et minoritairement de qualité.
Moi je dis vivent les jeux originaux! Le vrai homebrew! A mort les rips et les customs! Je n'ai rien contre les adaptations qui s'assument, c'est même une excellente chose.
Puis il ne faut pas croire que les codeurs sont au centre du monde. Bien sûr ils sont essentiels au développement d'un jeu, mais les gfxistes aussi ont leur mot à dire. A quoi bon faire un super moteur si la voiture autour est moche et inconfortable? Il faut bien créer un univers, des personnages, une histoire...
Oulà, je me relis, y a rien de cohérent... :D C'était un peu des pensées brutes qui me passaient par la tête. Je reviendrai demain ^^
C'est justement ca le truc c'est qu'il y en a un et si les graphistes ne font pas un minimum confiance aux codeurs c'est certain que les choses n'avance pas.
edit par exemple perso si j'etait un game designer j'aurrais sauté sur GOD c'est un moteur qui a bon potentiel si les perso sont ajoutés (en plus le path finder est la donc c'est pas long a mon avis).
Si parler au perso avant de sortir de la maison :ph34r:
Suffisant pour montrer que tous peuvent parler.
Pas dans cette demo mais quand meme il faut que je fasse quelque chose pendant qu'ils font leur sprites.
yopyop
Sauf que si tu essayes de recruter des graphistes il faut quand même leur en foutre un minimum dans la gueule...
Les codeurs ont quand même leur importance. C’est les seuls à pouvoir faire une base pour un projet qui montre que le projet est faisable. Qui n’a jamais vu un « scénariste » qui se targue d’avoir le meilleur concept du monde mais qui ne veut pas trop en dévoiler pour pas se faire voler l’idée, disons que c’est pas super motivant.
Sinon pour un projet qui commence à vivre c’est évident que tout le monde à son importance.
@DJP (mis fait pas non plus à ce pseudo !) pour ça il aurait fallu que je fasse de nouveaux sprites et ça prend un temps monstrueux ce qui n’est pas super motivant.
Pour le prochain projet je ne présenterais rien jusqu'à avoir un base encore plus solide et pour les sprites j’utiliserai des rip mais bon je suis certain que je serai démotivé avant et que ce projet rejoindra les autres et rebelote.
Dsl pour le hors sujet même si tout ça prouve que sans graphiste c’est difficile de faire un projet peut importe le type.
yopyop
pas entre nous.. ^^
Yopyop il assure, c'est un codeur de renom, il a fait un emulateur pour ds, juste ça, ça calme tout le monde.
edit par exemple perso si j'etait un game designer j'aurrais sauté sur GOD c'est un moteur qui a bon potentiel si les perso sont ajoutés (en plus le path finder est la donc c'est pas long a mon avis).
Tiens, ca me rappelle qu'il faut que je m'y remette... :-'
(mais sur le feu il y a aussi l'emu CPC, la modif du decodeur Adpcm, et la finalisation de ma mini-lib pour le sudoku... :ph34r:)
Globalement je suis plutot d'accord avec ce qui a ete dit, i.e. qu'il est parfois difficile de se motiver apres avoir pondu le moteur (surtout si tout le monde s'en fout), qu'il est evidemment difficile de tout faire soi-meme mais qu'on prefere souvent ne pas monter une equipe (c'est difficile, d'autant qu'il faut faire confiance aux gens et s'entendre avec eux). J'ajouterais aussi un manque de temps, tout betement !
Une remarque en passant : certains jeux qui paraissent simples sont en fait compliques a coder (et inversement) ; c'est dommage de s'entendre dire "oh, c'est un petit jeu" alors que le moteur est en realite plus complexe que celui d'un RPG classique :-*.
En tout cas une chose est certaine, il est preferable dans le cadre d'un homebrew de s'attaquer a des projets pas trop longs (notez que je n'ai pas dit "pas trop compliques") : le meilleur moyen de garder sa motivation jusqu'a la fin du developpement est de terminer le jeu rapidement ! C'est pour ca que je me suis lance dans Bomb Jack et Mario Balls : au moins je savais que je pourrai les terminer ! GOD est beaucoup plus ambitieux, et a moins qu'un editeur vienne me proposer de m'y remettre, j'avoue que j'ai du mal a me remotiver...
[Edit]
Au fait, Nes a dit un jour (http://playeradvance.org/forum/showpost.php?p=21917&postcount=66) : apres tu as des styles de codes + ou moin difficiles a comprendre (nrx => assé difficile a comprendre mais tu t'y fait [...]Heu, c'est vrai ca ? Qu'est-ce qu'il y a de difficile a comprendre dans mon code ? Je fais l'effort de tout bien decouper, tout commenter, ... ca m'embete qu'on trouve mon code complique ! :cry: (je ne plaisante pas, hein, votre avis m'interesse vraiment !)
[Edit-bis]
Je precise au passage, pour faire plaisir a Nes, que j'ai meme un "goto" dans Bomb Jack (cf. le Main.c), c'est donc un code super simple a comprendre :lol:.
ouais, perso, j'ai un peu de mal avec ton code Nrx. J'ai lu celui de marioball ya quelques temps et aussi celui du lecteur de pcm.
Autant pour marioball, ça va, autant le lecteur d'adpcm, j'ai eu du mal à m'y retrouver, j'ai pas encore tout compris d'ailleurs. disons qu'il se lit pas comme ça, comme on lirait du texte tranquille (comme certains codes qui se lisent sans effort et apres un passage ou deux pour voir par où ça passe t'as tout pigé le truc), il faut aller chercher profond des fois, mais bon, c'est comme ça, on code tous différement.
nrx: non le code pour l'adpcm ca va encore mais celui pour GOD il est assé difficile a comprendre (par rapport a d'autres entendon nous bien, j'ai pas dit que je le comprennai pas) a ta place je mettrai + de pointeurs sur structure en debut de fonction a la place d'y acceder directement, puis j'utiliserai + de #defines pour les codes qui ne bougent pas (surtout les attributions des registres) et surtout, c'est pas assé aéré Oo.
mais je dit ca pour moi, tout le monde n'interprete pas pareil et surtout j'ai enormement moin d'experiance que toi :ph34r:
un petit exemple sur une fonction simpliste:
// celui la tu le met dans le .h et tu le voit plus tu n'a plus a te le farcir ou y
// toucher sauf cas special
// ton texte:
// Passe en mode 0, et autorise l'affichage :
// - du fond du menu (BG0)
// - du texte du menu (BG1)
// Note : on passe en mode 0 mais les backgrounds 0 et 1 sont normalement deja actives, la GBA
// doit donc pouvoir switcher instantanement (pas de periode avec "3 lignes noires")
#define ActiveFenetre0 REG_DISPCNT&=WIN0_ENABLE ;\
REG_DISPCNT|=0|BG0_ENABLE|BG1_ENABLE ;
//////////////////////
// IsoInterruptDown //
//////////////////////
void CODE_IN_IWRAM IsoInterruptDown(void)
{
// Verifie qu'on est encore bien dans la zone affichable
if(REG_DISPVCNT<YM) {
// la tu sais que ca active la fenetre 0 sur 2 bg pas besoin de +
ActiveFenetre0
}
}
// c'est moche >_<
void IsoInit(unsigned char (*mapIsGround)(signed short),unsigned char (*mapIsWall)(signed short),
unsigned short mapWidthShift,unsigned short mapHeightShift)
{
unsigned short rotBgSize;
// Recupere les donnees de la carte
iso.mapIsGround=mapIsGround;
iso.mapIsWall=mapIsWall;
iso.mapWidthShift=mapWidthShift;
iso.mapWidth=1<<mapWidthShift;
iso.mapWidthMask=iso.mapWidth-1;
iso.mapHeightShift=mapHeightShift;
iso.mapHeight=1<<mapHeightShift;
// je trouve ca mieu, puis un pointeur y'a rien de plus rapide
void IsoInit(unsigned char (*mapIsGround)(signed short),unsigned char (*mapIsWall)(signed short),
unsigned short mapWidthShift,unsigned short mapHeightShift)
{
unsigned short rotBgSize ;
Iso *iso ;
// les espaces rendent mal dans cette balise php mais c'est censé etre bien aligné
// Recupere les donnees de la carte
iso->mapIsGround = mapIsGround ;
iso->mapIsWall = mapIsWall ;
iso->mapWidthShift = mapWidthShift ;
iso->mapWidth = 1<<mapWidthShift ;
iso->mapWidthMask = iso.mapWidth-1 ;
iso->mapHeightShift = mapHeightShift ;
iso->mapHeight = 1<<mapHeightShift ;
yopyop: ne te tracasse pas yopyop, je me suis cassé la gueule sur un rpg meme avec une equipe derriere, je trouve que tu t'en sort bien t'a pas eu a te taper le + difficile, la tu te dit que tu aurai pu finir, mais peut etre que tu te rend pas compte du temp et de l'ennuie que ca devient quand ton moteur de jeu est terminé.
puis tu te rend compte que tout le monde s'en branle de ton rpg, ca serai un portage de zelda tout le monde se serai jetté dessu comme des morfales mais puisque c'est un jeu original on s'en tappe (qu'il y ai + de boulot dessu ou pas) <_<
nhut/japi: je suis assé d'accord avec vous sur les jeu entierement originaux mais je reproche rien au codeurs qui font un portage je me demande juste pourquoi ils ne cherchent pas de graphistes.
ps: je me suis toujours demandé comment un gars pouvai dire en parlant d'un portage qu'il est bien dessiné ? bien rippé ok mais bien dessiné je pige pas :blink:
et surtout que le gars qui a rippé les gfx oser mettre qu'il est le graphiste du jeu.
Le code que tu montre est assez claire et en plus dans le tien il y a une erreur iso pointe sur rien.:devil:
yopyop: ne te tracasse pas yopyop, je me suis cassé la gueule sur un rpg meme avec une equipe derriere, je trouve que tu t'en sort bien t'a pas eu a te taper le + difficile, la tu te dit que tu aurai pu finir, mais peut etre que tu te rend pas compte du temp et de l'ennuie que ca devient quand ton moteur de jeu est terminé.
puis tu te rend compte que tout le monde s'en branle de ton rpg, ca serai un portage de zelda tout le monde se serai jetté dessu comme des morfales mais puisque c'est un jeu original on s'en tappe (qu'il y ai + de boulot dessu ou pas) <_<
J’avais prévu dés le début que je ne ferais pas la partie scénaristique et les graphismes (aux max j’aurais proposé des persos). Ce dont je ne me suis pas rendu compte c’est qu’Internet est si sectaire, je crois qu’il n’existe aucun forum ou les grapheux scénaristes et programmeurs se mélangent pour discuter sérieusement de projets.
Et de mon point de vu ce projet est mature
Par contre déçus de savoir que ton projet est mort aussi je pensais qu’au moins on aurait le tien. Vraiment dommage.
nhut/japi: je suis assé d'accord avec vous sur les jeu entierement originaux mais je reproche rien au codeurs qui font un portage je me demande juste pourquoi ils ne cherchent pas de graphistes.
Mission impossible 10
yopyop
Le code que tu montre est assez claire et en plus dans le tien il y a une erreur iso pointe sur rien.:devil:
j'ai bien precisé que c'etai un exemple ciblé simpliste ;) sur d'autres parties c'est beaucoup moin clair, pour l' iso faut mettre une fleche ou une variable temp ca ira mieu
Par contre déçus de savoir que ton projet est mort aussi je pensais qu’au moins on aurait le tien. Vraiment dommage.
mais non, ce projet ne mourra jamais :wub:
Ce dont je ne me suis pas rendu compte c’est qu’Internet est si sectaire, je crois qu’il n’existe aucun forum ou les grapheux scénaristes et programmeurs se mélangent pour discuter sérieusement de projets.
Tu sais quoi, on est arrivé aux m^me conclusions avec Nes et c'est pourquoi on aurait ptet un projet à monter pour remedier au probleme. A priori, certaines personnes pensent comme nous et ça pourrait marcher.
j'ai bien precisé que c'etai un exemple ciblé simpliste ;) sur d'autres parties c'est beaucoup moin clair, pour l' iso faut mettre une fleche ou une variable temp ca ira mieuHeu... mais pourquoi tu veux absolument acceder a une variable par le biais d'un pointeur ? Cet "iso" est une variable globale, dans laquelle je stocke tout ce qui est necessaire au moteur de 3D isometrique (globale pour que toutes les fonctions du moteur puissent facilement y acceder). Effectivement c'est une structure, mais ca ne te force pas a prendre un pointeur. Il est plus simple de faire :MaStructure a;
void truc(void)
{
a.popriete=2;
}que :MaStructure a;
void truc(void)
{
MaStructure* ptrA;
ptrA=&a;
ptrA->popriete=2;
}
En ce qui concerne ton autre exemple, dans lequel tu proposes de retier les 2 lignes "REG_DISPCNT&=WIN0_ENABLE;" et "REG_DISPCNT|=0|BG0_ENABLE|BG1_ENABLE;" pour les remplacer par un "#define" dans le .h, ce n'est pas ma politique : d'une part je trouve important de ne pas cacher ce qui se passe en le fourant dans le .h (ce sont des lignes de code !), en plus les commentaires expliquent bien ce qu'on est en train de faire, d'autre part appeler cette macro "ActiveFenetre0" pourrait induire des erreurs (je pourrais utiliser la WIN0 pour autre chose dans le code), et pour finir, ma regle est de ne mettre dans les .h que ce qui est utile a l'interface : autant quelqu'un qui utiliserait mon moteur ne doit pas avoir besoin de regarder le contenu du .c, autant il ne devrait rien trouver dans le .h qui ne lui soit pas utile.
Bon, je vais arreter la le HS ! Je souhaite vraiment a ceux qui se lanceraient a plusieurs sur un projet d'y arriver... on n'a pas eu beaucoup d'exemples de reussite jusqu'a aujourd'hui (!).
Je fais pas avancer le sujet, mais je te dirais de faire attention avec ça ;)
MaStructure a;
void truc(void)
{
a.popriete=2;
}
Si un jour tu as besoin de plusieurs 'MaStructure' par exemple, tu es bien embêté, si tu fais ça par contre:
MaStructure *a;
void truc(void)
{
a->popriete = 2;
}
//Pour faire plaisir à ceux qui me diront que 'a' pointe sur rien
__attribute__ ((constructor)) void Initialisation()
{
a = malloc(sizeof(*a));
}
Ben tu pourrais toujours bidouiller pour faire pointer 'a' vers n'importe quelle autre structure, ou même la passer en argument à 'truc' ^^
Je fais pas avancer le sujet, mais je te dirais de faire attention avec ça ;)
[...]
Si un jour tu as besoin de plusieurs 'MaStructure' par exemple, tu es bien embêté, si tu fais ça par contre:
[...]
Ben tu pourrais toujours bidouiller pour faire pointer 'a' vers n'importe quelle autre structure, ou même la passer en argument à 'truc' ^^Yes yes, je le sais bien ^^. D'ailleurs c'est ce que je faisais dans mes toutes premieres implementations de 3dIso et AStar... mais j'ai ensuite decide de simplifier la chose et ne proposer qu'une structure globale unique (=> pas d'allocation dynamique, et pas d'indirection), sachant que personne n'ira instancier plusieurs 3dIso dans le meme jeu !
Et pour etre tout a fait complet, j'ajouterais que lorsqu'on permet de creer plusieurs instances (= la methode que tu as decrite, avec un malloc), il vaut mieux retourner le pointeur vers la structure creee par le constructeur plutot que de le declarer en global. C'est ce que je fais pour les "cibles" dans le A* :Goal* AStarGoalInit(unsigned short size)
{
Goal* goal=(Goal*)malloc(sizeof(Goal));
goal->idx=0;
goal->max=size;
goal->mapIdx=(signed short*)malloc(size*sizeof(signed short));
return(goal);
}...et effectivement, je prefere ensuite passer ce pointeur aux fonctions qui en ont besoin :signed short AStarGoalAdd(Goal* goal,signed short mapIdx)
{
signed short idx;
idx=goal->idx;
if(idx==goal->max)
return(-1);
while(idx--)
if(goal->mapIdx[idx]==mapIdx)
return(idx);
goal->mapIdx[goal->idx]=mapIdx;
return(goal->idx++);
}
[edit]
...et puis, pour etre exhaustif sur le sujet, n'oublions pas de proposer un petit destructeur :void AStarGoalDestroy(Goal* goal)
{
free(goal->mapIdx);
free(goal);
}
Ok ^^
En ce qui concerne un projet communautaire, c'est bien le problème. Si on prend par exemple un jeu de plate-formes, on peut subdiviser un max:
Le code:
1) le moteur
2) les objets & ennemis (la plus grosse partie, plusieurs personnes)
3) l'écran titre, le générique, etc.
4) le(s) menu(s) (pause, sauvegarde, ...)
5) le système de carte
6) un ou plusieurs level-designers (ça n'en a pas l'air mais c'est très dur et important)
Les gfx, c'est plus dûr parce que dès qu'on touche un perso, il n'y a qu'une personne qui peut le faire:
1) les artworks (genre la grosse image de Sonic sur l'écran titre, le logo du jeu, ...)
2) les sprites du(des) personnage(s)
3) les sprites des objets / ennemis (travailler en collaboration avec l'équipe 'objets')
4) les tilesets des BGs (éventuellement une autre personne pour l'avant-plan)
5) 'tout le reste' (charsets, logo et anims de fin de niveau, ...)
Le son, là c'est encore plus dur parce qu'il faut un style et une ambiance, mais on peut au moins diviser en ce qui concerne les bruitages.
Et pour finir:
x) Un project manager, un scénariste (si besoin), ou un gars qui réfléchit à ce que devient le projet et qui recrute au pire :)
Dans cet exemple, chaque membre fait une petite partie qui correspond à ce qui le motive, et au final il voit le jeu avancer grâce au talent d'autres personnes (ce qui peut être bien plus satisfaisant que faire un projet soi-même, à moins qu'on manque sérieusement d'humilité :p) car un grapheux fera indéniablement mieux son boulot qu'un codeur.
Mais voilà le problème final: chaque membre est un maillon de la chaîne et il prend une responsabilité en s'engageant dans le projet. C'est le plus dur dans un projet amateur. Donc plus on est, moins on n'a de chances d'y arriver, à moins de pouvoir remplacer ceux qui quittent l'aventure. Mais commercialement c'est l'inverse :)
C'est pour ça que finalement c'est en général le codeur qui a les clés en main. C'est le seul qui peut décider de commencer un projet, et qui peut aussi décider de ce qu'il devient (si quelque chose est trop dur à coder, il n'y est pas tenu, et ça peut être une excuse aussi :whst:).
Je suis pas le mieux placé pour commenter le travail des autres (même pas le mien en fait), mais j’ai lu le code de GOD et je trouve ça facile à comprendre et n’importe quel codeur peut le reprendre sans mal.
En fait se qui manque en plus des persos, c’est juste un truc pour charger la structure d’un niveau qui contiendrais aussi un objectif a atteindre.
Pour ce qui est de la guerre de paroisse je n’y entrerais pas de toute façon tant que le code fait se qu’on lui demande c’est plus que suffisant.
(Nes ne le prend pas mal quand je taquine sur ton code mais c’est tellement amusant)
Pour le projet à plusieurs, parfaitement d’accord avec Brunni il suffit qu’un membre se casse pour que le projet soit mort.
yopyop
(Nes ne le prend pas mal quand je taquine sur ton code mais c’est tellement amusant)
mais je prend pas mal, ca prouve juste qu'on pourrai difficilement coder ensembles sur le meme projet nrx et moi ^^
comme le dit brunni c'est pratiquement impossible de partager les memes fonctions (sauf des trucs vraiment tres generique et pas discutable) les codeurs passerai des heures a essayer de prouver par a+b que tel code est meilleur quel tel autre ...
concernant les maillons je trouve qu'il y en a un peu beaucoup la (a part pour un jeu commercial sur pc ou limite sur psp) 4 ou 5 personnes c'est amplement suffisant (a partir du moment ou les gars savent faire du multitache sinon ca le fait beaucoup moin) :unsure:
En dehors du main codeur, si quelqu'un se casse sur un projet aussi subdivisé, tu fais juste changer l'orientation du jeu pour minimiser les pertes, et tu cherches quelqu'un d'autre.
Par exmple si le mec est spécialisé dans le dessin d'armure de chevalier,qu'il en fait et qu'il se barre, tu decides que le jeu sera moins orienté chevalier mais ptet plus mage et autre sorcier, apres tu cherches un mec qui veut bien dessiner des costumes, si il est chaud pour des tenus en cuir, alors hop, tu choisis ça comme orientation vestimentaires principales.
Enfin, c'est juste un exemple pourri mais bon, j'ai rien trouvé d'autres :-)
En dehors du main codeur, si quelqu'un se casse sur un projet aussi subdivisé, tu fais juste changer l'orientation du jeu pour minimiser les pertes, et tu cherches quelqu'un d'autre.
Par exmple si le mec est spécialisé dans le dessin d'armure de chevalier,qu'il en fait et qu'il se barre, tu decides que le jeu sera moins orienté chevalier mais ptet plus mage et autre sorcier, apres tu cherches un mec qui veut bien dessiner des costumes, si il est chaud pour des tenus en cuir, alors hop, tu choisis ça comme orientation vestimentaires principales.
Enfin, c'est juste un exemple pourri mais bon, j'ai rien trouvé d'autres :-)
Changer l'orientation du jeu ??? Non mais tu n'es pas bien dans ta tête :lol:
Lorsque tu fais un (gros) jeu tu prépares tout sur papier avant y compris l'ambiance, le scénario etc... Et le départ d'un mec ne doit rien y changer ! "Merde mon graphiste se tire, je vais devoir remplacer mon groupe de guerrier par des magicien" > C'est d'un ridicule enorme...genre ça ne risque pas de bousiller tout le reste du jeu...
tu vas m'apprendre à faire un jeu peut-etre... toi qui a tant d'expérience... j'aime pas utiliser ces formules, mais je reponds sur le ton du msg précédent.
toutes les teams de dev font ça, ya une merde sur un truc, et ben ils modifient un peu l'idée de base pour retomber sur leur pied. Le scenar est jamais figé, ça evolue, evidemment. Faut pas tomber dans les extremes, c'est anti debat de toute façon, j'ai pas dit tout changer... je parlais d'éléments du jeu.
Et puis, vu le découpage, tout est possible. Si le mec qui te faisait un truc part, ben tu te débrouille sans... ça ne "bousille" rien du tout, personne ne sait comment doit etre le jeu avant qu'il sorte alors les gens apprieront autant apres.
Même dans les équipes profesionnelles ya des gens qui partent, et ben ça stoppe pas le jeu pour autant, ils s'adaptent.
ca prouve juste qu'on pourrai difficilement coder ensembles sur le meme projet nrx et moi ^^Ben si, je pourrais te faire une lib avec 2~3 fonctions (genre le A*, le lecteur Adpcm, etc.) : tu pourrais par exemple faire un moteur de RPG en utilisant cette lib - il n'y aurait qu'a se mettre d'accord sur les interfaces (= le contenu du .h, avec principalement les prototypes de fonctions et l'explication detaillee de ce qu'elles font) ; ni l'un ni l'autre n'aurait a regarder le code de l'autre. Et le jour ou tu veux tout faire seul, il "suffit" de developper ta propre lib, avec les memes interfaces :).
Sinon, a votre liste de choses importantes a faire dans un projet, vous pouvez rajouter 2 roles :
- l'integrateur/gestionnaire de conf. (= celui qui merge tous les sources, graphismes, donnees et les cree les versions "stables"),
- et le testeur (= celui qui de facon independante va verifier de maniere exhaustive que tout fonctionne bien).
Notez bien que j'ai dit "roles" : ce ne sont pas forcement des personnes physiques supplementaires, mais seulement des responsabilites qu'il faut que quelqu'un assume ; dans une petite equipe l'integrateur sera peut-etre le codeur principal, mais en tout cas il faut bien quelqu'un qui integre tout le bazar fait par les autres.
Je trouve pas mal de raisonner en "roles" plutot qu'en "ressources", cela permet plus de flexibilite. Lorsqu'on reunit une equipe, il faut donc s'assurer que tous les roles sont tenus par des personnes qui ont les competences requises. Dans le cadre d'un dev commercial, la competence ne suffit pas, il faut aussi ajouter une notion de charge de travail et de budget : on ne peut pas avoir 1 personne pour chaque role (trop cher et trop lourd a gerer), mais inversement on ne peut pas avoir 1 seule personne pour tout faire (souvent incompatible avec le planning).
Ben justement ça dépend des différentes parties de code. Pour les objets, si je prends mon Sonic (désolé c'est pas pour ramener tout à moi mais j'ai pas d'autre exemple :-'), un ennemi simple qui se déplace vers la gauche sur le sol:
void hMotorbug(SONIC *s, PERSO *p, u32 msg) {
InitCollisions(p); //Collisions en mouvement
if (msg&MSG_AFFICHER) { //Faut-il afficher le personnage?
CreeObjetStandardP(p, AjTiles(motorbug_tiles, 32*32), AjPalette(motorbug_palette), TAILLE_32x32);
}
// Déplace un objet en tenant compte de la map. -1 => vers la gauche, 2 => gravité
MoteurCollisionObjets(p, -1, 2);
// Collision avec Sonic
hCollision(s, p, gcEnnemiSimple, TC_TOUS|TC_MOUV);
return;
}
u32 gcEnnemiSimple(PERSO *p, SONIC *s, u32 type) {
if (s->enboule) {
if (type==TC_HAUT)
Sonic_rebondit(s);
s->score += 100;
//Lance l'explosion
Perso_creve(p);
}
else
Sonic_perdBagues(s);
//Pas un "mur"
return 0;
}
Ok c'est laid, mais t'as pas besoin de connaître mon moteur pour le faire, juste les fonctions de base, c'est un peu comme faire une application Windows, t'as pas besoin de connaître le code source de Windows... ^^
Et si quelqu'un qui fait des objets lâche le projet ben on peut facilement le remplacer vu que ces objets sont indépendants du moteur et ne demandent en moyenne qu'une demie journée pour être codés :)
ravioli156
31/05/2006, 17h17
Pour le projet à plusieurs, parfaitement d’accord avec Brunni il suffit qu’un membre se casse pour que le projet soit mort.
yopyop
et vu que souvent c'est pas un mais la plupart qui se cassent :D
Mais ça me troue quand même quand je vois comme DJP a cassé ta démo, franchement c'était utilisable pour faire un rpg complet...
vBulletin® v.3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd. Tous droits réservés - Version française vbulletin-fr.org