Ainda hoje, as pessoas continuam a criar novos jogos para consoles antigos. Nós os chamamos de homebrew . Às vezes, essa é uma maneira de realizar o sonho de infância de criar um jogo para o console em que a criança brincava. Além disso, também é uma tarefa interessante para qualquer designer ou desenvolvedor de jogos: o ferro retro tinha muitas limitações que desafiavam a criatividade dos autores. Nos anos 90, para desenvolvedores profissionais, essas restrições eram familiares. Hoje, quando temos ferramentas mais avançadas, a criação de jogos para essas máquinas se tornou muito mais acessível.

No ano passado, escrevi um artigo sobre a criação de um jogo para o Game Boy . Hoje vou compartilhar minha experiência na criação de três jogos para o console doméstico SEGA Mega Drive / Genesis. Provavelmente, graças às modernas ferramentas poderosas, esta é a máquina mais fácil de desenvolver um jogo de homebrew. Por exemplo, eu até consegui criar um jogo (muito simples) em apenas 60 minutos e ele realmente é executado no console!

Os jogos

No ano passado, para comemorar o 30º aniversário do lançamento do Genesis / Mega Drive, criei um jogo chamado 30 Years of Nintendon't . Como o nome indica, esse é um tributo aos melhores jogos do console e ao marketing agressivo que a SEGA usou na época (por exemplo, o slogan "Genesis Does what Nintend don't").


Neste jogo, controlamos o evangelista da SEGA, que deve convencer os jogadores a esquecer seu NES e SNES, porque o Genesis tem jogos melhores! O jogo foi lançado online gratuitamente no 30º aniversário do console. Você pode reproduzi-lo aqui: https://drludos.itch.io/30-years-of-nintendont


Desde então, eu também criei dois (pequenos) jogos de arcade para o console:

"Quebre um ovo"



"MeteoRain"


Todos esses três jogos são vendidos em um cartucho publicado pela Cote Gamers:

http://cotegamers.com/shop/en/genesis-mega-drive/43-test.html

Ele vem em uma linda caixa de plástico, como jogos antigos de verdade, e com um conjunto de cartões postais.

Posso usar Unity, Unreal Engine ou Godot?

Desculpe, mas esses mecanismos não podem exportar jogos para o SEGA Mega Drive / Genesis (talvez por enquanto?). Mas não se preocupe, existe outra ferramenta que é tão útil quanto esses motores modernos populares e, ao mesmo tempo, projetada especificamente para Mega Drive / Genesis: SGDK . Essa é uma estrutura que permite escrever código para esta máquina em C. É muito mais simples e rápido do que aprender a linguagem assembly, exigida nos anos 90. Mas isso não é tudo. O SGDK também possui ferramentas para simplificar a criação de gráficos e sons. Você pode criar gráficos em seu editor de gráficos 2D favorito (do Photoshop para GIMP ou Asesprite) e ele será convertido automaticamente se você cumprir as restrições de hardware (mais sobre isso abaixo). O mesmo se aplica ao som: você pode criar efeitos sonoros em arquivos .wav e usar rastreadores diferentes para a música. Uma última coisa: o SGDK possui um poderoso “Sprite Engine” que simplifica a maioria das tarefas técnicas de exibição de imagens em movimento na tela. Mas quão "simples" é na realidade? No artigo, falarei sobre minha própria experiência de trabalho.

Processamento de explosão aparece em cena

Como qualquer programador de sistemas antigos lhe dirá, se você escrever um programa em C em vez de assembler, isso reduzirá o desempenho do jogo. E é verdade. Mas os custos em diferentes consoles retrô variam muito. Eles dependem da CPU usada, bem como da eficiência dos compiladores modernos que criam código para esses processadores antigos. Felizmente, o Mega Drive / Genesis usa o processador Motorola 68000, que é bastante adequado para trabalhar com os recursos da linguagem C. Isso é especialmente verdade em comparação com outras CPUs, por exemplo, com o console SNES 65816. Embora sejam poderosas por si só, as CPUs SNES são difíceis de forçar a executar programas escritos em C com velocidade suficiente. Ou seja, quando se trata de desenvolvimento de homebrew C, “Blast Processing” não é um mito de marketing, mas uma realidade!

Qual a velocidade da execução do código C?

Aqui está um exemplo da experiência pessoal - um GIF animado do meu jogo MeteoRain, no qual sprites de 45 meteoritos se movem sem demora a uma frequência de 60fps:


Aqui está outro exemplo de uma explosão do Break An Egg, que consiste em 40 partículas movendo-se a uma frequência de 60fps:


Se você usar os jogos antigos como exemplo, um bom exemplo do poder das CPUs Mega Drive / Genesis é o Contra Hard Corps. Embora o jogo tenha sido desenvolvido em montador e não em C (afinal, era nos anos 90) , os desenvolvedores poderiam usar um enorme poder de computação para mover muitos sprites pela tela e criar chefes atraentes com toneladas de partes móveis e explosões maciças.


Para comparação, o Contra III no SNES foi limitado pelo poder da CPU e, em vez de mover a pilha de sprites, a Konami usou efeitos gráficos exclusivos que apenas o chip de vídeo SNES era capaz, por exemplo, do efeito de transparência.


Embora ambos os jogos sejam igualmente interessantes, eles destacam perfeitamente as diferenças técnicas entre SNES e Mega Drive / Genesis. Mais informações sobre como a Konami criou cada um dos jogos no console correspondente podem ser encontradas no artigo “Making of Contra III and Hard Corps” do Retro Gamer No. 176 .

Restrições gráficas

Como o poder da computação não é um problema, o principal gargalo do console Genesis / Mega Drive para desenvolvedores de cervejas caseiras se tornou suas limitações gráficas. E, mais especificamente, um número limitado de cores exibidas por ela. Embora, em geral, o console possa gerar 512 cores exclusivas, ao mesmo tempo não pode haver mais de 64 cores na tela. Opa Para comparação: o SNES pode exibir 256 cores simultaneamente a partir de uma paleta de 32768 cores exclusivas. Ou seja, os artistas gráficos precisavam de muito talento para tornar os jogos da SEGA tão bons quanto os consoles dos concorrentes. E em muitos casos eles conseguiram. Apesar das restrições de cores, muitos jogos antigos de Mega Drive / Genesis são lindos, por exemplo, Comix Zone, The Story of Thor, Streets of Rage II, Ranger-X, Gunstar Heroes, Sonic 1-2-3, etc.


Zona Comix (1995)

Mas em outros casos, os jogos Mega Drive / Genesis pareciam bastante monótonos em comparação com as versões SNES. Um dos exemplos mais famosos é o Street Fighter II, onde as restrições de cores do console são muito visíveis:


O uso ideal de paletas limitadas (4 paletas de 16 cores para Genesis versus 16 paletas de 16 cores para SNES) foi um grande desafio para desenvolvedores que geralmente tinham muito pouco tempo para concluir projetos. Hoje, membros talentosos da comunidade SEGA podem modificar alguns jogos para otimizar o uso de cores. Por exemplo, Gabrielle Piron faz maravilhas com jogos como Castlevania Blood Lines, Golden Axe, Outrun ou o mencionado Street Fighter II:


(Acima está a paleta de cores do original, abaixo está um Gabriel modificado)

Com isso em mente, você pode usar seu editor de gráficos favorito para criar imagens, mas tenha muito cuidado ao escolher cores! Se você não combinar com a paleta de 512 cores piscada no equipamento, isso não será um problema: o SGDK converte automaticamente a imagem na paleta Mega Drive / Genesis. Mas quando se trata do número total de cores usadas e exibidas na tela, você deve fazer isso sozinho!

Fazendo objetos se moverem

Para exibir algo na tela, você precisa copiar os dados gráficos da ROM para a RAM de vídeo. A GPU não tem acesso direto aos dados na ROM, mas pode ler dados da RAM. Portanto, para alterar o plano de fundo ou a animação dos sprites, é necessário copiar regularmente novos dados da ROM para a RAM. E o número total de RAM de vídeo (VRAM) é limitado: apenas 64 KB. Comparado ao tamanho das ROMs de jogos (de 512 KB a 8 MB), isso é bem pequeno.

Gargalo # 1: transferência de VRAM

Se você criar um jogo muito pequeno com um pequeno número de elementos gráficos, poderá simplesmente carregá-los de uma vez por todas na memória quando o jogo iniciar. Mas a maioria dos jogos precisa atualizar regularmente os gráficos no VRAM para demonstrar várias animações. E, geralmente, causa muitos problemas!

A quantidade de dados gráficos que podem ser transferidos da ROM para a VRAM em cada quadro (isto é, 60 vezes por segundo) é limitada. Mais especificamente, são 7524 bytes por quadro, ou seja, cerca de 7 KB. Quando você precisa exibir grandes sprites animados e fundos animados, como no Street Fighter II, essa restrição interfere constantemente. E este é apenas o primeiro problema.

Gargalo # 2: restrições de sprite

Para consoles de 8/16 bits, outra dificuldade é o número total de sprites que o equipamento pode exibir. Geralmente, existem duas restrições: uma para o número total de sprites na tela e a outra para o número total de sprites em uma linha horizontal. Para consoles de 8 bits, como NES e Master System, essas restrições são muito severas: não mais que 8 sprites por linha horizontal e o número total não deve exceder 64 sprites. Isso significa que podemos exibir na tela 64 vezes o Sonic ou o Mario? Não, quero dizer "sprites de hardware", que são menores do que o que geralmente é chamado de sprite. Aqui está um exemplo de Super Mario Bros para NES, onde são necessários vários pixels de 8x8 pixels de sprites de hardware para exibir um único sprite de Mario.


(Fonte: https://nesdoug.com/2018/09/05/06-sprites/ )

Para consoles de 16 bits, as restrições de sprite são ligeiramente reduzidas. O Mega Drive / Genesis pode exibir até 80 sprites de hardware. Mas um sprite de hardware separado pode ter um tamanho de até 32x32 (anteriormente - apenas 8x8 pixels). Aqui estão alguns exemplos de como cortar "sprites de hardware" no Mega Drive / Genesis. Você notou que o Sonic utiliza apenas dois sprites de hardware, enquanto Mario no NES precisa de 8 sprites?


(Fonte: https://www.patreon.com/posts/new-resource-and-26847248 )

Gargalo # 3: prioridades do sprite

Como se isso não fosse suficientemente complicado, o Mega Drive / Genesis tem mais uma característica específica: uma cadeia de sprites. Ao aplicar dois sprites, o console deve descobrir qual deles deve ser exibido em cima do outro. No Master System e na maioria dos consoles da Nintendo (NES, Game Boy, SNES), os sprites eram colocados em uma tabela grande e sua ordem na tabela era usada para definir a prioridade de exibição. Escusado será dizer que esta é uma ferramenta bastante difícil de usar, porque você precisa redefinir constantemente esta tabela grande para alterar a prioridade dos sprites.

No Mega Drive / Genesis, a SEGA usou um sistema mais flexível e mais simples. Como em outros consoles, todos os sprites têm um número de índice em uma tabela grande, mas não é usado para definir a prioridade do sprite. Em vez disso, cada sprite armazena um link para o próximo sprite a ser exibido. Por fim, o console cria uma cadeia de sprites, começando com o sprite 0. Cada sprite sabe apenas o que vem depois dele. Isso facilita muito a alteração das prioridades dos sprites sem organizar todos os sprites em uma grande "tabela de links de sprites". Mas, francamente, embora esse sistema seja mais fácil de usar, ainda é irritante ao criar um jogo com prioridade de sprite que muda frequentemente, por exemplo, no beat'em up.

O caminho mais fácil: mecanismo de sprite SGDK

Exibir sprites em movimento e fundos de rolagem, levando em consideração todos esses gargalos, é um grande desafio. Todos os desenvolvedores dos anos 90 lutaram com ele, e muitos desenvolvedores de cervejas caseiras continuam a fazê-lo. Por exemplo, Matt Phillips lançou o magnífico jogo Tanglewood em 2018, mas o criou usando as ferramentas dos anos 90. Ele programou o jogo em linguagem assembly e usou o kit oficial de desenvolvimento de hardware, projetado cerca de 30 anos atrás. Por sua parte, foi uma escolha deliberada, ele queria experimentar completamente a técnica de desenvolver um jogo vintage.


(Fonte: https://www.gamasutra.com/view/news/325040/New_game_classic_hardware_Developing_Tanglewood_on_a_Sega_devkit.php )

Porém, para pessoas que não são tão experientes e pacientes quanto Matt, as ferramentas modernas podem reduzir o número de problemas criados por limitações técnicas de hardware. Já mencionamos que C é geralmente mais simples que o assembler. Também vale a pena acrescentar que o uso de um emulador Mega Drive / Genesis de alta precisão como o Blast'em em combinação com o Everdrive Flash Cart para testes em equipamentos reais torna o desenvolvimento do jogo quase indolor, comparado ao desenvolvimento usando emuladores de hardware antigos em combinação com um conjunto de ferramentas do DOS. Mas, novamente, o principal presente de nosso tempo é o SGDK.


Grave o jogo em um cartão SD, insira-o no Mega Everdrive e teste o jogo em hardware real!

Entre outras coisas, o SGDK também possui um poderoso "Sprite Engine", facilitando bastante a vida do desenvolvedor. Este é um conjunto de funções para processar a exibição de sprites de maneira semelhante à feita em estruturas modernas. Primeiro, você não precisa mais se preocupar com o número de sprites de hardware necessários para cada quadro da animação: o SGDK fará isso automaticamente. Além disso, ao trabalhar com prioridades de sprites, você não precisa definir manualmente a cadeia de sprites, porque o SGDK faz isso com o valor simples "prioridade de sprite", que pode ser definido para cada sprite, como em qualquer estrutura moderna. Uma última coisa: o SGDK também processa todas as transmissões em VRAM automaticamente! Sim, você entendeu corretamente, graças ao Sprite Engine, você não precisa mais cuidar da VRAM! Você pode simplesmente dizer ao SGDK para exibir a "animação do X sprite Y" e ele fará todo o trabalho tecnicamente difícil para você. Se você já teve que trabalhar com essas coisas manualmente, parece mágico - tudo é simples e claro!

Somente o Sprite Engine da estrutura SGDK torna o Mega Drive / Genesis o console retro mais fácil para o desenvolvimento de jogos, especialmente se você tiver experiência em trabalhar com estruturas de jogos em plataformas modernas. O SGDK é gratuito e de código aberto, mas se você quiser ajudar seu autor, Stefan Dallongevil, no desenvolvimento da magia retro, você pode fazê-lo no Patreon: https://www.patreon.com/SGDK/

Som

O som do hardware retro também é um teste real por si só, e cada console é único nesse sentido. O Mega Drive / Genesis possui um processador Z80 separado para esta tarefa, diretamente conectado ao equipamento de áudio. Ou seja, para criar som e música para o console, primeiro você precisa escrever um "driver de áudio": um programa para o processador Z80. Nos anos 90, cada estúdio de jogo desenvolveu seu próprio driver de áudio e o ajustou para cada jogo. No final da vida do console, drivers padronizados apareceram, por exemplo, o GEMS da Sega of America, usado em cerca de uma centena de jogos por desenvolvedores ocidentais.

Criar um bom som para consoles de 8/16 bits não é apenas uma questão de habilidades musicais, mas também de programação! Alguns jogos com boa música ou efeitos sonoros foram corrompidos por um driver de áudio ruim. O exemplo mais famoso é o Street Fighter II. O driver de áudio neste jogo sofre de bugs que distorcem todas as amostras de voz. Muitos anos depois, Stefan Dallongewil (autor e assistente reconhecido do SGDK ) fez a engenharia reversa desse driver de áudio e corrigiu seus erros. Como resultado, agora você pode jogar Street Fighter II com o grito claro "Hadoken!". Aqui está um vídeo onde você pode ouvir a diferença:


Mas vamos voltar ao desenvolvimento de cervejas caseiras e ao amado SGDK. Ele tem a capacidade de selecionar drivers de áudio que podem ser selecionados para se adequar aos requisitos de seu jogo. Por exemplo, existe um driver PCM que permite reproduzir um efeito sonoro por vez em qualidade muito alta (por exemplo, amostras de voz) . Mas há também um driver XGM que pode reproduzir simultaneamente uma faixa de música + 4 efeitos sonoros. O melhor de tudo é que você pode alternar entre drivers de áudio durante o jogo. Por exemplo, em 30 Years of Nintend, as amostras de voz na tela inicial e no final do jogo são reproduzidas pelo driver PCM para alta qualidade. Mas durante o jogo eu precisei tocar vários efeitos sonoros ao mesmo tempo, então usei o driver XGM.

Quanto aos próprios recursos, ferramentas modernas podem ser usadas para criá-los. Como eu disse acima, para efeitos sonoros, você pode simplesmente pegar arquivos .wav, que são automaticamente convertidos no formato desejado. Para música, a ferramenta padrão é o Deflemask - um rastreador que pode criar música para o equipamento de som de vários consoles de 8/16 bits. Não tenho muita experiência em criar música, porque as composições usadas nos meus jogos foram escritas por talentosos artistas de chips: Minerscale (Break An Egg) e Warlord (MeteoRain). Ambos usaram o Deflemask e exportaram suas criações para o formato VGM, que o SGDK pode converter para uso com seus próprios drivers de áudio.

Criar um jogo para Mega Drive / Genesis em 60 minutos? Chamada aceita!

Os congestionamentos de jogos são uma excelente maneira de aplicar suas habilidades de design e desenvolvimento de jogos: quão bom um jogo você pode criar do zero em um tempo limitado (geralmente 48 ou 72 horas)?

Em termos de tempo, o jam mais difícil é o 0h Game Jam . Como o nome indica, ele é realizado todos os anos durante a transição para o inverno. Você começa a criar o jogo às 02:00, na noite do relógio. Depois de trabalhar por 60 minutos, você libera o jogo on-line no exato momento em que o relógio retorna das 03:00 às 02:00. No ano passado, decidi participar dessa jam. Tendo acabado de completar 30 anos de Nintendon't, ganhei alguma experiência na criação de um jogo para Mega Drive / Genesis e fui inspirado pela simplicidade do SGDK. Mas o SGDK pode ser simples o suficiente para que eu possa criar um homebrew de 16 bits em apenas 60 minutos? Aqui está a resposta :


60 minutos de trabalho

Sejamos honestos, o resultado não é absolutamente impressionante. O saldo do jogo é terrível, e há um enorme erro no gerador de números aleatórios, e é por isso que o jogo se torna intransitável após o quinto ovo. Além disso, não há imagem de fundo, som etc.Mas, ainda assim, este é um novo jogo para Mega Drive / Genesis, criado do zero em 60 minutos e lançado em um console real. Não sei como, mas para mim isso já é um tipo de conquista!

Além disso, como a ideia de jogabilidade básica tinha um certo potencial, continuei trabalhando no jogo por muito mais horas. Como resultado, eu tenho um jogo de arcade bastante interessante que você pode jogar aqui . Ele também está disponível no cartucho 30 Years of Nintendon't, juntamente com o terceiro jogo, exclusivo para este lançamento na mídia física - o MeteoRain.


Muitas horas de trabalho extra!

Do homebrew ao indie

Embora o homebrew seja geralmente um nicho para amadores (como eu), hoje alguns consoles são uma plataforma muito comercial para estúdios independentes. Um ótimo exemplo disso são dois jogos lançados recentemente. Por um lado, a Tanglewood foi totalmente desenvolvida em montadoras, como nos anos 90, o que tornou o resultado final ainda mais impressionante. Por outro lado, a igualmente impressionante Xeno Crisis foi desenvolvida com o SGDK e aproveitou ao máximo o conforto e a simplicidade das ferramentas modernas.


Tanglewood (2018)


Xeno Crisis (2019)

Então, se você gosta de jogos retrô, por que não criar seu primeiro jogo Mega Drive / Genesis hoje?

No final, para obter o SGDK, basta seguir o link: https://github.com/Stephane-D/SGDK

Em conclusão

Espero que você tenha gostado deste artigo sobre a criação de três jogos SEGA Mega Drive / Genesis usando tecnologia moderna. Se você quiser jogar meus jogos em seu próprio console ou apenas apoiar meu trabalho, poderá comprar um cartucho em uma linda caixa com o lançamento dos meus jogos pela editora da Cote Gamers: http://cotegamers.com/shop/en/genesis-mega-drive/ 43-test.html

Se você está interessado apenas em uma versão digital (ou seja, ROMs), todos os meus jogos retrô podem ser encontrados aqui: http://drludos.itch.io/

Se você gostou do meu trabalho e pode permitir, em seguida, me apoiar financeiramente no Patreon. Meus jogos geralmente são lançados online como freeware, e alguns deles também são vendidos em cartuchos físicos. Ao me apoiar no Patreon, você também terá acesso às versões beta dos meus jogos, bem como a vários protótipos que eu crio (incluindo projetos abandonados).