Este curso oferece respaldo aos interessados em atuar como desenvolvedores, pesquisadores e docentes na área do jogos, tendo como foco o entendimento destes como partes integrantes da cultura contemporânea e do cenário artístico atual. Serão apresentados conceitos fundamentais às discussões dos videogames vistos como expressões culturais e artísticas. Através de videoaulas explanativas, leituras recomendadas, entrevistas com especialistas, exercícios reflexivos e discussões em grupo, serão transmitidos conhecimentos com o intuito de iniciar os interessados no tema ou mesmo enriquecer o repertório daqueles que já atuam na área. Embora este curso seja fundamentalmente teórico, pretendemos criar uma ponte entre as esferas acadêmica e mercadológica. Para isso, incentivamos a aplicação pragmática através da proposição de uma avaliação por pares. Os alunos serão levados a rascunhar o projeto de um videogame e compartilhá-lo com os colegas, tendo a chance de refletir sobre o feedback recebido. O objetivo principal deste oferecimento é propiciar embasamento adequado aos estudantes interessados em explorar as relações entre videogames e arte.
Entrevista - "O método iterativo", com Matheus Schmidt
Loading...
Do curso por Universidade Estadual de Campinas
A complexidade sensível: Um paralelo entre videogames e arte
154 classificações
Universidade Estadual de Campinas
154 classificações
Na lição
Processos de Criação
Neste módulo serão apresentadas entrevistas com especialistas da área de games, visando o entendimento de processos metodológicos que possam ser aliados aos conceitos vistos e aplicados na prática.
Conheça os instrutores
Julia StateriDoutoranda
Instituto de Artes - Departamento de Artes Visuais
Edson do Prado PfutzenreuterProf. Dr.
Instituto de Artes - Departamento de Artes Visuais
[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]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
