Grupo EE Games - Avanços do jogo

Devido a incompatibilidade de horários dos membros do grupo, a reunião que supostamente seria realizada na última quinta-feira (dia 12/09) foi adiada para terça-feira (17/09). No entanto, para que o andamento do jogo não ficasse prejudicado, foram definidas e realizadas algumas tarefas informalmente, sendo que estas foram adicionadas à planilha e-Kanban que o grupo está utilizando (link ao final da postagem).

A última publicação no blog evidenciou que a lógica principal do jogo havia sido desenvolvida e estava em teste. Desde então, durante a semana realizaram-se as tarefas de criação do repositório para controle de versões do software, utilizando as ferramentas Google Code e Mercurial. Foi necessário uma familiarização dos membros do grupo com o funcionamento das mesmas. A partir daí, a versão inicial do jogo foi subida para o repositório. Foram então adicionadas as funcionalidades de "vidas" e "score", bem como um menu inicial. Alguns bugs durante o desenvolvimento foram detectados via teste e já foram corrigidos.

A reunião da próxima terça abordará os temas de definição de lógica para as vidas no jogo, definição de cenário, definição de um nome para o jogo, e a ata será postada durante esta próxima semana.

A planilha de organização do e-Kanban pode ser acessada aqui:

https://docs.google.com/spreadsheet/pub?key=0ArdLUMUpNso3dFdmU3M0YWdhQXhvWEYwZTgxSUtrMGc&output=html

Grupo G8 Games

Ata da 2ª Reunião - 10/09

Membros:

Vinícius Garcia

Antônio Gonçalvez

Vitor Paisante

Bruno Liberal

Rafael Fonseca

- Objetivos da reunião: Definição do nome jogo, criação do gamedesign, elaboração do email com candidato a jogo e perguntas para levantamento de requisitos para o cliente (Sergio Crespo).

- Nome do jogo: Total software manager.

- Gamedesign: https://docs.google.com/document/d/1OOIfHoMfLaCkrSxpc61zG7390bl-ipWnbRiU3IKWX18/edit#

- Requisitos: Temos por objetivo fazer um levantamento de alguns requisitos funcionais, não-funcionais e experiências do usuário através de entrevista ou questionário via email. Como por exemplo o que o jogo deve ter? Quais expectativas ao jogar o jogo? Quais são os pontos fortes que se destaca no jogo?

- Email para o professor:

Professor Crespo,

Nossa ideia principal é fazer um jogo profundamente influenciado por jogos de cartas e tabuleiro, segue um link para o Game Design Doc:

https://docs.google.com/document/d/1OOIfHoMfLaCkrSxpc61zG7390bl-ipWnbRiU3IKWX18/edit#

Gostariamos de saber se existem certos fatores e aspectos, não apresentados no documento, que o senhor ache essenciais. Queremos direções e críticas que possam ser exploradas em reuniões seguintes e saber quais elementos, neste projeto, o senhor tem mais interesse de ver.

Por tanto, neste primeiro momento de conversa, seria bom, do senhor, que nos seja passado um feedback quanto a elementos importantes para o jogo e uma crítica a ideia como um todo, nos informando suas opiniões sobre o estilo de jogo que estamos propondo.

Obrigado pela atenção,

Atenciosamente

Grupo G8

- Conclusões da Reunião:

Decidimos que os membros irão ler e avaliar o game-design do jogo especificado pelo Vitor. Correções, alterações e discussões serão realizadas no próprio documento.

Nessa reunião também foi enviado um e-mail para o professor com dúvidas e questionamentos a respeito dos requisitos do produto, entendendo o professor no papel de cliente da empresa.

Na próxima reunião esperamos que todos tenham lido e aceito o documento de game-design, e poderemos então definir os requisitos do sistema e delegar as tarefas de produção do sistema.

Ata da 1a reunião do grupo Speed Games

Data: 03/09/2013

Integrantes: Júlio Albinati, Paulo Viana, Rubens Emilio 

1 - Descricao:

   A ideia principal do nosso jogo é fazer com que os jogadores respondam perguntas relacionadas a engenharia de software e processos de desenvolvimento. A dinâmica do jogo é dada da seguinte forma:

• os jogadores assumem o papel de investidores, controladores de empresas de desenvolvimento de software;
• no início do jogo, cada participante escolhe a metodologia de desenvolvimento de software (XP, Praxis, Scrum, …) que deverá ser aplicada nas empresas que possuir;
• a cada rodada, o jogador corrente deverá girar uma roleta, usada para definir a ação do turno. O jogador deverá tomar uma das seguintes ações:
• responder uma pergunta relacionada a aspectos gerais de engenharia de software;
• responder uma pergunta relativa ao método de desenvolvimento escolhido;
• retirar uma carta de sorte;
• retirar uma carta de revés;
• ao responder uma pergunta corretamente, o jogador receberá uma recompensa financeira e, caso a pergunta seja referente a seu método de desenvolvimento, retirará uma carta de sorte;
• ao responder uma pergunta erroneamente, o participante retirará uma carta de revés;
• os jogadores podem investir os recursos que possuirem, seja adquirindo novas empresas, ou melhorando o processo de desenvolvimento de suas empresas a partir de certificações CMMI;
• o jogo termina após certa quantidade de rodadas, a ser definida pelo jogador;
• ao término do jogo, cada participante é avaliado de acordo com o número de empresas que possui e suas respectivas certificações.

2 - Engine:

   A engine gráfica escolhida pelo grupo é o Allegro. Essa engine aparenta ser simples e possui uma boa documentação, o que avaliamos ser suficiente para o trabalho a ser desenvolvido.

3 - Processo:

   O processo de desenvolvimento escolhido pelo grupo é o XP. A decisão foi tomada a partir do fato de que este método prioriza o desenvolvimento ágil, uma vez que código e testes são constantemente atualizados. Além disso, aparenta ser um processo adequado para grupos pequenos e funcionar melhor quando envolve pessoas trabalhando próximas, como é o nosso caso.

4 - Metodologia:

   O grupo deve se reunir semanalmente para avaliar o desenvolvimento do trabalho. As versões do programa também devem ser disponibilizadas semanalmente.

5 - Ferramentas:

   Utilizaremos o Git como ferramenta de controle de versão, uma vez que todos os integrantes já usam essa ferramenta cotidianamente.

Prezado Professor Crespo,

Nós da G8 Games produzimos jogos o mais próximo possível das expectativas do cliente. Assim, gostaríamos de marcar uma reunião presencial com membros da nossa equipe para um levantamento de requisitos do projeto a ser desenvolvido. Também queremos sugerir nossas duas propostas para o projeto, ficando ao seu critério decidir o futuro do software a ser entregue.

Att.

Equipe G8 Games.

Prezados desenvolvedores,

Um jogo (de 2009) desenvolvido na plataforma Second Life é o Training in Requirements Engineering Game (TREG):
http://tregame.blogspot.com.br/

...é um dos jogos analisados na dissertação do Rodrigo Possa:
http://www.dcc.ufmg.br/pos/cursos/defesas/1261M.PDF

Grupo G8 Games

Ata da 1ª Reunião - 03/09

Membros:

Vinícius Garcia

Antônio Gonçalvez

Vitor Paisante

Bruno Liberal

Rafael Fonseca

- Objetivos da reunião: Decidir o jogo que iremos desenvolver, a engine que iremos trabalhar, processo de desenvolvimento, ferramentas utilizadas e nome do grupo.

- Nome do grupo: G8 Games

- Ideias para o jogo:

Idéia 1:

O jogador é o dono de uma empresa de software. Ele pode pegar contratos para projetos diferentes de softwares. Cada projeto possui itens que devem ser realizados e ao completa-los sua empresa ganha dinheiro, outros possíveis bônus e pontos de reputação. Com 20 pontos de reputação o jogador vence o jogo. Se o jogador falhar um projeto ele pode perder pontos de reputação, pagar multas e seus funcionários poderão perder pontos de moral. Cada projeto tem um número limite de turnos para ser completado.

Para realização dos projetos, o jogador precisa contratar funcionários. Cada funcionário possuí um salário pago a cada turno e um indicador de moral, se esse indicador chegar a zero, ele pede demissão. Cada funcionário pode realizar uma tarefa por turno e o conjunto de tarefas realizáveis por cada personagem depende de sua biografia (Sua profissão, suas experiências passadas e etc). Cada tarefa realizada por um funcionário pode contribuir com a realização de um item ou outra tarefa, essas contribuições influenciam na qualidade final dos mesmos aumentando a pontuação.

Com a conclusão de todos os itens realizados com, pelo menos, qualidade mínima estipulada, o jogador conclui o projeto e ganha os espólios pré-determinados, incluindo pontos de reputação. Com 20 pontos de reputação o jogador vence o jogo. Se ele for a falência ou ficar com 0 pontos de reputação ele perde o jogo.

Q&A:

Qual seria a diferença de um item para uma tarefa?

O item é especificado no contrato do projeto e pode ser, por exemplo “ - Criação de um banco de dados ”

as tarefas seriam: “Modelagem de um banco de dados”, “Implementação de um banco de dados” e “teste de um banco de dados”, por exemplo.  Um item é realizado com qualidade a partir da realização de algumas tarefas específicas. Testes podem beneficiar a qualidade de um item, assim, se o jogador realizar vários testes o item seria beneficiado pois sua qualidade aumentaria. A chave do jogo é organizar essas tarefas em um numero de turnos hábil e organizar em determinadas ordens, se a modelagem dá +2 de bônus pra implementação, modelagem tem de ser feita antes, mas certas tarefas podem dar bônus para outras se estas forem feitas ao mesmo tempo, por exemplo, e esses macetes têm de ser descobertos pelo jogador.

Um primeiro diagrama idealizado:

Idéia 2:

Jogo baseado em fases, onde cada fase é uma etapa do processo Praxis (Requisitos, Análise, Desenho, Implementação e Testes). Cada fase conterá um pequeno conteúdo explicativo sobre a respectiva etapa do processo Praxis e sobre o profissional que executa a tarefa. Em cada fase o jogador será um dos profissionais da equipe e terá que jogar umá espécie de mini-jogo relacionado com a etapa do processo para passar para a próxima fase.

Objetivo: Completar todas as fases e entregar o software para o cliente.Exemplo:  

Fase de Testes: O jogador está no papel de um engenheiro de testes. Inicialmente é apresentado um pequeno conteúdo sobre esta fase do processo Praxis e sobre a função do engenheiro de testes. Em seguida é apresentado um pequeno enredo e a tarefa que o jogador terá de executar afim de completar a tarefa e passar de fase. A tarefa neste caso pode ser, por exemplo, comparar uma lista de especificações com uma tela do sistema em um curto intervalo de tempo.

-Escolha da engine: Unity por termos mais familiaridade.

-Escolha do processo de desenvolvimento: Scrum. Membro do grupo já teve experiências profissionais com o processo.

-Ferramentas utilizadas:

• controle de versão: Usaremos Git para controle de versão. Site: http://git-scm.com/

• repositório de código: Usaremos o GitHub como repositório de código. Site: https://github.com/

• documentos e atas: GoogleDocs. Site: https://docs.google.com/

• controle de bugs: FogBugz. Site: http://www.fogcreek.com/fogbugz/

• controle do TaskBoard: SeeNowDo. Ferramenta de controle visual do Taskboard do Scrum. Site: https://www.seenowdo.com

-Conclusão: Houveram idéias para a criação do jogo, porém o grupo ficou dividido na escolha de qual escolher. Assim, ficou decidido que elaboraremos melhor as duas idéias apresentadas para escolhermos futuramente a melhor ou deixaremos o próprio Sergio Crespo decidir, já que ele é o “cliente” do software.

As outras decisões foram tomadas sem menores problemas.

Ata da 1a reunião do 20th Booth Games

Data: 01/09/2013
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)

3. MODELO DE GERÊNCIA

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).