Retrospectiva 2012 e conselhos

Agora que as férias realmente começaram e o fim de ano está chegando, nada melhor do que fazer uma autoavaliação a respeito do desenvolvimento do Shadow Struggles ao longo do período letivo. Espero que possa ser de utilidade a alguém, nem que seja para evitar cair nas mesmas armadilhas que nós. Lembrando que as opiniões aqui expostas não necessariamente representam o grupo inteiro, apenas o meu (Gabriel) ponto de vista, mas os outros membros estão bem-vindos a postarem também.

Primeiro trailer!

Desenvolvemos um pequeno trailer em inglês e português para nosso projeto como trabalho sobre propaganda para uma disciplina do curso. Nada muito sofisticado, mas foi uma boa oportunidade para aplicarmos nossos conhecmientos em Flash e pensarmos em uma estratégia de divulgação.

• Trailer - Português

• Trailer - Inglês

O fim?

Nosso grupo apresentou o projeto para os professores na quinta-feira, dia 22/11/2012. Acreditamos termos ido bem, então tudo finalmente terminou, certo? Bem, sim, pelo menos a questão do trabalho acadêmico. Mesmo assim, ainda estamos animados com o projeto, tanto por causa da boa recepção dos professores quanto de outros desenvolvedores indie. Confira o primeiro resultado de todo o nosso esforço:

Decidimos usar as férias para nos concentrarmos em aspectos do projeto que não foram contemplados, fazer preparações para o ano que vem e focar em algumas questões da equipe:

1. Restaram alguns probleminhas de internacionalização e Android que pretendemos resolver.
2. Nesta versão, 0.1, só foi implementada a primeira fase, além de faltarem algumas funcionalidades extras planejadas (loja de itens, edição de baralho etc.).
3. Assim que o aperto de fim de ano permitir, pretendo postar aqui algumas conclusões, aprendizados e conselhos gerais para ajudar outros desenvolvedores e alunos a partir da nossa experiência com o projeto. Também posso dar uma atualizada no guia de Subversion/Subversive, agora que possuo um domínio maior do assunto.
4. Após finalizarmos Shadow Struggles em seu escopo inicial, o próximo passo que estamos planejando é a adição de multiplayer, possivelmente utilizando a plataforma do Facebook.
5. É provável que o grupo se divida no ano que vem devido à reorganização da turma, então precisamos de uma estratégia que possibilite o desenvolvimento em duas vias.

Relatório de atividades (04/11 a 10/11)

Relatório curto, já que o clímax do projeto está se aproximando e estamos tentando ajustar os detalhes finais. A tela de cena já possui um estágio de implementação mais avançado, faltando apenas decidir o que fazer com cada escolha de cada cena, e parte dos algoritmos de inteligência artificial estão prontos. Como não vamos conseguir implementar tudo até a apresentação, decidi voltar a produzir alguns gráficos. Atualmente estamos decidindo entre os dois logos para o projeto:

Enquanto os programadores e ilustradores principais cuidam da finalização, eu vou iniciar uma intensificação da divulgação do projeto e a produção do trailer.

Resumo de outubro

Devido ao ritmo um tanto quanto frenético do mês de outubro, optamos por acumular todas as atualizações e fazer um mega-relatório em novembro. Atualmente, nossas atividades durante as aulas de LP2 e TDS estão voltadas ao desenvolvimento do projeto, então estamos tentando aproveitar bem essas ocasiões para fazermos decisões, continuar a implementação, cuidar da documentação etc. Dito isso, vamos ao relatório.

Relatório de atividades (16/09 a 22/09)

Neste final de mês, estamos conseguindo nos estruturar melhor e alguns avanços bem significativos estão sendo feitos.

Relatório de atividades (09/09 a 15/09)

Outro post curto. Parece que foi cedo demais falar em "volta à normalidade", já que nesses últimos dias ficamos ocupados com vários deveres acadêmicos. Para completar, o repositório da escola estava indisponível quando eu fui escrever este post, então não tenho como confirmar qualquer mudança.

Relatório de atividades (02/09 a 08/09)

Um fato que não foi mencionado no relatório passado foi a volta da greve dos professores de LP2 e TDS, então tudo voltou à normalidade por enquanto. A mudança mais significativa nesta semana foi a implementação de um arquivo de configuração global para a aplicação, em JSON. Isso deve ser um passo importante para estabelecer o resto da comunicação com arquivos.

Relatório de atividades (26/08 a 01/09)

Para encerrar o mês, segue um panorama geral das coisas e algumas perspectivas para o futuro.

Práticas de programação

Quase toda atividade possui um conjunto de boas práticas para assegurar um mínimo de qualidade ao trabalho, garantindo conformidade, menor chance de erros e outros benefícios específicos dependendo do contexto. E no desenvolvimento de software não poderia ser diferente. Trago aqui algumas informações acerca de algumas boas práticas e por que adotá-las.

Relatório de atividades (19/08 a 25/08)

Nem vale a pena escrever um post muito longo nesta semana, já que é basicamente uma repetição do que já vem sendo realizado: alguns recursos gráficos adicionais foram feitos e a implementação avançou mais um pouco. Mais especificamente, contornamos em parte os problemas envolvendo a câmera. Bem, se há falta de novidades, isso pelo menos implica que há falta de problemas também.

Desenvolvimento baseado em componentes

O desenvolvimento baseado em componentes é um paradigma dentro de engenharia de software que se preocupa principalmente com a separação de conceitos. Decidimos analisá-lo por ser uma tendência bem interessante no desenvolvimento de games.

Relatório de atividades (12/08 a 18/08)

Esta foi uma semana "normal", sem nada de muito notável. De qualquer forma, aí vai o relatório semanal.

Relatório de atividades (05/08 a 11/08)

Breve síntese do que foi feito na semana, de 05/08/2012 a 11/08/2012.

Implementação

O Felipe conseguiu resolver alguns problemas de manipulação de câmera que estávamos enfrentando e o Hugo concertou a incompatibilidade com o Android devido a arquivos corrompidos e implementou uma lógica inicial de manipulação de dados em arquivos. Quanto à implementação efetiva da mecânica do jogo, enfrentamos alguns problemas na camada lógica. Basicamente, ficamos quebrando um pouco a cabeça porque não entendíamos e/ou não concordávamos com a visão um do outro à respeito da arquitetura, que não ficou clara só com os diagramas.

Conseguimos chegar a pelo menos um consenso: ao invés de criar uma classe para cada carta, que era a intenção inicial, vamos reunir todas as informações das cartas em arquivos e estabelecer uma única classe responsável por implementar os efeitos possíveis. Por exemplo, uma carta teria informações em arquivo como algo do tipo:

nome: nome_carta

tipo: armadilha

custo: 20

duração (em segundos): 5

efeitos: {drenar_vida_lutador, drenar_vida_base_inimiga}

Assim, quando essa carta for ativada durante a partida, a aplicação vai chamar os métodos correspondentes aos efeitos drenar_vida_lutador e drenar_vida_base_inimiga. Isso inclusive deve permitir que os programadores principais, Hugo e Felipe, possam se concentrar mais na engine em si, enquanto outra pessoa pode editar os arquivos e adicionar funcionalidades extras.

Mesmo assim, ficou claro que não podemos começar direto pela lógica. Decidimos adotar uma abordagem mais top-down, ou seja, primeiro determinar como o sistema é apresentado ao jogador e só depois especificar o que ele deve fazer. Vamos dar uma atenção extra à interface gráfica, preocupando-nos em exibir as informações na tela, para apenas depois implementar a lógica e manipulação de dados.

Essa abordagem é vantajosa por cinco motivos:

1. Temos uma visão geral do que a aplicação realmente é, então evitamos problemas de módulos que deveriam ter sido implementados, mas acabaram passando batido, e módulos que alguém pensou que o jogo precisaria, mas ficaram inutilizados.
2. Podemos verificar desde o início as questões referentes ao design. No final das contas, o design é uma das coisas mais relevantes em um game e é o que o jogador realmente vê, apesar de ser o mais trivial em termos de programação.
3. Com a camada visual pronta, teremos mais facilidade em divulgar o projeto e apresentar nosso progresso nele.
4. É o modo mais natural e "concreto" de começar a implementação, sem que precisemos entrar em detalhes abstratos de lógica e organização.
5. Torna mais flexível a alteração do design em qualquer momento, pois a lógica ainda não estará completamente pronta e poderá ser adaptada.

Recursos gráficos

Em contraste à implementação, não houve muitos problemas em relação aos gráficos. O Leon terminou mais uma carta e iniciou a interface dos menus, enquanto eu comecei a parte de animações e fiz ilustrações adicionais. Eventualmente pretendo refazer algumas coisas, principalmente animações, mas ficam aí como recursos provisórios. Como dito anteriormente, sou inexperiente e o nível dos meus trabalhos ainda está abaixo do esperado, mas isso é algo que só melhora com o tempo mesmo.

Divulgação

Um dos principais objetivos do projeto é ter um bom alcance global, então eu dei mais alguns passos em direção a isso. Apliquei algumas técnicas de SEO (Search Engine Optimization) ao blog, a fim de melhor posicioná-lo em buscas, e encontrei bons espaços destinados a desenvolvedores indies pela web:

Indie Game Maker Brasil
GameDev
Indie DB

Também cadastrei o blog no diHITT, serviço que agrega diversos blogs.

Metas para as próximas semanas

O Felipe tinha sugerido no mês passado que utilizássemos a seguinte ordem de implementação:

1. Carregar um mapa (já feito).
2. Inserir um personagem no mapa que saiba se locomover à base inimiga.
3. Inserir vários personagens.
4. Fazer o lutador reconhecer se existe algo dentro de seu alcance e realizar a ação respectiva.
5. Carregar o baralho do jogador.
6. Implementar a I.A. do inimigo.

Proponho alguns passos intermediários visando principalmente o design e a interação com o usuário, além de detalhar um pouco mais:

1. Exibir a interface de batalha (cartas, indicadores de energia e vitalidade, baralho, menu lateral).
2. Implementar a inserção de uma carta.
3. Implementar as ações de uma carta.
4. Implementar o baralho do jogador e o saque (não regido pelo timer).
5. Implementar o indicador de energia dos jogadores.
6. Implementar a vitalidade das bases.
7. Implementar o timer, a recuperação de energia e o saque regido pelo timer.
8. Implementar a I.A. do inimigo.
9. Implementar as regras de jogo (condições de vitória/derrota).
10. Implementar a visualização de uma carta.
11. Implementar as opções do menu lateral.

Relatório de atividades (29/07 a 04/08)

Desta vez o relatório veio mais rápido porque não houve transtornos em relação ao repositório. Enfim, ao resumo da semana.

Greve

A greve nas universidades e institutos federais a este ponto parece ser de conhecimento geral. Acontece que no IFSP Campus São Paulo apenas os servidores estavam em greve até agora, mas alguns professores decidiram aderir ao movimento. Como resultado, não teremos aulas das disciplinas Teoria de Desenvolvimento de Sistemas e Linguagem de Programação 2 por tempo indefinido.

Cremos que isso não afetará muito o andamento do projeto, até porque os professores dispuseram-se a acompanhar e auxiliar os projetos de forma remota, via e-mail. Além disso, sempre que possível vou buscar algum conhecimento extra referente a desenvolvimento de software/games e publicar por aqui. O próximo assunto deve ser o paradigma de desenvolvimento baseado em componentes, com um foco na aplicação em games através dos Sistemas de Entidades.

Hospedagem no Google Code

Foi recomendado que não utilizássemos mais de um repositório para evitar complicações, mas achamos que vale a pena tentar pelos motivos citados no relatório anterior. No caso de ocorrerem problemas, vamos deixar o Google Code apenas para casos de emergência. Aí vai a página do projeto: http://code.google.com/p/shadowstruggles/.

Reajustes no cronograma

Não conseguimos prever e/ou gerenciar muito bem os rumos do desenvolvimento, então alguns prazos do mês de julho foram descumpridos. Os planos para o resto do ano foram reavaliados e podem ser conferidos na documentação do projeto. Basicamente, pretendemos concluir a mecânica de jogo neste mês de agosto e logo em seguida trabalhar nas demais funcionalidades, deixando o modo campanha a ser implementado na etapa final. O prazo dos recursos sonoros agora ficou para outubro, já que o Hugo estará ocupado com a implementação.

Renegociação das funções

Eu assumi a responsabilidade pelos recursos gráficos junto com o Victor, a fim de acelerar e otimizar o processo, uma vez que o game design, roteiro e documentação já estão em dia. Por hora, o Victor continua a trabalhar nos mapas enquanto eu cuido de outras ilustrações. As prioridades do momento são ter pelo menos um mapa e alguns efeitos, mas também comecei a criar outros recursos, como a logo da equipe e alguns ícones.

PS: Só sei mexer com ilustração o suficiente para fingir que consigo me virar em pequenos trabalhos, então pode ser que demore um pouco até eu melhorar o suficiente para fazer algo realmente bom. Tenham paciência comigo até lá, ok? xD

Relatório de atividades (22/07 a 28/07)

Novamente, relatório um pouco atrasado devido à indisponibilidade do repositório. Aliás, este é o primeiro assunto do relatório.

Hospedagem de projeto

Estamos considerando a possibilidade de utilizar o serviço de hospedagem de projetos do Google, além do repositório da escola. O principal propósito é ter uma alternativa para quando problemas semelhantes ocorrerem no futuro, mas também há aspectos bem interessantes que podem ser úteis: wikis, possibilidade de maior visibilidade, gerenciamento de tarefas e problemas etc.

A questão foi proposta recentemente e ainda está em discussão, então vamos informar os resultados no próximo relatório.

Game Design Document

O GDD (Game Design Document), que descreve o roteiro, cartas, batalhas e outros itens referentes ao andamento do jogo, foi completo de acordo com as especificações iniciais. É possível que sofra alterações no futuro, mas pelo menos a "versão 1.0" foi concluída por mim hoje e descreve com detalhes o que acontece no jogo.

Implementação

O Hugo e o Felipe continuaram o trabalho da implementação da mecânica do jogo, cujo prazo foi adiado para este próximo mês de agosto (antes, havia sido estipulado que teríamos a mecânica do jogo feita em julho). A alteração no cronograma não deve afetar o andamento de forma significativa, uma vez que a mecânica de jogo é um dos principais requisitos do projeto, sendo os elementos como loja de itens e modo campanha secundários.

Adicionalmente, foi decidido que será utilizado o formato de arquivo JSON. A estrutura de acesso aos dados deverá ser a mais genérica possível, de modo que seja possível mudar de formato se assim for necessário no futuro.

Recursos gráficos

O Leon continuou a criação dos gráficos das cartas e o Victor ausentou-se nesta semana por questões de saúde.

Relatório de atividades (15/07 a 21/07)

O relatório demorou um pouco porque o repositório da escola ficou off por um tempo, então não conseguimos rastrear muito bem o que cada um fez nos últimos dias da semana. De qualquer forma, as seguintes atividades foram realizadas.

Reunião

As conclusões da reunião realizada em 18/07 podem ser encontradas neste post. A maior parte das atualizações se deve a ela, aliás.

Início da implementação

Conforme discutido, o Hugo deu início à implementação da camada visual do jogo, que deverá ser complementada com a camada lógica implementada pelo Felipe. Como eu fiquei de terminar tanto o diagrama de classes para guiar a implementação quanto o GDD (Game Design Document), optei por dar prioridade ao GDD por enquanto, mas descrevi em linhas gerais os componentes das camadas visual e lógica:

Camada lógica. Clique para ampliar.

Camada visual. Clique para ampliar.

OBS: Lembrando que já tinha feito o diagrama geral no post anterior.

Progresso nas cartas

Por enquanto temos 4 cartas feitas pelo Leon: DR-002, DR-003, Mineralogy e Reconnect Circuits.

Progresso nos mapas

O Victor estava tendo algumas dificuldades por conta das complicações na integração entre o libgdx e o Tiled Map Editor, mas agora acreditamos que a maior parte dos problemas está resolvida.

Progresso no GDD

A descrição das cartas está completa, restando agora a descrição das batalhas e a elaboração dos demais fluxogramas do roteiro. Devo terminar tudo nesta última semana de férias.

Conclusões da reunião de 18/07

A seguir estão as conclusões que tiramos da nossa última reunião. Como o post ficou meio grande, foi melhor separá-lo do resto das atualizações da semana, que serão registradas no próximo relatório.

Pauta da segunda reunião

A reunião que provavelmente ocorrerá no dia 17/07 ou 18/07 tem como objetivos principais coordenar esforços e fazer algumas decisões críticas referentes ao projeto. Os assuntos previstos são, nesta ordem:

Revisão do design de alto nível

O design de alto nível dos requisitos e plano de validação apresentado no post anterior será retrabalhado para contemplar quaisquer aspectos levantados pela equipe. Em particular, o plano de validação deverá ter um detalhamento maior.

Recursos gráficos

Parecem não estar ainda muito claras as tarefas referentes aos recursos gráficos, então precisamos estipular o que precisa ser feito e quem vai fazer o que. Também precisamos avaliar a viabilidade dessas tarefas e, dependendo da avaliação, fazer alterações no roteiro.

Arquitetura do projeto

A visão geral da arquitetura do projeto será mais detalhada, possivelmente entrando nas especificações do fluxo da partida através de diagramas de atividade. Assim como em relação aos recursos gráficos, a divisão das tarefas de implementação ainda precisa de uma definição formal. As decisões devem ser facilitadas com o estabelecimento de uma arquitetura inicial.

Suporte a mapas

Enfrentamos algumas complicações na integração do Tiled Map Editor com o libgdx, então esperamos chegar a um consenso sobre como resolver os conflitos. Uma boa alternativa seria a construção e implementação de um mapa de teste.

Linguagem de script

Provavelmente não utilizaremos scripts devido aos entraves com o Android, mas se algum dos integrantes oferecer uma solução viável, seria um recurso interessante ao projeto. Alguma pesquisa adicional também poderá ser realizada.

Bibliografia

Nada melhor do que aproveitar as férias para estudar, certo? A intenção é pesquisar e trocar experiências sobre algum conhecimento que nos auxilie durante a construção do projeto, seja em relação aos gráficos, sons, game design, programação ou qualquer outro aspecto.

Atualização

Bem, não é exatamente um relatório semanal, mas achamos útil registrar aqui como anda o desenvolvimento do projeto Shadow Struggles. Entretanto, como dito no post anterior, o fato é que não havia sido feito um avanço significativo para ser registrado.

Documento de game design

Foi iniciado um documento de game design (GDD) para documentar aspectos mais específicos do jogo, como roteiro e descrição dos mapas e cartas. O roteiro em inglês está finalizado, bem como a descrição dos mapas, restando agora terminar de detalhar as cartas, partidas do modo campanha, IA dos oponentes e quaisquer outros pontos adicionais que venham a surgir.

O documento pode ser acessado aqui:

Design de alto nível

Seguindo as orientações do livro Engenharia de Sistemas para Leigos, leitura para a disciplina de Teoria e Desenvolvimento de Sistemas, iniciamos um design de alto nível contemplando o conjunto inicial de requisitos e planos de teste. Para os requisitos funcionais:

• Vermelho indica que o requisito é obrigatório para a avaliação do sistema como funcional;
• Amarelo indica que o requisito é desejável, mas não afeta a funcionalidade plena do sistema;
• Já os requisitos em verde podem ser removidos sem comprometerem a qualidade ou funcionalidade do sistema.
• Retas tracejadas mostram uma relação entre um requisito e seu plano de verificação ou refinamento.

Requisitos funcionais de design e jogabilidade. Clique para expandir.

Requisitos funcionais de modalidade e configurabilidade. Clique para expandir.

Requisitos não funcionais. Clique para expandir.

Arquitetura do projeto

Foi elaborada uma estrutura geral de organização que deve guiar a implementação do jogo. Por enquanto é apenas uma visão geral em alto nível das camadas, mas a intenção é refiná-la cada vez mais e complementar com diagramas adicionais.

Clique para expandir.

A camada de visualização é dividida em interface de navegação, basicamente a estrutura de navegação através de menus, e interface de batalha, que exibirá os gráficos e receberá os inputs do usuário durante uma partida.

Logo abaixo vem a camada lógica, responsável por interpretar as jogadas, aplicar as regras e retornar as respectivas consequências. A plataforma genérica é responsável pelas tarefas básicas de todas as partidas: carregar mapas, inicializar valores etc. Isso busca separar a lógica da partida em si da manipulação dos dados, que podem vir de um banco de dados, arquivo XML, script ou qualquer outro meio de armazenamento, além de proporcionar um grau de customização individual para cada partida.

Nos níveis mais baixos estão os dados, recursos e a camada interpretadora, responsável pela comunicação com esse meio externo. No lado esquerdo estão listados os testes previstos.

Linguagem de script

Pensamos em utilizar scripts para auxiliar na construção das entidades do jogo. Isso facilitaria bastante a customização de diversos aspectos sem ser necessário fazer alterações profundas no código da aplicação, permitindo também que mesmo os que não estiverem envolvidos diretamente com a implementação possam ajudar na programação dos scripts. A principal utilização seria programar a IA dos oponentes.

No momento, o principal entrave é a compatibilidade com Android. Em primeiro momento cogitamos a possibilidade de usar Groovy, mas este ainda não encontra suporte pleno na plataforma. Uma boa alternativa parece ser BeanShell. Enfim, o tópico ainda está sendo pesquisado e esperamos trazer uma conclusão no próximo relatório.

Reunião

Pretendemos realizar uma reunião com todos os membros da equipe para coordenar os esforços, trocar experiências e tomar algumas decisões importantes à respeito do projeto. A pauta será decidida em breve e publicada aqui no blog.

Subversion e Subversive - Guia rápido

Não tivemos muitas atualizações desde a última postagem, mas o ritmo de relatórios deve aumentar bastante durante este mês de julho, quando damos início ao desenvolvimento do projeto. E é por isso que hoje vamos falar um pouco de Subversion, tanto para tirar dúvidas dos integrantes da equipe quanto ajudar qualquer outra equipe de desenvolvimento que use ou queira usar o Subversion como ferramenta colaborativa.

Planejamento final

Nas últimas aulas de TDS (Teoria de Desenvolvimento de Sistemas), discutimos os últimos detalhes importantes do projeto e organizamos uma documentação inicial para formalizar e organizar o processo.

Relatório de atividades (20/05 a 26/05)

Conforme discutido neste post de planejamento, demos início a algumas atividades que podem nos ajudar a identificar e solucionar alguns problemas de desenvolvimento. Nesta semana também apresentamos as principais ideias do projeto, aprovadas pelos professores.

O ontem, o hoje e o amanhã

Não se trata de um relatório "oficial", uma vez que o projeto ainda não foi apresentado aos professores para aprovação. Mas, antes disso, queremos ter uma visão geral e bem definida das coisas a fim de melhor direcioná-las ao sucesso. Essa visão geral abrange passado, presente e futuro.

Projeto Shadow Struggles

Neste post inaugural, vamos apresentar o "esqueleto" do que vai ser nosso projeto para este ano: Shadow Struggles. Muita coisa ainda é incerta e é bem fácil se perder no entusiasmo inicial, então estamos tentando ir com calma, experimentar, delinear etc. Mas qual é a ideia que nos motiva, impele, obriga a agir?

O projeto

Propomos o desenvolvimento de um jogo do gênero estratégia em tempo real para PC e Android. Por que um jogo? São vários os motivos, tanto comuns a todos quanto pessoais, mas podem ser resumidos da seguinte forma:

1. É algo que todos os integrantes da equipe gostam e se sentem motivados a desenvolver;
2. O desenvolvimento de um jogo envolve tecnologias e competências diferenciadas, o que deve contribuir muito à nossa formação;
3. Um jogo não é particularmente preso a um negócio ou produto, o que permite a livre criação de um conceito original, único, com mérito artístico.

Cabe ressaltar aqui que o idioma principal escolhido foi o inglês, para contribuir à divulgação e ampliar o alcance do projeto. Pretendemos que o projeto final esteja também em português, como idioma secundário.

Mecânica do jogo

O objetivo do jogo é defender sua base e atacar a base inimiga em um confronto estratégico. Um esquema simples deve ilustrar melhor:

Os jogadores devem posicionar cartas que invocam lutadores, efeitos e armadilhas em seus respectivos campos. Além de raciocínio rápido, faz parte fundamental do jogo o planejamento de um bom deck (baralho), combinando diferentes cartas e estratégias para superar o oponente.

Esta dinâmica baseia-se em títulos como Nine Heroes e Age of Defense, agregando ao tradicional combate estratégico um sistema de cartas. As cartas adicionam uma camada extra de complexidade que colabora para uma experiência mais desafiadora e interessante.

O jogo termina quando o valor de vida de um dos jogadores vai a zero ou um dos jogadores não pode mais sacar nenhuma carta.

Tempestade de ideias

Apesar de a jogabilidade estar praticamente toda definida, ainda falta decidir sobre questões referentes ao roteiro, modos de jogo e demais funcionalidades. O que por enquanto temos são um amontoado de ideias que podem ou não ser implementadas:

• Tema do enredo: Alquimia, ficção científica e uma discussão metafísica sobre o bem e o mal.

• Ambientação: Versão alternativa da Terra, em um futuro distante.

• Estrutura da narrativa: Trama interativa, ou seja, haverá pontos de decisão nos quais o jogador deverá escolher qual rumo tomar. As combinações de escolhas vão posicionar o jogador mais próximo da "Luz" ou das "Trevas", sendo o final dependente desse posicionamento. Os dois caminhos principais possuem personagens, sub-tramas, cartas e outros itens exclusivos.

• Modos de jogo: Além do modo "campanha", que apresenta uma narrativa ao longo do jogo, possíveis alternativas são um modo "free play", no qual será possível jogar novamente fases do modo campanha, e um modo "desafio", contendo desafios complementares aos objetivos tradicionais.

• Funcionalidades extras: Uma loja com pacotes de cartas, cartas individuais e outros itens disponíveis à compra pelo sistema monetário do jogo, além da possibilidade de criar múltiplos decks.