UrWorld, le retour du retour

[..] Il n'y a qu'une seule limite à votre créativité : la hauteur de la map (je pense intégrer un scrolling vertical pour pallier à ce problème bien embêtant). Avancement

T'as zappé un retour à la ligne.

Screenschoots

Je viens de me dire que tes blocs sont trop carrés. Si 'était possible d'arrondir un peu les angles et de les irrégulariser un peu je penses que ça rendrait mieux.

De rien, par contre j'ai une majuscule à mon pseudo (et arrête avec tes "merchi" ) !

Bon ben j'attendrais …

<HS> J'aime cet avatar !</HS>

C'est pas "Screenschoots" mais "Screenshots"

Sinon je vois des blocs d'eau (si je me trompe pas) sur les screens, t'as un système de fluides dans ton jeu?

Coucou ! C'en est où la refonte du code ? Parce que si ça a déjà commencé, je veux bien voir ce que ça donne. Sinon, peut-être que je vais ébaucher quelque chose.

EDIT : Tant qu'on y est, c'est le moment d'appliquer la PEP-08 (conventions d'écriture) et la PEP-257 (commentaires).

Bon courage Folaefolc

Les premières classes à développer qui me viendrait à l'idée sont Jeu, Joueur, Carte, Inventaire, BarreDeVie (et BarreDeMana puisqu'il y en aura). Les niveaux sont gérés comment ? Un peu commme dans Minecraft ?

J'ai envoyé une Architecture à AlphaZeta, voyez ce que vous pouvez en tirer Pourquoi une classe pour Life et Mana ? Ce sont que des valeurs non ?

Si jamais il y a un systeme de niveau, sans doute que la vita max pourrait augmenter, puis il y a la vita actuelle. Ca fait deja 2 valeurs

Mouais Eventuellement rien que pour un life.draw() pour dessiner la barre de vie. Mais un perso.life, perso.lifeMax et perso.drawLife() ne me choque pas

J'aurai simplement mis tout ce qui concerne l'apparence du joueur dans une classe PlayerView qui a une méthode draw qui s'occupe de dessiner le joueur sur une pygame.Surface.

car elle gère leur affichage seule, et indépendamment du joueur

Pourquoi elle devrait être ainsi ? Éventuellement une view qui permet d'afficher le HUD, avec vie, mana, minimap, vie du boss, etc… Ça me paraît être la meilleure manière de procéder.

ca doit etre asynchrone

Encore une fois, pourquoi ?

et pis aussi car y a une fonction de régénération de la mana. et dans mana t'as auchi les sorts qui sont gérés

Alors pourquoi pas faire une classe Spell de qui découlera tous tes sorts ? Tes sorts auront une méthode cast qui prendra en paramètre le lanceur (le joueur ou quelconque autre entité maîtrisant la magie).

J'update l'UML pour t'expliquer

Moi je suis d'accord avec le fait de créer une classe vie et une classe mana indépendamment du joueur. On peut toujours faire une view du joueur qui utilise ces classes. Comme ça, si on veut radicalement changer la gestion de la mana et/ou des pv, il y aura juste à refaire les classe Vie et Mana, mais le reste n'aura pas besoin d'être modifié.

Par contre, ce n'est à mon avis pas à la classe de gérer les sorts, surtout pas ! Créer une class Spell avec une méthode "cast" me parait plus adapté.

Par contre, ton idée de la View n'est pas terrible sémantiquement. Ce serait une classe qui mélange pas mal de choses différentes, ça fait un peu fourre-tout. Je pense plutôt que la classe Jeu devra contenir un objet MiniCarte, un objet Joueur, Boss s'il y en a un etc…
C'est MiniCarte et cie qui devra se charger de générer son rendu et on pourra l'afficher avec une méthode afficher().

Salut,

Je poste le lien de l'UML en question ici, je suis nul en UML mais c'est histoire de faire un truc schématisé. Les sorts n'ont pas encore de méthodes, mais les classes filles permettent déjà de vérifier de quel type de sort il s'agit si jamais l'on veut customiser je-ne-sais-quoi (mon but ici est d'adapter l'architecture la plus retouchable) avec isinstance.

Quant à l'inventaire, il et représenté en mémoire comme une liste (il hérite de list). Il est sensé contenir des items (de la classe Item) que je n'ai pas encore représenté, j'ai du mal à trouver un pattern/architecture pour les représenter…

C'est quoi les blocs qui ont étés ajoutés ?