O documento aborda a mecânica de jogos digitais e a importância da documentação no desenvolvimento de jogos utilizando a metodologia Behavior Driven Development (BDD). Destaca a crescente indústria de jogos no Brasil, a necessidade de comunicação entre equipes e a utilização de metodologias ágeis para melhorar o processo de criação e design de jogos. Inclui discussões sobre a definição de jogos, suas mecânicas, equipes envolvidas e técnicas de design.

1. Mecânica de
Jogos Digitais:
documentando para
desenvolvimento com
Behaviour Driven
Development.

2. Ministrando:
Francisco Narto Pereira
Júnior

3. Quem Sou?
 Francisco
Narto Pereira Júnior;

4. Quem Sou?
 Francisco
Narto Pereira Júnior;
 Tecnólogo em Análise e Desenvolvimento
de Sistemas (IFRN) e graduando em
Ciências e Tecnologia (UFRN);

5. Quem Sou?
 Francisco
Narto Pereira Júnior;
 Tecnólogo em Análise e Desenvolvimento
de Sistemas (IFRN) e graduando em
Ciências e Tecnologia (UFRN);
 Pós-graduando em Especialização em
Jogos Digitais: Desenvolvimento e Design
(Estácio/iDez - JP).

6. Quem Sou?
 Bolsista
na Bugware/ABXY desde 11/2009
como programador;

7. Quem Sou?
 Bolsista
na Bugware/ABXY desde 11/2009
como programador;
 Bolsista CNPq de 09/2010 à 09/2012, em
processo de desenvolvimento de jogos
digitais. Também me mantive na empresa
citada por esse período.

8. Agenda
 Metodologia;
 Aplicabilidade;
 Justificativa;

9. Agenda
O
que é um jogo;
 Desenvolvimento de jogos;
 Design de jogos;
 Mecânica de jogos e Documentação;
 Conclusão.

10. Metodologia
 Apresentação



dividida em:
Abordagem sobre o que é jogo e como é
um jogo digital;
Explanação sobre a equipe e processo de
desenvolvimento;
Técnicas de design usadas em criação
jogos;

11. Metodologia
 Apresentação



dividida em:
Explicação sobre o que é Mecânica de
jogo e seus elementos;
Aplicação dos conceitos para gerar
documentação da mecânica no
documento de projeto de jogo (Game
Design Document – [GDD]);
Conclusão do resultado e esclarecimentos.

12. Aplicabilidade
 Desenvolvimento
de jogos com
metodologia ágil;
 Comunicação ubíqua entre
desenvolvedores e stakeholders;
 Exercício de documentação em projeto
de jogos digitais;
 Fomentação para desenvolvedores indie.

13. Justificativa
A
indústria de jogos é a 2ª maior do
mundo;
 O desenvolvimento de jogos no Brasil
cresce a cada ano;
 Há um crescimento no investimento em
jogos digitais no Brasil por
desenvolvedores;
 Pesquisas na indústria de jogos estão
cada vez aumentando;

14. Justificativa
A
documentação de um jogo é essencial
para que ele possa ser bem realizado
pela equipe de desenvolvimento;
 Ela é fundamental para projetos de maior
porte;
 Comunicação entre designers e equipe
de desenvolvimento e stakeholders é
primordial para que o projeto tenha a
qualidade esperada.

15. O que é jogo?

16. O que é jogo?

“Jogos são um exercício de sistemas de controle
voluntário, em que há uma competição entre forças,
limitadas por regras para produzir um desequilíbrio. ”
-
Eliot Avedon e Brian Sutton-Smith
(The Study of Games, 1971)

17. O que é jogo?

“Jogos são um exercício de sistemas de controle
voluntário, em que há uma competição entre forças,
limitadas por regras para produzir um desequilíbrio. ”
-

Eliot Avedon e Brian Sutton-Smith
(The Study of Games, 1971)
“[Um jogo é] uma estrutura interativa de significado
endógeno que exige que os jogadores lutem por um
objetivo”
Greg Costikyan
(I Have No Words, and I Must Design, em Interactive Fantasy 2, 1994)
-
-

18. O que é jogo?

“Um jogo é um sistema fechado, formal, que envolve os
jogadores em um conflito estruturado, e resolve-o na
forma de um resultado desigual”
-
Tracy Fullerton, Chris Swain e Steven Hoffman
(Game Design Workshop, 2004)

19. O que é jogo?

“Um jogo é um sistema fechado, formal, que envolve os
jogadores em um conflito estruturado, e resolve-o na
forma de um resultado desigual”
-

Tracy Fullerton, Chris Swain e Steven Hoffman
(Game Design Workshop, 2004)
“Um jogo é uma atividade de solução de problemas,
encarada de forma lúdica”
Jesse Schell
(The Art of Game Design: a book of lenses, 2008)
-
-

20. O que há num jogo digital?

21. O que há num jogo digital?

Tecnologia (infraestrutura):

Plataforma, linguagem de programação, arquitetura, IDE,
controles de usuário etc.

22. O que há num jogo digital?

Tecnologia (infraestrutura):


Plataforma, linguagem de programação, arquitetura, IDE,
controles de usuário etc.
História (ficção):

Enredo, narrativa, personagens, mundo etc.

23. O que há num jogo digital?

Tecnologia (infraestrutura):


História (ficção):


Plataforma, linguagem de programação, arquitetura, IDE,
controles de usuário etc.
Enredo, narrativa, personagens, mundo etc.
Estética (sentidos);

Design gráfico, músicas, efeitos sonoros, cinemática, vídeos,
desenhos, modelagem 3D etc.

24. O que há num jogo digital?

Tecnologia (infraestrutura):


História (ficção):


Enredo, narrativa, personagens, mundo etc.
Estética (sentidos);


Plataforma, linguagem de programação, arquitetura, IDE,
controles de usuário etc.
Design gráfico, músicas, efeitos sonoros, cinemática, vídeos,
desenhos, modelagem 3D etc.
Mecânica (leis).

Espaço; objetos, atributo e estados; ações; regras;
habilidade; e probabilidade;

25. O que há num jogo digital?
Estética
Mecânica
Jogo
Tecnologia
História

26. O que há num jogo digital?
Pirâmide Elementar

27. Equipe de
desenvolvimento

28. Equipe de
desenvolvimento

Designer de Jogos (Game Designer)



Roteiro (Narrativa);
Sistema (Mecânica);
Design de mundos.

29. Equipe de
desenvolvimento

Designer de Jogos (Game Designer)




Roteiro (Narrativa);
Sistema (Mecânica);
Design de mundos.
Artista (Artist)





Animação 2D e/ou 3D;
Modelagem 3D;
Pintura digital e/ou vetorização 2D;
Designer gráfico;
Arte conceito.

30. Equipe de
desenvolvimento

Engenheiro de áudio (Audio Engineerer)



Efeitos sonoros;
Trilha sonora;
Vocalização.

31. Equipe de
desenvolvimento

Engenheiro de áudio (Audio Engineerer)




Efeitos sonoros;
Trilha sonora;
Vocalização.
Programador (Programmer)





Rede;
Som;
IA;
Gráfico;
Ferramentas.

32. Equipe de
desenvolvimento

Produtor (Producer)


Desenvolvimento (equipe interna);
Publicador (marketing, vendas, QA e Localização).

33. Equipe de
desenvolvimento

Produtor (Producer)



Desenvolvimento (equipe interna);
Publicador (marketing, vendas, QA e Localização).
Testadores (Testers)




Garantia de Qualidade (QA);
Testes de jogabilidade;
Testes de usabilidade;
Testes não funcionais.

34. Processo de desenvolvimento

35. Processo de desenvolvimento
É
um processo iterativo incremental;

36. Processo de desenvolvimento
É
um processo iterativo incremental;
 É dividido em:

37. Processo de desenvolvimento
É
um processo iterativo incremental;
 É dividido em:

Pré-produção: conceito, requisitos e
planejamento do jogo;

38. Processo de desenvolvimento
É
um processo iterativo incremental;
 É dividido em:


Pré-produção: conceito, requisitos e
planejamento do jogo;
Produção: implementação do plano e
rastreamento do progresso;
 Testes: validação do plano.

39. Processo de desenvolvimento
É
um processo iterativo incremental;
 É dividido em:



Pré-produção: conceito, requisitos e
planejamento do jogo;
Produção: implementação do plano e
rastreamento do progresso;
 Testes: validação do plano.
Pós-Produção: aprender a experiência.
 Post-mortem.

40. Processo de desenvolvimento
É
um processo iterativo incremental;
 É dividido em:
 Pré-produção: conceito, requisitos e


planejamento do jogo;
Produção: implementação do plano e
rastreamento do progresso;
 Testes: validação do plano.
Pós-Produção: aprender a experiência.
 Post-mortem.

41. Processo de criação
(pré-produção)

42. Processo de criação
(pré-produção)

43. Processo de criação
(pré-produção)
Que tal
isso?

44. Processo de criação
(pré-produção)
Que tal
isso?

45. Processo de criação
(pré-produção)
Que tal
isso?

46. Processo de criação
(pré-produção)
Testando...
Que tal
isso?

47. Processo de criação
(pré-produção)
Testando...
Que tal
isso?

48. Processo de criação
(pré-produção)
Testando...
Que tal
isso?

49. Processo de criação
(pré-produção)
Aprovado?
Testando...
Que tal
isso?

50. Processo de criação
(pré-produção)
Aprovado?
Testando...
Que tal
isso?

51. Processo de criação
(pré-produção)
Aprovado?
Testando...
Que tal
isso?

52. Processo de criação
(pré-produção)
Aprovado?
Testando...
Que tal
isso?

53. Técnicas para Design

54. Técnicas para Design
 Caixa
morfológica:

55. Técnicas para Design
 Caixa

morfológica:
É um quadro;

56. Técnicas para Design
 Caixa


morfológica:
É um quadro;
Contém informações paramétricas;

57. Técnicas para Design
 Caixa



morfológica:
É um quadro;
Contém informações paramétricas;
Uso de combinações para um pitch* de
jogo;

58. Técnicas para Design
 Caixa



morfológica:
É um quadro;
Contém informações paramétricas;
Uso de combinações para um pitch* de
jogo;
*Pitch: apresentação curta (3-5 min) que deva mostrar o quão interessante é o
seu produto/serviço à um cliente ou investidor.

59. Técnicas para Design
 Caixa




morfológica:
É um quadro;
Contém informações paramétricas;
Uso de combinações para um pitch* de
jogo;
Para uso individual – mas pode ser em
grupo.
*Pitch: apresentação curta (3-5 min) que deva mostrar o quão interessante é o
seu produto/serviço à um cliente ou investidor.

60. Técnicas para Design
 Caixa
morfológica:

61. Técnicas para Design
 Caixa
morfológica:

62. Técnicas para Design
 Caixa
Plataforma
morfológica:

63. Técnicas para Design
 Caixa
morfológica:
Plataforma
Android
iOS
BB 10
PS3 (PS4)
Xbox 360 (One)
Browser
PC

64. Técnicas para Design
 Caixa
morfológica:
Plataforma
Android
iOS
BB 10
PS3 (PS4)
Xbox 360 (One)
Browser
PC
Gênero

65. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Android
Beat’em Up
iOS
RTS
BB 10
BTS
PS3 (PS4)
Aventura
Xbox 360 (One)
Point-and-Click
Browser
Luta
PC
Plataforma

66. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Android
Beat’em Up
iOS
RTS
BB 10
BTS
PS3 (PS4)
Aventura
Xbox 360 (One)
Point-and-Click
Browser
Luta
PC
Plataforma
Modos

67. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Modos
Android
Beat’em Up
Single player
iOS
RTS
Co-op
BB 10
BTS
Versus
PS3 (PS4)
Aventura
Multiplayer
Xbox 360 (One)
Point-and-Click
Browser
Luta
PC
Plataforma

68. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Modos
Android
Beat’em Up
Single player
iOS
RTS
Co-op
BB 10
BTS
Versus
PS3 (PS4)
Aventura
Multiplayer
Xbox 360 (One)
Point-and-Click
Browser
Luta
PC
Plataforma
Nº Jog.

69. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Modos
Nº Jog.
Android
Beat’em Up
Single player
1
iOS
RTS
Co-op
2
BB 10
BTS
Versus
3
PS3 (PS4)
Aventura
Multiplayer
4
Xbox 360 (One)
Point-and-Click
Browser
Luta
PC
Plataforma
4+

70. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Modos
Nº Jog.
Android
Beat’em Up
Single player
1
iOS
RTS
Co-op
2
BB 10
BTS
Versus
3
PS3 (PS4)
Aventura
Multiplayer
4
Xbox 360 (One)
Point-and-Click
Browser
Luta
PC
Plataforma
*Departamento de Justiça, Classificação, Títulos e Qualificação (DEJUS)
4+
DJCTQ*

71. Técnicas para Design
 Caixa
morfológica:
Plataforma
Gênero
Modos
Nº Jog.
DJCTQ*
Android
Beat’em Up
Single player
1
L
iOS
RTS
Co-op
2
10
BB 10
BTS
Versus
3
12
PS3 (PS4)
Aventura
Multiplayer
4
14
Xbox 360 (One)
Point-and-Click
4+
16
Browser
Luta
PC
Plataforma
*Departamento de Justiça, Classificação, Títulos e Qualificação (DEJUS)
18

72. Técnicas para Design
 Mapa
Mental:

73. Técnicas para Design
 Mapa

Mental:
Diagrama sistematizado pelo inglês Tony Buzan;

74. Técnicas para Design
 Mapa


Mental:
Diagrama sistematizado pelo inglês Tony Buzan;
Um conjunto de informações interligadas a
partir de um ponto inicial (centro);

75. Técnicas para Design
 Mapa



Mental:
Diagrama sistematizado pelo inglês Tony Buzan;
Um conjunto de informações interligadas a
partir de um ponto inicial (centro);
Pode ser feita com texto e imagens.

76. Técnicas para Design
 Exemplo
de Mapa Mental:

77. Técnicas para Design
 Brainstorming
(tempestade de ideias):

78. Técnicas para Design
 Brainstorming

(tempestade de ideias):
Possui 3 partes:

79. Técnicas para Design
 Brainstorming

(tempestade de ideias):
Possui 3 partes:
1.
Encontrar os fatos;

80. Técnicas para Design
 Brainstorming

(tempestade de ideias):
Possui 3 partes:
1.
2.
Encontrar os fatos;
Geração da ideia;

81. Técnicas para Design
 Brainstorming

(tempestade de ideias):
Possui 3 partes:
1.
2.
3.
Encontrar os fatos;
Geração da ideia;
Encontrar a solução.

82. Técnicas para Design
 Brainstorming

Possui 3 partes:
1.
2.
3.

(tempestade de ideias):
Encontrar os fatos;
Geração da ideia;
Encontrar a solução.
Em “Encontrar os fatos” temos:
 Definição
do problema;
 Preparação.

83. Técnicas para Design
 Brainstorming:

Princípios:

84. Técnicas para Design
 Brainstorming:

Princípios:
 Atraso
no julgamento;
 Criatividade em quantidade e qualidade.

85. Técnicas para Design
 Brainstorming:

Princípios:
 Atraso
no julgamento;
 Criatividade em quantidade e qualidade.

Regras:

86. Técnicas para Design
 Brainstorming:

Princípios:
 Atraso
no julgamento;
 Criatividade em quantidade e qualidade.

Regras:
 Críticas
são rejeitadas;
 Criatividade é bem-vinda;
 Quantidade é necessária;
 Combinação e aperfeiçoamento são
necessários.

87. Técnicas para Design
 Brainstorming:


Deve ter um Coodernador!
Vamos ao Brainstorming!

88. Mecânica de jogo

89. Mecânica de jogo
A
mecânica de jogo contém e é a
essência do jogo;
 É um conjunto de regras com objetivos
definidos;
 É abstrata e faz uso de modelos mentais.

90. Mecânica de jogo
 Ela






é fundamentada em:
Espaço;
Objetos, atributos e estados;
Ações;
Regras;
Habilidade;
E Probabilidade.

91. Mecânica de jogo
 Se
passa em um Espaço;
 Este pode ser:


Diferenciado, ou;
Padronizado (limites fixos).
 Tem
dimensões;
 Possui áreas limitadas que podem ou não
estar conectadas.

92. Mecânica de jogo
 Exemplo
de Espaço Diferenciado:

93. Mecânica de jogo
 Exemplo
de Espaço Padronizado:

94. Mecânica de jogo
 Exemplo
de Espaço Conectado:

95. Mecânica de jogo
 Espaço
limitado com dimensões:

96. Mecânica de jogo
 Contém
um conjunto de Objetos que
possuem Atributos e Estados;
 Exemplo:



As peça e as casas do xadrez são objetos;
O rei do xadrez tem um atributo “modo de
movimento”;
Possui estados “livre para mover”, “em
xeque”, “xeque-mate”.

97. Mecânica de jogo
 Exemplo
de Objetos, Atributos e Estados:

98. Mecânica de jogo
 Contém
Ações que ditam o que o
jogador pode fazer;
 Podem ser:


Operacionais: ações básicas que o
jogador pode realizar;
Resultantes: são ações que o jogador faz
no decorrer do jogo em busca do seu
objetivo.

99. Mecânica de jogo
 Exemplos:



Mover uma peça para frente é uma ação
operacional;
Pular ou comer uma peça do oponente é
uma ação operacional;
Sacrificar uma peça para ter vantagem
posteriormente é ação resultante.

100. Mecânica de jogo
 Exemplo:

101. Mecânica de jogo
 Exige
que o jogador exercite alguma
Habilidade;
 Podem ser habilidades:



Físicas;
Mentais;
Sociais.
 Há

duas categorias de habilidade:
Real vs Virtual;

102. Mecânica de jogo
 Exemplos
de Habilidades:

103. Mecânica de jogo
 Exemplos:

104. Mecânica de jogo
 Possui
Probabilidade;
 É referente a interações do que foi
abordado anteriormente.
 Pode ser relacionado com elementos do
próprio jogo e elementos humanos;
 Usado em balanceamento;
 Exemplo:

Qual a chance de um adversário no xadrez
comer uma peça posta para sacrifício?

105. Mecânica de jogo
 Exemplo
de jogo com Probabilidade:

106. Documentação

107. Documentação
 Há
um documento para a
documentação do jogo e se chama
Game Design Document;

108. Documentação
 Há
um documento para a
documentação do jogo e se chama
Game Design Document;
 Neste documento deve existir registros de
dados relacionados ao que se pretende
fazer em um jogo, informando a
tecnologia utilizada, estética, história...

109. Documentação
 Há
um documento para a
documentação do jogo e se chama
Game Design Document;
 Neste documento deve existir registros de
dados relacionados ao que se pretende
fazer em um jogo, informando a
tecnologia utilizada, estética, história...
 E mecânica!

110. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;

111. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design a:

112. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design a:

113. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design a:

Expor o que deve ser feito e como;

114. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design a:


Expor o que deve ser feito e como;
Estar sujeito a mudanças;

115. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design a:



Expor o que deve ser feito e como;
Estar sujeito a mudanças;
Controlar o andar da produção;

116. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design a:




Expor o que deve ser feito e como;
Estar sujeito a mudanças;
Controlar o andar da produção;
Ser referência quando o game designer
não estiver presente;

117. Documentação
 Está
inserida desde o início até depois do
fim do desenvolvimento do jogo;
 Ao produzir um jogo, seu uso é preciso
para organizar o design à:





Expor o que deve ser feito e como;
Estar sujeito a mudanças;
Controlar o andar da produção;
Ser referência quando o game designer
não estiver presente;
Aperfeiçoar o que já existe.

118. Documentação

Como fazer isso de forma ágil?

119. Documentação

Como fazer isso de forma ágil?
 Com
metodologias ágeis!

120. Documentação

Como fazer isso de forma ágil?
 Com

metodologias ágeis!
No desenvolvimento de software, na
década de 90, ocorreu um marco: O
Manifesto Ágil.

121. Documentação

Como fazer isso de forma ágil?
 Com


metodologias ágeis!
No desenvolvimento de software, na
década de 90, ocorreu um marco: O
Manifesto Ágil.
Motivo: devido aos processos, muitas vezes
burocráticos, que não auxiliavam a
gerência de configuração durante o
desenvolvimento, acabava-se gerando
mais custos e até desperdício do projeto.

122. O Manifesto Ágil




Indivíduos e interação entre eles mais que
processos e ferramentas;
Software em funcionamento mais que
documentação abrangente;
Colaboração com o cliente mais que
negociação de contratos;
Responder a mudanças mais que seguir um
plano.

123. O Manifesto Ágil: Princípios


Nossa maior prioridade é satisfazer o cliente,
através da entrega adiantada e contínua de
software de valor;
Aceitar mudanças de requisitos, mesmo no
fim do desenvolvimento. Processos ágeis se
adequam a mudanças, para que o cliente
possa tirar vantagens competitivas;

124. O Manifesto Ágil: Princípios


Entregar software funcionando com
frequência, na escala de semanas até
meses, com preferência aos períodos mais
curtos;
Pessoas relacionadas à negócios e
desenvolvedores devem trabalhar em
conjunto e diariamente, durante todo o curso
do projeto;

125. O Manifesto Ágil: Princípios


Construir projetos ao redor de indivíduos
motivados. Dando a eles o ambiente e
suporte necessários, e confiar que farão o seu
trabalho;
O método mais eficiente e eficaz de
transmitir informações para, e por dentro de
um time de desenvolvimento, é através de
uma conversa cara a cara;

126. O Manifesto Ágil: Princípios



Software funcional é a medida primária de
progresso;
Processos ágeis promovem um ambiente
sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser
capazes de manter indefinidamente, passos
constantes;
Contínua atenção à excelência técnica e
bom design, aumenta a agilidade;

127. O Manifesto Ágil: Princípios



Simplicidade: a arte de maximizar a
quantidade de trabalho que não precisou ser
feito;
As melhores arquiteturas, requisitos e designs
emergem em times auto-organizáveis;
Em intervalos regulares, o time reflete em
como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo.

128. Documentação

Uma metodologia Ágil: Scrum.

129. Documentação


Uma metodologia Ágil: Scrum.
Foi desenvolvida por Ken Schwaber e Jeff
Sutherland.

130. Documentação



Uma metodologia Ágil: Scrum.
Foi desenvolvida por Ken Schwaber e Jeff
Sutherland.
Por que Scrum?

131. Documentação



Uma metodologia Ágil: Scrum.
Foi desenvolvida por Ken Schwaber e Jeff
Sutherland.
Por que Scrum?
 Porque
ela serve para desenvolver
QUALQUER produto;

132. Documentação



Uma metodologia Ágil: Scrum.
Foi desenvolvida por Ken Schwaber e Jeff
Sutherland.
Por que Scrum?
 Porque
ela serve para desenvolver
QUALQUER produto;
 É cíclico: iterativo incremental;

133. Documentação



Uma metodologia Ágil: Scrum.
Foi desenvolvida por Ken Schwaber e Jeff
Sutherland.
Por que Scrum?
 Porque
ela serve para desenvolver
QUALQUER produto;
 É cíclico: iterativo incremental;
 Leve e prático;

134. Documentação



Uma metodologia Ágil: Scrum.
Foi desenvolvida por Ken Schwaber e Jeff
Sutherland.
Por que Scrum?
 Porque
ela serve para desenvolver
QUALQUER produto;
 É cíclico: iterativo incremental;
 Leve e prático;
 É transparente: uso de linguagem comum
entre os desenvolvedores;

137. Documentação

138. Documentação

Normalmente adota o uso de Estórias
como artefatos para execução de tarefas;

139. Documentação


Normalmente adota o uso de Estórias
como artefatos para execução de tarefas;
Mas, por que estórias?

140. Documentação


Normalmente adota o uso de Estórias
como artefatos para execução de tarefas;
Mas, por que estórias?
 São
simples;

141. Documentação


Normalmente adota o uso de Estórias
como artefatos para execução de tarefas;
Mas, por que estórias?
 São
simples;
 Fáceis de entender;

142. Documentação


Normalmente adota o uso de Estórias
como artefatos para execução de tarefas;
Mas, por que estórias?
 São
simples;
 Fáceis de entender;
 Claras e objetivas.

143. Documentação


Normalmente adota o uso de Estórias
como artefatos para execução de tarefas;
Mas, por que estórias?
 São
simples;
 Fáceis de entender;
 Claras e objetivas;

E o que são estórias?

144. Estórias
 São
pequenas descrições de
funcionalidades fornecidas por alguém
(normalmente um cliente), que auxilia a
entender o que um software deve fazer;

145. Estórias
 São
pequenas descrições de
funcionalidades fornecidas por alguém
(normalmente um cliente), que auxilia a
entender o que um software deve fazer;
 Lembre-se: TODO jogo digital é um
programa de computador.

146. Estórias
 Elas




tem:
Título;
Descrição;
Prioridade;
Pontuação (custo);

147. Estórias
 Exemplo:

148. Estórias
 Como
posso aproveitar ao máximo as
estórias?

149. Estórias
 Como
posso aproveitar ao máximo as
estórias?

Utilizando Desenvolvimento Dirigido à
Comportamento! (Behaviour Driven
Development - BDD);

150. Behaviour Driven
Development (BDD)

151. Behaviour Driven
Development (BDD)
 Criado
por Dan North, 2006

152. Behaviour Driven
Development (BDD)
 Criado
por Dan North, 2006
 Utiliza linguagem Ubíqua;

153. Behaviour Driven
Development (BDD)
 Criado
por Dan North, 2006
 Utiliza linguagem Ubíqua;
 É um modo de desenvolvimento que
realiza testes de comportamento;

154. Behaviour Driven
Development (BDD)
 Criado
por Dan North, 2006
 Utiliza linguagem Ubíqua;
 É um modo de desenvolvimento que
realiza testes de comportamento;
 Faz uso de estórias de usuário para criar
os cenários de teste;

155. Behaviour Driven
Development (BDD)

156. Documentação da mecânica
de jogo

157. Documentação da mecânica
de jogo
 Como
foi exposto, a documentação da
mecânica deve conter os seus 6
elementos básicos.

158. Documentação da mecânica
de jogo
 Como
foi exposto, a documentação da
mecânica deve conter os seus 6
elementos básicos.
 Será realizada utilizando o modelo de
Dan North;

159. Documentação da mecânica
de jogo
 Como
foi exposto, a documentação da
mecânica deve conter os seus 6
elementos básicos.
 Será realizada utilizando o modelo de
Dan North;
 “{}” indica que é há uma lista.

160. Documentação da mecância
de jogo
 Para






o Espaço:
Id: identificador do espaço (nome);
Rótulo: referente a um grupo de objetos;
Descrição;
Limites: área do espaço;
Ligações com outros espaços {}.
[Opcional] pode utilizar diagramas com
grafos;

161. Documentação da mecância
de jogo
 Para

o Espaço:
Grafos:
Banheiro
Cozinha
Casa
Sala
Quarto

162. Documentação da mecância
de jogo
 Para



os Objetos (estória de criação):
Id: identificador do objeto;
Rótulo: referente a um grupo de objetos;
Atributos {}:
 Id;
 Descrição.

Estados {}:
 Id;
 Condição(ões)
[(Ação(ões)];
 Resultado (descrição).

163. Documentação da mecância
de jogo
 Para



as Ações (comportamentos):
Id;
Rótulo;
Condição {};
 (entrada


do usuário – outras ações);
Resultado {}: ligado a um ou mais estados;
[Opcional] Objetos, atributos, estados e
ações estão tenuemente ligados, podendo
utilizar diagrama de máquina de estado;

164. Documentação da mecância
de jogo
 Para
Objetos, Atributos e Estados:

165. Documentação da mecância
de jogo
 Para
Estados:

166. Documentação da mecância
de jogo
 Para
Ações:

167. Documentação da mecância
de jogo
 Para

as Regras:
Objetivo {}:
 Id;
 Objetos
envolvidos;
 Descrição.

168. Documentação da mecância
de jogo
 Para
as Regras:

169. Documentação da mecância
de jogo
 Para
as Habilidades:
 Id;
 Descrição;
 Ação
 Grau.
{};

170. Documentação da mecância
de jogo
 Para
as Probabilidade:
 Id;
 Descrição;
 Espaço;
 Objetos
envolvidos;
 Ações Envolvidas;
 Regras;
 Habilidades.

171. Conclusão
A
documentação da mecânica é
essencial para o desenvolvimento de um
jogo digital;

172. Conclusão
A
documentação da mecânica é
essencial para o desenvolvimento de um
jogo digital;
 O modelo de Dan North é útil para
descrição dos comportamentos;

173. Conclusão
A
documentação da mecânica é
essencial para o desenvolvimento de um
jogo digital;
 O modelo de Dan North é útil para
descrição dos comportamentos;
 As estórias auxiliam no trânsito entre
design e papel;

174. Conclusão
A
documentação da mecânica é
essencial para o desenvolvimento de um
jogo digital;
 O modelo de Dan North é útil para
descrição dos comportamentos;
 As estórias auxiliam no trânsito entre
design e papel;
 Criar jogos é divertido, chato é fazer e o
melhor é ver o resultadol!

175. Obrigado!
E
bons jogos!