[MÚSICA] [MÚSICA] Dando continuidade ao nosso módulo de entrevistas, a gente tá aqui com o Mateus Schmidt que é graduando do Instituto de Artes da Unicamp e é coordenador geral do Gamux. O Gamux é grupo de estudos constituído por alunos do Instituto de Computação e de Artes da Unicamp que além de organizar reuniões semanais com atividades focadas pesquisa e desenvolvimento de jogos digitais, também promove as game jams. Mateus então com base na sua experiência junto ao Gamux como que você vê a utilização de uma metodologia de trabalho, no caso aqui a gente tá falando então da metodologia iterativa, né? pra guiar o trabalho do artista, não é? Você provavelmente já tentou trabalhar sem método, eu acho que todo mundo começa dessa forma, e depois foi descobrindo como se organizar, implementando processo de trabalho. Como que foi isso? >> Então como qualquer iniciante assim, quando eu comecei a trabalhar com jogos eu comecei tateando sozinho casa. E você acho que por estar treinado para fazer isso pela escola por todo o tempo que você passa estudando, você começa com método mais tradicional. Então você pega aquele método cascata, bem classicão, vai estudando passo a passo, fazendo tudo devagarzinho. Quando eu entrei no Gamux foi igualzinho: assim eu continuei nesse método cascata e isso dura assim até você acabar o primeiro projeto. Aí você percebe que o primeiro projeto não tem nada mais a ver com o briefing, tem erro de usabilidade, tem erro de interface, tem erro de jogabilidade. Às vezes a proposta do jogo inicial ela não é mais cumprida. Por que isso acontece? Assim o jogo ele é sistema complexo, tem vários fatores que eles agem entre si e eles acabam atuando no outro e momento essa interligação de fatores internos do jogo ela deixa de ser previsível. Então o que que a gente começou a perceber, no meu caso por ser das artes eu nem aprendi isso aula, foi uma coisa que a gente começou a reparar enquanto a gente desenvolvia mesmo, mas que a ação do tester ela era muito mais eficiente, a pessoa que estava testando o jogo, que sai jogando tudo muito mais eficiente quando você intercala ela durante a produção do jogo, do que quando você deixa ele testar no final. Porque muitas vezes a pessoa testa no final o jogo e você tem que alterar uma coisa que não dá mais para alterar. Então assim tinha muitas vezes que eu queria uma alteraçãozinha de código que era só mudar, mas tinha alteração que tinha que ia ter que mudar todas as classes e tinha alteração que às vezes na arte tinha você por exemplo fez as animações com os frames errados, no formato errado e tá dando pau e você tem que fazer todas as alterações todas as artes do jogo é uma coisa que fica inviável assim, toma muito tempo. A gente percebeu que a gente fazendo vários testes curtos a gente conseguia ir direcionando o jogo pra ponto que ele estava mais finalizado no final, se a gente fizesse isso no processo tradicional. >> Então eu acho que comparando por exemplo com outras obras de arte, outros trabalhos artísticos seria mais ou menos a mesma coisa de você pegar trabalho de arte, você apresentar a público e ele não ter o resultado que você esperou. O quê que você faz com isso, você consegue só corrigir no próximo projeto. >> Sim. >> E você partir por exemplo, nesse caso especificamente dos jogos, você consegue então trazer essa atuação do tester ou mesmo de qualquer representante que vai entrar contato, ele contribuir com as suas críticas no decorrer do desenvolvimento e já ir implementando essa essa, esse resultado. >> Isso, é, acaba sendo realmente método de desenvolvimento ágil, porque você precisa ter todo mundo junto, porque assim: é muito difícil de você conseguir fazer a arte separada da programação e dar tudo certo. Normalmente você enquanto você está fazendo a arte, o programador ali do lado ele já olha pra arte que está sendo feita e já fala o que vai dar errado, se vai dar errado. Ao mesmo tempo você vê por exemplo o sólido, por exemplo o quadrado vermelho pulando você fala: olha vai dar problema com a animação, o pé dele não está quicando, por exemplo uma coisa assim. Realmente no final você vai desenvolvendo método que ele é mais eficiente, ele é mais completo assim. Então no nosso caso, a gente sempre trabalha com a equipe inteira no mesmo lugar. A gente promove eventos de desenvolvimento que eles são maciços assim: então a gente não faz duas horas de desenvolvimento conjunto. A gente pega quarenta e oito fica todo mundo dois dias sem dormir, a gente pega e mata o jogo três, quatro dias desse desenvolvimento porque a gente percebe que a gente consegue fazer vária seções iterativas pedaços assim e no final juntar tudo e o jogo acaba estando mais perto do documento de game design que a gente montou no começo, quando a gente tem esse controle sobre as etapas. >> O game designer às vezes ele tem uma visão, uma ideia que o pessoal da programação muitas vezes não está implementando da maneira que foi idealizado. Então assim eu vejo que muitas propostas que partem somente de programadaores equipes que não têm artistas ou que o artista entra só no final do projeto, quando isso vai pra teste muitas vezes o jogador que vai testar ele não, não consegue compreender bem aquela mecânica. É como se ficassem uns pedaços separados do projeto, não é? >> Sim. Uma coisa que a gente faz pra tentar corrigir esse problema, que é problema bastante comum na verdade não só com jogos, qualquer projeto que você tem, que ele é compartimentalizado, você acaba tendo essa diferença de mentalidade de quem estava no planejamento e de quem está só executando. Uma coisa que a gente fez pra corrigir esse problema é que sempre antes de fazer o documento de game design, antes dos games designers, da equipe que faz o game design bolar a estratégia do jogo, a gente reúne todos os programadores e artistas discute com eles a ideia para todo mundo entender a essência do projeto, como o jogador deve se sentir, que estética a arte deve transmitir, como que a dificuldade vai progredir durante o jogo, se é jogo para pro player, para a pessoa que joga muito, se é jogo para quem não joga muito. Porque aí no final quando a pessoa for desenvolver, o panorama de ideia que a gente tem já está muito perto da do game designer. Então as correções que a gente faz do game design são bem menores >> Entendi. >> Nesse caso. >> E também tem aquelas reuniões que são pontuais, não é? Geralmente na metodologia ágil você sempre tem algumas reuniões que vão pontuando o decorrer do projeto, não é então. >> Isso. >> Para você ver se está amarrado com o objetivo, se o resultado está sendo atingido ou se precisa mudar alguma coisa. >> Geral quando a gente desenvolve, a gente não usa nenhuma figura de gerente de projeto muito forte assim, nunca é cara que está fora do projeto olhando de longe, é sempre alguém que está participando e que normalmente tem pouco mais de visão do jogo completo, normalmente é a pessoa mais experiente do grupo. E ela acaba sendo, no ambiente da metodologia Scrum que é bem comum, acaba sendo essa pessoa que vai estar cobrando as outras, que vai estar sempre deixando tudo transparente, o que está acontecendo por todos os lados, porque é a impossível a gente pegar e fazer o jogo sempre apenas assim. Então vira e mexe o jogo volta para a casa de programador olha sei lá, tem bug simples nas legendas, altera as legendas. Ele vai e altera. Olha os achievements estão dando pau. Essas coisas pequenas não tem necessidade da gente juntar a equipe inteira. Então sempre é bom ter alguém que está contato com todo mundo, que é essa pessoa que tem essa visão, essa pessoa que costuma ser responsável por marcar essas reuniões pontuais, que acabam auxiliando o desenvolvimento também. >> No Gamux vocês procuram então orientar os iniciantes nessa entrada para o mundo de desenvolvimento de jogos, não é? Vocês têm uma preocupação transmitir uma metodologia de trabalho para esse pessoal, vocês encontram uma certa resistência de transmitir essa metodologia para os iniciantes? >> Então, o que acontecia há pouco tempo atrás, na verdade fez uns três anos a gente tinha uma metodologia mais tradicional de ensino. Então o objetivo do Gamux sempre foi inserir as pessoas no mercado de jogos, seja indie seja por empresa. A gente quer dar a oportunidade para as pessoas de realmente entrar no mercado com tudo. O que acontecia no começo? A gente oferecia aquela metodologia bem tradicional de ensino. Então assim: tinha duas aulas semanais e as pessoas desenvolviam projeto por conta, que a gente ia vistoriando e dando palpite. O que acontecia sempre era assim. Obviamente a gente lida com público noventa por cento universitário, então a pessoa ia nas aulas, entrava semana de provas sumia não fazia mais nada, o projeto defasando ia caindo, caindo. No final de grupo de cinquenta, sessenta alunos a gente tinha quatro projetos acabados, cinco no máximo. E a gente tinha até se conformado com esse número, número que normalmente essas cinco pessoas entravam na administração do Gamux no período seguinte. A gente ia mantendo isso, até ponto que a gente teve a ideia de pegar uma game jam e modificar ela para ela servir na verdade como uma ferramenta de ensino que seguisse uma metodologia. Então como que a gente fez? Geral as game jams elas exigem que os participantes tenham algum conhecimento de jogos, então você entra se você sabe fazer a arte e você sabe programar, não tem espaço para aprender. O que a gente fez foi o contrário. A gente pegou uma game jam que ninguém sabe nada, a gente colocou dez membros do Gamux mais ou menos ali, experientes, para ajudar as pessoas que não sabem nada. Então você chega, você arrebanha pessoas, forma grupos, você começa a desenvolver o projeto do zero. >> Legal. >> Então o objetivo disso é passar a metodologia para eles. Então você faz eles fazerem reunião de game design, explica tudo que está ali se fazendo de errado e eles estão fazendo certo e aí você vai ensinando progressivamente até que no final com a habilidade que a pessoa tenha qualquer que seja ela consiga ter produto finalizado e pronto para ser usado. A nossa preocupação é essa. A característica mais comum de quem está tentando entrar no mercado é elaborar plano de MMO gigantesco de equipes absurdas de pessoas e a pessoa não conseguir fechar o projeto. >> Lógico. >> Então você pega pessoas que estudam jogos mesmo curso de graduação de jogos as pessoas não conseguem finalizar o projeto e ter alguma coisa para mostrar, quando elas estão procurando emprego. A nossa preocupação é exatamente essa assim: tenha controle do seu projeto para você conseguir ter produto finalizado para mostrar para as pessoas. >> Conseguir formar portfólio, não é? Depois. >> Isso exato, exatamente. >> Começar a fazer portfólio. Legal. Então Mateus, eu vou pedir agora para você deixar uma dica para o pessoal que está iniciando, não é, com relação a essa utilização da metodologia iterativa, especial para quem quer trabalhar com essa vertente mais subjetiva da estética dos games, do lado mais artístico, você que também é da área de artes. >> Certo. Olha a dica que eu posso dar, a dica que eu acho que pode ser mais significativa para essas pessoas é: trabalhe ciclos e finalize os projetos. Então assim, você fez ciclo com uma coisa que você já pode mostrar para as pessoas. Coloca isso como mínimo. Faça que esse ciclo seja curto. Pensa, antes de pensar no jogo, pensa: eu preciso ter alguma coisa jogável quinze dias. Se você desistir dessa ideia no meio, você já vai ter alguma coisa para mostrar e é isso que está faltando no mercado hoje: as pessoas não conseguem completar os projetos. Então elabore projetos que podem ser finalizados dentro do tempo que você tem. >> Então Mateus, muita obrigada pela sua participação, pela sua disponibilidade vir aqui conversar com a gente. >> Foi prazer. Eu é que agradeço. >> Então essa entrevista finaliza o nosso sexto módulo. A seguir vamos ver alguns conceitos finais para encerrar esse nosso curso. [MÚSICA] [MÚSICA] [MÚSICA]
