Wild Witch Project - Um game que você nunca viu

Neste jogo você precisa ajudar uma bruxa adolescente a salvar seu mundo da Mortífera Bunda Assassina do Espaço Sideral

Incorporando banco de dados

Pra quem pensou que apenas de personagens se faz um jogo ^_^

Pensei muito na real necessidade disso. E cheguei à conclusões interessantes.
Durante a implementação fiz uma pergunta ao Mauricio que também esta desenvolvendo um projeto similar, e descobri que ele também estava pensando na mesma coisa. E, talves pelo fato de eu te-lo lembrado, ele começou a implementar no proprio projeto ao mesmo tempo que eu comecei a integrar os testes no meu.

Bom, resumindo aqui as caracteristicas que pesaram em função do uso de uma base de dados no projeto:
Atomicidade do arquivo
  • Um arquivo único, ou um número menor de arquivos, é mais portavel que uma sequência enorme de arquivos. Compare com um pen-drive onde é mais rápido copiar um arquivo de 1GB doque 100 arquivos de 1MB. E eu quero que ele rode num pen!
  • Isolamento da media, podendo aplicar criptografia na mesma (lembrem-se que até aqui meu projeto é free e não open).
  • Melhor controle de save-games, e informações decorrentes do jogo.
  • Isto também resolveu meu problema de lógica autocontida, onde para cada cenário rodo um código Lua. (buffer por buffer acredito que não será muito diferente de eu ter uma tag INCLUDE ou uma seção CDATA num XML)
Velocidade e Flexibilidade
  • O light do SQLite não é apenas pela falta de recursos, ele é light também no peso rodando pouco abaixo da velocidade de uma abertura de arquivos normal (supondo-se que eu modele bem esse banco)
  • Ele também permite que eu monte um sistema de update automático. Não pretendo fazer nada que chegue próximo a um MMORPG, mas corrigir bugs e passar os fixes para os usuários, sem que ele tenha que baixar tudo de movo, é um vicio de todo usuário de Linux.
Conforto, rapidez e segurança
  • Um BD por menor que seja propicia sempre ótimas ferramentas, que seriam arduamente desenvolvidas "na mão". Por exemplo: reindexação dos dados e segurança de salvamento.
Detalhes da implementação

Ainda tenho que estudar com calma, mas possívelmente terei relações assim.
Como necessáriamente todas as consultas serão seriais, os relacionamentos devem ser poucos. Pretendo ainda rodar isso em um ambiente de thread separado. Garantindo que não haja transtornos na logica do jogo.


Indices, Indices... ó salvadores da pátria. Esse SQLite eu olharia ele com nojo ao ver suas limitações (e ainda olho).

O DB Designer é um pouco "bombado" demais pra produzir material pra ele, mas é ótimo p eu

Eu ainda não abandonei o XML de saida no Blender, ele é um importante método de gerar experimentaçao.


Um sistema de saida para arquivo foi o primeiro recurso utilizado e testado. No entanto todos que ja trabalharam com issu sabem a dificuldade, onde você difine a ordem que os bytes são salvos, o comprimento dos dados, e eu ainda tive o cuidado de projetar um sistema de blocos indentificavel, para que uma nova versão do sistema salva-se os arquivos de uma forma que a versão anterior não tivesse problema e ignorasse o bloco sem suporte.

Não que eu tenha totalmente abandonado o formato .8art (o que eu havia criado para a GE)... afinal estruturas de bancos de dados são passiveis de proteção por direitos autorais ^_~
(sim pequenos padawans, bancos de dados não são apenas depositos onde você consulte e salva, são "engines" completas com técnicas e manhas de performance e funcionalidade)

Outra conclusão

C++ é uma linguagem fodássstica e lindona. Pena que tudo que agente faz nela leva de 10 a 50 vezes mais tempo que nas outras.

Sim, eu ainda me atrapalho com esses ponteiros, ou coisa do mau!!!
Passei até no blog do BCSanches pra rever aquele artigo de memory leakes... e com certeza ainda terei muitos.
Mesmo tendo dedicado 30% do tempo num engenho de ponteiros com a biblioteca vector.h