Pygames: Coordenando múltiplos arquivos .py

No post de hoje vamos trabalhar com a integração de múltiplos arquivos de pygames (.py), pois a medida que os códigos começam a crescer, não basta apenas organização no arquivo de programação usando-se diversos class ou definições, afinal a programação começa a ficar muita extensa e de difícil leitura. Nesse caso, podemos criar arquivos .py secundários para cada um dos personagens executáveis pelo jogador, os controlados pela IA do game (NPC), bem como diversas customizações em separado e ao final, unir tudo em um único arquivo .py principal a ser executado. O exemplo que vamos utilizar está disponível no GDrive: https://drive.google.com/drive/folders/1U-_SQhtXz0Hpq1O4UYvK1plPOW3MGcya?usp=sharing e trabalha com quatro arquivos diferentes de personagens que são gerenciados pelo arquivo "jogo.py". Além disso, a grande maioria dos códigos aqui utilizado já foram vistos nos posts anteriores e podem ser acessados usando a tag "Pygames" do blog.

Vamos usar como exemplo de uma arquivo secundário o "morcego.py". Sua estrutura é baseada na que foi construída no post sobre construção de sprites e pode ser conferida em: https://vemfazermatematicaegames.blogspot.com/2020/07/pygames-usando-o-modulo-pygamesprite.html. Se você observar os comandos na figura abaixo, irá ver que foram retirados diversos comandos responsáveis pela execução da classe Morcego, que por sua vez estão presentes no arquivo principal "jogo.py" (esse é o arquivo que une os demais). Veja as diferenças na figura abaixo:

Na comparação acima dos arquivos "sprite" (versão com um único arquivo) e do "morcego" (versão com mais de um arquivo), pode ser constatado que comandos relacionados a iniciação, execução de loop (repetição) e finalização da programação não estão mais presentes. Eles serão adicionados no arquivo geral "jogo.py" que é responsável por carregar todos os arquivos auxiliares pygames (morcego,  quadrado, caramujo, caminhante).
Agora vamos focar no arquivo principal "jogo.py" e ver um pouco da sua programação. Nos comandos de inicialização (que não estão presentes nos outros arquivos secundários) temos a presença da definição "all_sprites =  pygame.sprite.Group"  que é o módulo que será responsável pela adição de cada um dos arquivos ''.py''. Em seguida, cada um dos arquivos é carregado via uma definição (exemplificando, "cami = caminhante()", nesse caso é o arquivo "caminhante.py" que está sendo definido como "cami") para em seguida com o comando "all_sprites.add(nome da definição do arquivo)" ele seja adicionado a linha de execução de comandos. Veja abaixo o que acabamos de explicar:

pygame.init() pygame.mixer.init() screen = pygame.display.set_mode((WIDTH, HEIGHT)) pygame.display.set_caption("Experimentando com Sprites") clock = pygame.time.Clock() all_sprites = pygame.sprite.Group() player = Quadro(10,RED) player2 = Quadro(6,GREEN) player3 = Quadro(4,BLUE) cami = Caminhante() bat = Morcego() cara = Caramujo() all_sprites.add(bat) all_sprites.add(player) all_sprites.add(player2) all_sprites.add(player3) all_sprites.add(cami) all_sprites.add(cara)

No decorrer do arquivo temos os comandos relacionados a repetição (loop), entrada do teclado (inputs) e desenho execução na tela, que já foram vistos em outros post com a tag Pygames (volte neles se for necessário uma revisão). Único ponto de atenção, é a forma como o Pygames executa todos os updates gráficos de todos os arquivos. Lembra da definição "all_sprites"? Ela retorna no fim do arquivo para fazer as atualizações (all_sprites.update) e execuções na tela (all_sprites.draw), fechando o ciclo da programação:

all_sprites.update() screen.fill(GRAY) all_sprites.draw(screen) pygame.display.flip() pygame.quit()

O post de hoje encerra-se com essa incrível possibilidade de construir diferentes arquivos e unir toda a execução dele em apenas um arquivo, facilitando a organização e leitura dos códigos, afinal, quanto maior a proposta do game, maior será o tamanho do código construído. Até a próxima!