Resumo. Este artigo apresenta um projeto que utiliza um sistema de banco de dados.
Ao que se segue ser apresentado o projeto de um sistema que armazena dados para um
jogo MMORPG, que de forma genrica pode ser usando tanto em uma rede local
quanto na internet, ou seja, pode evoluir e ser utilizado por diversos usurios online. O
texto que se segue no pretende mostrar todo o poder que banco de dados ORACLE
pode fornecer aos desenvolvedores, mais pretendemos mostrar como prtico e
divertido trabalhar com este sistema.
Palavras-chaves: MMORPG; Rede Local; Internet; Oracle.
Database MMORPG
Abstract. This article presents a project that uses a database. In what follows will be
presented the design of a system that stores data for a MMORPG game that can
generically be using both on a local network and the Internet, that is, he level up and
can be used by several users. The text that follows is not intended to show all the power
ORACLES database can provide developers, most intend to show how is practical and
fun to work with this system.
Keywords: MMORPG; Local Network; Internet; Oracle
1 Introduo
O projeto visa desenvolver um banco de dados para um jogo de MMORPG (Massively
Multiplayer Online Role-playing Game). O jogo permite armazenar jogadores, personagens,
classes de personagens, poderes de classes, armas, proteo e itens para consumo. Os jogadores
podem batalhar uns com os outros. Cada jogador pode possuir at 5 (cinco) personagens sendo
que possvel escolher apenas um para iniciar o jogo. Cada personagem contm uma classe, uma
arma, cinco protees (cabea, peito, pernas, mos e ps) e um item de consumo. Inicialmente h
cinco classes para jogadores e cinco classes para os inimigos no jogo, porm futuramente podem
ser cadastradas novas classes assim como os poderes, ou seja, o jogo pode ser expandido.
Cada classe possui um leque de poderes especficos e comuns a outras classes. O ataque feito
somente com uma arma e os poderes servem apenas para aumentar/diminuir os atributos do
personagem assim como os itens de consumo. Dependendo do item de consumo os efeitos duram
por um determinado tempo.
2 Definindo as Tabelas
Tabelas em bancos de dados representam entidades (e.g., pessoas, veculos, planetas, etc). Por
conveno utilizaremos caixa baixa para denominar nomes de tabelas e nomes de atributos, e
caixa alta para denominar comandos SQL, embora o SQL no faa distino entre caixa alta ou
baixa. Para representar as entidades do nosso projeto, vamos tomar como base informaes do
sistema que so permanentes, ou seja, que possuem dados que devem ficar armazenados no
banco de dados. O jogo possui as seguintes tabelas: jogador, poder, tipo_poder, classe,
poder_classe, tipo_protecao, proteo, tipo_arma, arma, personagem, tipo_item_consumo,
proteo_personagem, consumo, consumo_personagem
2.1 Jogador
A entidade jogador possui os seguintes atributos: nome, cpf, email, login e senha. E o seguinte
script[2] cria a tabela jogador:
CREATETABLEjogador(
cod_jogador
nome
cpf
email
login
senha
)
NUMBER(4),
VARCHAR2(60) NOTNULL,
VARCHAR2(14) NOTNULL,
VARCHAR2(100) NOTNULL,
VARCHAR2(20) NOTNULL,
VARCHAR2(13) NOTNULL
Cada atributo representa uma coluna da tabela (cod_jogador representa a chave primaria da
tabela[1]). Repare nos comando SQL (definidos por conveno em caixa alta) a frente de cada
atributo, ao criarmos uma tabela devemos especificar para o SGBD (Sistema Gerenciador de
Banco de Dados), que tipo de dado ser armazenado naquele campo (e.g., nmero, texto, letra,
data e etc).
Ateno: Devemos criar nossas tabelas seguindo um raciocnio lgico, onde, uma tabela s deve
ser criada em uma ordem lgica e estruturada, como por exemplo: criamos a tabela jogador
antes da tabela personagem, por que no faria sentido criar um personagem sem antes existir
um jogador (embora seja permitido cria uma tabela personagem ante de uma tabela jogar, para
efeitos de clareza vamos seguir a lgica). Campos definidos como NOT NULL informam ao
SGBD que estes campos so de preenchimento obrigatrio.
2.2 Poder
A entidade poder possui os seguintes atributos: nome, taxa (representa a porcentagem do dano),
bonus , durao e consumo. O seguinte script [2] cria a tabela poder:
CREATETABLEpoder(
cod_poder
NUMBER(4),
tipo_poder
NUMBER(4),
nome
taxa
bonus
duracao
consumo
)
VARCHAR2(60) NOTNULL,
NUMBER(5,2) DEFAULT0,
NUMBER(4)
DEFAULT0,
NUMBER(4)
DEFAULT0,
NUMBER(4)
DEFAULT0
Campos numricos podem ser declarados com um valor padro (DEFAULT) mantendo assim a
integridade dos dados. Observe o campo tipo_poder da tabela acima, este campo pode assumir os
valores: Ataque, Defesa, Cura e Penalidade. Observe que toda vez que inserirmos um poder em
nossa tabela temos que inserir qual o tipo desse poder, porm poderes podem referenciar um
mesmo tipo (e.g, Fria dos Deuses e Ataque Mortal representam o tipo de poder denominado
Ataque) ento teremos que referenciar um tipo de poder diversas vezes ao inserirmos dados na
tabela acima. Agora observe o script a seguir:
CREATETABLEtipo_poder(
cod_tipo_poder
NUMBER(4),
nome
)
VARCHAR2(20) NOTNULL
Foram criadas duas tabelas tipo_poder e poder, agora podemos cadastra na tabela tipo_poder
os valores: Ataque, Defesa, Cura e Penalidade. Na tabela poder o campo cod_tipo_poder
representa o cdigo do poder que estamos fazendo referncia, assim quando quisermos
acrescentar ou alterar algum tipo de poder faremos apenas na tabela tipo_poder e a alterao
ento ser realizada automaticamente na tabela poder que faz referncia a tabela tipo_poder.
2.3 Classe
A entidade classe possui os seguintes atributos: nome, taxa e
bonus. O seguinte script [2] cria a tabela classe:
CREATETABLEclasse(
cod_classe
NUMBER(4),
nome
taxa
bonus
VARCHAR2(60) NOTNULL,
NUMBER(5,2) DEFAULT0,
NUMBER(4)
A criao da tabela classe bem simples, mas agora temos que pensar que uma classe possui
poderes, e esses poderes so diferentes para diferentes classes (e.g., um mago possui o poder de
cura, mas no possui o poder de regenerao, e um lobo possui o poder de regenerao, mas no
possui o poder de cura). Com este pensamento temos uma relao de muitos para muitos [3], onde
um poder pode referenciar uma ou mais classes e uma classe pode referenciar um ou mais
poderes. Devemos ento criar uma tabela que ira representar este relacionamento:
CREATETABLEpoder_classe(
cod_poder_classe
cod_poder
cod_classe
)
NUMBER(4),
NUMBER(4),
NUMBER(4)
Est tabela faz referncia a tabela poder e a tabela classe, e aqui que devemos inserir os
relacionamentos entre elas de acordo com as regras do jogo.
2.4 Proteo
De forma anloga a entidade poder, nossa entidade protecao possui um tipo (e.g., Cabea,
Peito, Mos, Ps e Cala), ento teremos que cria uma tabela chamada tipo_protecao, que
servir como referncia para a nossa tabela protecao. O seguinte script define as tabelas
tipo_protecao e protecao:
CREATETABLEtipo_protecao(
cod_tipo_protecao
NUMBER(4),
nome
)
VARCHAR2(30) NOTNULL,
CREATETABLEprotecao(
cod_protecao
NUMBER(4),
cod_tipo_protecao
NUMBER(4),
nome
defesa
bonus
absorcao
amplificacao
durabilidade
)
VARCHAR2(60) NOTNULL,
NUMBER(5)
DEFAULT0,
NUMBER(5)
DEFAULT0,
NUMBER(5,2) DEFAULT0,
NUMBER(5,2) DEFAULT0,
NUMBER(5)
DEFAULT0
2.5 Arma
A entidade arma possui um atributo tipo (e.g., Arco, Arma Branca, Arma de Fogo, Basto e
Adaga), que de acordo com os exemplos visto at agora deve ser representado como uma
entidade. O script a seguir cria as tabelas tipo_arma e arma:
CREATETABLEtipo_arma(
cod_tipo_arma
NUMBER(4),
nome
)
VARCHAR2(60) NOTNULL
CREATETABLEarma(
cod_arma
NUMBER(4),
cod_tipo_arma
NUMBER(4),
nome
VARCHAR2(60) NOTNULL,
ataque
bonus
amplificacao
distancia
durabilidade
)
NUMBER(5)
NUMBER(5)
NUMBER(5,2)
NUMBER(5)
NUMBER(5)
DEFAULT0,
DEFAULT0,
DEFAULT0,
DEFAULT0,
DEFAULT0
2.6 Personagem
Para definirmos uma entidade personagem, o nosso jogo exige que o personagem seja criado por
um jogador, possua uma classe e inicie com uma arma correspondente a sua classe. A seguir o
script que cria a entidade personagem:
CREATETABLEpersonagem(
cod_personagem
NUMBER(4),
cod_jogador
NUMBER(4),
cod_classe
NUMBER(4),
cod_arma
NUMBER(4),
nome
sexo
vitalidade
magia
ataque
defesa
)
VARCHAR2(60) NOTNULL,
CHAR(1)
NOTNULL,
NUMBER(4)
DEFAULT1000,
NUMBER(4)
DEFAULT100,
NUMBER(4)
DEFAULT100,
NUMBER(4)
DEFAULT100
2.7 Consumo
Jogadores podem consumir itens para que seus personagens fiquem mais fortes
temporariamente, recuperem vida instantaneamente, recupere magia e etc. Todos os itens
de consumo possuem tipo (e.g., sanduiche que recupera vida).
CREATETABLEtipo_item_consumo(
cod_tipo_item_consumo
Nome
)
NUMBER(4),
VARCHAR2(60) NOTNULL
CREATETABLEconsumo(
cod_consumo
NUMBER(4),
cod_tipo_item_consumo
nome
absorcao
amplificacao
bonus
duracao
descricao
)
NUMBER(4),
VARCHAR2(60) NOTNULL,
NUMBER(5,2) DEFAULT0,
NUMBER(5,2) DEFAULT0,
NUMBER(5)
DEFAULT0,
NUMBER(5)
DEFAULT0,
VARCHAR2(200) NOTNULL
Na primeira alterao apenas definimos uma chave estrangeira na tabela poder para fazermos
referencia a tabela tipo_poder. Nas outras duas alterao definimos duas chaves estrangeiras, o
que nos da uma chave composta.
NUMBER (4),
NUMBER (4),
NUMBER (4)
NUMBER(4),
cod_consumo
NUMBER(4),
cod_personagem
NUMBER(4)
4 Um exemplo de utilizao
A partir de agora vamos executar alguns comando para testar o nosso banco de dados e observar
como ele se comporta.
a) Um comando SELECT que envolva mais de uma tabela:
O comando seguinte faz um pedido ao SGBD: Selecione o nome do jogaodor, o nome do
personagem, o nome da classe, o sexo, a vitalidade, a magia, o ataque e defesa da tabela
personagem onde o campo cod_jogador da tabela jogador seja igual ao campo cod_jogador da
tabela personagem e tambem aonde o campo cod_classe da tabela classe seja igual ao campo
cod_classe da tabela personagem:
SELECT J.nome AS JOGADOR, P.nome AS PERSONAGEM_NOME, C.nome AS CLASSE, P.SEXO,
P.VITALIDADE, P.MAGIA, P.ATAQUE, P.DEFESA
FROM
JOGADOR J INNER JOIN PERSONAGEM P
ON J.COD_JOGADOR = P.COD_JOGADOR
INNER JOIN CLASSE C ON C.COD_CLASSE = P.COD_CLASSE
d) Um comando UPDATE
e) Um comando DELETE que envolva sub-consulta
5 Concluso
Na prtica representar um jogo rpg pode ser muito complexo, como foi mencionado esta
apenas a primeira parte do projeto, porm o primeiro passo j foi dado, agora temos uma viso
geral de como ou para onde o sistema deve caminhar e como podemos evolu-lo daqui em diante.
Em um primeiro momento ns apenas escrevemos cdigos sem nem parar para pensar no projeto
como um todo, no podemos esquecer que existem bancos de dados que so totalmente livres
como o postgrees[1] (mas que no possuem todo o poder de um banco de dados com licena
paga mas pode ser til dependendo do projeto), dependendo do nosso objetivo um sistema
pago pode ser a melhor opo ou a mais barata (uma ferramenta que lhe da todo o suporte para o
desenvolvimento pode lhe poupar tempo que no momento uma das coisas mais preciosas que
possuirmos), isso, s pode ser definido previamente aps realizar um projeto detalhado do
sistema como um todo.
6 Referncias
[1] 4634A02LaboratriodeBancodeDadosITurma1682012/2Prof.DanielCallegari.
Notasdeaulas
[2] ELSMARI, R.; NAVATHE, S.B. Sistemas de Banco de Dados. 6. Ed. Pearson Brasil.
[3]