Desenvolvimento de jogos para MSX

Retro Rio 2019
Desenvolvimento de jogos para MSX
Giovanni Nunes

O que você aprenderá nesta tarde?
Como o software para MSX costumava ser escrito.
Algumas ferramentas úteis para auxiliar no desenvolvimento.
Uma forma de organizar o código para facilitar a programação.
Desenvolvimento de jogos para MSX 2

O que você não aprenderá!
A linguagem assembly para Z80 ou qualquer outro processador.
Como funcionam as entranhas do MSX.
Uma receita mágica para escrever jogos em um click.

Um pouco de história

Como o software para MSX era escrito?
Desenvolvimento nativo
Contando apenas com um MSX, drive de disquetes e um assembler.
Em alguns casos tão somente o cartucho do Mega Assembler e um
gravador cassete.
Ou seja, programar, testar e depurar o código diretamente "no
metal".
A solução de custo mais baixo.

Desenvolvimento cruzado
Escrever, depurar e, em alguns casos, executar o software
utilizando outro equipamento.
Mais complexo e também custoso (requer mais equipamentos).
Soa moderno mas foi mais comum do que imaginávamos.
HP 64000 Logic Development System.
Philips Microprocessor Development System.
Programmers Development System.

Um pouco mais sobre o PDS
O PDS foi criado por Andy Glaister e outros em 1984 para o
desenvolvimento do jogo Skyline Attack para o Commodore 64 na
Argonaut Games.
Solução que permitia programar e desenhar usando um IBM PC e
enviar o resultado à máquina de destino para execução e
depuração.
A transferência era feita com hardware próprio que permitia a
interligação dos computadores utilizando um pequeno programa de
carga.

Skyline Attack

(continuação)
Porteriormente fundaram a PD Systems para comercializar a
solução.
Além de IBM PC, também se podia utilizar um Atari ST e em ambos
era possível conectar até dois computadores simultaneamente.
Fora o C64 o PDS também suportava o desenvolvimento para
Amstrad CPC, MSX, SAM Coupé e ZX Spectrum.

(continuação)
Michael Archer liberou recentemente no GitHub o código fonte
das versões de C64 dos jogos Alien3, Altered Beast, Rampage e
outros. Todos desenvolvidos utilizando o PDS.
A versão de R-Type do ZX Spectrum, escrita por Bob Pape, foi
finalizada no PDS.
No livro IT'S BEHIND YOU ele conta como fez para conseguir um
PC-AT e o PDS para finalizar o jogo.

Caixa de ferramentas

Principais ferramentas
O conjunto básico é composto por três tipos de ferramentas:
Um editor de textos para escrever os programas.
O montador cruzado para gerar o código e
Um emulador para executá-lo.

Editor de Programas
Atom https://www.atom.io
Utilize aquele no qual você se sente confortável, lembre-se que
passará bastante tempo nele.
Algumas vezes também uso o Vim.
Tem uma interface limpa, se integra com o git e pode ser extendido
facilmente.
Extensões recomendadas: editorconfig, language-z80asm,
minimap e pigments.

Atom

Montador cruzado
Pasmo http://pasmo.speccy.org/
Montador escrito em C++ por Julian Albo.
Monta código de Z80, suporta todos os opcodes (inclusive os
"secretos"), gera executáveis nativos de diversas plataformas.
Segue a sintaxe do Macro Assembler da Digital Research.
Tem uma documentação ruim e bugs curiosos.
É utilizado no desenvolvimento da C-BIOS.

Emulador
OpenMSX http://openmsx.org/
Emula com perfeição, ou quase, os MSX, MSX2, MSX2+ e MSX
turbo R.
Para o básico a C-BIOS é mais que suficiente mas, cuidado, ela as
vezes se comporta de forma estranha.
Portanto, vale a pena ter um conjunto de ROM oficiais.
Ele te economiza tempo.

Ferramentas de apoio
Calma que tem mais!
GNU Bash, GNU Make e outras ferramentas.
Git para controlar a versão do código.
Gimp, MSX Screen Converter e Tiny Sprite para os gráficos
Um pouco de Python e MSX-BASIC para o resto.
As vezes é necessário escrever programas para se escrever um
programa.

Modelo de Desenvolvimento

A experiência do Flappybird
Meu primeiro jogo escrito inteiramente em assembly.
Inicialmente em MSX-BASIC mas recebeu tantas rotinas em
linguagem de máquina que ficou mais fácil codificá-lo em
assembly.
A primeira versão pública era uma "tripa" com 1.500 linhas de
código!
Sem uma separação clara entre os componentes, acrescentar
ou remover funcionalidades é um pesadelo.

Flappybird

Pensando na arquitetura
O Model-View-Controller (MVC) é um padrão de arquitetura de
software onde representação da informação e interação do usuário
estão separadas.
Mas isto se adequaria ao desenvolvimento de jogos?
Create a Platformer Game with JavaScript - Full Tutorial, do
Frank Poth trabalhando com uma arquitetura de Controller,
Display, Game e Engine.
Game Architecture: Model-View-Controller do Koen Witters
trabalhando com o MVC tradicional.

(continuação)
Acabei utilizando uma arquitetura um pouco mais simplificada.
Display : Contém tudo que efetivamente escreve na tela. É quem
inicializa o vídeo, desenha os tiles e posiciona os sprites.
Controller : Cuida de manipular os objetos dentro do jogo e da
interação entre eles.
Engine : Orquestra a lógica do jogo como um todo.
Enquanto escrevia esta apresentação comecei a considerar que
mover partes de Controller e Engine para criar Game uma boa
ideia.

Colocando em prática
Comecei a adaptando o código da minha versão para MSX do
Scutlebutt mas modificar algo existente pareceu arriscado e
trabalhoso.
E se era para experimentar, então era melhor com um projeto
começado do zero.

Nohzdyve

Nohzdyve
No final de 2018 o episódio Black Mirror: Bandersnatch foi "ao ar"
e, entre os diversos easter eggs disponíveis, estava um jogo de ZX
Spectrum, o Nohzdyve.
Ele foi escrito por Matt Wescott seguindo as especificações do
mockup apresentado no episódio.
No jogo você está despencando do céu e deve colecionar os globos
oculares enquanto evitar as paredes dos prédios e outros
obstáculos.

Nohzdyve em Black Mirror: Bandersnatch

Tela de abertura

Durante o jogo

A versão de MSX
Baseado na versão de ZX Spectrum mas não é uma conversão
direta.
Exceto pelos gráficos, nada mais do jogo foi utilizado.
Jogo de 8 KiB disponível tanto em ROM como binário.
Requer MSX com o mínimo 16 KiB de memória RAM e pode ser
jogado por teclado ou joystick.

Tela de Abertura

Iniciando a queda

Durante o jogo

Fim do jogo

Arquitetura do código
Componente Elementos
display/
Aircon Clothes Eyeball Man Screen Teeth Vase
Wall Window
controller/
Aircon Clothes Eyeball Man Score Screen Teeth
Vase Wall
engine/ Aircon Clothes Eyeball Man Teeth Vase

Arquivos auxiliares
Arquivo Descrição
__binary.asm
Encapsula main() para criar a versão binária
(BLOAD)
__cartridge.asm Encapsula main() para criar a versão em ROM
__config.asm Permite configurar os parâmetros do jogo
__macros.asm Macros
__variables.asm "Variáveis" (arquivo gerado dinamicamente)
main.asm Função main() do programa

Encapsuladores
Os arquivos "__binary.asm" e "__cartridge.asm" encapsulam a rotina
principal.
São eles que tem o conhecimento da estrutura de um BIN ou ROM.
Permite que outros formatos de distribuição sejam criados sem a
necessidade de alterações no código.

Configuração
Uma forma de colocar em um único lugar os parâmetros do jogo.
Ajustanto o valor de SET_EYE_COLOR é possível definir se globos
oculares serão exibidos em duas cores (como no programa de TV)
ou com cores aleatórias (versão do speccy).

Sobre as "variáveis"
Claro, não existem variáveis em assembly.
O que existem são os rótulos.
Você "aponta" um endereço de memória e usa para suas
necessidades.
O controle é manual, portanto passível de acidentes.
Para facilitar, criei uma notação para variáveis (inócua dentro do
Pasmo) e um programa para transformar isto no arquivo
"variables.asm".

A função main()
main:
proc
include "__variables.asm"
call INITIO
call GICINI
call engine_init
__loop:
jr __loop
endp
include "controller/__main.asm"
include "display/__main.asm"
include "engine/__main.asm"

Nohzdyve
Uma rápida passagem pelo código...

Perguntas?

Desenvolvimento de jogos para MSX

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (16)

Semelhante a Desenvolvimento de jogos para MSX

Semelhante a Desenvolvimento de jogos para MSX (20)

Desenvolvimento de jogos para MSX