Proposta de um Processo de Desenvolvimento de Games para Pequenas Equipes
Descrição do Produto
Pedro Barbosa Lima Ciarlini
Proposta de um Processo de Desenvolvimento de Games para Pequenas Equipes
Fortaleza - Brasil Setembro de 2014
Pedro Barbosa Lima Ciarlini
Proposta de um Processo de Desenvolvimento de Games para Pequenas Equipes
Trabalho de conclusão do curso de Animação e Jogos eletrônicos da pós-graduação da Universidade de Fortaleza
Universidade de Fortaleza – Unifor Animação e Jogos Eletrônicos Pós-Graduação
Orientador: Ana Paula Narciso Severo
Fortaleza - Brasil Setembro de 2014
Pedro Barbosa Lima Ciarlini Proposta de um Processo de Desenvolvimento de Games para Pequenas Equipes/ Pedro Barbosa Lima Ciarlini. – Fortaleza - Brasil, Setembro de 201480 p. : il. (algumas color.) ; 30 cm. Orientador: Ana Paula Narciso Severo Trabalho de Conclusão de Curso – Universidade de Fortaleza – Unifor Animação e Jogos Eletrônicos Pós-Graduação, Setembro de 2014. 1. BPM. 2. Processos de negócios. 3. Games. 3. Jogos eletrônicos. I. Ana Paula Narciso Severo. II. Universidade de Fortaleza III. Pós-graduação de Animação e Jogos eletrônicos IV. Proposta de um Processo de Desenvolvimento de Games para Pequenas Equipes
Pedro Barbosa Lima Ciarlini
Proposta de um Processo de Desenvolvimento de Games para Pequenas Equipes
Trabalho de conclusão do curso de Animação e Jogos eletrônicos da pós-graduação da Universidade de Fortaleza
Trabalho aprovado. Fortaleza - Brasil, 30 de Maio de 2014:
Ana Paula Narciso Severo Orientador
Nílbio Thé Professor
Fortaleza - Brasil Setembro de 2014
Este trabalho é dedicado às crianças adultas que, quando pequenas, sonharam em se tornar cientistas.
Agradecimentos Aos que tentam fazer das suas ações uma ferramenta para a evolução harmônica da nossa existência única, os meus sinceros agradecimentos. E aos que, estando perto, me influenciam a continuar, em especial minha querida esposa e revisora Raquel, meu muito obrigado.
“A violência é o último refúgio do incompetente.” (Isaac Asimov, A Fundação)
Resumo O objetivo deste trabalho é propor um guia, em forma de processo de negócios, para a gestão de desenvolvimento de jogos eletrônicos. Seguindo normas e metodologias bastante difundidas no mercado e usando as pesquisas feitas pelas entidades que as normatizam como principal argumento, esta proposta usa também um subconjunto de boas práticas de processos de desenvolvimento de software. Palavras-chave: BPM. Games. Processos de negócio.
Lista de ilustrações Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura
1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 10 –
Exemplo de raia e piscina . . . . . . . . . . . . . . Exemplo de Atividade de chamada . . . . . . . . . Exemplo de atividade manual, ou tarefa de usuário Exemplo de evento de início . . . . . . . . . . . . . Exemplo de evento de fim . . . . . . . . . . . . . . Exemplo de evento terminativo . . . . . . . . . . . Exemplo de portal exclusivo . . . . . . . . . . . . . Exemplo de portal paralelo . . . . . . . . . . . . . Exemplo de fluxos de sequência . . . . . . . . . . . Diagrama do processo proposto . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
24 25 25 26 27 27 28 28 29 48
Lista de abreviaturas e siglas BPM
Business Process Management
BPMN
Business Process Modeling Notation
CMM
Capability Maturity Model
PMBoK
Project Management Body of Knowledgement
BPM CBOK
BPM Common Body of Knowledgement
Sumário Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1
DIAGRAMA BPMN E GESTÃO POR PROCESSO . . . . . . . . . 21
1.1
Um jogo, um projeto. Os jogos, um processo . . . . . . . . . . . . . 22
1.2
Processo de negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3
Documentação do processo . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.1
Caso de processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.2
Piscina e Raia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3.3
Atividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.3.1
Atividade de chamada
1.3.3.2
Tarefa de usuário
1.3.4
Passos de uma tarefa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.5
Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.5.1
Evento de início
1.3.5.2
Evento de fim
1.3.5.3
Evento Terminativo
1.3.6
Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.6.1
Exclusivo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
1.3.6.2
Paralelo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
1.3.7
Fluxo de sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2
DESENVOLVIMENTO DE UM TIPO DE SOFTWARE: GAME . . 31
2.1
Gerência de configuração . . . . . . . . . . . . . . . . . . . . . . . . . 31
3
O PROCESSO DE DESENVOLVIMENTO DE JOGOS . . . . . . . 35
3.1
Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2
O diagrama BPMN
3.3
Papéis e acúmulo de funções . . . . . . . . . . . . . . . . . . . . . . . 36
3.4
Desvio do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5
Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1
Criar argumento e protótipos . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2
Analisar viabilidade do jogo . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.3
Arquivar idéia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.4
Elaborar documentação preliminar . . . . . . . . . . . . . . . . . . . . . . 38
3.5.5
Planejar desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.6
Criar arte conceito dos elementos das animações . . . . . . . . . . . . . . 39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.7 3.5.8 3.5.9 3.5.10 3.5.11 3.5.12 3.5.13 3.5.14 3.5.15 3.5.16 3.5.17 3.5.18 3.5.19 3.5.20 3.5.21 3.5.22 3.5.23 3.5.24 3.5.25
Criar interfaces de contexto de jogo . . . Criar animatics iniciais . . . . . . . . . . Desenvolver animações inicial e final . . . Criar tema e efeitos sonoros iniciais . . . Realizar provas de conceito . . . . . . . . Documentar e iniciar testes . . . . . . . . Pré-documentar levels . . . . . . . . . . Refinar documentação . . . . . . . . . . Desenvolver Level . . . . . . . . . . . . . Criar roteiro de teste . . . . . . . . . . . Sincronizar animações . . . . . . . . . . Desenhar elementos de contexto de Level Animar elementos de contexto de Level . Criar temas e efeitos sonoros do jogos . . Sincronizar cut scenes . . . . . . . . . . Testar Level . . . . . . . . . . . . . . . . Retestar levels . . . . . . . . . . . . . . Corrigir levels . . . . . . . . . . . . . . . Lançar jogo . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
40 40 40 41 41 41 42 42 43 43 44 44 44 44 45 45 46 46 46
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ANEXOS
51
ANEXO A – PROPOSTA DE JOGO . . . . . . . . . . . . . . . . . 53 ANEXO B – ELEMENTOS DO JOGO . . . . . . . . . . . . . . . . 59 ANEXO C – NARRATIVA . . . . . . . . . . . . . . . . . . . . . . . 65 ANEXO D – REGRAS . . . . . . . . . . . . . . . . . . . . . . . . . 71 ANEXO E – ROTEIRO DE TESTE . . . . . . . . . . . . . . . . . . 77 ANEXO F – RELATÓRIO DE TESTES
. . . . . . . . . . . . . . . 79
19
Introdução Como muitas áreas de trabalho que estão diretamente ligadas à tecnologia, o desenvolvimento de jogos tornou-se menos dependente de ferramentas caras e inacessíveis às pequenas equipes, deixando que as principais barreiras do desejo de criar e implementar jogos seja a dedicação e a disciplina. Com isso, além dos conhecimentos “artísticos” (concepção de personagens e cenários; criação de argumento, história e roteiro; composição de trilhas, temas, efeitos sonoros, etc) e “técnicos” (programação; uso de paleta de cores; harmonização de trilha sonora; aplicação de técnica de roteiro, etc...), uma equipe, mesmo motivada, precisa ter noções de gestão, que são comumente negligenciadas, resultando numa lacuna de tarefas para organizar, gerir e administrar as atividades realizadas. Na literatura usada neste estudo, encontrou-se apenas caminhos de pensamento a respeito do processo de se projetar games (SALEN; ZIMMERMAN, 2004). Mas qual o pontapé inicial? Quais passos um projetista de jogos deve seguir, junto com sua equipe, e em que ordem, para desenvolver seus primeiros jogos? Este trabalho sugere um Processo de Desenvolvimento de Jogos para pequenas equipes. Concebido como um diagrama de fluxo de trabalho, vai além do Iterative Design proposto por Zimmerman e Salen, onde as decisões de design são feitas através da experiência de jogar o game enquanto é desenvolvido, sem perder sua natureza iterativa de aprendizagem durante o desenvolvimento. Fora desenhado seguindo a notação BPMN 2.0 (Business Process Modeling Notation). A escolha da referida notação está diretamente ligada à possibilidade de automatizar o acompanhamento da execução de atividades usando um sistema de gerenciamento de processos de negócio (BPMS), que por sua vez permite o acompanhamento facilitado e a realização de medições precisas da execução do processo. Por se tratar de um tipo específico de software, são emprestadas práticas de guias de desenvolvimento de software na definição de atividades e do ambiente em que o processo é executado. No Capítulo 1 é explicado por que a gestão por processos foi escolhida, explicitando seus pontos positivos e descrevendo o seu modo de documentação. No Capítulo 2 é discutido o principal aspecto de um processo de desenvolvimento de software aplicado no Processo de desenvolvimento de Jogos proposto. Por fim, no Capítulo 3, o processo é detalhado atividade por atividade, pronto para ser adaptado e utilizado por uma equipe.
21
1 Diagrama BPMN e gestão por processo Em uma instituição, além das necessidades focadas no seu nicho, existem as de gestão. Acompanhar os lucros da empresa, o impacto desejado na sociedade, o retorno de investimentos, a produtividade e a qualidade da equipe são algumas das muitas ações que envolvem o ato de gerir uma empresa. Às pequenas, por possuírem poucos integrantes, resta a opção de decidir não desprender tempo para tais tarefas. Grande parte das atividades de gestão visam responder perguntas para auxiliar na tomada de decisões da instituição. Dentre elas, uma de relevância: “Como gerir as tarefas do dia a dia, necessárias para gerar meu produto/serviço, com eficiência e eficácia?” O BPM (Business Process Management, ou Gerenciamento de Processos de Negócios) é, de acordo com o ABPMP (2013), uma “forma de visualizar as operações de negócio”, onde tal visão “compreende todo o trabalho executado para entregar o produto ou serviço”. Entende-se por operações de negócio como as atividades diretamente envolvidas com o nicho da instituição, executadas repetidamente durante o ciclo de vida do produto ou serviço. Dessa forma, esse guia visa responder a questão acima ao agrupar técnicas e prioridades focadas em gerir o dia-a-dia. Dentre as práticas sugeridas pela gestão de processos, tem-se a de documentar os processos de negócio. É nessa prática que se desenha os diagramas de fluxo de trabalho e se descreve o que foi desenhado. Com tal documentação, o conhecimento das atividades a serem desempenhadas para se alcançar o objetivo do processo, ou seja, a entrega do produto ou do serviço, torna-se explícito, o que facilita o entendimento e a análise de maneira a possibilitar mudanças em tais fluxos e, consequentemente, no cotidiano da empresa. Dentre as várias maneiras existentes de se desenhar os fluxos, o BPMN 2.0, uma sigla que, em tradução livre, significa “notação de modelagem de processos de negócio”, foi escolhido neste trabalho por apresentar características positivas para o ambiente onde o processo proposto se insere, tais como: a) Notação pronta para ser automatizada em um sistema de gestão de processo de negócios, ou BPMS (Business Process Management System). Num BPMS podemos delegar aos computadores parte das tarefas do gerente de processos, que, por sua vez, é responsável pela execução dos seus processos no cotidiano (ABPMP, 2013). Assim, o acompanhamento, a medição e a comunicação do processo em execução podem ser realizados por uma máquina; b) Útil como modelo para públicos-alvos diferentes, funcionando como um ponto positivo ao denotar organização ao cliente;
22
Capítulo 1. Diagrama BPMN e gestão por processo
c) Possível diagramar vários níveis de processo: da visão macro à detalhada. Assim, o processo proposto pode fazer parte de um contexto maior ou ser refinado a pontos mais detalhados; d) É mantida pela OMG, “uma fundação sem fins lucrativos fundada em 1989 dirigida por fornecedores, usuários finais, instituições acadêmicas e agências do governo” (OMG, 2011), que tem grande credibilidade no mercado. A gestão por processos foi uma metodologia escolhida como guia base para a elaboração do Processo de Desenvolvimento de Jogos, o que não impede que outros subconjuntos de orientações e boas práticas sejam aplicadas, como artefatos apontados pela gerência de projetos ou práticas de processos de desenvolvimento de software.
1.1 Um jogo, um projeto. Os jogos, um processo O gerenciamento de projetos, que tem com um dos guias existentes o PMBoK (Project Management Body of Knowledge ou Corpo de Conhecimento da Gestão de Projetos), trata de projeto como “um esforço temporário com resultados exclusivos” (CARMO; ALBUQUERQUE, 2014). Ora, se o desenvolvimento de um jogo é um resultado exclusivo, por que tratá-lo como um processo? Porque, enquanto o “Desenvolver Jogo A” é um trabalho com resultado específico, “Desenvolver jogos” produz, do ponto de vista gerencial, o mesmo resultado. Então, é correto dizer que o Processo de Desenvolvimento de Jogos proposto nesse trabalho define o ciclo de vida da execução de vários projetos. De acordo com um estudo feito em um escritório de projetos, Welkey Carmo afirma que “a implantação do processo, por meio da automatização da metodologia de gerenciamento de projetos, exerce influência sobre a produtividade do escritório de projetos e melhora a comunicação entre os envolvidos em um projeto”. Tal processo orquestra as atividades do ciclo de vida de um projeto, então, sendo o desenvolvimento de um jogo compatível com um projeto, ao se definir e automatizar o seu processo, esperam-se melhorias na comunicação e possíveis boas influências na produtividade.
1.2 Processo de negócio “Uma agregação de atividades e comportamentos executados por humanos ou máquinas para alcançar um ou mais resultados” (ABPMP, 2013), essa é a definição de processo. Os processos de uma organização são modelados após a identificação das tarefas a serem executadas para se entregar o produto ou o serviço. Numa determinada empresa de jogos eletrônicos, por exemplo, a codificação do jogo ocorre invariavelmente pela contratação externa ou pela equipe interna. Assim, o processo para se entregar o produto (jogo) dessa empresa deve possuir, entre várias outras,
1.3. Documentação do processo
23
uma atividade chamada “Codificar jogo”, que ocorre independentemente do jogo a ser desenvolvido. Percebe-se, então, uma das características fundamentais da disciplina de processos de negócio: o padrão ou a repetição de ocorrência das suas tarefas, que devem ser definidas, no contexto do processo em que se inserem, de modo que possam ser realizadas independente da especificidade do produto ou serviço. A modelagem de um processo, mesmo que inflexível para efeito de medição, deve ser passível de alteração devido à necessidade de se adaptar aos novos anseios da instituição e às mudanças no ambiente em que estão inseridas. Tais alterações devem ser devidamente controladas para que sejam medidos os resultados e evidenciadas as melhorias ou pioras.
1.3 Documentação do processo Um modelo é uma representação esquemática de uma coisa, de um conceito ou de uma atividade. Modelos podem ser matemáticos, gráficos, físicos, narrativos ou uma combinação desses tipos (ABPMP, 2013). Diagrama do processo é o desenho do processo em si, contendo os elementos gráficos necessários para que estejam claros o seu objetivo, o seu ponto de início, as suas as etapas e o seu ponto de término. O digrama é composto por uma piscina, suas raias, e os elementos neles contidos. Junto a cada processo, devemos ter o Manual do Processo, que descreve textualmente os detalhes de execução de cada Atividade, os gatilhos dos Eventos e, se necessário, a definição dos Portais. Juntos, Diagrama e Manual formam o que neste trabalho convencionou-se chamar de Documentação do Processo, definido pelo CBOK como “Modelo do Processo”. Uma variedade de elementos gráficos é formalmente definida pela notação BPMN. Para compreender melhor o processo proposto neste trabalho, o subconjunto de elementos gráficos utilizado será explicado nos tópicos seguintes.
1.3.1 Caso de processo Após o fim da documentação, o processo entra em produção e começa a ser executado. Damos o nome de Caso (ou Instância) a cada execução, onde se espera seguir todas as etapas desenhadas no diagrama. É através das diversas medições feitas nos Casos de um processo que se tem uma idéia da eficiência do mesmo, podendo ser monitorado em tempo real caso esteja automatizado em um BPMS.
1.3.2 Piscina e Raia Esses termos são utilizados principalmente para deixar clara a ocorrência de handoff. Esse termo, no contexto de gestão de processos, denota o momento em que o fluxo de
24
Capítulo 1. Diagrama BPMN e gestão por processo
trabalho deveria ser direcionado para outro responsável ou função, ou seja, “qualquer ponto em um processo onde o trabalho ou a informação passa de uma função para outra” (ABPMP, 2013), e é nessa transferência de responsabilidade que pode ocorrer uma desconexão paralisando o fluxo. Assim, ao desenharmos as atividades fluindo por entre raias ou piscinas fica claro o handoff. Figura 1: Exemplo de raia e piscina
Na Figura 1 fica claro o handoff entre as raias “Game Designer” e “Gerente de projeto” quando o fluxo definido de execução das atividades flui da atividade “Criar argumentos e protótipos” para a “Analisar viabilidade do Jogo”.
1.3.3 Atividade É um trabalho realizado em um processo de negócios (OMG, 2011). Pode ser desenhada de modo a representar um conjunto de outras atividades (atividade de chamada, ou subprocesso) ou uma Tarefa, que é uma atividade atômica que está inclusa no processo. Usa-se uma tarefa quando o trabalho realizado não é detalhado em um nível mais refinado (idem). A representação gráfica de uma tarefa é um retângulo com cantos arredondados, com um nome centralizado identificando a tarefa. Ícones podem ser adicionados ao retângulo para identificar o seu tipo. Neste trabalho convencionou-se, como nomenclatura de atividades, um ou mais verbos no infinitivo seguidos por um ou mais substantivos.
1.3. Documentação do processo
25
1.3.3.1 Atividade de chamada É “um ‘invólucro’ para a invocação de um processo ou tarefa global dentro da execução” (ibidem). Diferente do Subprocesso, que não é usado no corrente trabalho, a atividade de chamada não define as atividades, eventos ou portais dentro do processo onde é definida e sim faz o redirecionamento da execução para outro processo que possui essas definições. A atividade de chamada pode ser usada para reaproveitar as atividades já definidas em outro processo, assim como para simplificar o entendimento do processo onde é desenhada. Essa simplificação ocorre através da abstração do detalhamento de tarefas do outro processo. Figura 2: Exemplo de Atividade de chamada
1.3.3.2 Tarefa de usuário A OMG classifica as tarefas manual e de usuário como sendo distintas. Ambas são executadas por humanos, mas sua diferença básica está no uso de algum sistema informatizado para sua execução (Tarefa de usuário). Nesse trabalho definimos toda tarefa que for executada por um ser humano como “Tarefa de Usuário”, independente das ferramentas utilizadas pelo executor. Figura 3: Exemplo de atividade manual, ou tarefa de usuário
1.3.4 Passos de uma tarefa Uma Atividade é considerada, pela OMG, “um passo de um processo”, mas o conceito de Passo não está claramente definido. Aqui usamos esse termo para definir as
26
Capítulo 1. Diagrama BPMN e gestão por processo
ações que devem ser realizadas para a completude de uma Tarefa, explicando de forma textual, e fora do diagrama, o “como” realizar, enquanto o nome da atividade indica o “o quê”. Vamos tomar por exemplo a atividade descrita na Figura 3, “Arquivar idéia”. Temos a noção de que uma “idéia”, que foi documentada em atividades anteriores, deve ser arquivada, mas não sabemos como ou onde arquivá-la, além de quais outras ações, que não estão diretamente ligadas ao arquivamento, devem ser tomadas, como “informar gerente do arquivamento”. Essas lacunas devem ser preenchidas através da especificação dos Passos da tarefa, não poluindo o desenho do processo com cada pequena ação a ser tomada.
1.3.5 Evento É algo que acontece durante o curso do processo, afetando o seu fluxo e, por vezes, requerendo uma reação. Existem 3 tipos básicos de evento: de início, de fim e intermediários. Além desses, a notação BPMN 2.0 prevê 61 outros tipos. Porém, neste trabalho serão definidos apenas os dois tipos básicos, a seguir.
1.3.5.1 Evento de início Evento de início define por onde um processo inicia. Ele é do tipo “captura” e pode indicar, através do seu nome, o que acontece no meio externo (ao processo) para que inicie. Ele é reconhecido por um círculo cuja linha delimitadora é simples e fina. Os fluxos de sequência podem começar dele, mas nunca terminar nele. Figura 4: Exemplo de evento de início
1.3.5.2 Evento de fim Indica onde o processo terminará. Esse tipo de evento é desenhado da mesma forma que o de início, com a diferença que a linha delimitadora do círculo deve ser mais espessa. Um processo pode ter vários eventos desse tipo e seus subtipos nomeados, significando possíveis conclusões e resultados no processo.
1.3. Documentação do processo
27
Figura 5: Exemplo de evento de fim
1.3.5.3 Evento Terminativo É um subtipo evento de fim. “Representa que todas as atividades do processo deverão ser imediatamente finalizadas. O processo será encerrado e todos os outros fluxos (instâncias) que tenham ligação com o principal também serão finalizados, sem compensações ou tratamento” (M.P.F., 2013). Figura 6: Exemplo de evento terminativo
1.3.6 Portal Originalmente chamado de Gateway, um Portal não denota um trabalho a ser feito, e sim denota uma alteração no fluxo de trabalho ao convergir, divergir ou escolher um ou mais caminhos no fluxo. A OMG declara que um Portal não precisa possuir conectores de Fluxo de sequência de chegada, mas neste trabalho considera-se obrigatória a presença de conectores de chegada e saída, para facilitar o entendimento. A sua principal função é controlar quando e quais conectores de saída serão percorridos. Essa decisão depende dos tipos de Portal, cujo subconjunto usado neste trabalho está descrito a seguir. 1.3.6.1 Exclusivo Como o nome já indica, apenas um dos conectores de fluxo de sequência é percorrido. No ponto de vista de negócios, ele indica uma decisão e percorre o caminho do fluxo adequado à decisão. É desenhado em forma de um losango com um “X” interno e os fluxos de sequência de saída devem especificar a condição em que serão percorridos.
28
Capítulo 1. Diagrama BPMN e gestão por processo
Quando esse Portal está desenhado de forma que recebe vários fluxos de sequência, durante a execução do processo ele percorrerá o caminho de saída no momento de chegada do primeiro fluxo, sem esperar que os demais caminhos sejam percorridos. Figura 7: Exemplo de portal exclusivo
1.3.6.2 Paralelo Utilizado quando não há decisão a ser tomada, pois todos os fluxos de sequência de saída devem ser seguidos simultaneamente. Quando existem vários fluxos de sequência de chegada, esse portal obriga a execução do processo a esperar a chegada de todos para seguir em frente. Figura 8: Exemplo de portal paralelo
1.3.7 Fluxo de sequência É usado para exibir a ordem dos elementos em um processo. Cada fluxo de sequência possui apenas um elemento de origem (de onde dizemos que o fluxo “sai”) e um elemento de destino (onde ele “chega”). Deve ser desenhado como uma linha fina, sendo finalizado por uma seta preenchida. Na Figura 9 vemos o exemplo de 5 fluxos de sequência, onde um deles nos informa que a Tarefa “Lançar jogo” ocorre após do Portal “Junção 5”.
1.3. Documentação do processo
Figura 9: Exemplo de fluxos de sequência
29
31
2 Desenvolvimento de um tipo de software: game Entende-se software como sinônimo de produto de software que é o conjunto de programas de computador, procedimentos e possível documentação e dados associados (ABNT, 2009). Assim, pode-se categorizar um game como um tipo específico de software, que pode ser tratado de forma semelhante quanto à organização de suas atividades e aos artefatos envolvidos. O Guia Geral MPS de Software, que tem como objetivo descrever o modelo de referência para melhoria de processos de desenvolvimento de software, aponta 19 processos a serem definidos e seguidos para que uma empresa possa ser considerada madura na atribuição específica de desenvolver software. Esses processos não são detalhados por esse guia, que documenta apenas os seus resultados esperados, e deixa a empresa a cargo de defini-los. Um desses processos, “Gerência de Configuração”, foi proposto neste trabalho e atende parcialmente às definições do MPS.BR, como podemos ver a seguir.
2.1 Gerência de configuração Os artefatos produzidos durante o processo de desenvolvimento de jogos podem existir para servir a vários propósitos, como: meio de comunicação entre participantes, dados de gestão, parte do produto final, código fonte de implementação, configuração do software, etc. Alguns adquirem importância vital para o jogo ou para a instituição, outros são usados apenas como esboço temporário. Definimos então que o GDD (Game Design Document, ou, em tradução livre, “Documento do Projeto do Jogo”) será dividido em vários documentos que, juntos, conterão as informações necessárias para garantir a comunicação entre os envolvidos no desenvolvimento do game, sem atenuar a complexidade do seu gerenciamento enquanto artefato. O gerenciamento dos GDDs seguirá regras bem definidas, guiados pelos resultados esperados pelo processo Gerência de Configuração. O propósito do processo Gerência de Configuração é estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou trabalho e disponibilizá-los a todos os envolvidos (MPS.BR, 2012, item 9.2.2).
Os itens de configuração (que neste trabalho são chamados “artefatos”), precisam ser armazenados, enviados e controlados mediante as regras definidas pelo gerente de
32
Capítulo 2. Desenvolvimento de um tipo de software: game
configuração. De acordo com o MPS.BR, essas regras devem ser definidas tendo em vista alguns resultados que devem ser alcançados, dentre eles: • Um Sistema de Gerência de Configuração é estabelecido e mantido; • Os itens de configuração são identificados com base em critérios estabelecidos; • Os itens de configuração sujeitos a um controle formal são colocados sob baseline; • O armazenamento, o manuseio e a liberação de itens de configuração e baselines são controlados; Simplificando esse modelo, para este processo os artefatos devem ficar armazenados em um repositório de controle de versão (como Subversion ou GIT), e deve ser gerada uma baseline sempre que uma nova versão do jogo for criada para testes ou homologação. Esse repositório deve estar organizado usando o seguinte formato de estrutura de pastas no sistema de arquivos do repositório: • (pasta) – (pasta) GDD – (documento) Proposta de Jogo – (documento) Elementos do Jogo – (documento) Narrativa – (documento) Regras • (pasta) Testes – (documento) Roteiro de teste - Contexto de jogo – (documento) Roteiro de teste - Level • (pasta) Arte gráfica – (pasta) Concept ∗ (documentos) – (pasta) Animações ∗ (pasta) · (documentos) ∗ (pasta) – (pasta) Sound design ∗ (documentos)
2.1. Gerência de configuração
33
– (pasta) desenv ∗ (pasta) modulo_jogo · (documentos) ∗ (pasta opcional) modulo_servidor · (documentos) ∗ (pasta opcional) modulo_ · (documentos)
35
3 O Processo de Desenvolvimento de Jogos A proposta do Processo de desenvolvimento de jogos descreve atividades necessárias para conceber, avaliar, gerenciar, desenvolver e avaliar a qualidade o jogo. Foi concebido de forma a tirar proveito do conceito de Design Iterativo, não de uma forma pura, onde a na primeira etapa já constrói um protótipo executável do jogo, mas de forma a trazer resultados e desafios nas primeiras fases de desenvolvimento, permitindo a equipe aprender sobre o jogo, tomando decisões antes que seja difícil alterá-lo. O processo foi desenhado de forma que existem 3 fases, cujas atividades são identificadas no diagrama pelas respectivas cores: a) Primeira Fase “Concepção e contextualização” (amarelo): como o nome sugere, é a fase onde o jogo é concebido e os membros da equipe são contextualizados. Nessa fase o gerente de projeto deve estar preparado para mudanças de escopo, dada a liberdade da equipe em adaptar-se as tecnologias, soluções, jogabilidade, mecânica e nuances da história do jogo. b) Segunda Fase “Realização” (azul): ao contrário da primeira fase, nesta deve-se concentrar no que foi decidido previamente, buscando evitar alterações no escopo do projeto e evitando retrabalho. c) Terceira Fase “Entrega” (vermelho): onde se gasta esforço para empacotar e lançar o jogo, e registrando os bugs conhecidos. Nessa fase deve haver uma atenção especial dos responsáveis pela de qualidade do produto e da Gestão de configuração, evitando enganos triviais no pacote que será distribuído.
3.1 Glossário Nesta documentação serão encontrados termos cujo significado particular se aplica apenas no contexto deste processo. Para isso, estão definidos a seguir: a) Arte conceito: é uma forma de ilustração usada para transmitir uma idéia antes de de ser inserida no produto final, e “permite ao artista projetar o look’n’feel de um filme, jogo ou personagem antes de entrar na fase cara de produção” (GAHAN, 2008). b) Contexto de jogo: usado para definir o escopo de um aspecto a ser descrito. Quando se diz que algo precisa ser feito “em contexto de jogo”, o escopo abrange todos ou mais de um level, e/ou partes do jogo que não estão em levels, como HUDs, rankings , mapas, etc., independente de serem elementos diegéticos.
36
Capítulo 3. O Processo de Desenvolvimento de Jogos
c) Baseline: Uma versão definida e fixada de um item de configuração em um determinado momento do seu o ciclo de vida (ABNT, 2009). d) Contexto de Level: é o escopo mais específico. Usado para descrever elementos ou aspectos de um único level. e) Diegese/Diegético: refere-se a todo elemento que está contido no universo ficcional de uma determinada obra (NETO, 2013), assim, diz respeito aos elementos que fazem parte da narrativa do jogo, interagindo com o personagem ou cenário. f) HUD : Do inglês “heads-up display”. “Diz respeito aos componentes sempre visíveis para o jogador, como por exemplo, uma contagem do tempo ou de pontos. Ao projetar a interface do jogo, é importante que alguns elementos estejam visíveis para comunicar ao jogador seu progresso de acordo com suas ações” (BOLDT; GARONE, 2013). g) Level : é um estágio do jogo. Dependendo da forma que o jogo for construído, pode ser que o jogador não perceba nenhum tipo de intervalo entre os levels, mas para efeitos de documentação e organização, é recomendado que o jogo seja dividido em levels. h) Look and feel ou look’n’feel: “na concepção de software o termo é utilizado em relação a interface gráfica do usuário e compreende os aspectos da sua concepção, incluindo elementos como cores, formas, disposição e tipos de caracteres (o ’Look’), bem como o comportamento de elementos dinâmicos tais como botões, caixas, e menus (o ’Feel’)”. Neste trabalho, o “feel” é definido pela animação de personagens e cenário e pela interação com as interfaces do jogo.
3.2 O diagrama BPMN O diagrama pode ser visto na Figura 10, contendo os elementos cujos significados foram explanados na seção 1.3
3.3 Papéis e acúmulo de funções As raias definidas no processo definem os papéis necessários para sua execução, contudo, não torna obrigatória a exclusividade de entre a relação participante-função. Ou seja, um determinado membro da equipe pode assumir dois ou mais papéis. Espera-se que, numa instituição realmente pequena, atribuir-se o papel de Gerente de projeto ao game designer, por exemplo.
3.4. Desvio do processo
37
3.4 Desvio do processo Após a adoção do processo, as atividades e seus respectivos passos devem ser realizadas. Isso não impede que o executor tenha outras ações que ajudem a alcançar o objetivo do processo, que é, por fim, desenvolver o jogo. Essas ações podem tomar tal importância a ponto de serem incorporadas ao processo, em forma de atividades ou passos de atividades. A teoria da gestão por processo defende essencialmente a visão de processos “ponta a ponta” a partir do foco no cliente (JESUS L.; MACIEIRA, 2014, p. 31), e não no processo, o que reforça a importância de se usar o processo como um guia geral para as atividades da equipe, seja o jogo uma demanda interna, onde o cliente do processo é a própria instituição, ou uma desejo um contratante de desenvolvimento.
3.5 Atividades 3.5.1 Criar argumento e protótipos • Objetivo: efetuar as ações necessárias para conceber, aprofundar e documentar uma idéia de forma concisa, que seja de fácil entendimento e possa ser arquivada para futuras referências. A motivação geradora da necessidade de se aprofundar nessas idéias de jogo podem surgir de várias fontes, desde um cliente que contrata a equipe para realizar o desenvolvimento até o uso de uma das propostas de jogo arquivadas e não implementadas no passado, mas que, por mudanças de cenário, se aplicam aos interesses da instituição. • Passos: essa foi desenhada como uma atividade de chamada, que direciona o fluxo para o subprocesso “Criar argumento e protótipos” (ver Figura 10). Esse subprocesso é uma sugestão, e esse trabalho não se aprofunda nessa etapa. • Critério de saída: documento Proposta do jogo, com protótipos explicativos. Essa atividade gera o que é chamado de Especificação de trabalho do Projeto (ETP) (PMI, 2013, p. 67). • Responsável: Game designer
3.5.2 Analisar viabilidade do jogo • Objetivo: decidir se o jogo idealizado será desenvolvido, analisando o retorno desejado para a instituição. • Passos:
38
Capítulo 3. O Processo de Desenvolvimento de Jogos
– Convocar o game designer para realizar pitching, utilizando a “Proposta de Jogo” como base da apresentação – Avaliar o alinhamento das características do jogo com o foco da instituição – Decidir entre desenvolver o jogo ou não – Caso positivo, preencher os tópicos Escopo, Riscos de alto nível, Requisitos para aprovação do jogo e macro-cronograma estimado, da Proposta de Jogo • Critério de saída: Se o jogo for aprovado deve uma Proposta de jogo pronta para ser assinada como Termo de abertura do projeto (TAP). Caso contrário, a proposta deve ser preparada para arquivamento. • Responsável: Gerente de projeto
3.5.3 Arquivar idéia Essa atividade é facilmente automatizada, dadas as tecnologias atualmente implementadas. • Objetivo: Guardar a idéia em formato digital num catálogo organizado, passível de consulta posterior. • Passos: Classificar o jogo (quanto a produção, estilo, jogabilidade, conteúdo, gráfico, tipo de narrativa) e armazenar a Proposta de jogo eletronicamente • Critério de saída: A proposta deve estar devidamente armazenada e de fácil recuperação. • Responsável: Game designer
3.5.4 Elaborar documentação preliminar • Objetivo: documentar o que for necessário para que outras equipes, incluindo Sound designer, Animadores, Designers gráfico e Desenvolvedores iniciem seu trabalho. • Passos: 1. Descrever cenário e ambiente e tema do jogo 2. Descrever os personagens(fenótipos, comportamentos, psicologia, história básica) e ambiente dos cenários. Informar caso não se aplique. 3. Descrever look’n’feel desejado 4. Descrever quais sentimentos deseja despertar no jogador 5. Documentar regras em contexto de jogo.
3.5. Atividades
39
• Critério de saída: GDD com alguns tópicos de alguns documentos preenchidos: – Elementos do jogo Personagens (descrição da aparência, psicologia, história), artefatos possuídos pelo personagem, cenários – Narrativa (Contexto) • Responsável: Game Desinger
3.5.5 Planejar desenvolvimento • Objetivo: executar os seguintes processos do PMBOK relativos a fase de iniciação do projeto: Desenvolver plano de gerenciamento do projeto, Coletar requisitos, Definir escopo, Estimar Durações das atividades • Passos: Analisando os GDD extrair informações para confeccionar o Cronograma, com os marcos indicando as fases deste processo (alguns levels considerados importantes também podem representar marcos no projeto); Declaração de escopo, contendo os levels que serão desenvolvidos e outras particularidades do que for implementado e que podem estar contidos neste documento, como artes conceituais, trilhas sonoras, engine exclusivamente desenvolvidas, etc; Termo de aceitação do projeto. • Critério de saída: Plano do projeto. • Responsável: Gerente de projeto
3.5.6 Criar arte conceito dos elementos das animações • Objetivo: Priorizar a arte conceito dos elementos que serão usados pelas animações de introdução, finalização, e loopings de contexto de jogo. “Uma parte essencial de qualquer jogo eletrônico é sua apresentação visual. É ela que atrai o usuário ao produto inicialmente” (BOLDT; GARONE, 2013). • Passos: entrar em sintonia com os animadores para que o fluxo de trabalho ocorra em paralelo, ordenando o esforço da concepção de acordo com a necessidade daqueles. • Critério de saída: todas as arte conceito dos elementos necessários a finalização das animações requisitadas, registradas no documento Elementos do Jogo. • Responsável: Designer Gráfico
40
Capítulo 3. O Processo de Desenvolvimento de Jogos
3.5.7 Criar interfaces de contexto de jogo • Objetivo: elaborar as interfaces onde o jogador interage com as informações do jogo, de forma diegética ou não. Ex.: Mapas, menus, Salvamento/carregamento de jogo, Lista de troféus conquistados/a conquistar, HUDs • Passos: acessar a documentação existente e extrair o look’n’feel decidido para, a partir dele, adaptar as interfaces necessárias ao jogo. Após a finalização, alterar o documento Elementos do Jogo incluindo um protótipo explicativo e de alta fidelidade na seção destinada a tal. • Critério de saída: arte conceitual das interfaces de contexto de jogo totalmente definidas. • Responsável: Designer Gráfico
3.5.8 Criar animatics iniciais • Objetivo: Criar as animações de introdução, finalização, cut scenes, e de movimentação de contexto de jogo. • Passos: 1. Usar os rascunhos e imagens presentes em “Proposta de Jogo” e “Elementos do Jogo”, assim como os roteiros (se presentes) em “Narrativa” para criar os animatics 2. Apresentar ao game designer para aprovação, registrar mudanças necessárias e realizar mudanças, até a aprovação ser concedida; 3. Entrar em sintonia com a a equipe de Design Gráfico e Sound Desginer, requisitando os elementos necessários para dar continuidade ao seu trabalho. Enquanto não for atendido, usar elementos prontos para criar versões “alpha” • Critério de saída: Animatics criados e aprovados pelo game designer. • Responsável: Animador
3.5.9 Desenvolver animações inicial e final • Objetivo: Desenvolver as animações inicial e final do jogo, se houverem, com um nível de detalhamento possível de ser a verão final. Nessa etapa devem ser definidos os estereótipos dos personagens e aplicado o appeal que será usado no jogo.
3.5. Atividades
41
• Passos: Baseado nos animatics aplicar as arte conceito já finalizadas e detalhar os movimentos dos personagens e dos cenários, atentando para o estilo e timing que o Sound Designer está confeccionando • Critério de saída: Animações inicial e final finalizadas (com possibilidade de alteração) • Responsável: Animador
3.5.10 Criar tema e efeitos sonoros iniciais • Objetivo: Criar a concepção dos elementos sonoros e musicais necessários ao jogo • Passos: Usando os elementos presentes nos documentos “Elementos do Jogo”, “Proposta do jogo” e “Narrativa”, selecionar (de um acervo da instituição) ou iniciar a concepção dos elementos sonoros, priorizando aqueles que serão usados nos animatics, através de pedidos feitos pela equipe de animação • Critério de saída: Elementos sonoros iniciais • Responsável: Sound Designer
3.5.11 Realizar provas de conceito • Objetivo: Implementar simulacões de partes do jogo que não foram implementadas em jogos anteriores pela equipe, buscando documentar o máximo possível nas novas técnicas. • Passos: Analisar os documentos do GDD existentes e extrair os pontos cujas técnicas de implementação são ainda desconhecidas e implementar simulações do que for necessário. Após as simulações, obter aprovação do Game Designer, registrando as mudanças necessárias efetuá-las, até a aprovação seja obtida. • Critério de saída: Documentação das técnicas descobertas; implementação da simulação. • Responsável: Programador.
3.5.12 Documentar e iniciar testes • Objetivo: contextualizar os testadores às novas implementações e ao ambiente do jogo e iniciar a documentação dos roteiros de teste. • Passos: analisar os documentos de GDD existentes, incluindo Regras e Narrativa e confeccionar Roteiros de teste relacionados as provas de conceito efetuadas pelos
42
Capítulo 3. O Processo de Desenvolvimento de Jogos
programadores e a todos os itens já documentados no GDD. Na planilha “Roteiro de Testes”, nas abas “CT_X” (casos de teste), preencher apenas as partes em cinza, que descrevem os testes a serem feitos. Ao finalizar a criação dos roteiros, atualizar a aba “Relatório” contendo a quantidade de abas “CT_X” existentes. • Critério de saída: roteiros de teste iniciais, que serviram de insumo para as demais partes do jogo. • Responsável: Testador
3.5.13 Pré-documentar levels • Objetivo: Amadurecer a documentação de Contexto de Jogo e iniciar a documentação de contexto de level. • Passos: 1. Refinar e completar documentação relativa aos elementos, narrativa e regras de contexto de Jogo 2. Catalogar levels já existentes, criando os tópicos necessários nos documentos Regras e Narrativa 3. Criar, de forma superficial, os roteiros das cut scenes necessários 4. Caso as atividades que estão sendo desenvolvidas pela restante da equipe durem mais tempo que o necessário para a documentação superficial desta atividade, aprofundar documentação existente, como previsto na atividade “Refinar documentação” • Critério de saída: Documentos de GDD atualizados com os levels existentes no jogo • Responsável: Game designer
3.5.14 Refinar documentação • Objetivo: aprofundar os detalhes de toda a documentação, atualizando-a com as mudanças decididas durante a primeira fase do processo. Essa atividade marca a transição entre as fases “Concepção e Contextualização” e de “Realização”, e é nela que o escopo do projeto deve estar maduro. Assim, se necessário, o game designer deve recorrer aos membros da equipe para revisões do que está sendo documentado. • Passos: 1. Comunicar ao gerente de projeto para cada novo level “descoberto” ou grande variação de prazo
3.5. Atividades
43
2. Realizar workshops com a equipe para esclarecer o que está sendo documentado, efetuando alterações de acordo com os feedbacks da equipe, seja para facilitar o entendimento ou para correções 3. Gerar baseline da documentação 4. A medida que os levels vão sendo documentados, já liberar as demais equipes para iniciar suas atividades, antecipando a execução e diminuindo o desperdício de tempo • Critério de saída: GDD completo • Responsável: Game Designer
3.5.15 Desenvolver Level • Objetivo: Implementar os algoritmos necessários para finalizar um determinado level do jogo, integrando os artefatos produzidos pelas outras equipes. • Passos: Escrever todo o código necessário para a execução do Level (HUDs, inteligência artificial necessária ao Level, Regras do Level, etc). Caso não tenha sido prevista a criação de algum artefato necessário no Level, o Programador (ou programador líder) deve solicitar a criação ao Gerente de projeto, reportando um impedimento, e continuar a implementação utilizando um elemento temporário que preencha aquela lacuna. O Gerente de projeto, por sua vez, deve priorizar o desenvolvimento do level, em detrimento das tarefas em paralelo sendo executadas pelas equipes. • Critério de saída: Level totalmente implementado, sem elementos temporários. • Responsável: Programador
3.5.16 Criar roteiro de teste • Objetivo: Escrever os roteiros de teste do jogo, tanto em nível de Jogo quanto em nível de Level • Passos: Nas planilhas de Roteiro de teste, tanto de contexto de jogo quanto de level, preencher as lacunas em cinza, criando uma aba “CT_X” para cada novo caso de teste necessário. As diretrizes para de preenchimento da planilha estão presentes na própria planilha. Ao finalizar cada planilha, atualizar a aba “Relatório’. • Critério de saída: Roteiros de teste devidamente preenchidos • Responsável: Testador
44
Capítulo 3. O Processo de Desenvolvimento de Jogos
3.5.17 Sincronizar animações • Objetivo: sincronizar as animações finais com o áudio criado. • Passos: Realizar todas as sincronias labiais, de efeito sonoro e leitmotiv’s. Inserir o som ambiente, atentando para a correta construção da paisagem sonora e inserir a trilha musical. • Critério de saída: Animações iniciais e finais finalizadas. • Responsável: Sound Designer.
3.5.18 Desenhar elementos de contexto de Level • Objetivo: Criar a arte conceito de cada elemento a nível de Level. • Passos: Analisar o documento Elementos do Jogo e catalogar quais os elementos precisam de finalização, priorizar os elementos a serem desenhados de acordo com a necessidade dos animadores e dos desenvolvedores, nessa ordem, alterando o documento Elementos de jogo com um exemplar finalizado. • Critério de saída: Todos os elementos de jogo desenhados. • Responsável: Designer Gráfico
3.5.19 Animar elementos de contexto de Level • Objetivo: Confeccionar imagens necessárias para animações usadas nos levels. • Passos: Analisando os GDD e consultando os desenvolvedores, extrair e catalogar as animações necessárias para os levels para então solicitar aos programadores que criem uma ordem de prioridade das animações. Para cada animação deve-se solicitar e priorização as arte conceito junto ao Designer gráfico, enquanto criam a animação com esboços de baixa fidelidade, para então finaliza-lá. • Critério de saída: Animações de level finalizadas; cut scenes prontas para sincronia sonora. • Responsável: Animador
3.5.20 Criar temas e efeitos sonoros do jogos • Objetivo: Criar todos sons que serão usados em contexto de level e de jogo.
3.5. Atividades
45
• Passos: A ordem de criação de efeitos sonoros e temas musicais deve ser baseada pela priorização dos programadores. Tendo essa priorização em mãos, deve-se criar os efeitos sonoros diegéticos reaproveitáveis em cada level, os sons usados pelos HUDs Elaborar temas musicais específicos dos levels • Critério de saída: Todos o material sonoro que serão usados no jogo. • Responsável: Sound Designer.
3.5.21 Sincronizar cut scenes • Objetivo: Realizar a sincronia dos sons das cut scenes • Passos: Realizar todas as sincronias labiais, de efeitos sonoros e leitmotiv‘s; inserir o som ambiente, atentando para a correta construção da paisagem sonora, e a trilha musical. • Critério de saída: Cut scenes finalizadas. • Responsável: Sound designer.
3.5.22 Testar Level • Objetivo: Testar o level por completo. • Passos: 1. Executar os testes presentes no Roteiro de Teste específico do level 2. Executar os testes presentes no “Roteiro de Teste - Contexto de Jogo” das funcionalidades impactadas pelo level 3. Acrescentar novos casos de teste, se necessário 4. Gerar o relatório de testes, atentando para a descrição completa de reprodução dos erros 5. Criar uma cópia do modelo, renomeando o nome do arquivo para “Relatório de Teste - - ”, onde: – = identificador do level ou “Contexto de Jogo”. Ex: “Level escondido 1”, “Level 3.2”, etc. – = sequencial do relatório. Ex: “Relatório de Teste - Level 3 - 1”, “Relatório de Teste - Level 3 - 2”, etc. • Critério de saída: Relatório de testes. • Responsável: Testador
46
Capítulo 3. O Processo de Desenvolvimento de Jogos
3.5.23 Retestar levels • Objetivo: Refazer os testes dos levels corrigidos. Essa atividade tem prioridade sobre o teste de um novo level. • Passos: 1. Extrair os erros reportados do relatorio de testes relativo as correções feitas, e retesta-los 2. Analisar o roteiro para selecionar e executar os os casos de teste possivelmente afetados pela correção. Se possível, retestar o level inteiro 3. Executar os testes presentes no “Roteiro de Teste - Contexto de Jogo” das funcionalidades impactadas pelas correções 4. Acrescentar novos casos de teste, se necessário 5. Gerar novo relatório de testes, da mesma forma que a atividade Testar level. • Critério de saída: Relatório de testes. • Responsável: Testador.
3.5.24 Corrigir levels • Objetivo: Corrigir os erros reportados pelos testadores. Essa atividade tem prioridade sobre a Desenvolver Level. • Passos: Extrair os erros reportados dos últimos relatório de testes ainda não corrigidos e efetuar a correção no código • Critério de saída: Nova versão do jogo. • Responsável: Programador
3.5.25 Lançar jogo • Objetivo: Criar o pacote de forma que o jogo possa ser distribuído. • Passos: 1. Empacotar jogo, nas diversas formas necessárias para serem distribuídas pelos meios planejados 2. Implantar servidores, se houverem 3. Publicar jogo nos meios de distribuição
3.5. Atividades
4. Efetuar teste do pacote, simulando a aquisição por parte de um jogador 5. Efetuar publicidade necessária para divulgação • Critério de saída: Jogo publicado e divulgado. • Responsável: Game designer
47
48
Capítulo 3. O Processo de Desenvolvimento de Jogos
Figura 10: Diagrama do processo proposto
49
Referências ABNT. Nbr iso/iec 12207 – tecnologia de informação-processos de ciclo de vida de software. Rio de Janeiro: ABNT, 2009. Citado 2 vezes nas páginas 31 e 36. ABPMP. Guia para o Gerenciamento de Processos de Negócio - Corpo Comum de R Conhecimento - (BPM CBOK ). [S.l.: s.n.], 2013. Citado 4 vezes nas páginas 21, 22, 23 e 24. BOLDT, A.; GARONE, P. M. C. Arte conceitual na concepção de jogos. 2013. Citado 2 vezes nas páginas 36 e 39. CARMO, W. C. do; ALBUQUERQUE, A. B. Project management suported by business process management. 2014. Citado na página 22. GAHAN, A. Game Art Complete. [S.l.]: Elsevier, 2008. Citado na página 35. JESUS L.; MACIEIRA, A. Repensando a gestão por meio de processos. [S.l.]: EloGroup, 2014. Citado na página 37. M.P.F., M. P. F. Manual de Gestão por Processos. [S.l.], 2013. Disponível em: . Citado na página 27. MPS.BR, G. G. Mps. br - melhoria de processo do software brasileiro. 2012. Citado na página 31. NETO, J. Interfaces diegéticas e o senso de imersão. [S.l.], 2013. Disponível em: . Citado na página 36. OMG. Notation (bpmn) version 2.0. Object Management Group specification, 2011. Citado 2 vezes nas páginas 22 e 24. PMI, P. M. I. Um guia do Conhecimento em Gerenciamento de Projetos (Guia R PMBOK ). [S.l.]: PMI, 2013. Citado na página 37. SALEN, K.; ZIMMERMAN, E. Rules of Play: Game design Fundamentals. [S.l.]: MIT Press, 2004. Citado na página 19.
Anexos
53
ANEXO A – Proposta de jogo
Proposta de jogo:
54
ANEXO A. Proposta de jogo
Histórico Versã o
Data
Responsável
Observações
55
Índice Histórico Índice Objetivo deste documento Argumento principal Categorização Produção Estilo Jogabilidade Plataformas Protótipos Macrocronograma estimado
56
ANEXO A. Proposta de jogo
1.
Objetivo deste documento ● Registrar uma idéia de jogo de forma concisa, que seja de fácil entendimento e possa ser arquivada para futuras referências. Esse documento é parte integrante do GDD. ● Selar acordo entre o patrocinador e o gerente de projeto de desenvolvimento sobre os seguintes aspectos: ○ Escopo ○ Cronograma de alto nível ○ Riscos de alto nível ○ Requisitos para aprovação do o jogo
2.
Argumento principal
3.
Categorização
57
4.
3.1.
Produção
3.2.
Estilo
3.3.
Jogabilidade
3.4.
Plataformas
Protótipos
5.
Macro-cronograma estimado
6.
Escopo
58
ANEXO A. Proposta de jogo
7.
Riscos de alto nível
8.
Requisitos para aprovação do jogo
59
ANEXO B – Elementos do Jogo
Elementos do jogo
60
ANEXO B. Elementos do Jogo
Histórico Versã o
Data
Responsável
Observações
61
Índice Histórico Índice Objetivo deste documento Personagens Características comuns Artefatos Cenários (locação)
62
ANEXO B. Elementos do Jogo
1.
Objetivo deste documento Documentar as características de cada elemento usado no jogo, visando facilitar a
comunicação entre membros da equipe de desenvolvimento de jogos, o reuso de elementos relacionados e a criação de novos elementos. Esse documento é parte integrante do GDD.
2.
Personagens 2.1.
Características comuns
2.2.
● Nome: ● Avatar: .
● Descrição do visual: ● Psicologia: ● História: ● Art concept:
63
2.3.
3.
Artefatos 3.1.
● Nome: ● Imagem de exemplo:
● Descrição: ● Art conecpt:
4.
Cenários (locação)
4.1.
● Nome: ● Imagem de exemplo:
64
ANEXO B. Elementos do Jogo
● Descrição:
5.
Interface de jogo
5.1.
5.2.
5.3.
65
ANEXO C – Narrativa
Narrativa
66
ANEXO C. Narrativa
Histórico Versã o
Data
Responsável
Observações
67
Índice Histórico Índice Objetivo deste documento Contexto Desenvolvimento Durante o jogo Leve N...
68
ANEXO C. Narrativa
1.
Objetivo deste documento ● Descrever a história do plano de fundo do jogo, assim como o que deve ser desenvolvido durante ele.
Esse documento é parte integrante do GDD.
2.
Contexto Informar que é necessário referenciar as histórias dos elementos de jogo presentes
no documento próprio.
3.
Interatividade da Narrativa
69
4.
Desenvolvimento da história 4.1.
Durante o jogo
4.2.
Level
5.
Roteiros
5.1.
Animação de Introdução
5.2.
Animação final
5.3.
5.4.
71
ANEXO D – Regras
Regras
72
ANEXO D. Regras
Histórico Versã o
Data
Responsável
Observações
73
Índice Histórico Índice Objetivo deste documento Personagens Características comuns Artefatos Cenários (locação)
74
ANEXO D. Regras
1.
Objetivo deste documento Documentar as regras do jogo, explicitando os valores e parâmetros que serão
usados como insumo para os programadores, lembrando que várias das informações aqui contidas serviram de base para criação gráfica e sonora. Esse documento é parte integrante do GDD.
2.
Mecânica Y o jogador atacado ganhar (pontuação), o defensor recebe (X Y) pinos. Se X
3.
Regras de Contexto de Jogo
4.
Regras de Contexto de level 4.1.
Nivel 1
4.1.1.
Regras de contexto de jogo
4.2.
Nivel 4.2.1.
Regras de contexto de jogo
Roteiro de Testes - Level
Número de passos:
Número de casos de teste:
77
ANEXO E – Roteiro de Teste
3 4
Resultado esperado
Nome do CT:
2
Passo 1
4 [1]
Seq.
Resultado encontrado
0 Status do teste
78 ANEXO E. Roteiro de Teste
11.43% 1 1 2
Erro minor Erro major Erro blocker
Números de erro
Testes com erro (visão total):
4
Número de CTs com erro: 25.71%
9
Casos de teste executados:
Testes efetuados (visão total):
35
Casos de teste existentes (visão total):
Data final dos testes:
Data inicial dos testes:
Relatório de Testes - -
22.22%
11.11%
11.11%
44.44%
79
ANEXO F – Relatório de testes
9 Caso de teste
2 Roteiro
Erro minor
Sucesso
Erro Blocker
Erro Blocker
Erro major
Resultado
Erro Encontrado
80 ANEXO F. Relatório de testes
Lihat lebih banyak...
Comentários
