UrWorld, le retour du retour

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous, vous avez sûrement remarqué mon post à propos d'UrWorld sur OpenClassroom. Parlons un peu de moi :D

Je suis un jeune développeur en python (version 3.4) utilisant Pygame pour créer des jeux 2D. Ce n'est pas ma première expérience en ce domaine, j'ai déjà codé plusieurs petits jeux en C également. J'aime la liberté, la créativité et la programmation par dessus tout.

Genèse

Ce projet est né en aout 2014, quand je me suis mit à étudier Pygame. J'avais envie de trouver un projet pour bien assimiler toutes les connaissances acquises autour de Python et de Pygame. Etant amateur de jeux de sand box, je me suis dit que j'allais créer le mien. De là est né UrWorld, du désir de construire son monde (en 2D), et de pouvoir le personnaliser le plus possible ! 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

Maintenant tout ca est bridé, performant, amélioré … la map est générée aléatoirement, et dernier ajout : un style de jeu 'sokoban' : les tables sont déplaçables :P Bientôt, le réseau sera mis en place ;)

Objectifs

J'aimerai à termes intégrer un système de craft où tout le monde pourra rajouter sa structure en utilisant simplement Pickle, avoir jusqu'à 96 blocs (c'est déjà pas mal du tout je pense), et un dossier 'Mods' où on pourra ajouter un fichier .py avec une seule fonction qui sera nommée ur_modding (sans arguments, ou sinon une class, les 2 options seront possibles), car j'appelerai toutes ces fonctions dans la boucle du jeu ! Ainsi on pourra coder des mods pour le jeu. Par contre, il vous faudra faire attention car cela pourra ralentir le jeu :) . D'autres objectifs seront sûrement énoncés plus tard :D .

Originalité du projet

Aucune. Nan je rigole ! Je souhaite tout de même que mon projet sois original, et ce grâce à ces points ci (entre autres) : - "moddage" facile du jeu,

  • open source,

  • créativité sans limite (j'espère)

  • et la communauté peut proposer des concepts !

pour vous donner une idée, 20% des idées du jeu ne viennent pas de moi, alors vous aussi, si vous avez des idées, vous pouvez aider !

Screenschots

Image utilisateur

Image utilisateur

Image utilisateur

Image utilisateur

Musiques (de Bat', merci à lui :D)

urworld-2

Liens

GitHub

Édité par Cithoran

Ma chaine YouTube ! | Seventh, un micro langage communautaire ! | Mon projet : Unamed (en pleine reprogrammation en C++11/SFML2.4) | Mon tuto sur Pygame !

+1 -0

Cette réponse a aidé l'auteur du sujet

[..] 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

Image utilisateur

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.

Musiques (de bat', merchi à lui :D)

urworld-2

Folaefolc

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

Auteur du sujet

ouaip ca avance mais pas en tant que code en fait, plutot en tant que design pattern ;)

pour le moment j'essaie de coder plusieurs class fictives que j'utiliserai par la suite (perso, life, et mana sont deja faites, level est en cours :))

Ma chaine YouTube ! | Seventh, un micro langage communautaire ! | Mon projet : Unamed (en pleine reprogrammation en C++11/SFML2.4) | Mon tuto sur Pygame !

+1 -0

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 ?

+0 -0

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.

Anciennement AlphaZeta

+0 -0
Auteur du sujet

ben pourquoi une class life + mana ?

car elle gère leur affichage seule, et indépendamment du joueur, ca doit etre asynchrone ;)

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 :)

Ma chaine YouTube ! | Seventh, un micro langage communautaire ! | Mon projet : Unamed (en pleine reprogrammation en C++11/SFML2.4) | Mon tuto sur Pygame !

+0 -0

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 :)

Édité par felko

Anciennement AlphaZeta

+2 -0

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().

+1 -0

Cette réponse a aidé l'auteur du sujet

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…

Anciennement AlphaZeta

+2 -0
Auteur du sujet

je passe juste pour dire que le projet continu et que je bosse encore et toujours sur l'architecture.

j'ai ajouté 2 blocs, bientot 3 autres suivront (pas d'inquiétudes, ils sont ajoutés selon la norme qui sera mise en place (class Bloc avec gestion des layers))

pour toutes suggestions, contactez moi ici ou par email : urworld@outlook.fr

Ma chaine YouTube ! | Seventh, un micro langage communautaire ! | Mon projet : Unamed (en pleine reprogrammation en C++11/SFML2.4) | Mon tuto sur Pygame !

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte