organisation du code pygame

Question

J'ai commencé à apprendre à faire des jeux avec python/pygame et comme s'il était facile de faire un jeu de travail rapidement dans pygame, il n'y a pas vraiment de tutoriel sur l'organisation du code.

Sur la page tutoriels pygame, j'ai trouvé 3 façons de le faire.

1- Aucune utilisation des classes, pour les petits projets

2- MVC ruby-on-rails type de structure, mais sans le cadre des rails qui se traduit par quelque chose de trop compliqué et obscur (même avec la programmation orientée objet et rails connaissances ?)

3- C++ - structure comme la manière suivante: (propre et intuitive, mais peut-être pas beaucoup python-like)

import pygame 
from pygame.locals import * 

class MyGame: 
    def __init__(self): 
     self._running = True 
     self._surf_display = None 
     self.size = self.width, self.height = 150, 150 
    def on_init(self): 
     pygame.init() 
     self._display_surf = pygame.display.set_mode(self.size) 
     pygame.display.set_caption('MyGame') 
     #some more actions 
     pygame.display.flip() 
     self._running = True 
    def on_event(self, event): 
     if event.type == pygame.QUIT: 
      self._running = False 
     elif event.type == KEYDOWN: 
      if event.key == K_ESCAPE: 
       self._running = False 
     elif event.type == MOUSEBUTTONDOWN: 
      if event.button == 1: 
       print event.pos 
    def on_loop(self): 
     pass 
    def on_render(self): 
     pass 
    def on_cleanup(self): 
     pygame.quit() 
    def on_execute(self): 
     if self.on_init() == False: 
      self._running = False 
     while(self._running): 
      for event in pygame.event.get(): 
       self.on_event(event) 
      self.on_loop() 
      self.on_render() 
     self.on_cleanup() 

if __name__ == "__main__" : 
    mygame = MyGame() 
    mygame.on_execute() 

Je suis habitué à faire des jeux SDL en C++ et j'utilise cette exacte structure mais je me demande si c'est utilisable pour les deux sma ll et grands projets ou s'il y a une manière plus propre dans pygame.

Par exemple, je trouve un jeu organisé comme celui-ci:

imports 

def functionx 
def functiony 

class MyGameObject: 
class AnotherObject: 
class Game: #pygame init, event handler, win, lose...etc 
while True: #event loop 
display update 

Il semble également très bien organisé et facile à suivre.

Quelle structure dois-je utiliser systématiquement dans tous mes projets afin d'avoir un code propre utilisable dans les petits et grands jeux?

Answer 1

Faites ce que vous pouvez suivre. Si vous pouvez donner un sens au code que vous avez publié, alors c'est ce que vous devriez utiliser. Si une structure différente semble plus naturelle, utilisez-la à la place.

Answer 2

Je suggère également d'utiliser des commentaires (aussi triste que cela puisse paraître en premier) pour diviser votre travail. A titre d'exemple:

import pygame, random, math 

## CLASSES ---------------------------------------------- 

class Ball(): 
    def __init__(self, (x,y), size): 
     """Setting up the new instance""" 
     self.x = x 
     self.y = y 
     self.size = size 

## FUNCTIONS -------------------------------------------- 
def addVectors((angle1, length1), (angle2, length2)): 
    """Take two vectors and find the resultant""" 
    x = math.sin(angle1) * length1 + math.sin(angle2) * length2 
    y = math.cos(angle1) * length1 + math.cos(angle2) * length2 

## INIT ------------------------------------------------- 

width = 600 
height = 400 
screen = pygame.display.set_mode((width, height)) 
pygame.display.set_caption("S-kuru") 

Et ainsi de suite.

Autre option à considérer, avez-vous pensé à utiliser des sous-modules? Ils sont juste d'autres fichiers Python (.py) où vous placez des fonctions couramment utilisées.

def showText(passedVariable): 
    print passedVariable 
    return 

Ce nouveau fichier est l'importation, comme les mathématiques ou aléatoire serait et la fonction utilisée en tant que telle:

import mySubModule 

mySubModule.showText("Hello!") 

Mais c'est juste la façon dont je travaille. Suivez absolument ce que vous pouvez comprendre, pas seulement maintenant, mais la semaine prochaine ou l'année aussi. MVC a été sous une forme quelconque tant qu'il y a eu des interfaces graphiques.