![[Entrevista]De jogador a desenvolvedor: Mike Z[+Skullgirls][+Epic Developer][+Tapa na cara da indústria de games] Empty](https://2img.net/i/empty.gif)
![[Entrevista]De jogador a desenvolvedor: Mike Z[+Skullgirls][+Epic Developer][+Tapa na cara da indústria de games] DMPfFsI](https://i.imgur.com/dMPfFsI.png)
Mike Z é uma pequena lenda e um gigantesco exemplo entre os desenvolvedores independentes: Inicialmente um ávido Jogador de Marvel vs Capcom 2, Ele se uniu ao artista Alex Ahad para criar o Ambicioso projeto Skullgirls: um game de luta criado do zero unindo a experiência de um jogador competitivo e programador com o mundo e personagens visionados pelo artista.
Em uma entrevista interessantíssima conduzida por Patrick Miller (do site shoryuken.com), Mike fala como entrou na indústria, os talentos que ele desevolveu como jogador que o ajudaram como desenvolvedor, além de insights interessantes sobre a filosofia de de desenvolvimento e dicas de como entrar no disputado mercado de desenvolvimento de games.
Segue abaixo uma tradução feita pelo google translate e toda revisada por mim (deu um trabalhão)
*NOTA: A entrevista usa uma série de termos específicos, sejam eles do "internetês", gírias ou termos da comunidade de jogadores de games de luta. Qualquer dúvida sobre o que lerem, favor postar e eu posto a "tradução" do termo.
Mike "Mike Z" Zaimont não é estranho para a comunidade de jogos de luta, depois de anos como um jogador ativo de Marvel vs Capcom 2, dedicou-se à construir e desenvolver o jogo de luta indie Skullgirls, primeiro com Reverge Labs e agora com a Lab Zero Games.
PM:Como você conseguiu o seu início no desenvolvimento de jogos?
Mike Zaimont:Como muitos aspirantes a desenvolvedores de jogos, fiz curso de ciência da computação na escola, me formei nisso na faculdade, e "programava coisas" em meu tempo livre, mas eu tive o meu início no desenvolvimento de jogos da mesma maneira muita gente fez antes da Digipen e programas de educação jogo focados existirem - trabalhando como testador. Ser um tester é uma boa introdução ao trabalho real que vai fazer em um jogo, ele permite que você ganha experiência com o processo de desenvolvimento, bem como conhecer a equipe de desenvolvimento, ao mesmo tempo sendo um pouco mal pagos e muito sobrecarregado, mas normalmente gostando disso.
Pandemic Studios tinha postado alguns panfletos na UCLA, e depois de muita insistência me candidatei e tornei-me um testador de Star Wars Battlefront. Lá, eu usei meu conhecimento de "Como isso foi provavelmente escrito, e como eles podem ter esquecido alguma coisa?" Para encontrar a bugs que irritaram a equipe de desenvolvimento suficiente para que eles finalmente me deixassem fazer o teste para programador, e acabei me tornando um programador/designer em Battlefront II.
A maior parte da Engine de Skullgirls foi escrita a partir do zero por mim entre 1999-2011, e eu fiz todo o script, design e equilíbrio para os oito (em breve nove!) personagens principais. Scripting e coding ainda são a maior parte do meu trabalho em uma base diária, e eu quero mantê-lo assim. Eu sempre preferi ser um "funcionário" do que ser um gestor, e ao longo dos anos eu abri mão de várias oportunidades de progressão na carreira que teriam tornado mais difícil para mim fazer parte da criação real do game.
PM: Como suas habilidades como um jogador competitivo em jogos de luta refletem na criação de games?
MZ: Eu tenho certeza que existem aqueles questionariam me chamar de "jogador competitivo." Porém: Para ser tanto um jogador competitivo em jogos de luta e um desenvolvedor de jogos de sucesso, você precisa ser capaz de analisar as situações de todos os ângulos, fazer planos de longo prazo, tratar bugs e glitches no jogo como recursos a serem explorados em vez de ignorados, ser capaz de entender como as outras pessoas provavelmente pensam, e criar a formas inovadoras de lidar com novos problemas na hora que eles aparecem
Uma das maiores coisas que ser um jogador de jogos de luta tem ajudado é com a minha filosofia de design. Como jogadores de games de luta, explorarmos todas as facetas dos jogos que jogamos com a esperança de ganhar algum tipo de vantagem competitiva. Com demasiada frequência, vejo equipes de desenvolvimento encarar design de jogos como "Vamos colocar um monte de coisas e, em seguida, encontrar todos os problemas com os testes", ou "Oh, isso é muito bom, vamos torná-lo muito difícil!"
Isso nunca funciona. Depois de anos observando as pessoas usarem "true-kara-Demons", "1-frame Rensen FRC "do Axl, "Gigas" parado, loops do T.Hawk, combos malucos com "refly", e tudo o mais considerado quase impossível para pessoas comuns para fazer, e fazê-los em torneios sob enorme pressão, a minha abordagem de design é bastante singular: Não levar em consideração a habilidade do jogador, assumir os jogadores podem fazer QUALQUER COISA, e supor que eles já tenham encontrado uma maneira de burlar todas as salvaguardas incluídas. Não acha que um jogador pode descobrir um combo infinito por causa de X, Y e Z? Suponha que eles já fizeram, e certifique-se de que há algo impedindo-os de qualquer maneira. Não acha que eles podem ignorar o limite no número de ground bounces? Suponha que eles já têm, e descubra que diferença faz no seu jogo. Sistemas de design que são, na terminologia de projeto de software, "tolerante a falhas" (fault-tolerant).
Um bom exemplo desta diferença na filosofia é o a forma que combos infinitos são impedidos em XvSF, MvC2, e MvC3. Resumindo uma série de nuances (desculpe Magnetro / SpiderDan / JChensor!), A Capcom passou muitos anos, De de MSH até XvSF/MvSF/MvC1, tentando fazer da Flying Screen (FS), uma mecânica que parasse combos infinitos. Isso nunca funcionou porque nunca realmente terminou seu combo, isto só tentava fazer o oponente ser lançado de tal forma que você não pudesse buscá-las novamente. Se você encontrou uma maneira de continuar mesmo assim, ou usar o efeito FS para seu benefício, ou apenas ignorar o FS por completo, presto - você poderia repetir esse padrão para sempre. E o pior, quanto mais estrito eles deixavam isso, menos criativo e divertido o jogo ficava como um todo, porque os limites impostos nos combos básicos eram muito duros(vide MvSF).
Em MvC2, alguém inteligente percebeu que poderia aproveitar o sistema de dizzy existente para parar combos infinitos, garantindo que uma vez que normalmente será atordoado, você ao invés sairá (do combo. "pop out") e se recuperará. Isto teve três vantagens importantes: 1) Não importa que combo você faz, depois de um tempo ele iria acabar, 2) não afeta o combo de forma alguma, até ser acionado, e 3) Ele não precisa quaisquer exceções intencionais. (o sistema de undizzy) se aplica em toda parte, em todos os momentos, e não faz nada até terminar completamente o seu combo. Então eles regrediram o Flying Screen para a versão muito menos restritiva do MSH, inserindo no que ficou conhecido como "undizzies", fim de papo. E para todos os intentos e propósitos, fora de combo videos com pads programados, funcionou. Você ainda pode ser criativo, ainda havia loops longos e combos 100%, mas não havia nada que continuasse para sempre.
No MvC3, eles tentaram fazer a mesma coisa com a deterioração de hitstun (HSD), mas se depararam com um problema: Isso afetou seu combo no meio, antes de ser forçosamente terminado. Para corrigir isso, eles colocaram em exceções - Shield Slash do Capitão América, no hurricane kick do Akuma, TAC, etc. ignoravam intencionalmente HSD, pois poderia ter efeitos indesejáveis durante o ataque. Como resultado disto, o sistema não era mais tolerante a falhas. Tudo o que um jogador tinha que fazer era descobrir uma maneira de combinar os ataques que ignoram HSD, e todo o sistema torna-se imediatamente irrelevante. Jogadores são um grupo criativo, logo, eles fizeram exatamente isso, e Capcom gastou o tempo restante patcheando infinitos Assim, a grande diferença entre, digamos, o "infinito" do Homem de Ferro em MvC2 e infinitos com TAC em MvC3 - em MvC3, você nunca, nunca, nunca tem que parar. Você ignorou totalmente o sistema. Se você quieser fazer um loop de dano baixo por mais de 60 segundos de jogo, você pode.
Esta idéia é a razão pela qual o sistema de prevenção de infinito em Skullgirls presta atenção ao combo está realmente fazendo / não faz nada até que ele pare o seu combo / não tem exceções intencionais, e o lembrete de que os jogadores podem e vão quebrar tudo o que você colocar em o jogo é uma influência constante no meu trabalho.
PM: Você conseguiu cultivar uma base de fãs extremamente leal. Você acha que a sua experiência na comunidade de jogos de luta ajudou a construir essa base?
MZ: A minha experiência no FGC definitivamente me ajudou a saber o que eu queria de um desenvolvedor de jogos: Sem de plahaçada ("No BS"). Eu não quero que me digam esta próxima iteração é "o jogo mais equilibrado que já fizemos", ou besteira similar. Eu não quero que mintam para mim sobre DLC, ou que me digam que nunca haverá outra atualização a menos que eu compre um jogo sem relação, ou que a opinião da FGC é mais importante que opinião final (da empresa), se isso não acontece.
Lab Zero se esforça bastante para defender este ideal, e eu acho que é uma das principais razões que temos uma base de fãs tão incrível. Se algo está errado sobre o jogo, eu falo sobre isso em público, e tento corrigir. Se algo der errado com o desenvolvimento, falamos sobre isso. Se algo der certo, nós falamos sobre isso também! Se você quiser falar com os desenvolvedores, você pode - ou no canal IRC Skullgirls, por PM em SkullHeart / SRK / Dustloop, ou pessoalmente toda semana na "Salty Cupcakes" (torneio/encontro de skullgirls organizado pelo Mike Z) . Eu também jogo o jogo, então eu sei em primeira mão os problemas que os jogadores de experimentam. Sabemos que estamos fazendo o que estamos fazendo para os nossos fãs, e nós não queremos ficar isolados em nossa torre de marfim.
PM:? Tem algum conselho entusiastas de games de luta tentando começar a fazer jogos?
MZ: Meu maior conselho para jogadores tentanto iniciar no desenvolvimento de jogos é sempre o mesmo: FAÇA ALGUMA COISA. Não se preocupe sobre onde começar, apenas comece, no momento que você chegar ao final, você terá feito tudo o necessário de qualquer maneira, e aprendido muito mais do que você teria se não tivesse feito nada.
Eu não ponho muita fé na maioria dos cursos para o desenvolvimento do jogos, porque eu não passei por isso. Isso não significa que eles não ajudam, isso significa apenas que, na minha opinião, não é necessário. Você se dar fazer tão bem quanto com formação em Ciência da Computação ou arte proveniente de qualquer outro lugar. Inicie um grupo, envolva-se em um projeto, fazer alguma coisa para demonstrar que você está disposto a trabalhar e tenha algo para mostrar. Uma demo fala mais alto do que qualquer currículo.
Quanto a ser um designer de jogos, eu defendo um background em programação, a arte, ou produção, porque ter um conhecimento de uma das disciplinas é extremamente útil, pois você estará constantemente lidando com os programadores, artistas e produtores. Algumas pessoas desenvolvem "sentindo" - Eu sou um - e algumas pessoas desenvolvem por análise ... mas há definitivamente qualidades que você não pode ensinar. Algumas pessoas "têm" e algumas pessoas não. O Que sempre dói ouvir quando quem é com você, mas não significa que aqueles que não têm "a faísca" para o desenvolver combates não vai podem ser incríveis level designers, designers de interface do usuário, scripters, ou mesmo artistas ou programadores ! Ser um bom jogador não faz de você um bom designer, e ser um jogador terrível não o torna terrível designer, mas de qualquer forma você deve ser capaz de considerar perspectivas de todos os outros.
Eu falo muito sobre como ser um designer significa olhar para as situações de todos os ângulos. Todo mundo pode se sentar na frente de um jogo e dizer se gosta dele ou não. Poucas pessoas podem descrever com precisão por que eles não gostam. Ainda menos pessoas poderiam me dizer se outra pessoa poderia gostar ou não, e menos pessoas ainda poderia me dizer por que alguém pode gostar se eles mesmos não gostam. Ser um designer significa considerar ponto de vista de todos, incluindo aqueles com quem você não concorda. Você pode odiar um certo arquétipo de personagem, mas há pessoas que os amam. Você pode entender o porquê, e fazer um personagem que agrada a eles, mas funciona no seu jogo? Eu espero que sim.
fonte: http://shoryuken.com/2013/08/05/from-fighting-games-to-making-games-part-3-mike-mike-z-zaimont-lab-zero-games/[/b]
