Uma das primeiras coisas que eu faço sempre que eu iniciar um novo projeto é o projeto do banco de dados.

De muitas maneiras, o banco de dados é o núcleo do seu jogo - sem ele, o jogo não é nada. Você poderia escrever toda a lógica que você queria, mas se você não tiver um banco de dados que a lógica seria inútil (não haveria nada para usá-lo lá!).

Há muitas maneiras de projetar um banco de dados, e algumas são melhores que outros. Para esta reportagem, eu estarei acompanhando-o através de como criar um banco de dados que tem como replicação de dados possível.

Por que você não quer a replicação de dados? Porque todos os dados que você estará armazenando em seu banco de dados acrescenta-se. Suponha que você tenha 5 Kb de dados que é replicado desnecessariamente para cada jogador do seu jogo. Seu jogo se move muito bem, e cresce lentamente - até que se apanhada por um site como o Digg ou Boing Boing - em que ponto você tem milhares de registros em um único dia. De repente, seu playerbase deixou de ser administráveis (1000) a grande! E é isso que vai acontecer quando você tem a replicação de dados:

1000 jogadores x 5 Kb = 5000 Kb (Aproximadamente 5 MB) 100000 jogadores x 5 = 500000 Kb Kb (Cerca de 500Mb!)

Claro, 5 Mb de dados extra é administrável. Mas é 500?

É por isso que você precisa para projetar seu banco de dados corretamente. A menos que você tenha dados replicados em seu banco de dados, a menos problemas que você vai encontrar mais tarde. Reduzir a replicação de dados também ajuda quando se trata de atualizar as coisas - ao invés de ter que atualizar os dados em vários locais, basta atualizá-lo em um lugar - e sabemos com certeza que onde quer que os dados são acessados, ele será atualizado.

Com isso em mente, vamos começar a desenhar uma estrutura de tabela básica para um jogo Browser.

Nós vamos precisar de usuários. E os usuários irão precisar de um nome de usuário, uma senha e um ID único (para que possamos associá-los a coisas). Por enquanto, isso é tudo que nós vamos dar aos nossos usuários:

1 2 3 4 5 6

CREATE TABLE usuários ( int id NOT NULL AUTO_INCREMENT, nome varchar(250), senha varchar(50), PRIMARY KEY(id) );

Se você executar esse pré no MySQL, você vai ter um recém-criado usuários mesa para brincar. Você deve estar se perguntando o que a PRIMARY KEY linha faz - basicamente, as forças de cada linha para ter um valor exclusivo na coluna. Isso ajudará a garantir que não tem sempre os conflitos como tentar criar dois usuários diferentes com um id '6 ', por exemplo. Você pode conferir o artigo da Wikipedia para mais informações sobre chaves primárias.

Então agora temos um usuários da tabela. Que mais o nosso jogo tem?

A maioria dos jogos têm algum tipo de inventário que seus jogadores têm, que eles podem usar para armazenar itens dentro Vamos criar mesas para os itens e os inventários de usuário:

1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE TABLE produtos ( id INT NOT NULL AUTO_INCREMENT, nome varchar(200), texto descritivo, PRIMARY KEY(id) ); CREATE TABLE user_inventory ( int id NOT NULL AUTO_INCREMENT, int item_id, user_id int, int quantidade, PRIMARY KEY(id) );

E agora nós temos todas as tabelas no local para acompanhar nossos usuários, e seus respectivos inventários, com replicação de dados mínima.

Suponha que, em nosso hipotético jogo, o jogador pega a Espada Vorpal de existência hipotética. A fim de adicioná-lo ao jogador o inventário, todos nós precisamos fazer é descobrir o ID da Espada Vorpal tinha, e depois adicionar uma nova linha (ou atualizar uma linha, se já tinha uma dela) dentro user_inventory.

O benefício real aparece quando chega a hora de atualizar alguma coisa, no entanto.

Digamos que após o jogo da sua base de usuários explodiu, aconteceu com alguém encontrar um erro: a Espada Vorpal, quando usado contra um inimigo determinado, era demasiado poderoso. Você precisa corrigir isso o mais rápido possível.

O que você faz? Graças ao design de banco de dados bom, você só precisa atualizá-lo em um só lugar! Você pode entrar em itens, encontrar Espada Vorpal único de identificação, e então atualizar qualquer atributo está causando o problema. Você poderia até mesmo mudar o nome, a Espada de Piorada hipotético Existência ou algo assim.

Como os dados importantes para cada item no banco de dados só são armazenados em uma área central, é fácil atualizá-lo. Mas você poderia imaginar o que seria como se você quisesse mudar a Espada Vorpal o nome, e era armazenada dentro user_inventory? Para cada usuário que tinha um, você precisa mudar o nome.

No cenário anterior, qual você prefere? Tendo que atualizar as linhas em cima de linhas de dados, ou apenas um? Eu sei que eu preferiria apenas uma atualização, e espero que isso ajudou para comunicar o que você está para ganhar criando o seu banco de dados de tal maneira que você só precisa atualizar uma linha.