Bonjour à tous!

Je post ici pour présenter mon projet du moment qui, vous devez sans doute vous le douter est un Zelda amateur. Même si ce n'est sans doute pas ce qui vous intéresse le plus, une petite présentation de ma personne s'impose  

DarkNath

Je me présente, je m'appel Nathan, j'ai 18 ans (bientôt 19) et je suis des études d'info (développement). Je suis passionné de la série The Zelda Of Zelda depuis mon plus jeune âge, mon premier jeu a été ALTTP sur Super NES. J'ai ensuite joué à OOT puis, un peu plus tard MM, Wind Waker, plus récemment Skyward Sword. J'ai aussi une passion pour le développement de jeux vidéo ainsi que pour la programmation en général, l'open-source et les systèmes UNIX.
Je me suis donc dit, pourquoi ne pas mélanger tout ça? Et de cette intense réflexion m'est venu l'idée de réaliser un zelda amateur open source:rolleyes: .

Mon expérience

J'ai environ 6 ans de développement pur derrière moi. J'ai fait énormément de programmation système sur UNIX en C. Il y a de cela 2 ans, j'ai commencé le "game-dev" avec Python. J'ai réalisé de nombreux petits jeux et un plus conséquent, toujours en développement: il s'agit d'un jeu de voiture en 2D jouable en ligne. J'ai également de bonnes notions d'OO.

Le projet

Actuellement, je ne suis pas en mesure de vous présenter un scénario pour la simple et bonne raison qu'il n'y en a pas. Je n'ai pas non plus de gameplay spécifique en tête. En réalité, pour le moment, j'ai dans l'optique de réaliser une sorte de "Zelda Engine" en Java. La plupart de mes anciens projets n'étaient pas très bien structuré d'un point de vue code et il est clair que je veux quelque chose de plus "propre" pour ce projet, j'ai donc décidé, dans un premier temps, de réaliser un engine sur lequel sera basé ce jeu (mes futurs jeux?).
Pour l'engine j'ai reprit le concept d'entité et de composants. C'est une approche assez puissance qui permet de correctement séparer la logique de jeu et la partie "rendering". La création de composants que l'ont vient attacher sur les entités pour en faire des entités avec un comportement bien spécifique permet une flexibilité assez énorme et me permet la réutilisation du code et évite ainsi des redondances dans l'écriture du jeu. Par exemple, l'entité représentant Link (le joueur) devra pouvoir se déplacer, je vais donc créer un composant chargé de gérer le déplacement de l'entité. Mais, les monstres, les NPC etc. devront également se déplacer, il sera donc possible de réutiliser ce même composant pour chacune de ces entités. L'engine permet également le chargement de carte réalisée avec Tiled ainsi que d'autres fonctionnalités pouvant s'avérer utile pour un A-RPG (ou du moins tout jeu utilisant un système de tiles pour les cartes).
A l'heure ou j'écris ces lignes, l'engine est déjà bien avancé et permet même de voir Link se promener dans une carte (encore un peu statique) avec une gestion des collisions presque propre.

• http://www.imagup.com/data/1159735733.html
• http://www.imagup.com/data/1159735871.html
• http://www.imagup.com/data/1159735899.html
• http://www.imagup.com/data/1159735920.html

Le projet est entièrement réalisé en Java avec la bibliothèque Slick2D. Le projet est communautaire est open-source, j'encourage tous ceux qui en ont envie à participer, proposer des idées de concept, de scénario ou autres ou même de contribuer au développement:

https://github.com/DarkNath/Zelda-making

Si vous êtes intéresser par l'évolution du projet, vous pouvez suivre l'actualité du blog que j'ai créé pour l'occasion, une vidéo montrant la réalisation d'une carte et le chargement de celle-ci dans l'engine y est illustré :

http://zelda-making.blogspot.fr/

Merci de m'avoir lu et à bientôt. Si vous avez des questions n'hésitez surtout pas  

[Spyz .200]

 le Graphisme semble très standard e je pense que cela manque d'originalité ... actuellement si tu veux que tes lecteurs t'encourage sur ton projet , tu dois rendre ton projet beaucoup plus original ...

s'il te plais , la prochaine fois que tu poste un Screen , évites  de nous montrer ton Bureau
essais d'encadrer uniquement la fenêtre du jeux

par contre si tu veux un coup de mains sur l'ALGO  , tu peux me contacter en MP , je m'y connais un peu sur Java Script   

Bonne continuation 

[Helmasaur]

Vous avez le don pour décourager ceux qui tentent quelque chose…

le Graphisme semble très standard e je pense que cela manque d'originalité ... actuellement si tu veux que tes lecteurs t'encourage sur ton projet , tu dois rendre ton projet beaucoup plus original ...

s'il te plais , la prochaine fois que tu poste un Screen , évites  de nous montrer ton Bureau
essais d'encadrer uniquement la fenêtre du jeux

par contre si tu veux un coup de mains sur l'ALGO  , tu peux me contacter en MP , je m'y connais un peu sur Java Script    

Bonne continuation  

Bonjour,

je ne pense pas que tu es correctement lu mon post, sans vouloir sembler agressif  . Mais... en quoi la réalisation d'un zelda engine devrait être originale? L'originalité du jeu viendra avec la scénario et le gameplay qui, comme écrit dans mon premier post, ne sont pas encore posé. Je préfère avoir un système de jeu fonctionnel plutôt qu'un "gameplay de la mort qui tue" et un scénario béton pour commencer.

Les graphismes trop standard? Oui sans aucun doute, sont ceux de ALLTP... encore une fois, les graphismes ne sont pas une priorité à l'heure où j'en suis, j'ai pas mal d'expérience dans le domaine du game-making et je sais qu'il ne faut pas commencer à parler graphisme avant d'avoir un système de jeu fonctionnel (surtout quand on est seul). Pour preuve, j'ai toujours commencé à développer avec des carrés de couleur en guise de sprites.

Enfin, ce qui me fait le plus penser que tu as lu mon post à 300 à l'heure (plus?) c'est :

par contre si tu veux un coup de mains sur l'ALGO  , tu peux me contacter en MP , je m'y connais un peu sur Java Script    

Je ne suis pas sûr de comprendre... je ne parle pas de JS dans mon post mais de Java... il est vrai que l'algorithmique est indépendante de tout langage alors... bref, éclair moi sur ce point  

J'espère avoir était plus clair sur l'orientation de mon travail : )

Merci.

EDIT:

Vous avez le don pour décourager ceux qui tentent quelque chose…

Ne t'en fais pas, ça ne me décourage pas dans la mesure où je pense que c'est plus de l’incompréhension (peut être un manque de clarté de ma part) et sans doute quelques lacunes d'un point de vue organisation de travail dans le domaine du game-dev. C'est vrai que de me parler graphisme alors que je suis au stade de la réalisation d'un engine c'est un peu gros  

Par contre bonne remarque concernant les screens, je vais essayer d'y faire attention.

[BenObiWan]

Intéressant, ceux qui me connaissent bien diront que j'ai un a priori positif parce que c'est écrit en Java (et non javascript  ) mais en fait c'est toujours sympa de voir quelqu'un essayer de faire un moteur dans un langage évolué sans utiliser un logiciel tout fait genre GameMaker & co, c'est même plutôt 'original'.
Évidemment ce genre de projet est bien plus ambitieux, et on en a vu un paquet qui s'arrêtaient en route, je te souhaite d'avoir la moitivation de le mener à bout
Si je trouve le temps je jetterai peut être un œil au code un de ces jours

EDIT:

Par contre bonne remarque concernant les screens, je vais essayer d'y faire attention.

Bof c'est marrant de voir que tu utilises NetBeans & Chrome avec gnome et sous debian. bon c'est vrai qu'on s'en fout un peu, mais tant pis

Évidemment ce genre de projet est bien plus ambitieux, et on en a vu un paquet qui s'arrêtaient en route, je te souhaite d'avoir la moitivation de le mener à bout

Merci. J'espère pouvoir le mener à terme (y a t'il vraiment une fin?) mais de toutes manières, les sources et le git resteront online et du moment qu'une personne assez courageuse pour continuer sera en vie, le projet le sera aussi. D'où l'intérêt et la grande passion que j'ai pour l'open-source.

Si je trouve le temps je jetterai peut être un œil au code un de ces jours

Avec grand plaisir, j'essaye de maintenir le code aussi clair et documenté que possible.

Bof c'est marrant de voir que tu utilises NetBeans & Chrome avec gnome et sous debian. bon c'est vrai qu'on s'en fout un peu, mais tant pis  

En effet  

[Spyz .200]

En faite il faut toujours un critique pour chauffer une discutions
tu as sans doute remarqué que personne n'a rependu a ton projet avant mon poste

bref tu as raison sur un point Java n'a rien avoir avec Java Script du HTML ...mais Bon
je veux dire si tu as un problème sur L'algorithme tiens moi au courant        

[BenObiWan]

Merci. J'espère pouvoir le mener à terme (y a t'il vraiment une fin?) mais de toutes manières, les sources et le git resteront online et du moment qu'une personne assez courageuse pour continuer sera en vie, le projet le sera aussi. D'où l'intérêt et la grande passion que j'ai pour l'open-source.

Non il n'y a jamais de fin !!!
Même ZS continue à évoluer, certes moins qu'avant mais Chris retouche bien au moteur
Quand je veux dire le mener à bout c'est arriver à une '1.0' qui est jouable intéressant et contient à peu près tout ce que tu veux mettre dans un premier temps dans le projet.
Évidemment l'open source c'est le bien, mais pour que quelqu'un ait envie de reprendre ton projet il faut quand même qu'il soit bien avancé

En faite il faut toujours un critique pour chauffer une discutions
tu as sans doute remarqué que personne n'a rependu a ton projet avant mon poste  

Même si il faut raconter n'importe quoi? Si les gens viennent voir mon projet pour suivre un "clash" ça ne m'intéresse pas   Les critiques, j'en raffole pour peu qu'elles soit constructives.

bref tu as raison sur un point Java n'a rien avoir avec Java Script du HTML ...mais Bon
je veux dire si tu as un problème sur L'algorithme tiens moi au courant      

Le JavaScript du HTML? Le javascript quoi, ce sont deux choses différentes même si intégrer du JS dans du code HTML est possible.

Quand je veux dire le mener à bout c'est arriver à une '1.0' qui est jouable intéressant et contient à peu près tout ce que tu veux mettre dans un premier temps dans le projet.

C'est effectivement mon objectif.

Bon, pour vous tenir au courant. Comme l'indique les commits du git, j'ai intégré (du moins en partie) deux choses assez importantes:

• Le ressource manager : en gros c'est une sorte de centralisation des ressources utilisées par le jeu. Les images, animations, scripts etc. Les ressources sont organisées dans un fichier XML. L'intérêt de cette approche est que je suis sur que les ressources sont chargées une fois au démarrage du jeu et que je peux y accéder simplement dans le code par l'id de la ressource
• Support des scripts Groovy. Groovy est un langage de script assez simple à intégrer avec java. Je m'en sert actuellement pour décrire mes entités. Ca me permet de consacrer la partie java à la logique de jeu et à l'engine et tout ce qui est de l'ordre du contenu, description d'entités, de scènes etc. sera déporté dans des fichiers XML ou des scripts Groovy.

Un article sera posté sur le blog avec plus d'informations pour ceux que ça intéresse. Il y aura aussi une vidéo qui présente le système de "téléporter". J'entend par là, les portes etc. Et ça dans la journée c'est pas beau?

Merci.

[Spyz .200]

Ok c'est compris , j'arrête mes conneries

C'est vrais , j'avoue avant j'avais lu tes introduction pendant 300 Msecond mes cette fois ci ce n'est plus le cas

quand tu parle de composant, tu veux sûrement dire Fonction  ou plus précisément des sous programmes
quelque chose que l'on peut appeler chaque fois qu'on a besoin ...

ne t'en fais pas , moi aussi j'étudie l'informatique et programmation à la Faq
voici mes conseil , tu feras mieux d'utiliser deux fonctions différent pour le déplacement de Link et pour le déplacement du monstre ...

je t'explique :
   dans le cas de Link , le sprite se déplace en fonction d'un touche , par contre le monstre se déplace en fonction du temps ou d'un points de repère

peut être que maintenant , tu n'as pas de problème a utiliser la même fonction mais top ou tard quand le nombre de ligne de commande commence à atteindre les milliers , tu vas sûrement avoir un problème de confusion ...

j'espère que mes conseil te seront d'une grande utilité ... 

Ok c'est compris , j'arrête mes conneries

C'est vrais , j'avoue avant j'avais lu tes introduction pendant 300 Msecond mes cette fois ci ce n'est plus le cas

quand tu parle de composant, tu veux sûrement dire Fonction  ou plus précisément des sous programmes
quelque chose que l'on peut appeler chaque fois qu'on a besoin ...

ne t'en fais pas , moi aussi j'étudie l'informatique et programmation à la Faq
voici mes conseil , tu feras mieux d'utiliser deux fonctions différent pour le déplacement de Link et pour le déplacement du monstre ...

je t'explique :
   dans le cas de Link , le sprite se déplace en fonction d'un touche , par contre le monstre se déplace en fonction du temps ou d'un points de repère

peut être que maintenant , tu n'as pas de problème a utiliser la même fonction mais top ou tard quand le nombre de ligne de commande commence à atteindre les milliers , tu vas sûrement avoir un problème de confusion ...

j'espère que mes conseil te seront d'une grande utilité ...  

Merci. En fait, voilà comment je résonne pour l'engine. Link est une entité, le monstre en est une également. Les deux unités doivent se déplacer: un mouvement est un mouvement, il n'y a aucune raison de créer un composant différent pour le déplacement du monstre et pour celui de link, seules les propriétés de ce composant vont changer, la vitesse par exemple. Ensuite, pour le monstre, le composant en charge du mouvement sera sans doute appelé par le module d'IA associé alors que pour Link, il est appelé par un autre composant associé à link qui est chargé de la gestion des touches.

Je t'invite à te renseigner sur le fonctionnement d'un engine basé sur l'association entity-component, y a pas mal de bonnes ressources à ce sujet sur le net.

Merci.

EDIT: pas le temps ni l'envie d’écrire l'article sur le blog mais sachez que le changement de map fonctionne et que j'avance pas mal dans ma gestion de scènes (des maps avec des évènements en gros) commence à prendre forme.

EDIT: L'article est en ligne. Screenshot et vidéo. Je suis en train de réfléchir à la prochaine étape: HUD ou text engine.

Je post ici pour présenter mon projet du moment qui, vous devez sans doute vous le douter est un Zelda amateur.

C'est quoi cette publicité mensongère? Y'a marqué "Zelda amateur" et on a même pas droit à un pet de scenar ou de gameplay, et pour ne rien arranger les screenshots sont tout droit sorti du placard... C'est pas sérieux tout ça !!!!
...

Blague à part, concernant le ressource manager, charger toutes les ressources d'un coup... je ne trouves pas ça terrible, même sans parler d'optimisation. Quand ton XML fera un dix milles lignes, ça risque être cosmique. 

Bonsoir.

Je l'ai déjà dit et redit, avant de m attaquer au scénario ou au gameplay, je préfère me consacrer à la realisation de l'engine. Non je n utilise pas de logiciel de game making donc oui il faut coder un engine, c'est dur la vie hein?

Je ne comprends pas ce que vous avez tous avec le scenario... Il en faut un bien entendu, y penser avant l'engine... Je ne crois pas.

Des screens sortis du placard, ça veut dire quoi?

Le resource manager, je préfère avoir un temps de chargement au début du jeu et un jeu fluide par la suite. C'est une technique connue, je n'invente rien.

Une publicité mensongère... Si tu veux. Moi j y vois un projet sérieux qui parle code avant de parler fantaisie... Bref, un projet un minimum réaliste.

[Wouf]

En fait, je me demande si ce projet n'aurait pas plus sa place dans la section programmation pendant la première phase (création du moteur). Ainsi, tu ne récolterais plus que les commentaires des gens intéressés prog
Après réflexion, il me semble que cette section-ci est d'avantage réservée à l'aspect "artistique" (graphismes, scénario, musiques, ...), le mapping et la logique du jeu. C'est un peu dommage d'exclure un pan du game dev, mais bon ...

Ah et aussi, par "moteur", j'ai envie de dire que tout dépend du niveau d'abstraction. Tant qu'il reste basique/générique, ça ne pose pas de soucis de commencer par là. Mais dès que l'on s'approche des spécificités du jeu, il devient intéressant de tirer les grandes lignes du projet avant, ne serait-ce qu'au niveau du game-play
Si on prend le processus dans son ensemble, entamer le moteur en premier me semble cohérent.

@Shield > Patience!

[Spyz .200]

je pense que le problème viens de l'ignorance de la signification du mot projet
qu'il soit du type programmation  ou du type Artistique; tant qu'on prépare quelque chose et on prévois un produit fini cela reste un projet
         En tous cas je suis de même avis que l’auteur  ( moi aussi j'utilise toujours cette méthode  )
DarkNath  ===>
 pour la prochaine étape du projet ( ils existe plusieurs choix  ) mais je te conseil de t'attaquer sur les interactions c'est à dire l'interférence entre deux objets actif; c'est le plus dur 

allez courage 

Bonjour,

En fait, je me demande si ce projet n'aurait pas plus sa place dans la section programmation pendant la première phase (création du moteur). Ainsi, tu ne récolterais plus que les commentaires des gens intéressés prog
Après réflexion, il me semble que cette section-ci est d'avantage réservée à l'aspect "artistique" (graphismes, scénario, musiques, ...) [...]

Si ce projet n'a pas sa place ici, je m'en excuse et qu'il soit déplacé.
Il est vrai qu'il y a beaucoup de projets réalisés via logiciel de game-making ce qui conduit sans doute à des résultats plus intéressants plus rapidement. Je conviens que pour ceux qui sont habitué à commenter des maps (leur design etc...) sont peut-être choqué en voyant des screenshots avec juste link marchant dans une pauvre map dépourvue d'intérêt. Mais il faut me laisser le temps, actuellement le moteur c'est 7000 lignes de code, je ne suis pas super-man  

Ah et aussi, par "moteur", j'ai envie de dire que tout dépend du niveau d'abstraction. Tant qu'il reste basique/générique, ça ne pose pas de soucis de commencer par là. Mais dès que l'on s'approche des spécificités du jeu, il devient intéressant de tirer les grandes lignes du projet avant, ne serait-ce qu'au niveau du game-play
Si on prend le processus dans son ensemble, entamer le moteur en premier me semble cohérent.

Exactly sir. Le moteur est générique. Pour être honnête il est bientôt terminé et je posterai sans doute une démo technique dans les jours qui viennent (peut-être dans une semaine) de ce qu'il est capable de faire.

DarkNath  ===>
 pour la prochaine étape du projet ( ils existe plusieurs choix  ) mais je te conseil de t'attaquer sur les interactions c'est à dire l'interférence entre deux objets actif; c'est le plus dur  

allez courage  

C'est exactement sur quoi je travail et c'est déjà bientôt terminé

Merci de vos encouragements.