jump to navigation

Os 14 Pecados dos 16-Bits 16 16America/Bahia outubro 16America/Bahia 2017

Posted by bluepasj in GENESISTÓRIAS.
Tags: , , ,
add a comment

Estes são os problemas que um jogo pode apresentar e que, quando graves, denotam um jogo ruim.

1- Resolução
Alguns jogos rodam dentro de janelas. É muito comum em jogos em primeira pessoa, que usam o método raycasting para parecerem 3D. Isso não é tão ruim, já que permitia que esses jogos existissem. Apesar de que achar que esse tipo de jogo não funciona em videogames 16-bits.

92596-zero-tolerance-genesis-screenshot-dead

Note que em Zero Tolerance a imagem fica enquadrada dentro de uma janela, deixando a área a ser processada menor.

Mas a resolução às vezes era um “pecado” de verdade. O SNES quase sempre usava resolução mais baixa nos seus jogos e o Mega Drive quase sempre usava resolução mais alta. Isso por que a resolução baixa prejudica a qualidade de imagem, já que a imagem precisa ser esticada para preencher a tela da televisão. Além disso, perde-se também área de jogo. Earthworm Jim é um jogo feito primeiro para MD e se utiliza da resolução maior. Note que o campo de visão é maior, dá pra ver até a área do cachorro no MD, o que faz com que se tenha mais tempo para reação, por exemplo. No SNES, quase todos os jogos são com zoom por default.

Mas a resolução às vezes era um “pecado” de verdade. O SNES quase sempre usava resolução mais baixa nos seus jogos e o Mega Drive quase sempre usava resolução mais alta. Isso é um pecado por que a resolução baixa prejudica a qualidade de imagem, já que a imagem precisa ser esticada para preencher a tela da televisão. Além disso, perde-se também área de jogo. Earthworm Jim é um jogo feito primeiro para MD e se utiliza da resolução maior. Note que o campo de visão é maior, dá pra ver até a área do cachorro no MD; o que faz com que se tenha mais tempo para reação, por exemplo. No SNES, quase todos os jogos são com zoom por default.

ejim sn md.jpg

A resolução baixa esticada para caber na tela também faz com que os objetos e personagens fiquem esticados, perdendo sua proporção. É normal alguns ports de e para o Super Nintendo terem personagens com aspecto engordado. A imagem do SNES acima (esquerda) seria esticada horizontalmente para preencher a tela da TV, deixando o Jim mais gordinho.

Alguns jogos, também, ao ser portados do SNES para Mega Drive, por questões de praticidade, mantinham a resolução menor que tinham no SNES, jogos como The Great Circus Mystery, por exemplo.

great circus snes md

Esquerda – SNES, direita – MD Note como a resolução é igual, a imagem é quadrada.

Outros chegavam ao ponto de nem esticar a tela no MD e colocar em uma janela, como Zombies Ate My Neighbors. Essa falta de otimização é certamente condenável.

37181-zombies-ate-my-neighbors-genesis-screenshot-starting-the-game

Aqui uma lista dos jogos que usam o modo de menor resolução do MD. Alguns desses ainda usam o modo de alta resolução (320 pixels) para logos, títulos ou cenas.

Também acho que é um pecado, e se relaciona um pouco com isso de ter menor campo de visão, quando o HUD, ou seja coisas como barras de vida, tempo, pontos, essas coisas, ficam em uma janela com fundo escuro. Isso não é bom sinal e, geralmente indica um jogo feito para outro console e mal portado para MD.

Radical_Rex__1994__Activision_thumb.jpg

Olhe a parte superior da tela, a barra vermelha por trás do HUD em Radical Rex. Não acho que seja um jogo ruim ou um port ruim, mas essa barra colorida não é legal e é um problema de falta de otimização do jogo para o console Mega Drive.

2- Excesso de dither

 

Alguns jogos usavam dither (quadradinhos coloridos alternados de tons de cor diferentes) para dar efeitos extras de cor na tela, como o Eternal Champions acima, visto puro na imagem à esquerda (cabo RGB) e com cabo AV na tela da direita. O dither se mistura em sinais com qualidade de imagem ruim, se tornando degradês de cor suaves ou transparências. Mas o dither também é um problema, que faz com que o visual dos jogos não seja tão bom usando cabos com qualidade melhor como, por exemplo, cabos componentes. Eternal Champions é um dos jogos que usa excesso de dither e tem a aparência completamente diferente quando ele fica a mostra. Além disso, dither fica ainda mais a mostra quando as cores que o compõe são muito diferentes. O Mega Drive é mais predisposto a ter problemas com uso do dither, por que ele tem poucas cores nas paletas comparado à concorrência para escolher e pouca quantidade de cores simultâneas na tela também, o que faz com que ele tenha que usar de truques como esse e o modo de constraste do sistema (shadow/highlight), que escurece ou clareia partes específicas da tela. Ele precisa fazer isso não por insuficiência de cores, mas pra poder concorrer com o SNES, que tem muito mais cores que o MD tanto em paletas quanto na tela. Outro motivo para o Mega recorrer ao dither é que o SNES faz alpha blending, ou seja, transparência nativa, mas o MD não faz. A única maneira do MD simular transparência é através do dither ou de shadow/highlight. Claro que até o alpha blending do SNES tem suas limitações, e o Super Nintendo também usa dither e shadow/highlight.

 

Note como, na imagem acima, do jogo The Great Circus Mystery, portado da Capcom do SN para o MD, o Mega (esquerda) usa dither para formar a neblina, enquanto o SN usa transparência.

3- Loadings
SNES--Mickey Mania_Jul10 4_32_20Só pra constar, todos os jogos tem loadings, mesmo jogos em cartucho. Só que o tempo é tão curto, 1 ou 2 segundos, que se torna imperceptível. Não é necessário, por exemplo, uma tela de loading como nos jogos do Playstation 1. Mas alguns cartuchos, especialmente do SNES, tem loading. Mickeymania, por exemplo, tem tela de loading. Acredito que isso se dê pelo processador mais lento do SNES, e por ele tentar ir além do que devia pra competir com um console mais rápido, o Mega Drive.

4- Slowdown
ezgif.com-video-to-gif.gifOu, quando o jogo fica lento, geralmente por que tem muitas coisas na tela. Não é tão comum no Mega Drive, mas acontece. Um bom exemplo é quando Sonic se choca com algum obstáculo ou inimigo e perde as argolas, fazendo com que muitos sprites de argola apareçam na tela rapidamente e o framerate caia por um instante. Não compromete a jogabilidade, mas é slowdown do mesmo jeito. Um subproduto do slowdown é o flickering, quando os sprites começam a ficar invisíveis ou piscar na tela por que sua quantidade extrapola o limite de sprites possíveis por scanline. Isso na verdade é programado no jogo pelos desenvolvedores, para que todos os sprites permaneçam na tela, intercalando-se, ao invés de sumirem completamente.

5- Detecção de colisão ruim
Uma coisa que jogos com sprites e tiles tem que processar é quando um elemento se choca ou toca outro elemento da tela, pra determinar coisas como se alguém tomou dano, por exemplo. Mas às vezes esse sistema é ruim, tornando o ato de jogar o jogo muito irritante. Isso pode ser por que você tem que estar muito próximo de algo para que uma ação funcione, já que o hit box, ou seja, a área em que sua ação pode funcionar, é muito pequeno. Pode ser por que você tem muitos poucos frames, ou seja pouco tempo, para realizar algo. Ou pode ser por que o jogo não foi otimizado o suficiente e às vezes nem percebe que você tentou socar aquele carinha mau. Um bom (por que é ruim) exemplo de colisão ruim é o game Awesome Possum.

6- Delay nos comandos/baixa responsividade
Isso acontece quando, ao apertar um botão no controle, o tempo de resposta, ou seja, o tempo que leva para o personagem realizar uma ação na tela, é muito longo. Isso pode irritar e tornar qualquer jogo uma experiência desagradável. É ainda mais desagradável quando se considera o fato de que controles com fio e TVs de tubo tem menos delay do que os controles sem fio e TVs de LCD/LED atuais. Note que nem sempre delay é algo indesejado, às vezes é parte do sistema de jogo e é fácil perceber isso.

7- Mal uso das paletas
Como eu já disse, o Mega Drive é mais limitado em paletas que seus concorrentes. Mas esse não é um problema para os desenvolvedores que otimizam jogos para o Mega Drive. O problema é que quando o jogo é um port de arcade ou de SNES, é mais barato não otimizar, e lançar só pra fazer uma graninha extra com o jogo. Ainda bem que o MD tem ótimos exclusivos. Claro que problemas com paletas não é algo que só pode acontecer com o MD, mas é algo que acontece com mais frequência. E aí o jogo pode acabar com um visual pior que de um jogo de 8 bits, vide Super Hydlide.

hydlide

NES à esquerda, Mega Drive à direita

Um problema que pode ser causado pelo mal uso da paleta, mas também por outras coisas, é quando você não sabe exatamente o que é interativo e o que não é no cenário. Bons exemplos são os jogos Krusty’s Fun House e Daffy Duck in Hollywood. Os jogos comumente usam uma paleta diferente para elementos que estão apenas no cenário de fundo, geralmente uma paleta mais escura, ou talvez uma arte um pouco diferente. Mas não nesses jogos, e é difícil saber o que pode ou não te machucar ou parar, já que ambos tem a mesma aparência.

Os cuidados com a paleta podem ser observados no sombreamento (uso de diferentes tons de cor para sombrear tiles e sprites) e quantidade de detalhes. Uma coisa que pode ser bastante irritante aos olhos é cores que não harmonizam perto umas das outras, com mudanças bruscas e que ficam desagradáveis. Se você pesquisar pelo círculo cromático na web, vai te ajudar um pouco a entender isso.

Bom sombreamento também significa escurecer nos locais certos, mais naturalmente. Olhe as imagens abaixo:

sor-sor2.jpg

Os gráficos do Streets of Rage 2 (direita) são melhores. Por quê? Seguem alguns detalhes a se notar. As letra Bar e LDevo no primeiro Streets of Rage tem cores sólidas, sem sombreamento ou textura, enquanto as do SoR2 sempre tem algum detalhe pra dar distinção. Além disso, a texturização no prédio do primeiro jogo não é tão boa, consistindo de gradientes de tons de cinza sem muito formato. Enquanto isso, no segundo jogo, é fácil distinguir tijolos de diferentes tipos e tamanhos. O chão de ambos os jogos usa padrões similares, mas o de SOR2 tem iluminação correta nas porções próximas às janelas iluminadas e debaixo dos postes de luz. Os postes de luz também são melhor iluminados no SoR2, com uma luz amarelada na frente onde a luz bate e cor púrpura atrás causada pela luz ambiente; o que contrasta com os postes simples do SoR1. Por fim, olhando para o próprio Axel, o contorno das pernas dele é mais bem definido no segundo jogo, com melhor contraste entre as cores dando volume e textura. O braço e a perna que ficam no interior da tela também são mais escuros que os que ficam no lado exterior, dando ilusão de profundidade. Só há uma coisa que o primeiro fez melhor nessas imagens, que é a definição de músculos.

8- Excesso de bugs
É comum jogos terem bugs. Especialmente quando eram feitos por tão poucas pessoas e em tão pouco tempo, como era comum na época do Mega Drive. Mas, ainda assim, os bugs devem ser raros e não interferir na diversão e na jogabilidade. Back to the Future Part III tem um erro que faz com que ele nunca mostre as paletas corretas!

9- Dificuldade exagerada ou falta de desafio
Muitas pessoas não considerariam algum desses dois um problema. Até por que a maioria dos jogos tem níveis de dificuldade nas opções. Mas é melhor quando um jogo tem equilíbrio em sua dificuldade.

10- Mortes súbitas (erro de design)
Jogos são baseados em interatividade, e interatividade é obviamente baseada em escolha. Mas escolha só é de verdade escolha quando é informada, do contrário é apenas ilusão de escolha. Essa é a minha opinião. E se em um jogo você não sabe que algo vai te levar a morrer, você não pode escolher tentar evitar essa coisa e, nesse caso, sua morte é uma consequência inesperada e indesejada. As consequências das ações nos jogos tem que derivar das escolhas do jogador ou da habilidade que ele tem para realizá-las. Fiquei muito filosófico, mas é a verdade. Seria design ruim se as molas nas quais o Sonic pula jogassem ele em espinhos fora da tela, por que não dá para o jogador prever e planejar sobre algo assim.

taz-mania-mega-drive-morte-subita

11- Animação ruim, com poucos frames
As animações são feitas através de frames de animação, ou poses, assim como em filmes e desenhos animados. Quanto mais frames, mais suave. Quanto menos frame, mais abrupto, quando um personagem pula de uma pose para outra sem algumas animações entre uma e outra. E as animações também influenciam no gameplay, por que é entre o começo e o fim da animação que alguma coisa acontece. Quando você dá um soco, em Street Fighter, entre o começo da animação de soco e o fim dela, a parte do personagem que corresponde ao punho gera dano no oponente caso colida com ele. Quando é um shoryuken, enquanto o personagem está no ar, ele está vulnerável a um ataque. Do mesmo modo, em alguns momentos o personagem ganha invulnerabilidade total ou em alguma parte do corpo. Sonic ganha vulnerabilidade momentânea total quando na animação de perda de anéis. O tempo da animação determina o tempo de resposta que o jogador vai ter e, por isso, é algo muito importante. Claro, então, que animações não podem ser muito grandes, exceto em momentos em que não vai atrapalhar a jogabilidade, como cenas e coisas assim. Animações também ocupam espaço, tanto no cartucho quanto na memória de vídeo do sistema, e por isso precisam ser compactadas. Então há limites para o que pode ser feito. Ainda assim, animações não deviam nunca ser como as do jogo No Escape.

12- Música mal feita
É preciso fazer um bom uso do chip sonoro do console para se ter músicas incríveis como em Streets of Rage e Sonic the Hedgehog, do contrário o jogo pode soar assim:

13- Baixa qualidade de efeitos sonoros, às vezes problema da engine sonora

As versões de Street Fighter II para Mega Drive são infames pelas vozes roucas dos personagens, culpa de uma engine sonora mal programada e mal otimizada para o MD. Acontece que o Mega tem menos canais de voz, especialmente comparado com a concorrência. Inclusive, em alguns jogos, a música ou parte da música pára quando uma voz está acontecendo, pois ambos usam o mesmo componente e não podem funcionar ao mesmo tempo. Mas o Mega Drive pode ter boas vozes e as tem em vários jogos, assim como excelentes efeitos sonoros (sons de pulo, soco, chute…). Uma boa mostra da diferença entre uma boa implementação de sons e uma ruim é com o hack de Street Fighter II feito pelo Stef, que corrigiu a engine sonora do jogo e tirou a rouquidão das vozes.

14- Tiles visíveisbloodlinesscivsuper3
Acontece quando os tiles, os quadrados que compõe a imagem, são muito visíveis, o que deixa os gráficos com um aspecto quadrado. Ambos o Castlevania de Super NES (imagem à esquerda) e o de Mega são culpados disso, o do SNES sendo o maior ofensor. Um bom exemplo disso sendo evitado são as ladeiras dos Sonics. Claro que às vezes um design mais quadrado e reto pode ser o necessário, em áreas industriais ou com design mecânico.

Anúncios

Reconhecendo e Limpando Cartuchos de Mega Drive 6 06America/Bahia outubro 06America/Bahia 2017

Posted by bluepasj in GENESISTÓRIAS.
Tags: , , , , , , , , , , , , , , ,
add a comment

Grande parte dos fãs de Mega Drive são colecionadores, gostamd e ter uma experiência legítima e, por isso, valorizam muito produtos originais e oficiais. Tanto, na verdade, que os preços para cartuchos originais de consoles antigos podem ser bem altos. Por isso, acho necessário e me interessei pelos métodos que os colecionadores usam em seu colecionismo. E do meu interesse veio a necessidade de fazer essa matéria e aumentar a almejada completude do Drive Your Mega. Não sabendo eu mesmo como fazer isso, fui buscar informações na internet para fazer essa postagem, visando ajudar colecionadores (provavelmente vocês já sabem tudo isso entretanto), pretendentes a colecionadores ou simplesmente compradores não querendo ser enganados.

Para começar preciso dizer que é imprescindível abrir o cartucho (se for original, pode ser necessário usar uma chave especial como a Gamebit). A primeira diferença que se vê ao abrir é que cartuchos originais tem um chip, enquanto os cartuchos piratas, muitas vezes, tem apenas um pingo cujo chip é bem pequeno e está debaixo dele. Esse chip grande dos cartuchos originais (e alguns piratas) é onde está a ROM, ou seja, o próprio jogo. Cartuchos originais tem um número serial no chip e a palavra Sega ou o nome do desenvolvedor do jogo. Note, nas imagens abaixo, as diferenças entre piratas, ou alternativos, e originais.

falseorig2 (1)

Acima: pirata; Abaixo: original

Cart2

O cartucho original é o de baixo, escrito “Sega” e não o de cima, escrito “James Pond”. A escrita importante é no chip (preto) e não na placa (verde).

2012-10-09_17-06-21_404.jpg

Traseira de um cartucho japonês

Cartuchos piratas também costumam ser diferentes na cor detrás dos pinos que ficam na parte debaixo da fita. É amarronzada nos jogos originais e geralmente mais pálida nos piratas. Isso, inclusive, ajuda a diferenciar jogos piratas japoneses, já que dá pra ver sem abrir o cartucho e cartuchos japoneses originais tem um selo atrás que talvez você não queira tirar. Outra coisa que vale a pena ser dita é que, por que a qualidade dos componentes é inferior, dá pra ver através da placa (verde) o que está do outro lado, o que não acontece em placas de cartuchos originais.

Pode ajudar também na diferenciação o fato de que na parte detrás das placas, cartuchos piratas podem ter queimaduras onde as soldas são feitas. Fitas originais, por sua vez, não tem nenhuma marca, por serem feitas por máquinas precisas.

Agora algo que pode realmente ajudar a diferenciar é a própria capa, antes mesmo de abrir o cartucho. Primeiramente, às vezes os cartuchos piratas não tem parafusos (sejam eles de metal ou plástico), o que já indica que pelo menos a carcaça não é original, mas ainda assim o que está dentro pode ser original. Mas a carcaça original pode ter se estragado e por isso alguém pode ter colocado o chip original em uma carcaça nova por exemplo. O contrário também pode ocorrer e alguém colocar um cartucho pirata dentro de uma carcaça original, por isso abrir o cartucho é sempre recomendado.

Oringin_05

Traseira de cartucho original Tec Toy.

Cartuchos piratas costumam usar uma carcaça universal que é um pouco maior do que o normal e, por isso, o rótulo fica com espaços nos lados, fica sobrando espaço na indentação. Além disso, na parte detrás da carcaça está escrito o nome do distribuidor. Em cartuchos piratas não tem nada ou o nome está errado. Por fim, a própria arte do rótulo às vezes é diferente da arte que um cartucho normal teria ou menos detalhada.

Observando cuidadosamente carcaça, placa e chip, você consegue aferir se uma fita é original ou não Exceto se o cartucho for reprogramado. Estava fácil demais, não é mesmo? Cartuchos reprogramados, ou repros, são cartuchos originais que alguém pega e apaga o conteúdo do EEPROM (onde fica salvo o jogo, é aquele chip preto) e grava outro jogo no lugar. Você consegue perceber que isso foi feito se digitar o número serial no Google e os resultados indicarem que é o serial de um jogo diferente do que está no cartucho. Repros são tecnicamente piratas, mas mantém a qualidade dos jogos originais já que os materiais são de jogos oficiais.

s-l300E aí está, as maneiras que encontrei na internet de se diferenciar entre fitas alternativas e oficiais. E depois de você fazer tudo isso, você pode querer limpar o cartucho que agora sabe que é (ou que não é) original. Inclusive é indicado limpar antes de colocar no seu aparelho. E nesse caso acho que todo mundo sabe, mas já encontrei pessoas que não sabiam, que assoprar cartuchos não é a melhor maneira. O sopro é úmido e umidade gera ferrugem, portanto acaba sendo prejudicial fazer isso. O que se tem que fazer é limpar usando uma borracha comum, daquelas que se usa em escolas para apagar erros de lápis. Passe ela nos conectores embaixo do cartucho (aqueles cujo fundo é marrom no original). Você pode também limpar a placa usando cotonetes com álcool isopropílico (com porcentagem alta de álcool) ou passando nos contatos/pinos um limpador de contatos  como o Oxicleaner que pode ser encontrado no Mercado Livre. Pode -se usar, também, um spray limpa-contatos (e não precisa nem esperar secar!).

genesisgutsbattery.pngEm último caso, caso o jogo não queira pegar, pode resolver se você tiver uma máquina de solda para eletrônicos e estanho e colocar um pouco de solda em cada uma das conexões na parte traseira da placa. Existe também a possibilidade de trocar os capacitores para tentar trazê-la de volta à vida. Soldar é, também, a maneira correta de trocar a bateria de jogos que tem save e em que a bateria pode ter estragado. Você tira a solda da bateria antiga para poder tirá-la, coloca a nova no lugar tomando cuidado com o lado positivo (+) e negativo da bateria (pode ser necessário cortar um pouco o pino que atravessa o chip para entrar nos buraquinhos) e, do outro lado do chip, solda os pinos da bateria nova no lugar. É até possível trocar a bateria sem perder os saves. Para isso é necessário ter um medidor de voltagem. Na parte detrás do chip perto de onde ficam os conectores da bateria, tem duas conexões por onde passa corrente elétrica da bateria. Se a bateria atual está definhando mas ainda não morreu, você deve conseguir medir voltagem passando por ali. Basta pegar pilhas que se equivalham à voltagem da bateria, usar cabos para conectá-las nessas conexões e soldá-las, trocar a bateria e depois separar a pilha.

Com essas dicas deve ser possível recuperar quaisquer jogos, originais ou não, e também aumentar a vida útil dos mesmos. Sei que são dicas amplamente divulgadas e fáceis de encontrar, mas mesmo assim espero que essa postagem seja útil para alguém em algum momento. Não faz mal ter esse tipo de conteúdo disponibilizado em mais um lugar. Mas esse texto já se estendeu demais, então vou parar por aqui. Ah, se você souber de alguma informação que ficou faltando ou tiver qualquer coisa a adicionar ao que foi discutido aqui, não se acanhe e comente abaixo! Aliás, comente de qualquer jeito. Obrigado pela atenção e volte sempre!

Fontes: This Does Not Compute
Megadriveanos
Megadriveanos
Outros.

Entrevistas – Wolf Team 21 21America/Bahia setembro 21America/Bahia 2017

Posted by bluepasj in GENESISTÓRIAS, Traduções.
Tags: , , , , , , , , ,
2 comments

Essas três entrevistas curtas com a Wolf Team, arranjadas cronologicamente de 1990 a 1991, oferem um olhar às preocupações de uma desenvolvedora 3rd party durante as terras incertas dos 16-bits.
Além de uma breve entrevista focando em Granada, é mais focado na “indústria”.
Essas entrevistas foram encontradas no GSLA, um site japonês que preserva entrevistas com desenvolvedores de jogos de agora defuntas fontes impressas. A GSLA costuma redatar as questões originais do entrevistador, então o texto lê mais como narrativa do que entrevista.

DESENVOLVIMENTO NO MEGADRIVE E NO X68000 – 1990

Decidimos adentrar no desenvolvimento para Mega Drive verão passado (1989). Tínhamos um interesse em sistemas de console como o Nintendinho, o PC Engine e outros, mas o Mega Drive tinha a maior quantidade de memória disponível, o que combinava bem com o estilo de nossos jogos. Pegar hardware limitado e fazer o melhor possível dentro dos limites não é nosso estilo de design de jogos; queremos fazer coisas que fazem os jogadores dizerem “uau”. Por isso, o tamanho da memória foi um fator decisivo.

Quando o Mega Drive saiu, não estavamos realmente pensando tão seriamente em desenvolver para ele. Mas o hardware e o design do controle mudaram um pouco, e ele tem a mesma CPU que o X68000, fazendo ports de arcade fáceis. Então achei que o futuro reservava coisas excitantes para nós e o Mega Drive.

A base de usuários do Nintendinho é principalmente de crianças abaixo da idade de colégio. Acho que o Mega Drive definitivamente tem apelo com um grupo mais velho, crianças colegiais e acima. Isso é apenas especulação no momento, entretanto, eu não tenho estatísticas detalhadas disso ainda.

Em cima Final Zone PC-88 Embaixo Final Zone Senki Axis (x68k)

Em cima Final Zone PC-88 Embaixo Final Zone

Nosso primeiro jogo de Mega Drive vai ser um port de Final Zone II, que estamos lançando também para PC Engine, mas a versão do Mega Drive vai ter um visual muito diferente e possivelmente outro título. Não parece nem um pouco com a versão PC-88. Mas para o seu tempo, as cores do Final Zone de PC-88 foram revolucionárias, e da mesma maneira, planejamos incorporar novas ideias revolucionárias na versão MD.

Como você sabe, o X68000 e o Mega Drive tem especificações similares, então é fácil portar do X68000 para o Mega Drive. Entretanto, isso significa que podemos portar do Mega Drive para o X68000 também. Ao invés de “port”, acho que é mais correto dizer que estamos criando um jogo de X68000 no estilo de um de Mega Drive e vice-versa.

Para jogos nós desenvoilvemos em disquete, comprimimos para caber em uma ROM de Mega Drive. Temos que fazer tudo parecer tão bom quanto possível dentro desse espaço limitado de memória, então gastamos muito tempo nesse aspecto em nossos jogos. Nosso grupo de desenvolvimento no Mega Drive atual consiste de 4-5 pessoas, mas até a primavera planejamos expandir para três grupos. No total temos aproximadamente 35 funcionários de desenvolvimento. Perto da metade vai acabar trabalhando no Mega Drive. Nós também queremos continuar fazendo jogos de PC. Esse ano queremos focar em criar jogos de simulação, certos de atrair jogadores adultos com 20, 30 anos.

Para os periféricos do Mega Drive, estamos interessados no drive de disquete já que queremos fazer jogos com mais memória. Não pensamos muito nos outros periféricos.

Sobre o Super Nintendo, a Nintendo nunca pediu nossa companhia para desenvolver para ele. (risos) Mas já que a maioria das pessoas tem 2 ou 3 consoles, não vemos isso como um problema tão grande. Da nossa perspectiva como desenvolvedores, o Mega Drive tem o mérito da facilidade se fazer ports para ele, e com o Mega Drive podemos atender mais prontamente às demandas de nossos fãs que querem jogar jogos dos fliperamas em casa.

Muitos dos jogos da Wolf Tem tem sido visualmente impressionantes. Temos muita confiança na nossa habilidade de fazer jogos divertidos com locações e mundos detalhados. Além disso, acho que recentemente atingimos um nível alto de qualidade substancial em nossos jogos também. Acho que estamos nos movendo na direção certa como uma companhia, e vamos continuar a mirar em fazer jogos que orgulhosamente mostram sua originalidade.

Namco's Assault (E) e Grobda (D), dois grandes influências em Granada

Namco’s Assault (E) e Grobda (D), duas grandes influências em Granada

GRANADA – ENTREVISTA COM DESENVOLVEDORES EM 1990

Kazuyoshi Inoue – Planejamento
Toshio Toyota – Programação Principal
Masahiro Akishino – Produtor
Masaaki Uno – Som

-Qual você diria que é o apelo de Granada?
Toyota: O que vende Granada? Eu diria que são todas as frentes: gráficos, som, e algoritmos de inimigos extensivos. Você pode pegar qualquer sprite grande de personagem de qualquer fase – revisamos eles de novo e de novo, só usando aqueles que finalmente nos satisfizeram.

-Quais são algumas das influências de Granada?
Inoue: O Toyota é, por natureza, um grande fã de jogos de arcado, então pode haver partes em Granada que inconscientemente refletem essa influência. Granada em si é (Assault + Grobda) ÷ 2, certo? (risos)

-Quanto tempo Granada levou para ser concluído e quais foram alguns dos desafios que vocês enfrentaram?
Toyota: Se você incluir o trabalho que fiz no meu próprio tempo livre, Granada levou aproximadamente dois anos. Comparado com minhas versões prévias, o produto final é uma ordem de magnitude mais polido.
Akishino: Até agora, a maneira que procedemos em nossa produção de jogos é primeiro criarmos uma história, e depois fazer a estrutura do jogo combinar. Graças a isso, nossos jogos sempre tinham seções mal balanceadas. Desta vez, com Granada, criamos a jogabilidade primeiro e fizemos a história depois. Talvez isso signifique que Granada tem uma história mais fraca que nossos jogos anteriores, mas na mesma medida, a ação tem importância muito maior.

-Entendo que Granada em sua totalidade usa MIDI.
Uno: Sim. Acerca dos recursos MIDI, tecnicamente é algo que tivemos em nossos jogos desde a versão PC-98 de Zan-kagerou no Toki – lançado ano passado, mas não era feito plenamente. Com Granada finalmente conseguimos uma implementação digna de MIDI. Não simplesmente usamos remendos Roland MT-32, mas verdadeiramente editamos eles para criar nossos próprios sons. Isso pode ser inédito nessa indústria. Além disso, se existe algum usuário por aí que quer que implementemos funcionalidades KORG M1 em Granada, queremos ouvir de vocês. Isso é algo que talvez possamos vender a nossos consumidores através do correio.

-Por favor nos diga o que o futuro reserva para a Wolf Team.
Akishino: Vamos colocar todo nosso esforço na própria jogabilidade, ao invés da história, para nossos futuros jogos. Apesar de ser um passo atrás em termos de história, vai ser dois passos a frente para a jogabilidade.

WOLF TEAM – ENTREVISTA COM DESENVOLVEDORES EM 1991

Masahiro Akino – Time de desenvolvedores #2, chefe de seção
Masaaki Uno – Time de desenvolvedores #2, assistente diretor de P&D

-Por favor nos fale do seu novo jogo, El Viento.
Uno: El Viento foi criado pela mesma equipe que fez Granada. Graças a eles conseguimos carregar a experiência técnica daquele jogo. As cenas em quadrinhos são outro recurso. Usar anime em nossos jogos tem sido nossa especialidade por algum tempo já.
Akishino: As explosões são realmente impressionantes e chamativas. Se você conseguir memorizar o tempo para desviar das balas, entretanto, não acho que será um jogo tão difícil.
Uno: El Viento tem uma mulher como protagonista, e o próximo jogo na série, Earnest Evans, vai ter um homem… para o terceiro jogo, estamos pensando que será uma história derivada, com um protagonista totalmente diferente?

-Quais são as vantagens de desenvolver para CD-ROM?
Akishino: Jogos em CD-ROM nos permitem realmente nos aprofundarmos na história e cenas. Previamente tínhamos uma memória limitada, mas agora podemos praticamente ignorar essas limitações, e toda uma nova variedade de estrutura de jogo está aberta a nós. É muito legal.

Uma cena em anime de El Viento
Uno: Um grande mérito dos CD-ROMs é que diminui o tempo de produção. Além disso, CD-ROMs são mais baratos se comparados a memória ROM, então o preço de venda de nossos jogos pode refletir o custo mais barato dos materiais. Com o jogo “Annette Evans” que estamos fazendo agora, incluir a funcionalidade de zoom nos sprites em ROM acabaria custando mais de 10000 ienes em venda. Conseguir lançar o mesmo jogo por 8000, 7000 ou 6000 ienes é uma das vantagens do formato CD, eu diria.
Akishino: Basicamente, daqui pra frente não mais faremos jogos baseados em ROM (cartuchos). Planejamos mudar totalmente para o CD-ROM. Estamos esperançosos que conseguiremos fazer muitas coisas no Sega-CDS que não pudemos fazer nos computadores.
Escalar sprites e dar zoom tem sido difícil, mesmo no Sega CD. Atualmente tivemos que adicionar suporte a isso no software, tem sido difícil. Se estivéssemos usando apenas uma CPU, isso é uma coisa, mas há dois CPUs 68000, e se você adicionar o z80 são 3. Porém há muito potencial aqui. Não pudemos realmente começar a usar funções de escala e zoom até nosso quarto jogo de Sega CD, Aisle Road.

-Quais são seus planos futuros?
Uno: Queremos atingir a mais ampla variedade de idades possível entre os usuários de Mega Drive. É difícil mirar em grupos de tenra idade.
Akishino: Nosso port de Mega Drive do shmup Sol-Feace deve ser igual senão exceder a versão X68000. Os sprites vão todos ficar um pouco maiores no Mega Drive. Acho que vão ficar bonitos. Esperançosamente poderemos também vender por um preço bem baixo.
Sobre Fhey Area, estamos trabalhando cuidadosamente nele. É um jogo com visão superior, mas sinto que o design de personagens ainda está um pouco fraco. Porém vai ser um jogo divertido.

Fonte: Shmuplations

Entrevista – Kid Chameleon 28 28America/Bahia maio 28America/Bahia 2017

Posted by bluepasj in GENESISTÓRIAS, Traduções.
Tags: , ,
add a comment

 

khameleon“Kid Chameleon tinha apenas começado quando cheguei lá (na Sega)”, explica Steve Woita, responsável por muito da programação do jogo e design dos chefes. “Um programador saiu e o Mark (Cerny, chefe do Sega Technical Institute) me contratou. Aceitei e todos nos juntamos e pensamos no que poderíamos fazer com isso”. O desenvolvimento do jogo foi feito no Amiga e isso levou um tempo para se acostumar. “Em qualquer outro lugar essas coisas eram feitas em PCs, então, quando cheguei na Sega, fiquei tipo ‘O que há com esses Amigas?’. Tínhamos que nos acostumar às idiossincrasias do Amiga, como tudo funcionava e as ferramentas proprietárias, então trabalhávamos com um dos designers no que queríamos”.

“Por que ele tinha tantos capacetes, muitos dos testes eram para assegurar que, dependendo do elmo que ele usasse, não quebraria o jogo. Era como testar oito personagens diferentes com atributos diferentes”, diz ele ainda..

khameleinic

O vasto número de blocos era um grande trabalho pelo qual Steve foi o único responsável. “Eu programei todos os blocos e coisas assim – quando você acerta um bloco e estilhaços voam, como os blocos se movem e quão longe você podia pular de um bloco de borracha. Você tinha que acertar o máximo possível. Muitos desses eram efeitos visuais, mas alguns causaram deslocamento em onde o personagem deveria estar então isso tinha que ser feito o mais rápido possível para que pudesse ser feito e refeito depois caso eu mudasse os valores em como os blocos de borracha funcionavam ou coisa assim. Haviam testes constantes no jogo, mas a gente tinha um bom departamento de testes que nos reportava coisas. Sempre tentamos manter o jogo funcionando com o maior framerate possível, houve momentos em que tive que me assegurar de cortar coisas no momento exato para que não continuasse sendo processado. Acerte um bloco, estilhaços estão voando; acerte outro bloco, estilhaços estão voando enquanto os antigos ainda estão lá. Eu tinha que ter certeza de que eles passassem sobre os estilhaços antigos e não junto à tela. Eu tinha que reutilizar um pouco de estilhaços, mas se os usasse muito cedo iria ficar louco na tela, então como o jogo prosseguia, havia muito de copiar daqui e colar ali”.

khamaeleaeon

Com 103 fases, Kid Chameleon não é fácil de ser finalizado. “Não incluímos um sistema de save lá atrás – decisão minha – já que salvar naquela época requeria uma bateria dentro do cartucho,” explica Steve. “Tentamos estrutura-lo para que não fosse necessário por uma bateria, mas ele se tornou tão grande e longo que precisava de algum tipo de mecanismo de salvamento. Foi meio que engraçado ouvir histórias de pessoas deixando o jogo ligado por três dias seguidos”. Quando questionado se implementar um sistema de save teria sido uma boa ideia, Steve não está convencido. “Achei que você tinha que terminar em uma sessão por que sou um desses puristas. Se você volta, é como se estivesse ouvindo metade de uma canção. Eu tinha um certo jeito de pensar sobre como eu queria que a experiência fosse”.

Apesar de haver uma bíblia de personagens feita por Broderick Macaraeng que manteve o design geral sob controle, muito da criação era flexível e desenvolvida no momento.

“Do meu lado eu teria uma ideia para um chefe. O Shishkaboss foi o primeiro que eu fiz – o cara de três cabeças com uma flecha nele – e basicamente o desenhei em um pedaço de papel com três círculos e uma flecha trespassando, coloquei uns olhos, e fui ao artista dizer: ‘Isso é o que eu quero. É um chefe com três cabeças; você tem que pular nele três vezes e então o olho salta da primeira e então a segunda e então a terceira, e tudo quebra’. Ele só pegou daí e criou esse modelo bacana em 2D, ele tinha um brinco parecido ao Mr. T. Era assim que eu trabalhava: eu criava uma ideia, ia com um esboço, pegava a arte final, em pouco mais de um dia refinava e bum! Se você tem energia para a ideia, não demora até que a veja na tela”.

Mesmo uma ideia sutil, como reflexos na água, foi adicionada. “Onde vivíamos na Califórnia há uma autoestrada chamada 280 e um reservatório chamado Crystal Springs”, se lembra Steve. “Quando eu estava dirigindo para o trabalho, percebi a maneira em que as árvores refletem na água – não estávamos fazendo aquilo no jogo. Eu falei com a artista e disse: ‘Quando estou dirigindo por Crystal Springs percebo a reflexão e as colinas são similares em Kid Chameleon. Podemos refletir na água?’. Então ela e outro programador, Bill Willis, fizeram isso acontecer”.

Como Steve tinha uma paixão por chefes, ele fez o design de muitos deles. “Uma fase era em uma cidade e eu estava pensando em Nova York, e eles tem excelentes bagels lá. Eu reutilizei cabeças do Shishkaboss e renomeei para os Irmãos Bagel ou algo assim”. O chefe final também foi uma criação do Woita, e um código de trapaça sem querer apontou para isso: “Ninguém foi creditado por essas coisas, e em jogos japoneses os créditos só acontecem no final, era assim que ia acontecer em Kid Chameleon. Então dissemos, ‘Vamos fazer com que você possa trapacear para chegar à última fase’, que era o final com os créditos. Então fizemos isso e estávamos ficando prontos para finalizar o jogo quando um dos outros designers adicionou outra fase ao jogo. Na verdade isso puxou tudo, então o código de trapaça agora apontava para meu chefe logo antes dos créditos, pareceu que eu estava fazendo ele apontar para uma fase na qual trabalhei. Mark Cerny perguntou, ‘Você sabe algo sobre a habilidade de trapacear para chegar aqui?’ e eu fiquei tipo, ‘Não’. Não planejamos isso dessa forma, não checamos para ter certeza, eu devia ter feito isso com quatro ou cinco outros designers de fases, mas como estava apontando para a tela errada, eu que fiquei como o cara mau”.

O fim tem uma conexão pessoal a Steve. “Você tem meu nome debaixo do Kid Chameleon, mas você não vê a cara dele, então perguntei: ‘Por que você me colocou como o Kid Chameleon?’. Rick disse, ‘Você parece mais com ele’, mas eu pensei ‘Onde está minha cara?’ e ele respondeu: ‘Eu na verdade não sei como te caracterizar’, e eu fiquei tipo ‘O que isso significa?’. Então ao fim do jogo você só vê as costas do Kid. Foi meio que divertido”.

khamelonicUm dos momentos mais memoráveis do Steve na Sega envolveu um encontro com Yuji Naka. “Eu encontrei o Naka primeiro em uma pizzaria, ele estava nos seguindo, sem ter certeza de para onde iríamos. Seu inglês era bastante bom e estávamos apenas conversando comendo pizza, ele é um cara muito legal. Eu me lembro de um encontro no escritório no Sega Technical Institute às 9 horas, em que o Naka estava parado em volta da mesa e tínhamos que contar uma história por alguns minutos, como uma boa maneira de conhecer todo mundo. Eu nunca vi isso antes ou depois em nenhuma outra empresa”.

Apesar de desenvolvido por um time pequeno, Kid Chameleon foi bem recebido pelos jogadores e a Sega parecia feliz com o produto final. “Eles produziram um comercial antes do natal,” diz Steve, “nós vimos o comercial na TV e ficamos tipo, ‘Uau, algo em que trabalhamos está na TV’. Eles devem ter tido alguma fé, já que publicidade custava muito dinheiro naquela época, e houve muita propaganda impressa”.

Infelizmente, apesar do time querer trabalhar em uma continuação, não aconteceu. “Estávamos prontos para vir com todas essas novas ideias para a próxima versão, que não pudemos colocar no primeiro jogo”, lembra Steve. “Eu queria colocar mais chefes. Eu estava realmente invocado com os chefes ao invés de simplesmente muitas fases. Eu queria focar em uma pequena coisa no mundo onde você tem que descobrir como derrotar essa criatura. Mas eles não queria fazer uma continuação, então não a fizemos”.

khameleonin

Fonte: Revista Retro Gamer,
n.º 96.

Mega Drive vs PCs da Época 24 24America/Bahia abril 24America/Bahia 2017

Posted by bluepasj in DUALIDADE, GENESISTÓRIAS, INUTILIDADES.
Tags: , , , , , , , , , , , , ,
add a comment

É uma curiosidade comum das pessoas saberem como os consoles caseiros de videogame de cada época se comparam aos PCs equivalentes. Sei lá, me bateu essa curiosidade, então decidi pegar umas imagens no MobyGames comparar. Até por que eu nasci no mesmo ano que o Mega, não posso dizer que vivi a época e definitivamente eu não tive um PC até muito tempo depois. Mas aos que viveram… e aos que não viveram também… aproveitem. Lembrando que as imagens do Mega Drive em todas as comparações são as da direita (->).

old pcs

Sharp X68000

O X68000 foi lançado em 87, um ano antes do lançamento japonês do Mega Drive. Como se pode ver, ele compara positivamente ao MD e é de fato mais poderoso. E um dos mais caros também. O processador dele é um da Hitachi baseado no Motorolla 68000. Inclusive uma versão dele teve o Motorolla propriamente dito, o mesmo processador do MD. Inclusive os produtores de Thunder Force II, em entrevista que até já publiquei aqui no DYM, disseram que um dos motivos para decidirem fazer jogos para MD é que faziam jogos para o X68000 e seria uma transição fácil pois “o X68000 compartilha a mesma CPU e chip de som FM do Mega Drive”. md-68000- 2md-68000

Fujitsu FM Towns

Nascido em 89, era um PC japonês. Também é um dos PCs mais potentes de sua época e segundo o site Giantbomb apenas o X68000 rivalizava.

md-fmtowns

PC-98

Vários PCs japoneses da série PC98000 foram lançados pela NEC de 1982 até o ano 2000.

md-pc98

Windows 3X

3X é a designação dada ao sistema operacional Windows 3.0 e seu sucessor Windows 3.1X. O Windows 3 foi a primeira versão do Windows a fazer sucesso.

md-win3x

PC Amiga

Linha de PCs da Commodore lançada de 1985 a 1994.

md - amiga

Amstrad CPC

Sendo um pouco defasado já à época do MD, é um 8-bit lançado em 1984 e descontinuado em 1990. Mas teve ports de alguns jogos que também estiveram no MD, como se vê abaixo.

md - amstradcpc

Apple II

Lançado em 1977, tendo várias revisões posteriores (como Apple II Plus, Apple IIe e Apple IIGS).

md - appleii

Atari ST

Linha de PCs 16-bits lançada em 1985, o primeiro teve como processador o Motorolla 68000.

md - atarist

Commodore 64

O 8-bits C64 foi lançado em 82 e fez muito sucesso nos anos 80.

md - commodore

Macintosh

Feitos pela Apple, o primeiro Macintosh foi lançado em 84.

md - macintosh

ZX Spectrum

O Sinclair ZX Spectrum foi um 8-bits lançado em 1982 no Reino Unido.

md - zxspectrum

DOS

Sistema operacional bastante popular antes do advento do Windows.

md-dos

Entrevista – Alisia Dragoon 19 19America/Bahia abril 19America/Bahia 2017

Posted by bluepasj in GENESISTÓRIAS, Traduções.
Tags: , , , ,
add a comment

AlisiaEsta pequena entrevista sobre Alisia Dragoon apareceu na revista BEEP Megadrive e apresenta membros de ambas Gainax e Game Arts. Ela apresenta uma imagem bem diferente da Game Arts que um dia seria conhecida pela série Grandia; em muitas maneiras, foi o último momento do desenvolvimento da primeira série de ação da Game Arts, Thexder (note o envolvimento do co-criador de Thexder/Fire Hawk, Satoshi Uesaka).
A entrevista também foca fortemente nas novas ferramentas de edição de mapas e sprites da Game Arts, “KETCHUP” e “DARI”. Incluí muitas imagens que oferecem mais insight em ambos o desenvolvimento de Alisia Dragoon especificamente e o ambiente de trabalho na Game Arts em 1992

Hajime Satou – Monstros/ Designer de fundos
Satoshi Uesaka – Supervisor (não-creditado)
Yoshimi Kanda – Design de jogo e locações.

– Kanda, qual foi seu papel no desenvolvimento de Alisia Dragoon?

Kanda: Reclamador chefe. (risos) Só brincando. Eu ajudei no projeto de jogo. Originalmente a Game Arts veio a nós perguntar sobre trabalharmos juntos em um port para Mega Drive do jogo Fire Hawk. Desde então venho pensando muito sobre que tipo de jogo os jogadores gostam.

– Você pode nos dar mais especificidades sobre seu envolvimento?

Kanda: Minha companhia Gainax é um estúdio de animação, e já que os demográficos de fãs de anime e de jogos se sobrepõem, me pediram que analisasse que tipo de coisas usuários gostariam de ser em um jogo.

– Foi assim que você criou o tema de fantasia de Alisia Dragoon?

Kanda: Eu teria que dizer que o tema fantástico veio depois, na verdade. Nossa primeira ideia era ver se podíamos de alguma maneira combinar Fire Hawk com elementos de RPG. A diversão nos RPGs é encontrada no combate e solução de puzzles, mas diferentemente dos shmups, não há necessidade de começar de novo ou resetar se você tem um mau momento. Quando você está jogando um jogo de tiro e alcança poder total, apenas para perder tudo em um instante… é extremamente frustrante. Queríamos tentar remover essa experiência.

alisia033

Yoshimi Kanda (esquerda) e Hajime Satou (direita). O texto para o Kanda lê: “Trabalha para a Gainax. Designer de jogo de Alisia Dragoon. Famoso para muitos por seu trabalho em jogos (Den’nou Gakuen) e anime (Wings of Honneamise e Nadia: Secret of Blue Water)”. O texto para Satou lê: “Originalmente trabalhava como ilustrador. Ele ajudou com o design de ítens de Dragon Quest IV. Para ver suas habilidades como ilustrador, ele recomenda suas ilustrações para o livro Genjuu Dragon”.

– É daí que veio a ideia para os Monstros Opcionais, que podem subir de nível como em um RPG?

Kanda: Sim. Enquanto nossas discussões progrediam, percebemos que se esse é um jogo de tiro, temos que ter opções! Mas opções tradicionais do estilo Gradius realmente nos impediam de usar robôs no ambiente… Em algum momento, alguém veio com a imagem de uma garota liderando um bando de bestas esquisitas em batalha, e todos nós pensamos que era um ideia muito legal, e o jogo gradualmente se tornou no jogo de fantasia que é hoje.

– E sobre a história e ambientação?

Uesaka: A história básica foi criada por nós da Game Arts. Mas também adicionamos muitos detalhes aqui e ali. Por exemplo, na fase 3 quando a aeronave gigante aparece, achamos que seria entediante se fosse uma nave comum, então transformamos ema em uma criatura viva gigante.

Kanda: Isso é verdade para ambos animes e mangás, mas acho que jogos também, muitas das melhores ideias já foram exauridas e usadas. Não é mais tanto sobre criar algo totalmente novo, mas sim como artisticamente e criativamente combinar elementos existentes em algo novo.

Sendo assim, acho que não há nada verdadeiramente original em Alisia Dragoon. Entretanto, trabalhamos agressivamente para remover quaisquer elementos que pudessem fazer dele um jogo ruim. Isso foi de primeira importância.

– Quais foram alguns dos desafios que vocês encontraram em criar o mundo e locação de Alisia Dragoon?

 

alisia02

Essa tela (cortada do jogo final) mostra que Alisia Dragoon originalmente tinha um sistema de password e 4 outros Monstros Opcionais.

Kanda: Algo que aprendi durante este desenvolvimento é que mundos em jogos são muito únicos. Pegue como exemplo um jogo de ação: além de terrenos e paisagens normais, você também tem os típicos cenários de gelo, lava e espaço. E você tem que adicionar acentos e nuances por que é um jogo em volta do qual você projeta o mundo. Então eu fiz o melhor para criar um ambiente para Alisia Dragoon que se curvou em algumas instâncias aos desejos do jogo.

 

– Imagino que seja difícil criar um jogo que realmente capture e melhore a história inicial que você criou.

Kanda: Quer dizer, ultimamente, as histórias de jogos de ação e tiro não realmente fazem sentido, certo? Não acho que alguém se senta com um manual de instruções, lendo a história, se imergindo no mundo e mitologia, e então dizendo “ok, agora estou pronto para jogar!”. Minha opinião pessoal é de que a história é mais para dar aos criadores alguns limites e direção, e ajudar a unificar o design geral do jogo.

-Entendo que há muitos estágios diferentes em Alisia Dragoon?

Kanda: Há 13 no total, e sim, você visita uma porção de áreas diferentes. O formato foi decidido inicialmente pela Game Arts, mas então trabalhamos juntos para completar e adicionar nuance em cada fase. Por exemplo, quando a nave aparece e bate na lateral da montanha, sugerimos que a fase deveria ser orientada diagonalmente (e de ponta-cabeça!). Basicamente, tentamos dar muita atenção aos pequenos detalhes. E somos muito cuidadosos para não deixar as coisas ficarem monótonas.

– Satou, pelo que entendo você trabalhou nos monstros e designes de background.

Satou: Isso está correto.

Uesaka: Ele também criou a arte para a parede de fundo na cena de abertura, a tela de seleção de Monstro Opcional, e projetou o layout básico da tela de jogo. Um pouco disso, um pouco daquilo… continuamos dando mais e mais para ele fazer!

Satou: Hah! Contanto que seja trabalho interessante, não me importo.

alisia08

Essa imagem mostra o software interno da Game Arts, “KETCHUP”. Também foi usado para edição de mapas detalhados, mas também (como mostrado nas duas imagens inferiores) para rapidamente definir padrões de movimento dos inimigos. O algoritmo que define curvas de um punhado de pontos é promovido aqui.

– Você originalmente era um ilustrador, certo?

Satou: Sim, fui uma das pessoas que sonhou em ser artista de mangá. Mas, eh, acho que jogos acabaram sendo mais interessantes para mim.

– Como foi seu trabalho em Alisia Dragoon?

Satou: Meu primeiro passo sempre era me consultar com Uesaka, então fazer algum progresso, consultar com ele de novo… e assim em diante.

– Pegue um mapa de fundo, por exemplo: como era seu processo de design?

Satou: Primeiro eu escrevia um rascunho do que acho que uma fase seria. Então eu o levava à Gainax, e então nós discutíamos, eu desenhava um esboço básico, “oh, algo assim, você quer dizer?”. Depois disso eu começava a criar os fundos, expandindo eles com detalhes extras no processo.

– Como era o processo de design de personagens?

Satou: Para sprites realmente grandes, tudo tinha que ser baseado na arte conceitual inicial que eu tinha desenhado. Mas para personagens pequenos, primeiro tínhamos que decidir como eles iriam se mover e agir, e então eu me assegurava que a arte combinava.

– O que você mais achou desafiador nesse trabalho?

Uesaka: Em nossos primeiros encontros, haviam ideias criativas e interessantes voando para lá e para cá entre nós, mas quando chegava a parte de incorporarmos elas no jogo de verdade, tínhamos que limitar ao que era possível e o que não era.

– Todos esses encontros devem ter levado muito tempo!

Satou: Nos encontrávamos quase toda semana. Começando no último outono e passando pelo inverno, tínhamos encontros duas vezes por semana.

Uesaka: Satou foi de grande ajuda durante os encontros, compartilhando suas opiniões sobre as ideias que os outros traziam: “vamos fazer isso” ou “vamos tentar dessa maneira”.

Satou: Com tantas fases e inimigos, as coisas eventualmente começaram a sentir muito iguais. Evitar isso foi um desafio.

alisia10

Essas imagens mostra o DARI, o editor de personagens proprietário da Game Arts. A Game Arts alega que desenvolveu esses editores para Alisia Dragoon e pretendia usá-los para incrementar a velocidade do desenvolvimento de futuros jogos de Mega Drive e X68000. É incerto se eles foram usados novamente, apesar de que a série Lunar é uma possibilidade.

– Você sabe quantos monstros diferentes havia, no total?

Uesaka: Se você incluir os Monstros Opcionais, havia aproximadamente 70 tipos diferentes.

– Quão grande é a diferença entre a arte conceitual e a arte em pixel?

Satou: A pessoa que realmente renderizou as artes conceituais em arte em pixels fez um ótimo trabalho, então não, não noto nenhum problema.

Uesaka: Antes de começarmos o processo de arte em pixel, trabalhamos muito com os designs para nos assegurarmos de que eles funcionariam como sprites, então quanto finalmente chegamos nesse estágio não houve muitos problemas. Sim, nós tivemos alguns problemas com as cores desta vez, entretanto. Queríamos adicionar um pouco mais de sombreamento, por exemplo.

– Quanto tempo foi gasto criando cada inimigo?

Satou: Hmm… acho que consegui criar mais ou menos 3 por dia. O chefe final, entretanto, levou umas três semanas inteiras para fazer.

– Por favor, deem uma mensagem final aos leitores.

Kanda: A maneira em que fizemos esse jogo era pensando em todas as coisas que nos incomodavam em jogos diferentes que jogamos, e então tentar remover ou eliminar essas coisas uma a uma. Acho que esse é o maior destaque de Alisia Dragoon. Tenho esperança de que os jogadores não vão passar correndo pelo jogo para o fim dele, mas vão gastar tempo e aproveitar a atmosfera do mundo e a arte e os gráficos também.

alisia09

(E) Programador principal Naozumi Honma e (D) Programador assistente Osamu Harada lidando com os sistemas DARI e KETCHUP, que (como muitas ferramentas de desenvolvimento no Japão nos anos 80 e 90) funcionavam em computadores X68000.

alisia06

Arte conceitual, incluindo um estágio inicial de mapeamente de pixels que Satou diz que o ajudou a manter consistência entre arte conceitual e o jogo finalizado.

alisia05

Um exemplo de arte conceitual para os fundos dos cenários.

alisia07

Arte conceitual para três inimigos de Alisia Dragoon: (E-D) “Enemy Sorceress-Warrior, Saida”, o empunhador de machados “Maata”, e o Slime.

Fonte: Shmuplations