Fazendo um jogo SEGA Mega Drive/Genesis em 2019
Hoje em dia, as pessoas ainda criam novos jogos para consoles há muito descontinuados. Chamamos isso de “homebrew”. Às vezes, é uma maneira de realizar um sonho de infância fazendo um jogo para o console que você tinha quando criança. Mas também é um desafio divertido para qualquer designer de jogos ou desenvolvedor de jogos: o hardware retrô vem com muitas restrições que desafiarão sua criatividade. Nos anos 90, essas restrições eram tudo menos dolorosas para os desenvolvedores profissionais. Hoje, como temos ferramentas melhores, fazer jogos para essas máquinas é muito mais acessível.
No ano passado, escrevi um artigo sobre como fazer um jogo para Game Boy. Hoje, vou compartilhar minha experiência de fazer 3 jogos para o console doméstico SEGA Mega Drive/Genesis. Esta é, sem dúvida, a máquina mais fácil de desenvolver um jogo homebrew, graças às poderosas ferramentas que temos agora. Por exemplo, eu até consegui fazer um jogo (bem básico) em 60 minutos, e ele roda no console!
Os jogos
No ano passado, para comemorar os 30 anos do Mega Drive, criei um jogo intitulado “30 Anos de Nintendon’t”. É uma homenagem óbvia aos melhores jogos do console e ao marketing agressivo que a SEGA usou na época (por exemplo, “Genesis faz o que a Nintendon’t.”)
Neste jogo, você joga como um evangelista da SEGA que deve convencer os jogadores a deixar seu NES e SNES porque o Genesis tem jogos melhores! O jogo foi lançado gratuitamente online no aniversário de 30 anos do console, e pode ser jogado aqui: https://drludos.itch.io/30-years-of-nintendont
Desde então, também criei dois (pequenos) jogos de arcade para o console:
Estes 3 jogos estão agora disponíveis em um cartucho publicado pela Cote Gamers:
http://cotegamers.com/shop/en/genesis-mega-drive/43-test.html
Ele vem com uma bela caixa de plástico como os jogos vintages reais, e uma série de cartões postais bônus.
Posso usar Unity, Unreal Engine ou Godot?
Bom, lamento dizer que, infelizmente, esses motores não conseguem exportar jogos para o SEGA Mega Drive/Genesis (ainda?). Mas não tenha medo, existe outra ferramenta que é tão útil quanto aqueles populares motores modernos, ao mesmo tempo em que é feita sob medida para Mega Drive/Genesis: SGDK. É uma estrutura que permite codificar para esta máquina na linguagem C. É muito mais fácil e rápido de aprender do que a linguagem Assembly que era obrigatória nos anos 90. Mas não para por aí. SGDK também vem com várias ferramentas para facilitar a criação de gráficos e sons. Você pode criar seus visuais com seu editor gráfico 2D favorito (do Photoshop ao GIMP e Asesprite) e eles serão convertidos automaticamente, desde que você respeite as limitações de hardware (mais sobre isso mais tarde). O mesmo vale para o som: você pode criar seus efeitos sonoros como arquivos .wav, e para a música você pode usar várias ferramentas de rastreador. Por último, mas não menos importante, o SGDK possui um poderoso “Sprite Engine” que simplificará a maioria das tarefas técnicas para exibir imagens em movimento na tela. Mas quão “fácil” é na realidade? Neste artigo, darei meu feedback pessoal sobre esse ponto.
Aqui vem o processamento de jateamento
Como qualquer programador vintage lhe dirá, escrever um programa em C em vez de Assembly terá um custo no desempenho do seu jogo. E isso é verdade. Mas o custo varia muito de um console retrô para outro. Depende da CPU que eles usam, e também da eficiência dos compiladores modernos que fazem código para esses processadores vintage. Felizmente, o Mega Drive/Genesis usa um processador Motorola 68000, que é bastante adequado para lidar com as particularidades da linguagem C. Isso é especialmente verdadeiro quando comparado a outras CPUs como a 65816 do SNES. Embora seja poderosa por si só, a CPU do SNES tem dificuldade em executar programas escritos em C a uma velocidade razoável. Então, quando se trata de desenvolvimento homebrew em linguagem C, “Blast Processing” não é mais um mito de marketing, mas uma realidade!
Quão rápido seu código C pode ser executado?
Para um exemplo pessoal, aqui está um GIF animado do meu jogo MeteoRain, com 45 sprites de meteoritos se movendo perfeitamente a 60fps:
E aqui está outro exemplo de uma explosão feita com 40 partículas se movendo a 60fps em Break An Egg:
Se olharmos para jogos vintage, um bom exemplo do poder da CPU Mega Drive/Genesis é Contra Hard Corps. Enquanto o jogo foi desenvolvido em Assembly e não em C (era a década de 90), os desenvolvedores foram capazes de usar o enorme poder de processamento para mover um monte de sprites na tela, criando chefes memoráveis com muitas partes móveis e explosões enormes.
Em comparação, Contra III no SNES era limitado pelo poder da CPU e, em vez de mover cargas de sprites, a Konami dependia de efeitos gráficos únicos que apenas o chip de vídeo SNES pode alcançar, como transparência.
Embora ambos os jogos sejam igualmente divertidos de jogar, eles destacam as diferenças técnicas entre o SNES e o Mega Drive/Genesis muito bem. Você pode ler mais detalhes sobre como a Konami adaptou cada jogo para seu respectivo suporte no artigo “Making of Contra III and Hard Corps” da Retro Gamer #176
Limitações gráficas
Como o poder de processamento não é um problema, o principal gargalo do Genesis / Mega Drive para desenvolvedores homebrew são suas limitações gráficas. E, mais especificamente, é o número limitado de cores que pode exibir. Enquanto o console pode gerar 512 cores únicas no total, apenas 64 cores podem estar na tela ao mesmo tempo. Ai. Para comparação, o SNES pode exibir 256 cores ao mesmo tempo de uma paleta de cores exclusiva de 32768. Então, os artistas gráficos tinham que ser muito talentosos para fazer os jogos da SEGA parecerem tão bons quanto seus concorrentes. E em muitas ocasiões o fizeram. Muitos jogos vintage de Mega Drive / Genesis parecem bonitos apesar dessas limitações de cores, como Comix Zone, The Story of Thor, Streets of Rage II, Ranger-X, Gunstar Heroes, Sonic 1-2-3, etc.
Zona Comix (1995)
Mas em outras ocasiões, os jogos de Mega Drive/Genesis pareceriam bastante sem graça em comparação com as versões SNES. Um dos exemplos mais famosos é Street Fighter II’, onde as limitações de cores do console realmente se mostram:
Fazer um bom uso das paletas limitadas disponíveis (4 paletas de 16 cores para o Genesis vs. 16 paletas de 16 cores no SNES) foi um verdadeiro desafio para os desenvolvedores, que geralmente tinham um tempo muito limitado para concluir seus projetos. Hoje em dia, alguns membros talentosos da comunidade SEGA são capazes de consertar alguns jogos para melhorar seu uso de cores. Por exemplo, Gabriel Pyron está fazendo maravilhas em jogos como Castlevania Blood Lines, Golden Axe, Outrun ou o aforementionado Street Fighter II’:
(Linha superior é paleta de cores originais, linha inferior é paleta de cores modificada por Gabriel Pyron)
Com isso em mente, você pode usar seu programa gráfico favorito para fazer suas imagens, desde que você tenha muito cuidado ao escolher cores! Se você não corresponder à paleta de 512 cores real definida no hardware, não é um problema: o SGDK converterá automaticamente sua imagem para a paleta Mega Drive / Genesis. Mas quando se trata do número total de cores usadas e exibidas na tela, você está por conta própria!
Fazendo as coisas se moverem
Para exibir algo na tela, primeiro você tem que copiar os dados gráficos da ROM para a RAM de vídeo. De fato, o processador gráfico não tem acesso direto aos dados da ROM, mas é capaz de ler dados da RAM. Então, para fazer o plano de fundo ou as animações de seus sprites mudar ao longo do tempo, você tem que copiar regularmente novos dados da ROM para a RAM. E a quantidade total de RAM de vídeo (VRAM) disponível é limitada: 64KB. Não é muito em comparação com tamanhos de ROM de jogos que variam de 512KB a 8MB.
Gargalo #1: Transferência de VRAM
Se você está fazendo um jogo muito pequeno com poucos elementos gráficos, você pode simplesmente carregar todos eles na inicialização de uma vez por todas. Mas a maioria dos jogos precisa ter os dados gráficos em VRAM constantemente atualizados para mostrar muitas animações diferentes. E isso geralmente significa muito problema!
Na verdade, a quantidade de dados gráficos que você pode enviar da ROM para a VRAM a cada quadro (ou seja, 60 vezes por segundo) é limitada. Para ser exato, são 7524 bytes por quadro, portanto, cerca de 7KB. Quando você quiser exibir sprites animados enormes, além de fundos animados, como em Street Fighter II’, você vai lutar regularmente com essa limitação. E essa é apenas a primeira questão.
Gargalo #2: Limitações de Sprites
Com consoles de 8/16 bits, outra dificuldade está no número total de sprites que o hardware pode exibir. Normalmente, há dois limites: um para o número total de sprites na tela e outro para o número total de sprites na mesma linha horizontal. Para consoles de 8 bits, como o NES e o Master System, esses limites são severos: não mais do que 8 sprites por linha horizontal e um número total de 64 sprites. Isso significa que podemos exibir 64 vezes Sonic ou Mario na tela? Não, aqui estamos falando de “sprites de hardware”, que são menores do que o que costumamos chamar de sprite. Aqui está um exemplo de Super Mario Bros no NES, onde vários sprites de hardware grandes de 8x8 pixels devem ser usados para exibir um único “Mario sprite”.
(fonte: https://nesdoug.com/2018/09/05/06-sprites/)
Com os consoles de 16 bits, os limites de sprites foram relaxados um pouco. Para o Mega Drive / Genesis, você pode exibir 80 sprites de hardware no total. Mas um único sprite de hardware pode ser tão grande quanto 32x32 pixels (em comparação com 8x8 pixels anteriormente). Aqui estão alguns exemplos de corte “hardware sprite” no Mega Drive / Genesis. Você notou que Sonic é exibido com 2 sprites de hardware apenas, enquanto 8 sprites eram necessários para Mario no NES?
(fonte: https://www.patreon.com/posts/new-resource-and-26847248)
Gargalo #3: Prioridades dos sprites
Como se isso não fosse complexo o suficiente, o Mega Drive/Genesis tem outra especificidade: a cadeia de sprite. Quando dois sprites se sobrepõem, o console precisa saber qual deles exibir em cima do outro. No Master System e na maioria dos consoles Nintendo (NES, Game Boy, SNES), os sprites são definidos em uma grande tabela, e sua ordem na tabela é usada para definir a prioridade de exibição. Não é preciso dizer que é uma ferramenta bastante complexa de usar, pois você tem que redefinir constantemente essa grande tabela para modificar as prioridades do sprite.
No Mega Drive/Genesis, a SEGA utilizou um sistema mais flexível e simples. Como para os outros consoles, todos os sprites têm um número de índice em uma grande tabela, mas ele não é mais usado para definir a prioridade do sprite. Em vez disso, cada sprite contém uma referência ao próximo sprite que será exibido. No final, o console cria uma cadeia de sprites, começando com o sprite 0. Cada sprite só conhece o que vem depois de si. Dessa forma, você pode modificar mais facilmente as prioridades de sprite, sem ter que reordenar todos os seus sprites na grande “tabela de referência de sprite”. Mas, para ser honesto, mesmo que seja mais fácil de usar, ainda é um incômodo quando você está fazendo um jogo onde as prioridades de sprite mudam com frequência, por exemplo, em um beat’em up.
A maneira “fácil”: motor de sprite SGDK
Exibir sprites em movimento e planos de fundo de rolagem com esses gargalos é um grande desafio. Todos os desenvolvedores dos anos 90 lutaram com isso, e muitos desenvolvedores homebrew ainda o fazem. Por exemplo, Matt Philips lançou o brilhante jogo Tanglewood em 2018, que ele criou usando apenas ferramentas dos anos 90. Ele programou o jogo em linguagem Assembly e usou um kit oficial de desenvolvimento de hardware projetado há cerca de 30 anos. Foi uma escolha deliberada em seu final para experimentar plenamente o método de desenvolvimento de jogos vintage.
Mas para pessoas não tão habilidosas nem tão pacientes quanto Matt Philips, as ferramentas modernas esperançosamente diminuirão o incômodo das limitações técnicas de hardware. Já evocamos que a linguagem C costuma ser mais fácil de usar do que a Assembly. Também podemos mencionar que o uso de um emulador de Mega Drive / Genesis altamente preciso, como o Blast’em, em combinação com um Everdrive Flash Cart para testar em hardware real torna o desenvolvimento de um jogo indolor em comparação com o uso de um hardware antigo In-Circuit-Emulator alimentado por um conjunto de ferramentas baseadas em DOS. Mas, mais uma vez, o principal presente que a modernidade traz para a mesa chama-se SGDK.
Coloque seu jogo em um carrinho SD, insira-o em um Mega Everdrive, e você pode testá-lo em hardware real!
De fato, entre todos os outros recursos, o SGDK também vem com um poderoso “Sprite Engine” que tornará sua vida mais simples. É um conjunto de funções para lidar com a exibição de sprites como você faria em uma estrutura moderna. Para começar, você não precisa mais se preocupar com o número de sprites de hardware necessários para cada quadro de animação: o SGDK fará isso automaticamente por você. Então, quando se trata de prioridades de sprite, você não precisa definir manualmente a cadeia de sprite, pois o SGDK fará isso para você usando um valor simples de “prioridade de sprite” que você pode atribuir a cada sprite, como em qualquer estrutura moderna. Por último, mas não menos importante, SGDK também lida com todas as transferências VRAM automaticamente! Sim, você leu certo, com o Sprite Engine você não precisa se importar com a VRAM! Você pode simplesmente dizer ao SGDK para exibir “animação X no sprite Y”, e ele fará todo o trabalho técnico e complexo para você. Se você já teve que lidar com essas coisas manualmente, isso parece mágica, pura e simplesmente!
O recurso Sprite Engine da SGDK por si só é o que torna o Mega Drive / Genesis os consoles retrô mais fáceis de fazer jogos, especialmente se você tiver alguma experiência com estruturas de jogos em plataformas modernas. SGDK é gratuito e de código aberto, mas se você quiser ajudar seu autor Stéphane Dallongeville a continuar fazendo magia retrô, você pode apoiá-lo no Patreon: https://www.patreon.com/SGDK/
Áudio
O áudio em hardware retrô também é um verdadeiro desafio por si só, e cada console é bem diferente nessa área. Para o Mega Drive/Genesis, você tem um processador Z80 dedicado a essa tarefa, pois ele está diretamente conectado ao hardware de áudio. Então, para fazer som e música neste console você primeiro precisa escrever um “driver de áudio”: um programa para o processador Z80. Nos anos 90, cada estúdio de jogos desenvolveu seu próprio driver de áudio e o personalizou para cada jogo. No final da vida comercial do console, alguns drivers padronizados apareceram, como o GEMS da Sega of America, usado em cerca de uma centena de jogos de desenvolvedores ocidentais.
Fazer um bom áudio em consoles de 8/16 bits não é apenas uma questão de habilidades musicais, mas também uma questão de habilidades de programação! Alguns jogos com boa música ou efeitos sonoros foram massacrados por um driver de áudio ruim. O exemplo mais famoso é, mais uma vez, Street Fighter II’. O driver de áudio deste jogo sofre de bugs que distorcem todas as amostras de vozes no jogo. Muitos anos depois, Stéphane Dallongeville (autor do SGDK, ele é um bruxo, lembre-se) fez engenharia reversa deste driver de áudio e corrigiu seus bugs. Como resultado, agora você pode jogar Street Fighter II’ com “Hadoken!”. Aqui está um vídeo onde você pode ouvir a diferença:
Vamos voltar ao desenvolvimento homebrew e ao nosso amado SGDK. Ele vem com uma seleção de vários drivers de áudio, dependendo do que você precisa fazer no jogo. Por exemplo, você tem o driver PCM, que pode reproduzir um único efeito sonoro ao mesmo tempo em alta qualidade (por exemplo, amostras de voz). Mas você também tem o driver XGM, que pode reproduzir uma faixa de música + 4 efeitos sonoros ao mesmo tempo. A melhor característica é que você pode mudar o driver de áudio que você usa durante o jogo, dependendo de suas necessidades. Por exemplo, em 30 Years of Nintendon’t, as amostras de vozes da tela de título e da tela de jogo sobre são reproduzidas usando o driver PCM para maior qualidade. Mas, durante o jogo, como eu precisava ter vários efeitos sonoros tocando ao mesmo tempo, usei o driver XGM.
Em relação aos ativos em si, você pode usar ferramentas modernas para criá-los. Para efeitos sonoros, como mencionei anteriormente, você pode simplesmente usar arquivos .wav que serão convertidos automaticamente no formato certo. Para música, a ferramenta de referência é o Deflemask, um rastreador que pode criar música para o hardware de áudio encontrado em vários consoles de 8/16 bits. Eu não tenho muita experiência para compartilhar com vocês sobre criação musical, pois as músicas que usei para meus jogos vieram de artistas de chiptune extremamente talentosos: Minerscale (Break An Egg) e Warlord (MeteoRain). Ambos usaram Deflemask, e exportaram sua criação para o formato VGM que SGDK pode converter para uso com seus próprios drivers de áudio.
Fazer um jogo Mega Drive/Genesis em 60 minutos? Desafio aceito!
Game Jams são uma excelente maneira de exercitar suas habilidades de design e desenvolvimento de jogos: quão bom um jogo você pode criar do zero em um tempo limitado? (geralmente 48h ou 72h).
Em termos de tempo, a jam mais brutal de sempre é, sem dúvida, a 0h Game Jam. Como o nome indica, ele ocorre durante o Winter Time Shift (Horário de Verão) a cada ano. Você começa a fazer seu jogo às 02:00 durante a noite de mudança de horário. Depois de trabalhar duro por 60 minutos, você libera seu jogo online no exato momento em que seu relógio recua das 03:00 às 02:00. No ano passado, decidi participar dessa geleia. Tendo acabado de completar “30 Years of Nintendon’t” eu já tinha alguma experiência em fazer um jogo Mega Drive/Genesis, e muito apreço pela simplicidade SGDK. Mas será que o SGDK poderia facilitar o suficiente para eu fazer um homebrew de 16 bits em apenas 60 minutos? Aqui está a resposta:
60 minutos de trabalho
Sejamos honestos, o resultado está longe de ser alucinante. O equilíbrio do jogo é horrível e há um enorme bug no gerador aleatório que torna o jogo imbatível após o 5º ovo. Também não há imagem de fundo, nenhum som, etc. Mas é um novo jogo Mega Drive/Genesis, criado do zero em 60 minutos, que roda no console real. Não sei para você, mas para mim já é algum tipo de conquista!
Além disso, como a ideia principal de jogabilidade tinha algum potencial, continuei trabalhando no jogo por muitas mais horas. Eu acabei com um jogo de arcade bastante divertido que você pode jogar aqui. Ele também está disponível no cartucho 30 Years of Nintendon’t ao lado de um terceiro jogo exclusivo para este lançamento físico, MeteoRain.
Muitas horas de trabalho adicional!
Do homebrew ao indie
Embora o homebrew seja geralmente um nicho para amadores (como eu), alguns consoles ainda são uma plataforma comercial viável para estúdios independentes hoje. Dois jogos recentes são um exemplo perfeito disso. Por um lado, Tanglewood foi totalmente desenvolvido em Assembly como nos anos 90, tornando o resultado final ainda mais impressionante. Por outro lado, o igualmente incrível Xeno Crisis foi desenvolvido com SGDK, aproveitando ao máximo o conforto e a facilidade que as ferramentas modernas trazem para a mesa.
Tanglewood (2018) ·
x_eno_ Crise (2019)
Então, se você gosta de jogos retrô, por que não fazer seu primeiro jogo Mega Drive / Genesis hoje?
Afinal, SGDK a apenas um clique de distância: https://github.com/Stephane-D/SGDK
Palavras finais
Em conclusão, espero que tenham gostado deste artigo sobre como fazer 3 jogos para o SEGA Mega Drive/Genesis com a tecnologia de hoje. Se você quiser jogar meus jogos em seu próprio console, ou simplesmente apoiar meu trabalho, você pode comprar uma bela versão de cartucho de caixa dos meus jogos da minha editora Cote Gamers: http://cotegamers.com/shop/en/genesis-mega-drive/43-test.html
Se você está interessado apenas em lançamento digital (ou seja, ROMs), você pode encontrar todos os meus jogos retrô aqui: http://drludos.itch.io/
Se você gosta do meu trabalho e pode pagar, você pode me apoiar financeiramente no Patreon. Meus jogos geralmente acabam sendo lançados como freeware online, enquanto alguns deles também são vendidos em cartuchos reais. Ao me apoiar no Patreon, você também terá acesso exclusivo às versões beta dos meus jogos, e até mesmo aos vários protótipos que crio (incluindo projetos cancelados).
Se você simplesmente quiser ser notificado sobre meus últimos lançamentos de jogos e artigos, você pode se inscrever na minha newsletter. Eu só uso para anunciar lançamentos de jogos e artigos, então exceto cerca de um e-mail a cada 1-2 meses no máximo.