Discussion :

[the-morpher]

Bonsoir tout le monde.

J’aimerai vous présentez un jeu en cours de développement 2D basé sur un système de tuile orthogonale.
Le moteur graphique ma pris énormément de temps qui me permet de gérer l'affichage des Sprite/Assets, de créer des animations et ce qui est essentiel c'est la gestion des événements Clic, survole ...

Le jeu tourne sur l'histoire de Naruto, j'ai prévus 4 classes au départ, pour les autres ça viendra au fur et à mesure du développement.
Le nom du jeu je n'ai pas encore décidé, mais j'ai mis un nom au pif "Nova Super Heroes".

Voici des images :




J’ai prévus aussi une vidéo qui explique un peut l'ensemble du jeu pour plus détaille :

je vais citer un peut se qui a été réalisé :

• Système de mouvement y compris la détection des obstacles, et le faite de trouver le chemin du point A au point B.
• Lancement du combat en mode Free Play opérationnel.
• Création du 1er sort Rasengan pour la classe Naruto.
• Système de blocage entre les joueurs en combat.
• Calcule des dommages en prenons en considération la défonce de l'adversaire.
• Sécurisation des données des 2 cotés Client et Serveur.

...

Ce qui reste à faire :

• Ajouter d'autres sorts qui ne soient pas en ligne directe, donc diagonale.
• Réussir à réaliser la portée d'un sort qui frappe en diagonal avec les obstacles qui doivent cachés certaines zone qui ne sont pas accessibles et franchement je ne sais pas comment faire celle-là
• Ajouter plus d'animation lors du combat.
• Fixer quelque bug et ajouter des améliorations sur le système de mouvement.
• Améliorer le système de discussion et revoir l'ensemble du système Front End.

Avantage :
Un jeu RPG Naruto digne de ce nom , enfin je ne sais pas trop

Inconvenants :
Le jeu est fixé sur un affichage 800x600, donc il sera pas agrandi ou redimensionné puisque le moteur graphique ainsi que le jeu est basé sur les pixels,
Donc une tuile veux 30x30, un redimensionnement va fausser le calcule surtout la détection des événements souris.
La portabilité sur une autre plateforme à part Windows est impossible malheureusement.

C'est vrai que je ne me suis pas penché réellement sur ces problèmes mais pour le moment j'essaie de faire ce qui est important, à savoir un jeu qui marche de A à Z.

Pourquoi je poste mon projet, c'est pour la simple raisons que je suis codeur dans mon âme, et tous ce qui est graphisme me sort par l'oreille
Voilà je fais demande d'aide pour les taches suivantes :
Un ou plusieurs graphistes pour des Assets, le décors et les monstres, avec Sprite-Sheet (en mouvement tous les directions).
J'aurai préférer avoir mes propres personnage et créer tout une nouvelle histoire à part le monde Ninja de Naruto mais vus ce que j'ai trouvé sur le net je n'arrive pas à faire autrement, si un bon dessinateur / graphiste est disponible pour la réalisation de nouveau personnage avec la prise en charge complète de tous ses mouvement ça serai un idéal.
J'aurai besoin d'une personne pour la sonorisation, ainsi qu'un scénariste.

je précise que je suis pas entrain de recruter pour des postes rémunérés mais juste des bénévoles qui souhaites contribuer au développement d'un jeu et qui y vives à long terme, sa leur fera découvrir de quoi ils sont capables ainsi ça va laisser une trace et une référence pour leurs travaux que je tacherai à renseigner dans un coin au future site de ce jeu.

j'attend vos commentaire sur le jeu, se que vous proposez, se que vous détestez, ...

Voila, sur ce je vous souhaite une agréable soiré.

[the-morpher]

Bonjour,

j'aimerai donner suite à mon projet,
j'ai finalement résolue l'énigme de la porté d'un sort et l'obstacle qui dois cacher tous l'angle de vu, problème précédaient cité par une autre personne sur la discussions ;
http://www.developpez.net/forums/d14...e/#post8076674

chose faite maintenant je pourrai faire toute sorte de sort à mes personnages

[Invité]

Ha bah ça va au niveau du gameplay tu es déjà plus avancé que moi mdr, moi je n'ai encore rien fait de ce côté là.

Par contre mon moteur est plus avancé au niveau du graphisme, il gère l'éclairage, les ombres, la 3D, les particules, la semi-transparence, etc...
Peut être pourras tu t'en inspiré pour améliorer tes graphismes.

Je suis curieux de savoir comment tu as fais pour le chat, avec les liens clickable, la scrollbar, ainsi que toutes les guis, à vrai dire c'est les seules choses qui me reste à faire pour mon projet.

Je pensais m'inspirer du projet sfgui, je ne sais pas si toi tu utilises une biblitohèque ou si tu fais toutes les textures toi même mais en tout cas gg.

[the-morpher]

Bonsoir Lolilolight,

merci pour ton poste, mais le rendu 3D n'est pas fait pour le genre d'application que je veux faire, vus que mon 1er projet été la création d'une bibliothèque qui gère les éventements sur les objets Sprite/Assets comme MouseClic, MouseOver ...
pour le chatbox c'est tout simplement un RichTextBox qui est un contrôle parmi ceux fournis sur votre Editeur Visuel, MAIS normalement cet objet ne gère pas les liens cliquable comme tu as dis, il faut utiliser une lib nommé RichTextBoxEx, qui hérite du 1er objet, à savoir RichTextBox puis elle ajoute des fonction.
pour les GUI que j'utilise, comme je l'ai dis, j'utilise ceux fournis par défaut comme textBox, MessageBox ... si non, j'utilise une Sprite et je lui associe un événement OnClic.

Bonne soiré

[PixelJuice]

Bonjour,

@Lolilolight :

Ton intervention est très déconcertante. Ça se voyait un peu que c'était du pur Winforms et d'ailleurs quelques remarques a ce sujet:

-Winform et GDI ne sont absolument pas fait pour ça. Tu as ou tu vas avoir des performances pire que catastrophique , et très limité niveau graphisme , etc.
On voit sur ta vidéo les labels tiltés comme des fous car l'UI doit être déjà a bout.

-C'est dommage parce qu'on sent de la passion et ta volonté de bien faire , d'ailleurs le travail que tu as déjà fait est très bien. Mais tu aurais du partir dès le début sur un truc plus viable pour les jeux , du genre XNA / MonoGame.

-En plus passer sur ce genre de framework réglerait tout les inconvénients dont tu parles.

-Pour ce qui est des assets , tout ça , je te recommanderai d'aller directement voir du coté de la communauté Naruto francophone (forum rpg , etc), tu trouvera peut être ton bonheur la bas.

Sinon j'aime beaucoup le concept , je doute qu'il y ai déjà un jeu Naruto de type RPG Tactic donc si tu arrives a aller jusqu'au bout et au vu de l'énorme fan base de Naruto , ça peut être très intéressant. Je te souhaite bon courage .

[the-morpher]

Bonjour et merci pour ton soutien,

mon projet été lancé au départ sur la plateforme XNA, mais j'ai tourné la page dès que j'ai su que Microsoft a lâché le projet,
j'ai aussi testé SDL mais pas de support non plus en vus, il y avais aussi un autre problème, c'est que je ne trouvais pas comment associer a mes Sprite les différent événements obligatoires.
du coup j'ai temporisé, et lancé mon autre projet, un moteur graphic 2D en GDI+ qui prend les événements, + système réseau TCP/UDP + PathFinding.
je sais que mon environnement de dev / technologie choisie n'est pas au top mais j'aimerai expérimenter la puissance de ma lib.

en faite, j'utilise pas les contrôles Label pour les label affichés, mais c'est bien du texte dessiné sur l'écran en GDI+
à part les contrôles TextBox et RichTextBox je me contente d'utiliser des sprite comme GUI mais c'est bien de me citer se qui pourra m'attendre si le projet deviens gourmand

[Invité]

Donc tu fais ton propre système de gui si j'ai bien compris. (Enfin..., ta propre bibliothèque plutôt)

Ca peut être sympa et fun, moi aussi je pense que je vais faire comme ça, après tout, j'ai déjà un système de contexte pour les événements.

@Lolilolight :

Ton intervention est très déconcertante. Ça se voyait un peu que c'était du pur Winforms et d'ailleurs quelques remarques a ce sujet:

Je n'ai jamais utiliser ses choses là pour développé un jeux donc..., je n'aurai pas pu le remarqué.

[I_Pnose]

mon projet été lancé au départ sur la plateforme XNA, mais j'ai tourné la page dès que j'ai su que Microsoft a lâché le projet

C’est bizarre comme raisonnement, XNA ne recevra plus de mise à jour c’est un fait (le matériel de la Xbox 360 étant figé, il ne peut en être autrement), mais je ne vois pas pourquoi cette techno n’en fait pas un choix viable pour autant. C’est un Framework des plus matures, et je ne vois vraiment pas ce qui te manque dans ce dernier, le seul truc qu’on peut lui reprocher c’est qu’il ne s’appuie pas sur la dernière version de DirectX sortie (encore une fois la XBoite 360 ne gérait que DirectX 9), mais si c’est le seul argument que tu as contre XNA, alors je crains que Winforms soit un choix bien pire sur le plan graphique.

Et quitte à laisser tomber XNA, autant migrer sur Monogame ; c’est un Framework qui reprend le flambeau de XNA en proposant des performances revues à la hausse et un câblage sur plusieurs APIs graphiques (ce qui lui permet d’être multiplateforme en prime).

je sais que mon environnement de dev / technologie choisie n'est pas au top mais j'aimerai expérimenter la puissance de ma lib.

Ça va au-delà d’un choix "pas top".
Passons sur le fait que Winforms est câblé sur GDI (le dinosaure des bibliothèques graphiques) et que par conséquent ta carte graphique est totalement inexploitée (un comble pour un jeu vidéo), le moteur même (event-driven) de Winforms n’est pas adapté à du jeu vidéo ; en Winforms l’application attend un évènement de la part de l’utilisateur (un click, un redimensionnement, etc...), même le rendu est déclenché sur évènement (si une zone de l’appli a été modifiée, alors les controls impactés sont invalidés et redessinés), avec XNA (et tout autre Framework de jeu vidéo) on n’a pas de pile d’évènements, on est dans une optique complètement procédural au sein d’une boucle de jeu ou à chaque frame le rendu est réalisé dans un buffer, puis l’intégralité de l’écran est effacé et le buffer basculé à l’écran... tu n’auras jamais ça en Winforms (ce qui va engendrer, outre des performances atroces dues au câblage software, de très vilains scintillements... au mieux).

Bref, en résumé, de toutes les technos que propose le Framework .Net, tu as pris la pire pour ton besoin. C’est dommage.

[maeiky]

Passons sur le fait que Winforms est câblé sur GDI (le dinosaure des bibliothèques graphiques) et que par conséquent ta carte graphique est totalement inexploitée

Les fonction de blit de GDI utilise l’accélération matériel:

Depuis Windows 95 et jusqu'à Windows XP, GDI est en partie accéléré matériellement ; il fait office d'intermédiaire entre l'application et le driver graphique. Sous Windows Vista le support matériel est abandonné et GDI est alors entièrement logiciel. Puis sous Windows 7, les applications s'exécutant sur le nouveau moteur de composition sont à nouveau accélérées matériellement, au plus proche du matériel (voir GDI Hardware Acceleration).

De plus, ce n'est vraiment pas mauvais, dépendamment du types de jeu, quand un prend OpenGL tout le CPU se consume juste en synchronisation. Alors qu'avec GDI, sa laisse respirer le reste, puis ça à une meilleur portabilité.

[I_Pnose]

Les fonction de blit de GDI utilise l’accélération matériel:

Oui tout à fait. Sauf que Winforms utilise GDI+ (j’ai fait une petite erreur dans mon post précédent, my bad) plus haut niveau que GDI et ne bénéficiant pas de cette accélération matériel. La solution est de passer par p/invoke pour faire appel à GDI par exemple. Bref, nativement, ce n’est pas la joie de ce côté-là, j’insiste grandement.

De plus, ce n'est vraiment pas mauvais, dépendamment du types de jeu, quand un prend OpenGL tout le CPU se consume juste en synchronisation. Alors qu'avec GDI, sa laisse respirer le reste,

Je comprends sans doute mal tes propos, mais un framework de jeux un tant soit peu intelligent sait faire du batching et ne sollicite le CPU qu’au minimum (après si on code directement en OpenGL comme un goret, oui, on risque de se retrouver avec des perfs très proche de ce qu’on obtiendrait avec Winforms, voire pire... mais ce n’est pas ce que je proposerais à quelqu’un voulant développer un jeu vidéo de toute manière).

puis ça à une meilleur portabilité.

Je ne comprend pas cette partie ; GDI serait plus portable qu’OpenGL ? J'ai un "léger" doute.

[maeiky]

Je ne comprend pas cette partie ; GDI serait plus portable qu’OpenGL ? J'ai un "léger" doute.

Dans un monde de gamer ou que tout le monde dispose de la dernière carte graphique, peut-être pas, mais je prend en considération que certains on des vieux PC. De plus la carte graphique ne dispose peut-être pas de la version demandé et de toute les extensions utilisés. Juste en regardant la différence entre OpenGL 2 et 3, les frameworks vont probablement se concentrer sur une ou l'autre des versions. Avec GDI, même quelqu'un disposant de win2k va pouvoir l'utiliser.

Je suis d'accord que pour un jeu ce n'est peut-être pas le mieux, mais ce n'est pas mauvais non plus. Dépendamment de ce que l'on veut faire, les opération CPU sont excellentes pour redessiner que les zones à changement et même éviter ceux déjà dessinés. C'est un procédé qui à fait ses preuves, si on regarde par exemple les tout les jeux Flash qui sont principalement géré par CPU. Aussi la SLD 1 était entièrement par CPU et ça n’a pas empêcher de faire des jeux alors que l'on avait des ordi bien moins puissant. Ça peu être pratique, si on se fait un moteur qui n'est pas nécessairement pour des jeux, mais aussi pour des applications. De plus GDI offre la possibilité de dessiné de la semi-transparence par pixel, ce qui peut-être vraiment bien pour un widget ou un superbe splash screen


Sinon tant qu'a conseiller un framework, on pourrait dire d'aller sur Unity comme ça même pas besoin de faire du C++, et puis pas de problème au niveau graphique tout est déjà codé, tant qu'a y être allons tous vers un monde Unity tout le monde sera contant main dans la main parmi des petit lapins roses gambadant dans la joie

[I_Pnose]

Avec GDI, même quelqu'un disposant de win2k va pouvoir l'utiliser.

Soit, c’est un peu un secteur de niche (isolée sur une île déserte... dans le triangle des Bermudes), mais admettons.

Je suis d'accord que pour un jeu ce n'est peut-être pas le mieux, mais ce n'est pas mauvais non plus.

Je maintiens mon point de vue ; c’est une mauvaise solution (et je parle en connaissance de cause, mes propos ne sont pas gratuits).

Dépendamment de ce que l'on veut faire, les opération CPU sont excellentes pour redessiner que les zones à changement et même éviter ceux déjà dessinés. C'est un procédé qui à fait ses preuves, si on regarde par exemple les tout les jeux Flash qui sont principalement géré par CPU. Aussi la SLD 1 était entièrement par CPU et ça n’a pas empêcher de faire des jeux alors que l'on avait des ordi bien moins puissant. Ça peu être pratique, si on se fait un moteur qui n'est pas nécessairement pour des jeux, mais aussi pour des applications. De plus GDI offre la possibilité de dessiné de la semi-transparence par pixel, ce qui peut-être vraiment bien pour un widget ou un superbe splash screen

Je n’ai absolument rien contre le rendu CPU (j’ai pris énormément de plaisir à jouer avec la SDL pendant des années), ni même contre ce pauvre GDI. J’émets uniquement un très gros doute sur Winforms en tant qu’outils pour développer un jeu vidéo, un outil qui n’a ni l’architecture de la SDL, ni l’accélération matériel de GDI (je le rappelle GDI+ est purement software). Winforms demeure un excellent choix pour développer des applications de type formulaire ou application de gestion dont les SI sont très friands. Mais même pour une application orientée graphique, Winforms est souvent délaissée au profit de WPF dans ces même SI (mais là on s’écarte du sujet).
Bref, pour ce qui est de créer un jeu vidéo Winforms n’a pas la souplesse de la SDL ou de flash... on en est très très loin.

Sinon tant qu'a conseiller un framework, on pourrait dire d'aller sur Unity comme ça même pas besoin de faire du C++, et puis pas de problème au niveau graphique tout est déjà codé, tant qu'a y être allons tous vers un monde Unity tout le monde sera contant main dans la main parmi des petit lapins roses gambadant dans la joie

Là on passe d’un Framework de jeu vidéo à un moteur de jeu vidéo. Le ticket d’entrée n’est pas du tou le même ; Unity nécessite un certain temps d’apprentissage (et non, tout n’est pas codé... mais on ne va pas retomber une énième fois dans ce troll fatiguant), alors qu’un Framework comme XNA ou Monogame est relativement facile d’accès.

Et au passage, je ne vois pas pourquoi tu cites C++ dans ton argumentaire étant donné que Winforms, XNA ou Monogame peuvent être attaqué indifféremment en C#, en Vb.net (ou accessoirement en C++/CLI).

[maeiky]

Ah oui, tout à fait d'accord.
J'ai supposé que son moteur était en C++, mais en fait il a pas précisé, c'est en quoi?
Pour les Winforms c'est vrai que le rendu est pas jolie, la rapidité de développement est peut-être le seul point positif.

[I_Pnose]

J'ai supposé que son moteur était en C++, mais en fait il a pas précisé, c'est en quoi?

Ça peut être n'importe lequel des langages managés supportés par la plateforme .Net. Les plus courants étant le C# et Vb.net.

[the-morpher]

Bonsoir,

et merci pour l’intérêt afin d'examiner plusieurs points concernant ce sujet.
mais on s'éloigne un peux comme vous l'avez dis, concernant quel et quel technologie choisir mais pour calmer les esprits une explication s'impose
comme j'ai cité avant, j'ai débuté a codé en XNA, juste après j'ai été frustré par l'idée que le projet a été abandonné alors qu'il commence a donner ses fruits, j'ai un peut suivie la communauté mais plusieurs articles commences a tourner la page, et cela ma poussé a élargir mes recherches et du coup je suis tombé sur une vidéo qui montre qu'on GDI+ on peux faire un jeux tout simple.
j'ai commencé a explorer la dite "le dinosaure des bibliothèques graphiques" et je me suis dis, tien et si j'essai de coder un moteur graphique
cela été un défie pour moi plus qu'un désire surtout que je n'ai jamais eu a le faire avant.
chose faite je me suis dis, tien essayons de voir si elle s'adapte a mon projet RPG.
c'est que quelque temps après que XNA a été repris pour maintenir le projet par des tierces personnes mais voila je vais pas basculer chaque mois entre l'un et l'autre.

il faut savoir que mon jeu et tout simple si vous avez vus les image, et nécessite aucunement l'exploitation extrême d'une carte graphique donc pas la pains de dramatisé
mise a part l'affichage des Sprite et leurs déplacements, je n'ai pas l'intention d’intégrer un système de particules ou des animations époustouflantes, autant aller jouer sur wow ou autre
et puis ce n'est pas un choix, c'est une expérience que très très peut ont tentés, et comme maeiky a dis

maeiky
Avec GDI, même quelqu'un disposant de win2k va pouvoir l'utiliser.

donc ça cible aussi un matériel pas top top

I_Pnose, rendu est réalisé dans un buffer

le GDI+ gère aussi le Double Buffering

maeiki
Dans un monde de gamer ou que tout le monde dispose de la dernière carte graphique, peut-être pas, mais je prend en considération que certains on des vieux PC

voila

le jeux tourne sur une technologie .NET, donc il n y'à pas 36 langages
je pourrai aussi migrer vers une autre technologie mais franchement j'aimerai bien tenter cela

[MoDDiB]

Tu vas t'amuser pour les perfs mais pourquoi pas : ça s'est déjà vu à priori :
http://www.mobygames.com/images/shot...screenshot.png ( pour ceux qui se souviennent de ce jeu )

[I_Pnose]

Je me souviens ^^
Seulement ces jeux n’ont pas été développés en Winforms (le Framework .net n’existait même pas à l’époque), mais en C++. Le rendu graphique était réalisé via WinG sous Windows (et AppKit sous Mac) si je ne dis pas de bêtises. Bref là tu parles d’un temps que les moins de vingt ans ne peuvent pas connaitre =P

Quand bien même, partir sur du Winforms ne signifie pas pour autant qu’on soit obligé de se farcir du GDI+ à toutes les sauces. Winforms est même tout ce qu'il y a de plus viable pour servir de conteneur (pour créer des éditeurs de niveaux notamment, c’est bien pratique, on n’a pas besoin de se farcir le développement de tous les contrôles).

Exemple avec le moteur NeoAxis dans une fenêtre Winforms :


@the-morpher > mille excuses pour avoir fait dévier ton sujet vers ce débat, j’étais simplement surpris que tu aies laissé tomber XNA au profit de WinForms (je ne suis d’ailleurs toujours pas convaincu par tes arguments, mais après tout c’est ton projet, tes choix).
Bonne continuation ^^