Integrantes: André Harder, Josué Costa, Júlio César, Yuri Pessoa
1. DEFINIÇÃO DO JOGO
A partir das discussões realizadas, optamos por seguir um modelo semelhante ao usado na franquia de jogos "Phoenix Wright" (Capcom). Este modelo é uma mistura de dois gêneros de jogos, Visual Novel e Puzzles.
O jogo busca incentivar o raciocínio e a busca por informação sobre tópicos de engenharia de software. Isto é feito por via da interação do jogador com elementos do jogo, como entrevistas com NPCs, análise de ambientes e verificação de dados provenientes do caso em questão. A meta do jogador é avaliar uma empresa em algum quesito de engenharia de software (por exemplo, a adequação dela para um determinado grau de CMMI).
A implementação segue principalmente um paradigma Point and Click, onde o jogador navega diálogos e cenários relevantes a sua busca por informações que lhe ajudarão em suas avaliações.
O jogo fornecerá formas de ensinar ao usuário as informações que ele precisa para resolver os desafios (por exemplo, feedback sobre as decisões já tomadas e uma base de recursos didáticos in-game). O jogo fornecerá métricas para avaliar tanto o conhecimento anterior do jogador (conhecimento meta-game) e o quanto ele aprendeu durante o jogo (conhecimento in-game).
2. ENGINE E RECURSOS TÉCNICOS
Optamos por utilizar o flash/actionscript para a implementação do programa. Acreditamos que esta plataforma oferece características mais próprias para o desenvolvimento do jogo (especialmente tomando em consideração sua escala pequena), tais como:
- Facilidade de interação com o usuário
- Linguagem simples, porém com expressividade suficiente
- Portabilidade
- Direcionado para a criação de aplicativos gráficos
- Grande disponibilidade de recursos programáticos e audiovisuais (e.g.: tutoriais, bibliotecas, sprites, engines, sons, etc)
Escolhemos a metodologia Kanban, por objetificar diversos aspectos do desenvolvimento do jogo:
- Facilita a concatenação dos processos
- Facilita o julgamento referente à utilização do tempo
- Garante a entrega de um produto final
- Força a modularização do jogo em componentes atômicos
4. GESTÃO DE CONFIGURAÇÕES E CONTROLE DE VERSÕES
Optamos por uma metodologia mais casual para gerencia e controle de versões, onde todos os artefatos do projeto serão mantidos em conjunto. Tal será implementado sobre um sistema de arquivos compartilhados que mantém um histórico de usuário x alterações (dando a opção reverter para estágios anteriores se necessário).
Acreditamos que, embora não seja um sistema formal de controle, ofereça funcionalidade mais que adequada para o contexto corrente.
5. CRONOGRAMA DE ENTREGAS
Diversos itens foram decididos referentes ao cronograma:
- Postagem semanal no blog, contento o progresso obtido
- A cada semana avaliar a necessidade de um encontro; Havendo tópicos suficientes para serem discutidos em grupo, realizar a reunião.
- As releases serão enunciadas dentro dos posts (porém não necessariamente haverão releases a cada post).
Nenhum comentário:
Postar um comentário