Prototipagem rápida de gameplay

Apresentação em tema: "Prototipagem rápida de gameplay"— Transcrição da apresentação:

1

2 Prototipagem rápida de gameplay
Cláudio H P Lins – Produtor líder Sócio fundador da Preloud Entretenimento Eletrônico Brasil

3 A Preloud Existe desde 2002 como projeto pré-incubado e incubado, em 2003 como empresa formalizada. Esta no porto digital, tem atualmente 8 jogos in box para PC no mercado exterior em mais de 6 paises. Atualmente conta com 14 membros e esta trabalhando com parceiros no exterior e no Brasil.

4 Funcionamento padrão de desenvolvimento:
Conceito Proposta de projeto Proposta de custos/ orçamento Cronograma de milestones/ versões Desenvolvimento/ Produção clássico/tradicional (os 5 primeiros jogos seguiram esse padrão) - Áreas de desenvolvimento isoladas Código Arte Gestão Produção Game design ... - Documentações pré-estabelecidas - Cronogramas fechados no inicio do projeto - Listas e mais listas – “to do list” Funcionalidades Texturas

5 Principais Problemas encontrados no desenvolvimento clássico.
Provar o que foi feito no milestone a olhos leigos - Muitas vezes uma área anda mais rápido do que outra, dificultando mostrar certos “features” Atraso de pontos específicos Quando uma área atrasa as outras sofrem não concluindo assim as metas esperadas. Mostrar visualmente o que foi feito Quando não há uma interação entre as áreas é bastante comum ter divergências de pensamentos. Áreas isoladas trazem problemas de comunicação Sempre que um erro for encontrado, em qualquer área que seja, será resolvido apenas por ela mesma.

6 Cronograma feito no inicio do projeto
Documentação fixa - Documentação pré-estabelecida de arte, gd ou código. - Documentações fixas independentes. - Game design fixo – seguir cegamente. Cronograma feito no inicio do projeto - Quando o projeto já esta definido e amarrado com suas “listas” prontas fica complicado conseguir segui-lo de algo der errado. Dificuldade de inclusão de novos features no projeto - Como todo o cronograma foi estabelecido no inicio do projeto fica difícil a re-locação de recursos na metade do projeto. Dificuldade de manter o interesse da equipe - Quando as partes trabalham separadas e um dia vão juntar código e arte e virar jogo, é difícil manter o animo de todas as partes se ainda não tem nada “rodando”.

7 Dificuldade de manter a unidade inicial do projeto e qualidade
- Quando se começam as listas torna-se um trabalho manual, mecânico, e deixa de ser encarado como “arte” – logo vira uma “linha de montagem em partes que um dia será alguma coisa”. (colcha de retalho) Resultados mais tardios - Demorava bastante para se apresentar as funcionalidades do projeto funcionando em 100%. Maior facilidade de erros - Como todas as “peças” foram trabalhadas diferentes não da para garantir que todas irão “encaixar” perfeitamente como mágica.

8 A experiência 4 demos em 4 semanas
Jogos que nunca tivéssemos trabalhados antes – tudo do zero Equipe pequena sempre presente (8 horas por dia 7 dias por semana) Desenvolvimento em seqüência lógica e necessária – “made in na hora”

9 Desenvolvimento em seqüência lógica e necessária – “made in na hora”
Especificação dos demos Destrinchar exatamente quais as características usadas no processo (60% planejamento 40% desenvolvimento) Planejar o que vai ser usado na cena Fazer os conceitos que serão usados na cena Programar o que será feito na cena Fazer as animações que vai terá na cena Fazer o “design concept” da cena Inicialmente é necessário ter um “game concept” básico do projeto.

10 “Modelar” a cena Destrinchar um cronograma simples com “macro blocos” de “features” específicos. EX: se uma cena vai ter um soldado atirando será necessário: O soldado ARTE O conceito do soldado O modelo 3D A textura do modelo 3D A animação de atirar Os efeitos especiais da bala para que ele atire CODIGO Colocar o soldado na tela A funcionalidade do soldado atirar Produção Cronograma para saber o tempo que esse “macro bloco” vai ser feito. Assim o “macro bloco” “soldado atirando” vai ser feito por toda equipe ao mesmo tempo e automaticamente testado e validado por toda a equipe.

11 Divisão de recursos exata para validar somente o que necessário
- Uso da mão-de-obra necessária Arte em conjunto com código – áreas conjuntas – não há divisão entre a equipe - Tudo que foi feito em arte foi validado em tempo real. Incluindo modelos, texturas, cenário, animações e mais o que for necessário. - Tudo que é validado automaticamente é testado - Cada novo feature implementado é testado em tempo real junto com toda a equipe responsável pelo feature e logo corrigido se der algum problema. E é finalizado somente quando concuido. Game design e documentação mutante e assistido por toda a equipe. Toda a equipe sente o jogo crescer em tempo real. A responsabilidade de uma tarefa deixa de ser de apenas uma pessoa e começa a ser de toda a equipe envolvida no “feature especifico” Apresentação do feature, funcionalidade, mais rapidamente. - Como é baseado em macro blocos, cada macro bloco pode ser considerado sub metas que podem ser apresentados muito mais rapidamente.

12 Testes em tempo real a cada funcionalidade adicionada.
Maior facilidade em mudar o rumo do projeto Caso alguma funcionalidade não seja como imaginado existe como contornar isso mais facilmente. Maior facilidade em encontrar gargalos no Cronograma Como a equipe esta próxima e se cobrado para concluir os macro blocos é mais fácil de detectar os gargalos. Manter a unidade inicial e qualidade do projeto - Como esta sendo tudo validado em tempo real e toda a equipe esta acompanhando é mais fácil acompanhar a qualidade e adicionar alguma alteração ou ate mesmo nova tecnologia no projeto. Maior facilidades para incluir novos features - Como tudo que esta no projeto esta “previamente” funcionando, é mais possível incluir novas funcionalidades em cima das já existentes.

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34