Como Montar Seu Banco de Dados em jogos!

Primeiro de tudo, é recomendável você criar primeiro seu banco de dados antes de criar o jogo, afinal pode-se ter a melhor lógica e não ter com oque trabalhar com ela, acabar tornando-a inútil.

A muitas maneira de fazer o deseing de bancos de dados, e vou descrever uma bem breve.

Este modelo frisa em ter quanto menos replicação de dados melhor.

Por que você não quer replicação de dados, simples cada vez que dados desnecessários são acumulados eles pesam no seu banco de dados. E se muitos jogadores acessarem seu jogo (em caso de onlines) por dia, seu banco de dados vai ficar muito grande e sem como dar manutenção.

Isso irá acontecer quando você tem replicação de dados:

1000 players x 5 Kb = 5000 Kb (Quase 5Mb)
100000 players x 5 Kb = 500000 Kb (Quase 500Mb!)

Certamente, só cinco megas de dados replicados são facilmente manuseáveis, mas 500 megas ai já não é!

É por isso que você precisa desenhar seu banco de dados apropriadamente!
Sem contar que se deve evitar o máximo disso, por que quanto menos replicação de dados existir, menos problemas será encontrado. Também, quando for atualizar alguma coisa, será muito mais fácil atualizar coisas em um só lugar do que em múltiplos lugares e também é certo que ao dado ser acessado, ele será atualizado.

O esquema a seguir é melhor apropriado para jogos de navegador:

CREATE TABLE users (
 id int NOT NULL AUTO_INCREMENT,
 username varchar(250),
 password varchar(50),
 PRIMARY KEY(id)
);

Em um jogo de navegador, ou de MMORPG  um jogador deve ter nome de usuário e senha e um ID único. Em alguns casos, o ID pode ser u nome de usuário, mas isso fará com que seja necessário verificar constantemente se aquele nome se encontra disponível.

Esse ID será a chave primária do do jogador, ou seja, nenhum jogador terá o mesmo ID sendo ele unicamente identificável no banco de dados. O Comando de auto_incremento, significa que ele será incrementado sozinho toda a vez que um jogador for salvo dando a certeza que não terá dois jogadores com o mesmo ID.


A maioria dos jogos, o jogador tem um preventório de items,  então a seguir será demonstrado como se cria uma segunda tabela que será a de itens e ao menos tempo ligá-la á tabela do jogador:

CREATE TABLE items (
 id int NOT NULL AUTO_INCREMENT,
 name varchar(200),
 description text,
 PRIMARY KEY(id)
);
CREATE TABLE user_inventory (
 id int NOT NULL AUTO_INCREMENT,
 item_id int,
 user_id int,
 quantity int,
 PRIMARY KEY(id)
);

Então, para melhorar ilustrar, suponha-se que o jogador pegue um item : " A Espada Vorpal de Existência Hipotética". Para adicioná-la ao inventário do jogador, deve-se descobrir qual ID a Espada Vorpal  possui e adicioná-la á coluna da tabela vazia ou atualizar uma existente. 

Também por atribui-la a um ID único  poderá atualize-la uma vez só, caso haja algum bug. É possível até renome-la para outro nome, como "Espada Nefasta de Existência Hipotética" ou algo assim. 

Quando o item está armazenado em uma única tabela , fica fácil editá-lo. Mas já pensou se a Espada Vorpal estivesse armazenada  na tabela de itens do jogador? E fosse necessário mudar o nome dela?

Seria necessário atualizar a o item de cada jogador que tivesse a Espada Vorpal.

Obviamente, fazendo um modelo de relacionamento bem feito, economiza-se tempo ao se atualizar dados na tabela. Será necessário fazer apenas uma alteração ao invés de atualizar os campos de cada jogador. 

Fonte