[AVIS ?] Projet en cours : Un Zelda complet !

Bonjour à tous !

Hop, petite précision, je ne cherche pas à refaire un Zelda mais à en simuler les mecaniques, je ne suis pas de ceux qui pensent refaire HL2 une fois OpenGL maitrisé ^^

Cela dit, le boulot avance pas mal, et j'aimerai maintenant avoir votre avis sur la chose.

Bibliotheque utilisée : SDL

A l'attention des fous d'algorythmique, je ne fais du C que depuis deux mois, et je n'ai meme pas encore appris comment gérer le son et le texte via la SDL, mais j'ai voulu tester ce que je venais d'apprendre en suivant des cours , et c'en est devenu un passe-temps à force.

http://www.enseirb.fr/~ribon/SDL_Zelda.jpg

Cela se télécharge ici :

http://www.enseirb.fr/~ribon/

Sources incluses, DLL et exécutable windows fourni. Code entièrement portable normallement.

______________________

Bref, pour vous résumer l'idée, je viens de terminer la gestion des mouvements du personnage, incluant par là les collisions avec le décor (mouvement et frappe) et le blocage de l'écran une fois arrivé en bordure (très chiant ça).

Le niveau est éditable en ouvrant "decor.txt".

La prochaine étape du projet est une gestion de changement de niveau en passant par des ouvertures en bordure de décor, comme dans le vrai Zelda quoi. Ca devrait être prêt demain.

______________________

NOTE : la gestion des erreurs (dossier image manquant par exemple) n'est pas encore totalement implémentée, aucune raison que cela plante, mais je le dis pour les férus, cela viendra toutefois ^^

NOTE2 : certaines fonctions doivent encore être dénuées de commentaires je crois. Elles sont généralement très explicites dans leur fonctionnement mais de totues facons je suis en train de tout commenter, passé le cap des 1000 lignes de code, je commence moi-meme à m'y perdre parfois :)

:salut:

Oh, un enseirbien... :aie:



En tout cas, c'est bien ce voir que tout le monde cherche pas à refaire Wow en mieux... :mrgreen: J'ai un peu regardé le code, tu devrais essayer de créer un module pour gèrer les sprites (genre avec des fonctions du style : spriteChargementJoueur(void))...) car tu mets un peu tout dans le main.

De gérer les touches comme ça (d'après mes souvenirs) ne permet pas de gérer l'appuie simultané sur plusieurs touches. :aie:

Pour ton niveau, tu devrais créer un type énumeré pour ce que représente tes cases (parce que pour l'instant, c'est simplement des caractères) et ça sera plus compréhensible.


Ta fonction Bloc* bloc_recherche, je suis étonné qu'elle fasse des modifications sur ton ss... Je ne vois pas trop ce que ça fait, ta fonction m'a l'air vraiment suspecte...

Dans void test_collision_decor(SS *ss), tu devrais découper en plus de sous fonction, en testant par exemple la collision avec un personnage (car on peut imaginer que tu pourras porter le jeu pour que l'on puisse jouer avec plusieurs personnes en même tps).

Il y a des parties, c'est assez dur de comprendre, par exemple la ligne :

Code:

---

if (ss->perso.masque.y == 2*(PERSO_HAUTEUR + 1) + 1 + 4*(PERSO_HAUTEUR + 1))

---

Au passage, tu as des variables "globales", mais qui sont en fait vraiment lié au joueur. Pourquoi ne pas les intégrer dans une structure adéquate.

Tu devrais plus fragmenter ton code en séparant bien les fonctionnalités de chaque partie.


Essaye au maximum de séparer Graphisme et visualisation du Moteur de jeu.


Et pour le texte, tu seras obligé d'utiliser la bibliothèque externe SDL_ttf.


Enfin, continue comme ça :mrgreen:


EDIT : Tu peux jeter un oeil ici http://www.developpez.net/forums/sho...d.php?t=230049, ce n'est pas une référence de codage, mais ça pourra peut être t'aider.

Tu peux jeter un oeil aussi sur un petit jeu que j'avais fait : http://humbert-florent.developpez.co.../jeux/boulder/, il n'est pas compliqué en soi, mais je trouve que c'est un bon exemple de programmation. Modulaire, séparation graphique/moteur de jeu (on peut facilement changer de moteur graphique), programmation Objet en C.

Merci d'avoir pris le temps de regarder, cela fait vraiment plaisir, si rare ^^

Je dois bien t'avouer que je code ça vraiment pour me distraire, je n'ai aucune "ligne de conduite" en tête et je ne sais pas vraiment dans quelle direction je vais, alors j'adapate mon code à chaque fois que je souhaite implémenter une nouvelle possibilité à la chose, c'est pourquoi il n'est pas vraiment optimisé à 100% :)

- Pour l'appui des touches en simultané, justement, ça permet de le faire, j'utilisais une autre méthode au début, mais celle ci me permet de faire aller le personnage en diagonale et de le faire frapper si on déclenche cet évenement même s'il est déjà en train de marcher.

- Pour le niveau, je vais de toutes facons finir par être limité par les caractères du clavier, donc je passerai à une autre solution, peut-être sous forme d'image avec un code de couleurs...

- La fonction bloc_recherche relève énormément du bidouillage, c'est vrai, je ne l'ai implémentée que parce que mon système de gestion des collisions en a pris pour son grade lorsque je suis passé d'un système de personnage qui se déplaçait sur un décor au système actuel où c'est le décor qui se déplace sous le personnage. Elle ne fais que renvoyer l'adresse du bloc qui a pour coordonnées de blit (SDL_Rect pos) des valeurs proches des X et Y qu'on envoie à la fonction.

Cela me permet donc de manipuler des blocs non pas en connaissant leurs identifiants I et J, mais en fonction des coordonnées X et Y...

- Le test_collision_decor() est calibré pour tester les collisions avec le décor seulement pour l'instant, je n'avais pas encore pensé à implenter des ennemis, en fait je pensais m'arreter assez vite, mais on se prend au jeu et au final on continue, donc c'est exact, il faudra y rajouter un module de plus pour les ennemis, mais ca ne devrait pas être trop dur ce coup-ci.

- Les parties comme :

Citation:

---

if (ss->perso.masque.y == 2*(PERSO_HAUTEUR + 1) + 1 + 4*(PERSO_HAUTEUR + 1))

---

ne sont pas assez commentées, je te l'accorde facilement, c'est pour ça aussi que je commence maintenant par tout commenter avant de passer à la suite ^^

- Pour le coup des variables globales, j'avoue ne pas tellement voir, vu que je ne les ai jamais aimées, logiquement toute variable fait partie d'une structure....tu parles de quoi ? :3



Et effectivement, ton Boulder Dash est très intéressant, je vais essayer de me prendre à deux mains pour remettre mon code en bonne forme...


EDIT : Et puis à l'Ensierb je fais de l'électronique, l'info passe un peu à coté, faut pas nous en vouloir ^^

Bon, j'aurais pas un avis autant technique que millie, car j'y connais rien en C. Mais je trouve très bien de voir qu'il y a encore des gens qui font des petits projets atteignables avec leur moyen et qui ne veulent pas aller trop vite et refaire des gros jeux tout seul en croyant que c'est tout simple.

En tout cas, un grand bravo, c'est simple mais efficace et c'est déja un très bon début ;)

Bonne chance pour la suite.

Citation:

---

Envoyé par Obligen

- Pour le coup des variables globales, j'avoue ne pas tellement voir, vu que je ne les ai jamais aimées, logiquement toute variable fait partie d'une structure....tu parles de quoi ? :3

---

Je parlais du fichier constantes.


En fait, je pensais à créer un "objet" Joueur avec des fonctions dessus du genre :

Code:

---

1 2 3

int joueurLireLargeur(Joueur*); int joueurLireHauteur(Joueur*);

---

Joueur sera "simplement" une structure contenant la hauteur et la largeur (et d'autres choses).

Code:

---

1 2 3 4 5 6

typedef struct { int largeur; int hauteur; int posx;... } Joueur;

---

Ou si ces constantes sont intraséquement lié à du graphisme, alors tu peux les mettre dans une autre structure qui irait bien pour ça.



EDIT : Dans le boulder dash, je vois maintenant qu'il y a des parties un peu foireuses et assez dangereuses que j'aurais fait autrement si j'avais à le refaire. Genre la liste, maintenant j'aurais plutôt fait un Ensemble avec des itérateurs dessus, mais comme j'aurais eu la flemme des les implémenter jl'aurais fait en C++ :aie: .

EDIT 2 : J'ai vu que tu avais une structure SS (comme super structure), tu devrais lui donner un nom plus spécifique.

Tu devrais éviter les (mettre une instruction sur la même ligne d'un for) :

Code:

---

1 2	for (i=0; i < 300; i++) ss.clavier[i] = 0; ss.compteur = 0;

---

arf la classe ... je m'etait mi au C++ le mieux que je fesait c'etait déplacer un pixel sur une fenetre noire ^^ G pa encore regarder le code source mais je sens que je vai m'en inspirer je cherche a faire un truc dans le même genre (un bonhomme quis e deplace sur un terrain) en delphi avec asphyre. Enfin bref bien joué et bon courage pour la suite.

Bravo pour ton initiative !
Je suis un un grand fan de Link et si tu as besoin d'un coup de main je veux bien t'aider avec mes humbles connaissances... :D


ps:
Bug Report : Quand on fait gauche+haut+espace ou droite+bas+esp, link ne frappe pas tandis qu'avec les deux autres diagonales, oui.

Bug non reproductible, je ne le constate pas chez moi, les quatre diagonales fonctionnent avec la frappe, quelle que soit la direction dont a été issue la diagonale :/

D'ailleurs, le code est homogène, il reproduit le même schéma quelle que soient les directions, si cela marche dans un sens, il n'y a pas de raisons que ca ne marche pas dans les autres sens. Si toutefois quelqu'un arrive à reproduire ce bug, qu'il me le fasse savoir.

Solution après réflexion : en fait je suis persuadé que cela vient de ton clavier, la façon dont ont étaient codées les touches, numériquement parlant, empêche l'appui simultané des 3 touches dont tu parles. Mon G15 me fait la même chose dans le sens où je ne peux pas, dans un jeu quelconque, m'accroupir (avec CTRL) en allant en diagonale arrière, alors que cela marche en diagonale avant (au prix qu'il coute, c'est une honte).

Les claviers n'étant pas tous codés de facon similaire, certains auront ce bug, d'autres pas.

Tu peux d'ailleurs tester facilement la chose : remplis un fichier texte de lettres et déplace le curseur clignotant avec les flèches dans ce fichier. Puis essaie, pendant le déplacement, d'appuyer sur espace, je suis sur que tu rencontreras le même problème que dans mon programme ^^

Plus d'infos sur la facon dont un clavier gère les touches matriciellement :

http://www.mail-archive.com/cybertec.../msg22714.html

____________________________

Tu as raison pour les constantes Millie, mais je fais ça au fur et à mesure de l'expansion du projet. Au début, j'avais un fichier rempli de constantes, nombres de lignes, de colonnes, etc etc....et je le vide au fur et à mesure que mes nouvelles fonctionnalités imposent des variables dynamiques et non constantes :)

Pour le nom de la super-structure, c'est plus par esprit de lisibilité qu'autre chose. Elle n'est pas explicite mais elle est unique et représente la "racine" de toutes les variables utilisées. Vu qu'elle revient dans le nom de chaque variable à manipuler, au niveau du décor, de l'écran, du perso ou quoi que ce soit, utiliser un nom plus grand aurait de lourdes conséquences sur la longueur de chaque ligne de code :/

_____________________________

Sinon, merci pour vos encouragements, j'apprécie beaucoup ^^
A la prochaine mise à jour !


Note : pas possible d'avoir un avatar lorsque l'on vient d'arriver sur le forum ? C'est terne :3