UrWorld, le retour !

Version Alpha 0.0.1 ! Sortie pour le nouvel an !

a marqué ce sujet comme résolu.

J en suis encore et toujours aux tests de cette implémentation vois tu.

Alors tu me l avais proposé mais … Je voyais pas comment m implémenter. Une seconde demande pour cela me montre que j avais tord. Il fallut bien l implémenter. Enfin après réflexion c est uniquement 151 lignes a modifier delà bonne manière, et un système d ajout sur la 2 ND couche. A moins que je ne passe par une autre double liste, ce qui serait plus léger a enregistrer comme je thread (cela devrait diviser les temps d enreg).

Alors oui, je dois faire de l'OO. Mais faut que je me motive car les connaissances ne font pas le programmeur. Je vais déjà faire quelques classes puis je passerai, si j y arrive et que je tiens les délais, au moins la moitié du projet en POO. Le plus chiant sera bien sur les déplacements et l affichage du personnage, car je devrais tout faire en interne par rapport a ma class personnage.

@Stranger: Tu as raison je me suis mal exprimé… Je ne voulais pas dire que le fonctionnel est dégueu, mais maintenir un code en OO est 100 fois plus facile que le même code en fonctionnel, à condition d'être bon en OO bien entendu. Si John Carmack dit du bien sur le fonctionnel, c'est parce qu'il maîtrise à la perfection ce paradigme. Python est 100% orienté objet, le fonctionnel y est rarement pertinent, ou avec modération contrairement au Haskell.

Edit: Le fonctionnel en Python peut être pertinent, mais un jeu de cette envergure entièrement en fonctionnel n'est pas raisonnable…

+1 -2

s_invent_idd : le 's' est un id pour moi, par rapport à une map nommée S

invent : inventaire

idd: inventaire drag and drop

s est une carte

31 : largeur, 52 : hauteur (en raison de décalages) oui ce code marche encore si on change la fenetre de taile tkt

je ne renomme jamais mes resx, je prend toujours le soin de les nommer … avec un bon nom quoi :D

si load echoue, ca bug, normal. mais l'user n'a pas à modifier / toucher aux resx normalement

et bien non, ce ne sont pas les memes param, l'un sert pour checker le bloc en cours en mettant l'img check.png dessus, l'autre pour faire l'affichage standart

Je rejoins complètement Stranger, c'est pas beau ce code !

31 : largeur, 52 : hauteur (en raison de décalages) oui ce code marche encore si on change la fenetre de taile tkt

Stocke ta hauteur et ta largeur dans des constantes (ou des variables au pire), parce que si tu veut afficher plus de blocs un jour, tu va devoir re-modifier tout ton code …

je ne renomme jamais mes resx, je prend toujours le soin de les nommer … avec un bon nom quoi :D

si load echoue, ca bug, normal. mais l'user n'a pas à modifier / toucher aux resx normalement

Image un utilisateur un peu curieux va modifier le nom de te ressources, il ne peut plus jouer :/

Je confirme à 100 % ce que dis Stranger. Je pense que tu devrais t'atteler à réorganiser tout ton code avant même d'ajouter une nouvelle fonctionnalité (comme le joystick)

Honnêtement, tu fais comme tu veux, c'est ton code. Mais si on est plusieurs à le dire, c'est parce que tel que t'es parti, plus tu vas avancer et plus tu vas te prendre la tête pour déboguer. À la fin ça deviendra ingérable et personne n'aura le courage de t'aider parce que le code sera trop compliqué et difficile à comprendre :o
C'est vraiment dans ton intérêt de commencer par tout réorganiser et repartir sur un code propre et structuré.

EDIT : Je n'ai aucune animosité, je cherche sincèrement à te conseiller ;)

+6 -0

je viens vous signaler que le site est down en raison de la supsension de mon compte (allez savoir pourquoi ^^) j'espère y remédier (meme en changeant de nom de domaine dans le pire des cas) le plus vite possible

petite information : controle au joystick terminé et opérationnel

je viens vous signaler que le site est down en raison de la supsension de mon compte (allez savoir pourquoi ^^) j'espère y remédier (meme en changeant de nom de domaine dans le pire des cas) le plus vite possible

oooooooh .... Mince !

petite information : controle au joystick terminé et opérationnel

Folaefolc

Ouais !
Décidément, une mauvaise nouvelle en appelle souvent une bonne !

Je testerais bien le jeu sur GNU/Linux (je n'aurai pas accès à un Windows avant un moment).
Avec Wine, l'installateur fonctionne (et ensuite j'ai dû installer une bibliothèque en plus, mais c'est un jeu d'enfant pour un habitué du terminal) mais le hic, c'est que PIL n'est disponible que sur Windows apparemment.

Pour ce qui est de réorganiser ton code, je pense que tu peux t'inspirer du pattern Strategy expliqué dans le tuto Java. Si tu ne connais pas le Java mais que tu connais le C++, ce site (en anglais) explique une sorte d'ECS (Entity Component System) simplifié qui revient au même que le pattern Strategy.
C'est simple de l'appliquer à Python, les interfaces pouvant être de simple classe qui lèvent une exception lorsque l'on appelle la méthode à surcharger :

Petit exemple :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
class Component:
    def __init__(self, entity=None):
        self.ent = entity

    def update(self, delta_time):
        raise NotImplementedError()


import controller
class Input(Component):

    def update(self, entity):
        # En supposant que le module controller contient des fonctions pour connaître l'état du clavier et du joystick :
        entity.vx = entity.vy = 0
        if controller.joystick_dir() == LEFT:
            entity.vx = -1
        elif controller.joystick_dir() == RIGHT:
            entity.vx = 1
        elif controller.joystick_dir() == UP:
            entity.vy = -1
        elif controller.joystick_dir() == DOWN:
            entity.vy = 1


class Physics(Component):

    def update(self, entity):
        entity.x += entity.vx
        entity.y += entity.vy


class Entity:
    def __init__(self, input, physics, x=0, y=0, vx=0, vy=0):
        self.x = x
        self.y = y
        self.vx = vx
        self.vy = vy

        self.inp = input
        self.phy = physics

    def update(self):
        self.inp.update(self)
        self.phy.update(self)

Et donc de même avec un composant Graphics qui s'occuperait d'afficher l'entité (dont les sprites peuvent être stockés dans l'entité ou le composant, au choix).
Peut dériver de Input : KeyboardInput qui regardera les entrées clavier et JoystickInput qui regardera les entrées joystick, la classe Input étant dans ce cas une interface (sa méthode update lève une exception).
Pour que le joueur passe du joystick au clavier, il suffit de recréer une instance de KeyboardInput dans l'entité à la place de l'actuel composant input : entity.inp = KeyboardInput().

+1 -0

Non, je crois qu'il s'est désinscrit volontairement. Il en a parler sur GH parce qu'il avait une 500 en se désinscrivant … :(

Mais c'est bizarre, il abandonne tout comme ça ? Enfin il avait déjà deux projets, pas mal de personnes que ça intéressait et puis il laisse tout tomber, sans rien dire ? C'est vraiment bizarre …

Ce sujet est verrouillé.