Bonjour à tous,

Depuis longtemps, j'ai un projet de jeu en tête. Je l'ai toujours nommé BladeKinesis.

Je n'avais jamais dépassé le stade du projet dans ma tête car je n'avais pas les notions nécessaires pour le réaliser. Mais en utilisant Flash, je me suis rendu compte que cela pourrait facilement (tout est relatif ) être réalisable.

De plus, grâce à cette nouvelle partie du forum, je me suis dit que, peut-être, je pourrais trouver quelqu'un pour m'aider dans ma tâche car je ne suis pas encore très à l'aise avec le code.

Je vais donc vous expliquer le principe du jeu, tel que je le conçoit dans ma petite tête, et si cela intéresse l'un d'entre vous (ou plusieurs),ce serait fantastique.

Tout d'abord, commençons par l'histoire (à peaufiner selon les idées des autres collaborateurs).

Vous incarnez Nicholas, un ancien militaire, qui suite à une expérience ratée sur la télékinésie, fut laissé pour mort (en fait dans un profond coma).
A votre réveil, bien des années plus tard, votre mémoire a disparue, mais vous vous rendez compte que vous pouvez manipuler les objets à distance, mais seulement des masses réduites (vous n'avez pas assez d'énergie psychique pour déplacer un 36 tonnes non plus).Vous pouvez également léviter au dessus du sol sans aucune difficulté, il vous suffit de le vouloir. Au fur et à mesure de votre progression, vous pourrez manipuler de plus en plus d'objets en même temps.
Petit à petit, la mémoire vous revient, et vous commencez à avoir la haine quand vous vous rendez compte que vos anciens patrons se sont débarrassé de vous comme on jette une vieille chaussette.

Et là, vous décidez de vous aider de vos nouveaux pouvoirs pour vous VENGER !!! (Tadam !!!)


Maintenant, le fonctionnement.

BladeKinesis serait un mélange entre un Shoot'em Up et un jeu de plateforme.

Pour être plus précis, le décor sera celui d'un jeu de plateforme mais dans lequel on pourra se déplacer à la souris en lévitation.
Le personnage sera en quelque sorte ce qu'on appelle dans le domaine de la Fantasy un SwordDancer. C'est à dire un personnage qui manipule des épées par la seule force de son esprit.
Mais en plus, il pourra utiliser des objets du décor pour se protéger ou attaquer les adversaires.

En ce qui concerne le fonctionnement, je pense qu'il y aura des choses à voir en avançant dans le projet.


Je pense avoir dit le principal.

Si vous êtes intéressé ou si vous souhaitez des précisions sur quelque point que ce soit, surtout n'hésitez pas.

Merci d'avoir lu ce post en entier (ou pas)

A+

Joni

PS: pour l'instant, je suis en train de travailler le graphisme du personnage, mais étant perfectionniste, je ne veux rien poster tant que ce n'est pas à mon goût.

Salut,

L'histoire à l'air d'être intéressante, un soucon de XIII...
Pour le concept technique, çà me fait penser à Side Arms (tournait sur Amstrad à l'époque et sur Amiga/Atari) essayes de te renseigner sur ce jeu çà poura te donner des idées (voir : Lien).

La manipulation d'objets à distance va a mon avis te poser quelques soucis de conception, mais ce n'est pas insurmontable.

Je suis curieux de voir tes premiers tests.

Cordialement,
Monsieur Spi

Salut,

J'ai regardé du côté de SideArms et ca reste un pur Shoot'emUp alors que ce que j'ai en tête serait plus orienté plateforme. Dans mon idée, je voyais plus cela dans le genre de Castlevania : Symphony Of The Night mais avec un côté lévitation et manipulation télékinésique en plus (ce qui pourrait ajouter le côté Shoot dont je parlais, j'ai pas très bien expliqué sur ce point ...)

Pour l'instant j'ai déjà pas mal de boulot pour faire la partie graphique du personnage, des principaux ennemis, des objets, du décor ... mais je pense qu'en parallèle, je vais commencé à bosser sur le gameplay en utilisant des designs grossiers.

Le principal souci, c'est que je n'ai quasiment aucune connaissance en principe de développement de jeux vidéos.

Toi qui a l'air calé, pourrais-tu me donner deux trois conseils pour partir sur de bonnes bases ?

Je pense que je vais commencé par faire un niveau simple pour éviter de partir dans toutes les directions.

Merci et A+

Joni

Salut,



En fait je suis pas vraiment "calé", il y en a sur ce forum qui le sont largement plus que moi et qui pourrons t'aider, moi je ne fais que bidouiller mais je peux essayer de te filer un coup de main si tu veux.

Tout d'abord avant de te lancer tête baissée dans la construction je te conseille de tout mettre sur papier. De créer un scénario complet, d'imaginer le nombre de niveaux que tu souhaite, de détailler le maximum de choses en ce qui concerne tes personnages (héro et ennemis) et décors, possibilités d'actions, déplacements possibles, armes, particularités...
Cà te fera une bonne base pour prévoir tout ce que tu va avoir à faire, cette base va bien sur évoluer en fonction des idées qui te viendrons au fur et à mesure que tu avance sur la construction.
Sur la même idée, commence également à imaginer des plans de tes niveaux (level desing) et mets les bout à bout pour voir si l'ensemble reste cohérent.

Une fois que tu aura fait tout çà tu aura déjà une grosse partie du boulot qui sera faite, la construction de ton programme et de tes algorythmes s'en trouvera grandement simplifiée et te parraitra évidente.

Si tu lis l'anglais je te recommande d'aller faire un tour sur le tutoriel génial de Tonypa (voir: Lien), il va te donner les renseignements essentiels pour ta programmation, bien sur vu ce que tu veux faire je te recommande le Tile-Based qui à mon avis sera le plus simple à gérer. Tu peux reprendre ses FLA pour faire tes tests et dessinner les plans de tes niveaux, çà te donnera déjà les matrices de départ et une idée de la manière dont il gére tout çà, mais je te recommande quand même de développer ton propre moteur et de ne pas te contenter de reprendre simplement ce qu'à fait un autre, c'est quand même çà le plus intéressant quand on développe son propre jeu .

Sinon un autre conseil, arme toi de patience et de courage, créer un jeu est en général très long surtout quand il est lié à une histoire et qu'on veux des graphismes et une jouabilité poussés.

Bon courage et n'hésites pas à nous envoyer tes premiers tests.

Bonjour.

J'aime bien l'idée générale, mais je reste sceptique sur la gestion de la télékinésie, non pas niveau conception ou intégration, mais directement périphérique.
Si le déplacement du personnage se fait à la souris, cela voudrais dire que la télékinésie ce fait au clavier.
Pas forcément très pratique pour le ciblage des éléments du décors. De même que pour la manipulation proprement dite par la suite.

Tu as une idée plus précise de la façon dont devrais fonctionner le gameplay ?

Pour ce qui est du développement, commencer par un niveau unique n'est pas une mauvaise idée selon moi, mais il faut penser à généraliser au maximum les opérations pour que ce soit aisément adaptable au multi-niveaux par la suite.

Et j'appuie les conseils de Monsieur_Spi sur l'importance de la phase de conception. Le tableau blanc et le velleda, le papier et le crayon, voila les vrais outils du développeur.

Bonne journée.

H M Powered Man (Iron Savior)

Merci pour ces conseils (et pour ton lien Mr Spi qui à l'air très riche en infos)



J'y ai réfléchi et je pense qu'en fait je vais gérer les déplacements au clavier et la télékinésie à la souris.

Un truc du genre, tu déplace le perso au clavier (en lévitation totale donc) et avec la souris, si tu cliques sur un ennemi, ça lance une des épées que tu as avec toi, et si tu cliques sur un objet du décor (qui peut être balancé), un système de drag and drop avec calcul de la vitesse et de la trajectoire.

Mais je pense que je mettrai cela vraiment au point en m'attaquant à la prog, donc en voyant selon la difficulté de gestion du système de télékinésie.

Si vous avez d'autres idées ou conseils, surtout n'hésitez pas.

A+

Joni

Hello.

Mon conseil dans le dev de jeu, c'est vraiment d'éviter de rester sur des idées vagues et de se dire "bon on verra bien au moment d'implémenter".

Rédiger un document de game-design est très important, ca permet de clarifier ses idées, d'avoir un apercu sur la facon dont elles s'enchainent et de détecter une bonne partie des erreurs de conception. Or corriger des erreurs de conception au moment du développement, c'est une perte de temps folle, donc autant éliminer le plus tot possible celles qui peuvent l'être.

On peut croire que rédiger un document c'est fastidieux, mais je pense qu'on peut tourner ca d'une facon agréable. Commencer par écrire au brouillon les idées principales, puis chercher et tester des jeux deja existants qui implementent ces mécanismes pour se faire une idée de ce que ca donne et comment affiner les concepts. Puis passer a la rédaction du document proprement dit en essayant d'etre le plus précis possible (écrire du pseudo code avec des commentaires informels me parait etre le bon équilibre). Le document donnera donc une vision globale du jeu, des indications sur la manière de les coder et sera une bonne réference pour évaluer les temps de développements.

Bon apres je dis ca, mais on peut aussi coder freestyle en partant de rien, mais j'insiste sur le fait que c'est très risqué (abandon du projet).

Voilou

Salut Logic,



Pour cela, je suis entièrement d'accord. C'est d'ailleurs ce que je fais avant de commencer la réalisation.



Mais pour ce qui est de cette phrase:


Je voulais dire qu'il va falloir que je fasse des tests sur le gameplay à proprement parler. Car je n'ai que très peu d'expérience dans le domaine du contrôle de clip à la souris et au clavier (surtout les deux en même temps). Certes, j'ai déjà une idée de comment je vois la chose, mais je ne sais pas encore si c'est réalisable avec flash et/ou si la prise en main sera assez facile.


Sinon je suis entièrement d'accord avec ce que tu dis, j'en suis bien conscient.


J'en suis au stade ou je prends des notes un peu dans tous les sens, sur toutes les idées qui me viennent à l'esprit.
Ensuite je mettrai le tout bien en forme en ajoutant des bouts d'algo ou des schémas explicatifs.
Enfin je m'attaquerai à la prog à proprement parler.

Mais il n'empêche que je dois en parallèle effectuer quelques test techniques sur la jouabilité et les possibilités de Flash en terme de jeux vidéos.

A+

Joni

Hello Joni,

De part ma propre expérience je te conseillerai de faire des petits modules indépendants pour tester les différents aspects de ta programmation, essayes de faire en sorte de construire des codes facilement intégrables par la suite dans un projet plus vaste. Par exemple ton moteur de déplacement peut être testé avec quelques carrés et quelques ronds mais un code propre.
La création de petits modules indépendant va te permettre de gérer ton code au mieux (du moins moi c'est comme çà que je fais) et d'être sur que aucune erreur de programmation n'est imputable à une autre partie du code (variables identiques etc...).

A la fin tu va te retrouver avec plein de petits modules qu'il te suffira, si tu as tout fait proprement, de réunir dans ton projet final. (Ce n'est pas la meilleure méthode mais çà rend les choses plus faciles pour les personnes qui ne sont pas habituées à programmer et à gérer des codes parfois très longs. L'idéal est bien sur de programmer l'ensemble de ton projet d'un coup à partir de tes algorytmes sur papier).

En ce qui concerne les possibilités de Flash, tu peux tout faire ou presque, ce n'est qu'une question de programmation. Dans l'ensemble il vaut mieux se limiter à des jeux que l'on créais au début du jeu vidéo (référes toi à tous les anciens jeux à base de tiles comme les Mario, Side Arms, Gryzor, Zelda, Rtype, Bomberman, etc...), en ce sens la référence c'est les années 80. Par contre je te conseilles de te limiter à de la 2D (2D classique ou isométrique, qui est de la 2D en perspective). Evite tout ce qui est calcul 3D, Flash est simplement beaucoup trop gourmand en ressources pour gérer des moteurs 3D propres (bien que certains comme André Michelle - voir via Google - aient réussi de jolis moteurs 3D). Dans le même ordre d'idée, plus tu va utiliser du vectoriel plus tu va demander du calcul à ton projet et à ton moteur, il vaut mieux travailler à partir de GIF ou de PNG avec transparence si tu décide de faire du Tile-Based avec des graphismes chiadés. Les problèmes que tu va rencontrer le plus souvent (hormis les erreurs classiques de programmation) seront liées à l'utilisation des ressources par le Flash Player.

En ce qui concerne la jouabilité je pense que ce n'est pas lié à Flash (qui te permet d'utiliser toutes les touches du clavier, la souris ou même les joysticks avec un petit composant à rajouter et que je pourrais te filer si tu veux), mais plutôt à ton gameplay et à la manière que tu auras choisi d'affecter tes touches et de gérer ton code (sans parler du Level Design).

Ton problème principal sera donc de créer un jeu léger qui ne demande pas trop de ressources pour pouvoir fonctionner sur la plupart des machines, et c'est la raison pour laquelle la plupart des jeux faits avec Flash sont directement issus des années 80 ou calqués sur les jeux de cette époque. Les ordinateurs sont plus puissants aujourd'hui mais le Player Flash demande trop de ressources puisqu'il n'utilise pas les librairies DirectX ou OpenGL et doit tout calculer de lui même.

Bon courage.

Salut, pour la télékinésie en gros ça voudra dire "prendre un objet et le déposer autre part" ou tu pensais plutôt à des trucs plus compliqués comme empilements de plusieurs objets, jets d'objets etc., parce que là je dois te dire que ça risque d'être difficile pour un débutant, et ce qui est sûr c'est que la physique des objets ne sera pas réaliste à moins que tu utilises un moteur physique open-source en Flash, mais là encore je ne sais pas si c'est à ta portée.

En fait "les possibilités de Flash en termes de jeux vidéo" sont très larges. Les seules vraies limites sont le manque de puissance du langage (pas de 3D, pas trop de calculs) et le poids des fichiers.

Après, l'autre facteur est surtout le temps dont on a besoin pour réaliser ce qu'on souhaite en fonction de ses compétences. Pour commencer il faut surtout pas viser trop haut sinon ça n'aboutira jamais.

Salut,

Tout d'abord, il n'est nullement question de 3D. Je compte gérer le jeu en 2D avec des tiles comme les jeux des années 80. Comme dit dans un de mes posts précédents, un jeu de plateforme à la Castlevania.

Pour la télékinésie, je compte d'abord l'utiliser uniquement pour les épées que le perso transporte toujours avec lui. En gros, quand il attaque, ca balance une épée vers la cible et si celle ci est sur la trajectoire -> Touché.

C'est vrai que j'avais pensé utiliser aussi la télékinésie pour balancer des objets du décor sur les ennemis, mais je pense que pour l'instant je vais laisser cela de côté (peut-être dans une V2 en gérant dans l'histoire avec une évolution des pouvoirs)

Pour ce qui est du temps, je ne suis absolument pas pressé. Ca va aussi me servir à apprendre l'AS de manière assez poussée.


Quand je parle de jouabilité, je parle justement de la façon dont MOI je doit l'intégrer et non réellement des possibilités de flash.

Si cela vous intéresse, je pourrais partager mon fichier de Game Design quand il sera un peu plus avancé pour que vous puissiez me dire ce qui est à changer, à faire attention, à ajouter, ....

Merci pour tous ces conseils

A+

Encore une petite chose concernant la créa. Une fois que ton projet est sur le papier, ne te laisses surtout pas bouffer par les idées qui te viennent au moment où tu commence à programmer, certaines seront certainement très bonnes mais souvent elles t'obligent à revoir trop de choses ou retardent considérablement la sortie de ton jeu. Force toi à respecter au maximum ce que tu as mis sur le papier et n'hésite pas à sacrifier des idées qui te semblent géniales, gardes les pour un autre projet
Je dis çà parceque lorsqu'on travaille sur ce genre de projet avec passion on essayes souvent de tirer le meilleur de soi mais que comme tout processus créatif il n'y à jamais de fin sauf celle que l'on s'impose, une idée en entraine une autre ect, c'est ce qui est à mon sens la vraie difficulté de ce type de projet lorsque l'on est seul et sans personne pour nous imposer des limites.

Je me doute.

Surout quand on est ultra perfectionniste comme moi ...

Tout à fait flash pose un gros problème de lenteur et pas seulement pour la 3d, c'est aussi vrai en deux dimensions dès que l'on cherche à faire un scroll sur une grande surface ça rame car le retracage de flash est très lent.

Pour y remédier on a deux solutions. La première est de ne pas faire de scroll du tout, ça permet d'avoir un écran très grand et des zones de retracage assez petites, on ne retrace que là où il y a quelque chose qui bouge.
La seconde plus maline, est de ne faire scroller qu'un premier plan composé de quelques plateformes, et l'arrière plan reste fixe.

Les tuiles ne sont pas ce qu'il y a de mieux pour flash, ça n'a aucune utilité à part le charme "vieux jeu" il est plus intéressant de travailler avec des rectangles quelconques: http://www.strille.net/tutorials/part1_scrolling.php

Bon courage...

Monsieur_Spi Mon message répète un peu la même chose que toi, on a tous les deux réagi sur les possibilités de Flash parce que quand j'ai posté le mien j'avais pas vu que t'avais déjà posté...

Idem on a posté en même temps.

Verpan,
Le principe est exactement le même, c'est à dire se débrouiller pour n'afifcher que les zones visibles de ton décor.

Pas exactement, là tu parles du principe logique du scroll qui sert à réduire la quantité de sprites et de comportements.

La remarque que j'ajoutais c'est concernant la réduction des zones de retracage, ce n'est pas la même chose. Pour les réduire on fait un arrière plan immobile (qui ne retrace pas) et on scrolle seulement un premier plan composé de quelques sprites.

Hello,

J'ai beau chercher mais je ne vois pas ce que tu entend par "retraçage", il doit me manquer un truc que je connais pas ou j'ai mal compris

Le tutoriel de Strille est un (bon) moteur à base de tiles (ou Tile-Based et plus précisément ici des "Super Tiles"), exactement comme Tonypa et OutsideOfSociety's, d'ailleurs les trois approches sont issues d'un tuto de OutsideOfSociety's au départ. J'ai lu le tuto histoire de pas répondre sans savoir.

L'auteur (Strille) dit ceci dès le départ :

Si j'ai bien compris, et pour résumer le principe (arrêtez moi si je dis une énorme connerie), il s'agit donc d'afficher des groupes de tiles que l'on déplace en tant que groupe et non une grille complète en traitant chaque tile individuellement. Ce qui à pour but effectivement d'alléger le processus dans certains cas puisque l'on traite uniquement le déplacement de gros tiles (consitutés de plein de petits) et non de plein de petits directement. C'est une bonne approche mais qui ne concerne que certains jeux, çà marche pour Sonic ou pour des ShootEmUp classiques, mais pas pour les JDR en vue Iso à la Zelda par exemple, par contre c'est vrai que la réactivité demandée n'est pas la même.

Allez voir : la démo du moteur de jeu de plateforme
Appuyez sur B pour afficher les tiles çà donne un très bon exemple de la manière dont sont utilisés les groupes de tiles. (dit dans le tuto).

Dans le fond il s'agit du même concept et presque du même moteur, çà reste du Tile-Based avec le même principe général (fractionner en tuiles les images trop lourdes à scroller en un seul bloc), sauf que dans le cas de cette approche on considère des groupes et non des individus. Cà à certains avantages mais aussi des inconvénients (voir la fin de son tuto où il explique justement tout çà.)

Bon tuto, autre approche, bon courage Joni !
Je pense que tu n'en est pas encore là mais ce sont de bonnes références.

Salut,

Merci beaucoup pour ce lien Mr Spi. Ca à l'air très intéressant. (Hop enregistré sur le disque dur)

De plus l'exemple avec l'affichage des blocs est vraiment bien fait.

Je regarderai cela plus tard en détails.

A+

Joni

Spi>

Télécharge les version debug de flash player (standalone et plugin), puis fais clic droit dans les swf et afficher les zones de retracage.

Le retracage de flash est très lent c'est pour ça qu'on cherche à le réduire au maximum.

Très impressionnant la démo de strille!

Elle renvoie sur le lien que j'ai passé plus haut.

Comme je l'expliquais ça consiste à afficher un décor constitué de plusieurs sprites de tailles différentes, c'est plus adapté à flash que les petites tuiles carrées.

Bonjour,

Mon dossier de Game-Design avance bien.

Je suis en train d'effectuer quelques tests techniques sur la jouabilité (avec des carrés et des ronds pour l'instant) et j'arrive à faire ce que j'imaginais pour les déplacements assez facilement. Il me reste à peaufiner un peu mon code.

Je vais m'attaquer aux attaques maintenant.

Je suis aussi en train de bosser un peu la bande son. Et c'est beaucoup plus long qu'il n'y paraît de faire une bonne bande son. Heureusement, ma copine fait des études de sonorisatrice et m'aidera pour cette partie.

Voilà pour l'évolution de ces derniers jours.

Quand ce sera un peu plus avancé, je vous posterai mes fichiers de test si vous voulez.

A+

Joni

Bonjour à tous,

J'ai une question qui me taraude ...

Vaut-il mieux que je gère mon niveau (qui risque d'être assez important) en une seule partie que je charge progressivement à l'affichage, ou dois-je découper mon niveau en plusieurs pièces avec un petit temps de chargement entre chaque ?

J'espère que c'est assez clair.

Merci

Joni

Salut,

Et bien nous en revenons à notre problème de Tile-Based dont nous parlions depuis le début

Tout dépend de la structure que tu souhaite adopter. Un jeu basé sur le le principe du dessin unique des tes niveaux "art-based" (une grande image) ou d'une image découpée en tiles (plein de petites tuiles avec un moteur qui te permet de les déplacer et de n'afficher que ce qui est utile).

Tu dois faire un choix dans ton gameplay, si tu souhaite faire du scolling je te recommande du "tile-based" (après à toi de voir quel est le meilleur moteur parmi ceux que nous t'avons donné en exemple, que ce soit celui de Strille ou celui de Tonypa). Si tu ne souhaite pas de scrolling mais des niveaux fixes tu peux sans doute te diriger vers du "Art-Based" c'est à dire des niveaux fixes dessinnés en un bloc mais qui ne bougent pas, on passe simplement d'une pièce (ou d'un point de passage) à une autre par l'intermédiaire d'une porte.

De ce choix découlera ton choix de découpe de ton (tes) niveau en fonction de sa longueur. Si tu choisi de faire un seul grand niveau essayes de placer des points de sauvegardes régulièrement çà évite de devoir se retaper tout le niveau à chaque fois. Si tu choisi de le faire par morceaux essayes de faire repartir le héro à la dernière porte (ou point de passage) lorsqu'il meurt. Si tu fais du scrolling je pense que tu peux faire un seul grand niveau, si tu n'en fait pas découpes ton niveau en petites portions.

Les deux solutions se valent, à toi de choisir.

Merci pour cette réponse détaillée.

J'avoue que j'ai encore en peu de mal avec la visualisation du concept Tile-Based ... car je ne suis pas habitué.

Pour mon jeu, je pensais faire un système hybride entre les deux. C'est à dire un système de pièces (avec un système de chargement par porte) mais avec des pièces assez grandes et qui seraient donc scrolable ... Penses-tu que ce soit trop compliqué à gérer ?

A+

Joni

J'ai une autre question,

Elle concerne l'animation des persos.

Je pensais faire des animations pour chaque mouvement de mon perso, mais j'ai peur que cela soit trop lourd à gérer. Qu'en pensez vous ?

Sinon, est-ce que seules quelques images-clé des déplacements suffiraient ?

Merci

Joni

Le Tile-Based c'est une recommandation que je fais mais ce n'est pas la seule solution, d'autres te proposerons surement autre chose, si tu te sent plus à l'aise avec une autre méthode tu peux aussi l'essayer.



Je pense que ce que tu veux au final c'est çà : Lien (regarde le swf d'exemple)



Je recommande la technique des Sprites, c'est à dire une suite d'images qui détermine ton mouvement, les images sont traitées via photoshop par exemple ou un logiciel d'animation 3D (Poser, 3DS, Maya (pour les plus calés)) le principe des sprites est assez simple à comprendre, c'est simplement une suite d'image pour chacun de tes mouvements que tu intégre dans un MovieClip comme une animation indépendante, tu appelle ce clip en fonction du mouvement que tu veux utiliser, regarde pour l'exemple les planches de sprites utilisées dans les jeux old-school : Lien

Tu peux utiliser les fonctions de Flash pour animer ton perso (vectoriel et clés d'animation) mais n'oublie pas que tout ce qui va être vectoriel va devoir être calculé par Flash et va donc ralentir l'ensemble de ton programme. C'est utile lorsque l'on veut faire des petits jeux pas lourds pour le web (NelChaël et son superbe jeu d'arcade ShooShoo utilise principalement des calculs vectoriels par exemple, il t'en dira plus que moi à ce sujet).

Une fois encore tout dépend de l'orientation que tu veux donner à ton jeu et tout ceci rappelle l'importance de bien préparer ton projet sur papier avant de te lancer dans la programmation, tes choix techniques en dépendent.

Oui exactement. Je ne me souvenais plus que dans ce tuto c'était expliqué.
Ca c'est réglé.



Au final, je me suis dit également que ce serait la meilleure solution. En plus, ça permettra de garder l'aspect jeu des années 80 ...

Merci beaucoup pour ces réponses constructives.

A+

Joni

Moi j'aurai un dernier conseil: te fais pas trop chier non plus. Si tu sens à un moment que la méthodologie te coupe du plaisir ou t'emmerdes plus qu'autre chose, laisse tomber et joue la au feeling.

La méthodologie c'est utile et rend performant, ya pas de doute. Mais bien souvent c'est parce qu'on est passé par des projets sans méthodologie, avec son lot d'erreurs (et de prises de tête), qu'on en arrive à vouloir réfléchir plus longtemps au moment de la conception et à apprécier les docs de game-design, les méthodes orientée objet et autre joyeusetés formelles.

Je suis assez d'accord avec Logic, commence par ce que tu sais faire et surtout amuse toi.
Le reste viendra après au fur et à mesure de ton évolution, mais il est bon de connaitre au moins les techniques de départ pour commencer dans la bonne direction.

Bonjour,



Ca c'est sur. De toute facon, je ne cherche pas à faire un jeu professionnel. C'est surtout pour m'obliger à bosser sur un projet assez complexe pour apprendre ce qui me manque en Action SCript.

Et déjà, rien qu'en effectuant quelques petits tests techiques, j'ai appris pas mal de choses intéressantes (comme l'utilisation des tween, génial).

Si ca vous interesse, voici le swf des tests de maniabilité que je suis en train de faire.

BladeKinesis

Merci

A+

Joni

Hello,

Je confirme (mais c'est un choix tout à fait personnel) que je n'aime pas du tout les déplacements à la souris dans ce type de jeux, je préférerais gérer la télékinésie des objets avec la souris tout en déplaçant le perso au clavier.

Bon courage.

Salut,

Justement, en parallèle, je suis en train de faire un test en mettant le controle du perso au clavier et celui de la télékinésie à la souris. Je pense que ce sera mieux car en plus, on pourra balancer l'épée vers le pointeur de la souris, au lieu d'être limité à l'horizontale pour l'attaque.

C'est en cours, je posterai ça dès que ce sera prêt.

Sinon, pour l'introduction de l'histoire, j'ai une question qui m'embête.

Je compte faire une petite séquence d'intro qui raconte l'histoire pour bien rentrer dans l'ambiance. A votre avis, vaut-il mieux parler au joueur directement comme s'il était le personnage, ou bien parler du personnage à la troisième personne pour le présenter ?

Que préférez-vous?

Merci d'avance

Joni

Tout dépend du scénario, si c'est un peu à la XIII tu peux utiliser une sorte de voix off ou une conscience qui guide et aide le perso au fur et à mesure (le perso se parle à lui même, essayes de faire le tri dans ses souvenirs qui arrivent par flash ....)
Si tu te dirige plus vers un jeu sans indices en cours de route etc... alors utilise un conteur, une personne qui raconte l'histoire (une peu comme dans MadMax 2 par exemple où on commence par une histoire racontée par un narateur et on fini par la présentation de ce narrateur qui en fait faisait partie de l'histoire).

Vraiment à ce niveau tout dépend de ton scénario.

Bonjour


Le choix de la narration dépend de beaucoup plus que le choix de la personne.
Par exemple, il y a aussi la position temporelle du narrateur par rapport à l'histoire
Voici quelques exemples de type de narrations:

Narration immédiate : 1° personne, présent. Le personnage raconte 'sur le vif' ses pensées.
Cela peut être sous forme directe (on affiche ce que le personnage pense), ou indirecte (le personnage écrit un journal de bord, jour après jour).
Exemples : Metroïd Fusion, Impossible Creatures

Biographie : 1° personne, passé. Le personnage raconte son histoire.
En général, le personnage écrit sont histoire après que l'aventure soit finie.
Phrase classique : Si j'avais su ce qui allait arriver...
Exemple : Pas d'idée en tête mais j'ai déjà du en voir une

Dialogue : 1°, 2° et 3° personnes, passé. Le personnage explique et/ou se fait expliquer son histoire.
Peut se dérouler entre amis, ou dans une cour de jugement, ou encore chez un psy ou un journaliste...
Exemple : Eck VS Sever

Narrateur omniscient : 3° personne, présent et/ou passé et/ou futur. Une personne externe à l'action raconte l'histoire.
Souvent trop impersonnel à mon avis.
Exemple : NeverWinter Nights

Journaliste : 3° personne. présent. L'histoire est racontée par le biais de nouvelles et de journalistes.
Souvent sous la forme de Flash Infos.
Exemple : MechCommander 2

Accompagnateur : 3° personne, présent et/ou passé. Ce n'est pas le personnage principal qui raconte l'histoire, mais un autre personnage de l'histoire (compagnon, adversaire...)
Peut être sous forme immédiate, biographique ou de dialogue.
Exemple: _

Narrateurs multiples : 1° et/ou 3° personnes, présent et/ou passé. Plusieurs narrateurs se passent la main pour raconter l'histoire.
Bon principe s'il y a plusieurs aventures dans le même jeu.
Utilise généralement plusieurs accompagnateurs.
Exemple : Tomb Raider 5 : Sur Les Traces De Lara Croft


Le choix dépend pas mal du scénario (comme le dit Spi), sinon, c'est à toi de voir.

Bonne journée.

Règle n°1 du game-design: éviter tout ce qui fait perdre l'immersion du joueur dans son univers.

Donc il faut parler au joueur comme étant le personnage. Lui dire "tu" (ou "vous" si t'es poli) dois accomplire la mission X, "tu" dois sauver la princesse, "tu" as réussi la mission Y. Car si tu pointes le personnage en disant "il" doit faire ceci et cela... tu mets je joueur de coté et finalement la seule expérience que tu lui offres, c'est d'être le spectateur d'un film dont il va influer le déroulement. Or ce n'est pas ce que l'on veut, le joueur n'est pas spectateur, il est acteur et il subit et agit dans son univers: le joueur incarne le héros.

Bien sûr ensuite l'usage du "il" peut provenir du contexte de narration, comme le décrit Aralicia. Si le personnage lit le journal intime d'un personnage X qui parle du personnage-joueur, alors ce sera bien par le biais d'un "il".

Mais il me semblait que ta question était plus de l'ordre de la position du joueur dans le mécanisme d'immersion: le joueur est-il acteur incarnant le héros (le "tu") ou spectateur influant le déroulement du scénario (le "il"). Je persiste, on est bien dans le "tu" et tout ce qui fait passer du coté "il" est une erreur.

D'un autre coté il faut aussi bien se rendre compte que j'ai caricaturé. En général aucun jeu plutôt élaboré n'utilise explicitement le "tu", sauf les jeux destinés aux jeunes enfants. Utiliser le "tu" explicitement arrive quand on insère un personnage omniscient dans le scénario (cas typique des tutoriaux). Or j'ai bien l'impression que le recours aux personnages omniscients est de plus en plus évité dans les jeux. Ca casse l'immersion et il est bien plus efficace d'injecter l'information utile dans les personnages ou les objets immergés dans le jeu.

voilà moin point de vue et désolé pour le monologue lol

Le problème quand on débute c'est qu'on se motive en imaginant des gameplays très ambitieux alors qu'on a pas le niveau pour le coder.
Il faut essayer de trouver un juste milieu: pas trop ambitieux mais pas trop rebutant non plus

Les shoot-plateforme comptent parmi les jeux 2d les plus compliqués à coder, les algo de scrolling sont très loin d'être facile à optimiser avec flash, quand aux collisions avec les plateformes et entre les objets c'est encore une autre histoire...

Pour se familiariser avec les grilles il vaut mieux commencer par un puzzle ou un tetris, pour apprendre à faire des collisions entre objets multiples et les scroll c'est mieux de démarrer par un space invaders, quand aux collisions plateformes / objet il vaut mieux commencer par un truc comme bombjak
Une fois que tu auras développé plein de librairies de code qui gèrent tout ça tu pourras envisager d'attaquer un super shoot plateforme.

Une autre approche intéressante pour les débutants c'est de faire un jeu d'aventure sans action, pour ne pas avoir à développer des choses complexes et critiques en optimisation comme du scroll ou des collisions. Le déplacement du personnage peut être très simplifié, ça peut être une simple interpolation entre des cases ou des points reliés par des segments, voire pas de déplacement du tout, on fait une animation interactive.
Flash est bien fait pour ce genre de jeux, avec la timeline on peut faire des choses assez intéressantes

Bonjour,

Je suis bien conscient que ce ne sera pas forcément évident mais d'une part, je ne suis pas du tout pressé, cela prendra le temps qu'il faudra, et d'autre part, je ne suis pas un débutant en développement, juste en flash, et un langage, quand on en a vu déjà plusieurs, ce n'est pas ce qu'il y a de plus difficile à apprendre.

Comme je l'ai déjà dit plus haut, je fais ce jeu pour enrichir mes connaissances en flash. J'ai volontairement choisi quelque chose d'ambitieux pour me pousser en avant.

Même si le dev de ce jeu doit prendre 2 ans, je veux surtout apprendre en y prenant du plaisir...

A+

Joni

Ce n'est pas très motivant d'attendre 2 ans pour voir le résultat.

Il vaut mieux commencer par des petits projets, qui vont permettre d'une part d'avoir des librairies récupérables pour des projets plus gros, d'autre part de décrocher des contrats pour des projetsplus gros et rémunérés, et aussi ne serait ce que pour le feedback personnel, c'est agréable d'avoir réussi à faire quelque chose rapidement même si c'est un petit jeu et ça donne envie de continuer.

On voit de nombreux débutants sur les forums qui se lancent dans des projets très ambitieux et dans 100% des cas ils se découragent, le plus tôt étant le mieux. Ceux qui s'en sortent commencent par du très facile: pong, morpion, puzzles, space invader...

pas plus motivant que de faire un puzzle ou un pong cela dit

Bonjour,



Ca c'est sur ...

C'est pour cela que je préfère partir sur un projet complexe mais beaucoup plus intéressant.

De plus, j'ai déjà eu ma dose de Memory, Mastermind et compagnie quand j'étais à l'école.

A+

Joni

Il doit tout de même exister des nuances intermédiaires entre un projet de deux heures et un projet de deux ans

L'idée en fait c'est de le décomposer en sous-projets plus petits, à chaque fois on repart du moteur précédent et on ajoute et améliore des choses.

Comme ça tu as un feedback continu tout en ayant un projet ambitieux.

Hello,

En fait çà dépend beaucoup de la personne, de son niveau et de sa force de volonté.
Certains ne seront pas capables de tenir des projets ambitieux (souvent les débutants et les jeunes moins enclins à tenir la distance), d'autres en seront tout à fait capable, en particulier les gens ayant deja des expériences en programmation et en développement de projets. Dans le cas de Joni (si je comprend bien, sinon Joni corriges moi), c'est un "débutant en création de jeux" en Flash mais pas en programmation. Je comprend alors que repartir encore sur des petits projets ne soit pas super motivant, on connais deja le résultat et faire un Xième tetris ou casse brique n'apporte pas grand chose, il est plus motivant de se donner des objectifs plus ambitieux (surtout dans le cas où on ne souhaite pas une commercialisation ou une distribution d'échelle).
Donc d'accord avec toi pour les purs débutants, pas d'accord pour ceux qui ont deja un certain niveau en programmation.

Au contraire je ne conseillerais surtout pas cette méthode de travail à des débutants en programmation.
Par contre c'est un principe largement employé dans la production idustrielle.


Je parle bien de la méthode qui consiste à découper le développement en phases, on commence par une version la plus simple possible, puis on perfectionne. (pas de faire un pong ou un morpion)

Un exemple possible adopté à son développement:

Je veux aboutir à un shoot / plateforme, basé sur une grille uniforme (tuiles carré)

Découpage possible:

1/ je fais un editeur de map le plus simple possible, des maps d'un seul ecran pour commencer. j'ai donc déjà une lib qui va gérer un affichage de tiles dynamique
2/ dev de la librairie qui gère les collisions box et tuile pour en faire un casse-briques
3/ agrandissement des maps, je développe un algorithme de scroll, pour faire un mario like (etape difficile également, faire un scroll propre avec flash n'est pas simple du tout)
4/ ajout des tirs, des bonus, des portes...
5/ ajout d'ia
6/ etc

A chaque étape je peux oublier l'ensemble du programme et me concentrer sur le point dur concerné


Bien entendu il n'est pas obligatoire de travailler comme ça, mais cette façon de faire est sympa, on a le sentiment d'avancer.

Bonjour,

Mon dossier de game-design avance pas mal. Et les tests aussi. Je pense être arrivé à la jouabilité que j'escomptais (avec encore quelques petites retouches,ce sera vraiment bon).

D'ici peu de temps, je posterai mon fichier de test pour que vous puissiez me dire ce que vous en pensez et si vous voyez des bugs (mais là je l'ai pas sur moi, je suis en déplacement pro, donc ce WE).

Par contre, j'aurais besoin d'un gros coup de main pour ce qui est du graphisme.

Connaitriez-vous des forums dédiés au graphisme où je pourrais trouver un coup de main, car sinon, j'ai peur de ne pas m'en sortir ou de faire un truc moche graphiquement?

Merci d'avance,

Joni

yo, je n'ai pas lut les tartines qu'il y a la haut, ou alors très en diagonal, donc mon avis sur le projet ne sera peut être que de la redite.

Il y a une chose a prendre en compte avant de commencer un gameplay, c'est de prendre en compte l'interface de jeu, ici à priori, on à faire à un jeu flash, donc accessible sur le net, et donc jouable via l'interface clavier/souris de l'ordinateur, hors d'après ce que j'ai pu voir, l'utilisation de la souris est complètement laisser de coté, au niveau accessibilité joueur il faut comprendre que la souris est quasi primordial, parce que toucher toute les touche pour savoir enfin laquelle me permettra de flinguer le zombi c'est pas top - je sais je lit jamais les tuto. comme tout le monde ceci dit. Bref la souris permet un confort d'utilisation et il serait très mal venus de s'en passer sans compter que cela peut enrichir le game play.

Ensuite le "uniquement jouable à 2", la encore il faut prendre en compte la manière d'utiliser-le support, un ordinateur c'est une personne, et jamais plus, donc on a un problème de fondement, il faut réfléchir au comment manier le couple de héros. (c'est la que la souris notamment peut aidé)

Fait un résultat au plus vite j'ai crue lire a un moment un truc du genre "attendre 2 ans pour voir son jeu fini c'est pas kikoolol" - bon c'est un peu faux puisque si tu attend, il ne se passera rien, le mot travailler aurais été plus approprié. Donc effectivement c'est pas génial, et tout les premiers projets sont un échec à cause de la longueur que peut prendre un dev, donc mon conseil n'est pas de restreindre tes ambitions, mais plutôt de la découpé en plus petites parties vachement plus réalisable. C'est plus motivant pour soit quand les étapes sont franchies. Plus tu fait de projet, plus les ambitions sont accomplis, c'est comme ça que ça marche.

bon courage, tcho

Euh... je crois que tu mélanges deux projets de jeux différents.



Je fais un jeu solo. C'est KellAndSam qui se joue à deux. Et ce n'est pas moi qui le développe. Je sais bien par expérience que le jeu à deux sur un clavier n'est pas terrible.



Au contraire, dans la première version de gameplay que j'avais fait, le déplacement du perso se faisait à la souris mais cela n'est pas pratique du tout, donc je suis passé sur un gameplay déplacement du perso au clavier / visée et tir à la souris.
Vous pourrez tester quand j'aurais posté mon nouveau fichier.



En fait, quand j'ai parlé de 2 ans, c'était plus pour dire que j'avais pas de pression au niveau du délai puisque c'est un developpement perso que je fais pour apprendre en me faisant plaisir. J'espère bien que cela ne me prendra pas 2 ans, mais je n'ai pas non plus envie de bacler le jeu pour pouvoir sortir un truc rapidement.



Y a un peu de redite, mais aussi du mélange entre mon projet et un autre. (mais je comprends que tu n'aies pas eu envie de te retapper tout le topic car il est assez long).

Aller, je suis grand seigneur aujourd'hui, et je ne t'en voudrai pas !!!

A+

Joni

hhaaa effectivement j'ai confondu 2 projet ! desolléé