Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Ultimate Smash Friends: un smash bros like en python

[supprimé]

Ah... da moteur physique ist eine gros morceau ! :lol:
Tu pourrais peut-être en utiliser un existant, genre box2D ! Ca fait une dépendance en plus, mais au moins tu aurais un truc à peu près fiable question physique, parce que j'imagine qu'à terme tu veux des trucs qui pètent, des objets qui tombent, qui roulent... Ce n'est pas un conseil, je n'ai encore jamais eu besoin d'un "vrai" moteur physique, mais c'est une suggestion.

Je suis en train de jeter un oeil au code.

[supprimé]

J'ai un lien qui peut t'intéresser :
http://www.gamedev.net/community/forums/topic.asp?topic_id=509143

tshirtman

@nathéo: bon courage 🙂 n'hésite pas a poser des questions si tu bloque sur un truc avec pygame ou si tu as besoin de comprendre un truc dans mon code 🙂.

@kaoron: en effet le lien est intéressant, pour le changement de mode, j'ai fait légèrement ça (tenter de se passer d'un certain nombre de tests quand on est au sol) mais pour l'instant ça n'a pas donné grand chose, faut que je me repenche dessus, le moteur physique c'est le truc sur lequel je revient constamment depuis le début, et il ne gère ni les pentes ni les destructions de niveaux, c'est vrai que le premier ça manque pas mal, et le deuxieme serait carrément fun.... mais là faudrait tout changer niveau format de niveau... je sais pas si ce sera pour ce jeu, ou au moins cette version du jeu ^^. J'avais hésité pour le niveau en svg à un moment mais j'ai un peu pris peur ^^ (mais p*tain qu'est ce que ce serait puissant!)

Pour l'intégration d'un moteur physique, je me demande toujours comment on peu gérer ses évenements et tout ça quand justement on le délègue à un moteur externe, mais bon faudrait que je teste ^^ c'est vrai qu'il y a de bons moteurs 2D bien plus efficaces que ce que je fais avec grand peine.&

[supprimé]

Pour l'intégration d'un moteur physique, je me demande toujours comment on peu gérer ses évenements et tout ça quand justement on le délègue à un moteur externe

A froid, je te dirais de la même manière que tu traitres les events de la sdl -avec un poll, mais au lieu d'avoir des events hardware, tu aurais des events logiques- ou bien avec un système de callbacks/surcharge de méthode qui te permet de définir l'appel à effectuer en cas d'un évènement X.

tshirtman

t'a sans doutes raison, ça parait raisonnable 🙂

des réactions sur mon code? 😛 (oui tout n'es pas commenté, faut que je me reprenne là dessus ^^')

nathéo

Ok donc premier problème où doit être placer ce bout de code

pygame.joystick.init(): return None

Est-ce que je dois créer une autre ligne contenant

 def __init__(self) :

nathéo

Un autre soucis : un double saut sur le niveau mansion conduit inéluctablement à la perte d'un cœur, est-ce que c'est voulu?

tshirtman

il faut ajouter

pygame.joystick.init()

dans le __init__ dans controls... je dirais

edit: non mais ça se corrige facilement, je vais ajouter un peu de marge au dessus du niveau.

[supprimé]

Hmmm, vrouaip. Plutôt que juger la qualité du code, je te passe des liens qui me semblent parlants (pas forcément à recopier tels-quels, mais dont la conception peut être intéressante à étudier).

Je pense que ta boucle de jeu pourrait être plus claire, en poussant un peu plus loin le concept d'états de jeu que tu as commencé à implémenter.
Basiquement, je verrais un truc du genre :

while True:
    while e = event.poll() :
        currentstate.processEvent(e)
    currentstate.update()
    clearwindow()
    currentstate.draw()
    display()

Le pattern gamestate : http://www.planet-dev.com/developpement/jeux-video/game-state-pattern
Une proposition de squelette d'application : http://www.sfml-dev.org/forum-fr/viewtopic.php?p=16831#16831
Un article sur la boucle de jeu : http://dewitters.koonsolo.com/gameloop.html

Aussi, la gestion de ressources a l'air morcelée sur différentes classes. Tu pourrait implémenter un gestionnaire de ressources contenant un dict des images utilisées dans le jeu, la classe implémenterait ton/tes loaders et dans le reste du code il te suffirait d'appeler ressources.getImage(["media","misc","toto.png"]) pour obtenir (et charger à la volée si besoin) une référence à media/misc/toto.png.
La gestion de ressources : http://www.sfml-dev.org/wiki/fr/sources/imagemanager

Sinon, j'ai un peu de mal à me retrouver dans ton code, je ne sais pas exactement ce qui gère la physique, les ressources, la logique du jeu... Un peu de séparations dans tout ça éclaircirait le tout à mon avis.

Comme d'hab, ce ne sont que des suggestions.

nathéo

Ok je veux bien mais dans quel _init_ exactement parce que lorsque je regarde controls.py je tombe sur

  def __init__(self, player, keys, action, condition=None):

def __init__(self):

[supprimé]

Sinon, si tu veux discuter création de jeux, passe à l'occasion sur le GCN, forum et [url=irc://gcn@irc.langochat.net]canal IRC[/url].
Il y a quelques python/pygame-istes sur le canal, et on est toujours ravis de causer création 🙂

tshirtman

je vais regarder ça, pour la gestion d'image par contre je sais pas si tu as vu mais c'est le fonctionnement actuel quand je veux afficher une image je fait surface.blit(loaders.image('chemin_de_l_image') et elle est chargé, mais le chargeur a un décorateur 'memoize' ce qu'il fait que si elle a déja été chargé il renvois le résultat de la fois précédente (stoqué dans un dico) ça a fait sacrément gagner en perfs, plutot qu'essayer de savoir moi même si je l'avais ou pas... (pour les persos c'est à peine différent, je les charge de la même façon au chargement du niveau, pour pas que ça rame en jeu, je testerai peut être de voir si ça fait rammer tant que ça). Tu notera que la gestion des zooms d'image est stoqué au même endroit donc chaque niveau de zoom necessaire n'est fait qu'une fois par image.

Pour le reste des chargement oui on (moi et toineo) travaille sur l'idée d'une refonte pour mettre plus en commun les ressources, dans un gestionnaire.

Pour ce qui est des séparations, c'est vrai que j'ai du faire quelques compromis un peu sales, et au niveau de la physique c'est assez éparpillé (une partie dans la boucle de jeu, une autre dans les entitées elles mêmes... 🙁) faut que je remette ça en forme aussi.

Je vais lire tes suggestions de lectures au plus tôt 😉. (c'est vrai que j'ai très peu fréquenté les forums du genre, j'ai un peu fait dans mon coins).

tshirtman

natheo a écritOk je veux bien mais dans quel _init_ exactement parce que lorsque je regarde controls.py je tombe sur

  def __init__(self, player, keys, action, condition=None):

def __init__(self):

arg tu as eu la malédiction de bas de page -_- j'avais pas vu ton message! désolé :s

c'est dans le __init__ de controls qu'il faut ajouter (si necessaire) ta ligne, mais si ça se trouve c'est déjà initialisé en même temps que le reste.

@kaoron: pas encore trop lus tes liens, je suis dans un chantier là, mais ça devrait pas tarder 😉. J'ai fait un tour sur ton forum et j'essayerai de m'inscrire et d'y présenter mon jeu un de ces 4, voir ce qu'en pense les gens, ça grouille pas d'open source, mais je peux essayer de montrer que c'est faisable 😛.

samυncle

je m'abonne 😉

geenux

Moi aussi, je vais tester ton petit jeu pour voire 🙂

tshirtman

/me compte faire des releases plus souvent... dont une cette semaine, garder l'oeil ouvert...

LittleWhite

... et en plus il nous empêche de fermer les yeux :s
De toute façon, j'aurais une notification ... donc je peux fermer mes deux yeux :p

tshirtman

pour ceux qui utilisent le svn je veux bien des tests de la version de maintenan et avoir des retours avant de sortir une release avec. (pas ce soir 😉)

sinon bonne nuit 😉

Кຼزດ

$usf
Fatal Python error: (pygame parachute) Segmentation Fault
/usr/bin/usf: line 3: 19589 Abandon                 python ultimate-smash-friends

:/ j'ai la dernière version de pygame, et je viens d'installer la version svn

tshirtman

arf :/ j'ai pas testé avec pygame 1.9... :/

« Page précédente Page suivante »