criando um MMORPG

Um guia para iniciantes de como criar um MMORPG
por Radu Privantu
Traduzido por Sérgio Oliveira

Esse artigo irá focar nos primeiros passos da construção dos seus próprios RPGs On-line massivos (do inglês, MMORPG - Massive On-line Role Playing Games). ele é voltado para o desenvolvedor de jogos iniciante, com recursos e experiência limitados. Depois de ler esse artigo, você deverá saber o que é necessário para começar, e alguns conselhos sobre o que fazer e o que não fazer. O primeiro passo é avaliar suas habilidades, e os seus recursos. Você precisa ser honesto consigo mesmo, porque pode ser frustrante perder o seu tempo tentando construir algo que você não consegue.

Primeiro passo: Avaliando suas habilidades

Habilidades necessárias:

1. Conhecer pelo menos uma linguagem de programação. Até aqui, o C++ é a escolha mais popular entre os desenvolvedores devido as suas vantagens de eficiência e performance. O Visual Basic, Java ou C# também devem dar conta.

2. Familiarize-se com uma biblioteca gráfica. Escolhas mais populares são o SDL, OpenGL, ou DX/D3D... Escolha a biblioteca que você irá utilizar. Você pode escolher entre a WinSock, SDL net, ou DirectPlay.

4. Adquira uma experiência geral em programação de jogos. Por exemplo, o laço dos eventos, multithreading, design de GUI, etc.

Habilidades altamente recomendadas:

1. Comunicação Cliente/Servidor e arquitetura.

2. Programação multiplataforma. Você provavelmente vai querer projetar o seu MMORPG, e especialmente o servidor como um que possa rodar em múltiplos SOs. Para esse propósito, eu recomendo usar SDL, OpenGL e SDL net.

3. Desenvolvimento Web. Isso será necessário se você quiser permitir às pessoas verem as estatísticas do jogador, as informações do servidor, e outras informações em um website.

4. Segurança & Administração. Você não vai querer que alguém hackeie o seu servidor e bagunce tudo!

5. Habilidades do time. Você vai precisar de um time que possa liderar e gerenciar com sucesso.

Segundo passo: Faça um projeto preliminar.

Eu notei muitas pessoas postando em vários fóruns a procura de times para fazer MMORPGs. A maioria deles começa com algo assim: "Nós somos uma empresa/estúdio de jogos iniciante e estamos precisando de 3 artistas, 2 programadores, 1 músico, etc. para um inovador, nunca visto antes, MMORPG onde você terá total liberdade para fazer o que você quisesse e remodelar o mundo, etc. Nós iremos pagar você quando o jogo estiver pronto e nós tivermos feito algum dinheiro." Infelizmente, com a tecnologia atual e largura de banda limitada, você não consegue ter um mundo dinâmico. Visar algo impossível irá inevitavelmente levar à falha. Ao invés disso, tente começar com um projeto e uma arquitetura pequenos, funcionais, e expansíveis.

Arquitetura de Software Básica

Primeiro, tente focar em fazer um modelo cliente/servidor simples, onde você poderá:

1. Criar um novo personagem
2. Salvar o personagem (no servidor)
3. Loguar com o personagem
4. Permitir conversar com os outros
5. Permitir navegar pelo cenário em 3D

Salvar os personagens pode parecer simples, mas de fato, não é. Por exemplo, há duas maneiras de salvar os personagens: usando um servidor de banco de dados ou usando arquivos. Há vantagens e desvantagens para ambas:

http://img83.imageshack.us/img83/8196/iyung5.jpg


Terceiro passo: Escolhendo um protocolo interno para transmissão de dados

Isso pode parecer simples, mas, novamente, não é. Você não pode simplesmente mandar strings com, '\0' para encerrar. Isso porque você irá precisar de um protocolo consistente, que poderá enviar ambas a string e os dados binários. Não é aconselhável usar 0 (ou qualquer outra seqüência) para encerrar, porque o encerramento pode ser parte do fluxo de dados que você quer enviar. Além do que, se você enviar 20 bytes, e depois outros 20 bytes, é muito provável que o servidor não irá receber um pacote de 20 bytes, e depois outro pacote de 20 bytes. Ao invés disso, ele irá receber 40 bytes de uma vez, para evitar ficar desperdiçando banda com cabeçalhos desnecessários. Alternativamente, você pode mandar um pacote de 1K, mas o servidor irá recebe-lo em dois pacotes menores. Então você precisará saber onde um pacote começa, e onde ele termina.
No Eternal Lands, nós usamos o seguinte método:

* Offset 0: 1 byte denotando o comando transmitido.
* Offset 1: 2 bytes, o comprimento do dado transmitido.
* Offset 3: comprimento variável, o corpo da mensagem.

Esse método tem a vantagem de ser consistente: todos os dados transmitidos seguem o mesmo padrão.
A desvantagem é que alguns comandos têm a um comprimento conhecido, fixo, então a largura de banda é desperdiçada. Nós iremos eventualmente alternar para um aproximação híbrida, num código mais adiante.
A próxima coisa a se decidir é o modelo do servidor: "sem sockets de bloqueio, sem threading", ou "com sockets de bloqueio, com threading". Ambos métodos (com threading X sem threading) têm suas vantagens e desvantagens.

Com Threading:

1. Uma resposta um tanto quanto reprimida do servidor, desde que um jogador precise de muito tempo (como ler dados do banco de dados) isso é feito no seu próprio thread, não afetando outros.
2. Muito difícil de depurar e implementar propriamente: Você vai precisar de muita sincronização, e um pequeno descuido pode ter efeitos desastrosos (queda do servidor, duplicação de item, etc.)
3. Faça uso dos sistemas multiprocessadores.

Sem threading:

1. Muito mais fácil de implementar e depurar.
2. Tempo de resposta menor.

Na minha companhia, nós optamos pelo caminho sem threading, porque eu simplesmente não tenho recursos e disposição para lidar com o threading.

Quarto passo: O Cliente

Você planeja fazer um jogo 2D ou 3D? Alguns iriam argumentar que é mais fácil fazer um jogo 2D. Eu fiz ambos, e eu acredito que o 3D seja mais fácil. Deixe-me explicar.

Em 2D, você normalmente tem o buffer de frames, que é um grande array de pixels. O formato desses pixels podem diferir, de placa de vídeo para placa de vídeo. Algumas têm modos RGB, outras têm modos BGR, etc. O número de bits para cada cor podem variar também. Isso acontece só para modos de vídeo de 16bpp. Modos de vídeo 8-bit e 24-bit são mais fáceis, mas com seus problemas (8-bits te dão algumas cores (256), enquanto modos de 24-bit são mais lentos). Você também irá precisar fazer as suas próprias rotinas de tratamento de sprites, e você tem de selecionar os seus objetos sozinho, então eles serão desenhados na ordem certa. Claro, você pode usar OpenGL ou D3D para jogos 2D, mas normalmente não se usa. Nem todo mundo tem uma placa aceleradora 3D, então usar uma biblioteca 3D para um jogo 2D normalmente traz as desvantagens dos dois mundos: Nem todo mundo vai poder jogar o seu jogo, e você não poderá rodar a câmera, ter sombras melhores, e várias outras coisas específicas de aplicações 3D.

O modo 3D, como eu já disse, é mais fácil, mas requer algum conhecimento básico de matemática (especificamente trigonometria). Hoje em dia as bibliotecas gráficas são muito poderosas, e irão oferecer a você as operações básicas de graça (você não precisa selecionar os seus objetos para a frente de novo, mudando a cor e/ou a textura de um objeto é muito fácil, os objetos serão iluminados de acordo com a luz e com a sua posição (conforme você calcula os vetores normais para eles), e mais. Assim sendo, 3D dá a você muito mais liberdade de criação e movimento. As desvantagens são que nem todo mundo poderá jogar o seu jogo (você ficaria surpreso com a quantidade de pessoas que não tem placas aceleradoras 3D), e gráficos pré-renderizados sempre irão parecer melhor que seus equivalentes renderizados em tempo real.

Quinto passo: Segurança

Obviamente, não dá pra se confiar nos usuários. Em nenhuma circunstâncias você pode assumir que os usuários não poderão derrotar os seu super bem projetado esquema de criptografia (se você usar um), ou seus protocolos. Tudo que o usuário mandar para o servidor tem de ser validado. Muito provavelmente, no seu servidor você terá buffers fixos. Por exemplo, é comum ter um pequeno buffer (talvez de 4K) para os dados que chegam (dos sockets). Um usuário malicioso pode mandar uma seqüência de dados realmente grande. Se não for verificado, isso irá sobrecarregar o buffer, resultando em queda do servidor, ou, pior, o usuário poderá conseguir hackear o seu servidor, executando códigos arbitrários. Toda mensagem sozinha tem de ser verificada: quer ocorra a sobrecarga do buffer, quer dados inválidos sejam enviados (como uma mensagem do usuário "entre nessa porta" ainda que a porta esteja no outro lado do mapa, ou "use a poção de cura" ainda que o usuário não tenha tal poção, etc.)

Eu vou repetir: É extremamente importante validar todos os dados. Sempre que houver uma violação, registre o nome do usuário, o IP, o horário e a data, e a natureza da violação. A cada intervalo de tempo, verifique o registro. Se você achar violações de muitos usuários, isso é normalmente um bug no cliente, ou um problema de rede. Entretanto, se você achar muitas violações do mesmo usuário ou IP, esse é um bom indicador de que alguém está brincando com o servidor, tentando hackear ele, ou rodando um macro/script. Também, nunca armazene dados no cliente. O cliente deve receber seus dados do servidor. Em outras palavras, Ele não deve mandar coisas como: "OK, essa é minha lista de itens" ou "minha força é 10, minha mana é 200, e minha vida é 2000 de 2000". Também, o cliente não deve receber mais dados do que os necessário. Por exemplo, o cliente não deve saber onde os outros jogadores estão, exceto se eles estiverem próximos. Isso é senso comum, já que mandar todos os jogadores pra todo mundo irá consumir muita banda, e alguns jogadores podem hackear o cliente para a eles vantagens desonestas (como pegar a posição de certo jogador mostrado no mapa). Tudo isso é de senso comum, mas, novamente, você ficaria surpreso em descobrir quantas pessoas não possuem o que chamamos de senso comum.

Outras coisas a se considerar, quando falamos de segurança: A velocidade que um jogador anda deveria ser forçada para o servidor, não para o cliente. O servidor deve manter a contagem do tempo (em milisegundos) de quando um cliente se moveu pela última vez, e se uma requisição de movimento chegar mais rápido do que o limiar normal, essa requisição deveria ser descartada. Não responda a essas falsas requisições, por que elas podem resultar em latência na rede (ex: lags do jogador, e todos os dados que ele mandou nos últimos 10 segundos voltam mais uma vez).

Verifique a distância. Se um jogador tentar trocar com outro jogador que está a 10 bilhões de quilômetros de distância (ou mesmo em outro mapa) registre isso. Se um jogador tentar visualizar, ou usar um objeto do mapa que está distante, registre. Seja cuidadoso com IDs falsos. Por exemplo, é normal assinar um ID para todos jogadores (o ID pode assinado quando eles logam, ou pode ser permanente (ID único)). Se o ID é dado quando o jogador faz login (ou quando um monstro é criado), faz sentido usar a posição (índice) na array dos jogadores (onde o jogador está) como o ID.

Então o primeiro jogador que logar terá o ID 0, o segundo terá o ID 1, e assim por diante. Agora, muito provavelmente você terá um limite de, digamos, 2000 índices na lista do jogador. Então se um jogador mandar um comando como: "veja o ator com o ID 200000" isso irá derrubar o servidor se ele estiver desprotegido e tentar acessar uma memória inválida. Então uma verificação como:"
se ator id<0>max de jogadores então registre a violação e desconecte o jogador". Se o seu programa estiver em C ou C++, então tome o cuidado de definir o índice como 'unsigned int' e verifique cadeias maiores, ou se por alguma razão você definiu o índice como int (int, é colocado como padrão), lembre-se de verificar se o ator é <0>max. Uma falha nisso irá resultar em muita frustração tanto para você quanto para os outros usuários. Similarmente, verifique coordenadas fora do mapa. Se você tem alguma forma busca de trajetória no seu servidor, e os cliente se movem clicando na posição no chão, certifique-se de que eles não irão clicar fora do mapa.

Sexto passo: Montando um time

Montar um time dá muito trabalho (a não ser para Pong ou Tetris). Isso é especialmente verdade para MMORPG. Você não pode simplesmente fazer tudo sozinho. O ideal é que um time seja composto de:

* Ao menos 3 programadores: 1 para o servidor, e 2 para o cliente (ou 1 para o cliente, um para as ferramentas, mais de 6 deve ser muito. Isso realmente depende das suas habilidades de liderança. No mínimo 1 artista, mas preferencialmente 2 ou 3. Se for um jogo 3D você vai precisar de um artista 3D, de um artista 2D (para texturas, interface, etc.), um animador, e um líder para o departamento de arte. A menos que você seja um bom artista, o departamento precisa se manter junto e coordenado por um artista experiente.

* Alguns construtores de mundos: construir todos os seus mapas é um longo processo, e é critico para o sucesso do jogo. Novamente, se você irá precisar de um líder para o departamento de construção do mundo, Você não pode simplesmente ter qualquer um fazendo o que diabos ele quiser já que o design do mundo deve ser consistente.

* Um webmaster é excelente, a não ser que você seja realmente bom com web design, e esteja disposto a gastar o seu tempo fazendo um website. Ter um músico não é necessário, mas um jogo com som e música pode ser mais enjoativo do que um sem.

* Um designer para economia do jogo. Você pode pensar que isso é fácil, e você pode fazer tudo sozinho, mas de fato é uma das coisas mais complicadas. Se sua economia for mas projetada (ex os itens não estiverem propriamente balanceados, recursos são colocados aleatoriamente nos mapas, etc.) os jogadores vão ficar enjoados/frustrados e irão sair. Nós tivemos um grande problema em um dos nossos estágios iniciais, especialmente porque a economia foi feita principalmente por mim (um programador), e não foi planejada de maneira apropriada. Então levamos cerca de 2 meses para repensar e reimplementar um novo sistema de economia. Isso também exigiu uma eliminação total dos itens. Felizmente, a maioria dos nossos jogadores concordaram com a idéia, mas ainda foi frustrante gastar tantas horas argumentando, comprometendo, explicando, e em geral, perdendo tempo. Mas veremos mais da economia mais tarde.

Como mencionei antes, você irá precisar de 10 a 15 pessoas para o time, não incluindo os moderadores e administradores. Essas de 10 a 15 pessoas deveriam ter experiência prévia nos seus campos. Se todas elas forem iniciantes normalmente fica mais difícil, já que você irá precisar gastar muito tempo explicando a eles o que fazer, como fazer, porque o jeito que eles estão fazendo é ruim, etc.

Conseguir de 10 a 15 pessoas desde o início é quase impossível. Não importa o quanto você irá postar nos fóruns, você não vai conseguir membros do time de qualidade. Além do que, se alguém tiver muita habilidade em seu campo, porque ele iria se juntar ao seu time, se você não tem nada para mostrar? Muitas pessoas têm grandes idéias, mas implementa-las exige muito tempo e esforço, então elas preferem trabalhar em seus próprios projetos do que no seu. Então se você precisa de 10 a 1 pessoas, mas não consegue fazê-las se juntar ao seu time, como você conseguirá fazer um MMORPG? Bem, na realidade, você não irá precisar de todas elas desde o começo. O que você realmente irá precisar é de 1 programador e 1 artista. Se você é um programador, arrume um artista. Pegue um amigo com habilidades gráficas, pague um amigo de escola para fazer a parte artística ou outra coisa para você.

Agora que você tem um artista, e pelo menos uma idéia de como o jogo deveria ficar, é hora de começar a implementar a idéia. Uma vez que você tiver um projeto funcionando de um semi cliente/servidor, e alguns screenshots para mostrar (ou ainda melhor, a habilidade para os jogadores realmente logarem nos seu mundo, andar por ele, e conversarem um com o outro), mais pessoas irão querer se juntar ao seu time.
Preferencialmente, a menos que você tenha uma incrível tecnologia que ninguém mais tem, você deve deixar o código fonte do seu cliente aberto. Muitos programadores iriam se juntar (como voluntários) a um projeto de código aberto, ao invés de um projeto de código fonte fechado. O servidor, por outro lado, deve ser um código fonte fechado (a menos que você planeje desde o início fazer um código de MMORPG totalmente abeto).

Alguns outros conselhos: Não fique se gabando do seu jogo até que você tenha algo pra mostrar. Uma das coisas mais alarmantes é quando um novo usuário posta um pedido de ajuda, pedindo para um grande time se juntar ao jogo dele, explicando o quanto é legal o jogo dele. Uma vez que você tenha ido para os anúncios do website (normalmente em um serviço de host gratuito) você verá um impressionante menu de navegação, contendo seções como: "Download", "Screen Shots", "conceitos de arte", "Fóruns". Você clica no link de download, e você obtém um página muito legal de "Em construção". Então você clica clica no screenshot da página de Screenshots, e você terá o mesmo resultado. Se você não tiver nada para baixar, não coloque um link de um screenshot. Ainda melhor, nunca perca o seu tempo com um website até que você tenha pelo menos 10% dentro do projeto (programação e arte).

Sétimo passo: Desfazendo alguns mitos

1. Você não pode fazer um MMORPG, só dá pra uma companhia grande construir um.

Eu discordo disso. Enquanto produzir um jogo como um World of Warcraft, Ever Quest 2, Asheron's Call 2, Lineage 2, e outros é impossível para times pequenos, de desenvolvimentos independentes, fazer um jogo decente é possível, desde que você tenha experiência, motivação e tempo. Você irá precisar de pelo menos 1000 horas de programação para ter um demo muito simples, e talvez mais de 10-15K horas de programação para um cliente/servidor quase completo. Mas como o líder do time terá de fazer muito mais do que simplesmente programar, ele terá de manter o time junto, resolver conflitos, fazer relações públicas (RP), suporte de tecnologia, configurar servidores, banir criadores de problemas, brainstorming, etc. Serão suas atribuições. Então você também será sobrecarregado com tarefas que não são de programação. Então você provavelmente irá precisar ir para o trabalho/escola, o que diminui o tempo que você terá para se dedicar para o seu projeto. Nós tivemos sorte de nenhum membro ter deixado o time, mas se isso acontecer pode realmente ser um problema. Apenas imagine seu artista saindo na metade do caminho do projeto. E ainda pior, ele não te da permissão para usar mais a sua arte. Claro, isso pode ser resolvido assinando um contrato, mas seria muito penoso coseguir outro artista. Ter dois estilos de arte diferentes no mesmo projeto pode ser um problema.

2. Grandes quantias de dinheiro (normalmente com 4-6 dígitos) são necessárias para manter um servidor.

MMORPG. Bem, isso simplesmente não é verdade. Eu tenho visto servidores dedicados, como 1000GB/mês para aproximadamente 100 USD/mês (e uma configuração 2-300 USD livre). A menos que o seu protocolo de transferência de dados seja muito mal projetado, 100 GB/mês deveria ser suficiente para um servidor manter o seu website o os downloads dos seus clientes (o download do cliente pode gerar muito tráfego, uma vez que ele se torne popular). Nosso cliente tem cerca de 22MB, e algumas vezes nós temos uma transferência de 400 GB/mês. E nós não somos tão populares (ainda). Outra coisa é, você não irá precisar de um servidor dedicado para começar esse projeto. Um cabo DLS pode fazer esse trabalho muito bem, até que você atinja 20-30 pessoas online ao mesmo tempo. Aí é melhor encontrar companhia de hospedagem mais amigável para hospeda-lo de graça, em troca de alguma publicidade, ou pague do seu próprio bolso.

3. Fazer um MMORPG é divertido.

Isso não é verdade. Você pode achar que todo mundo irá gostar de você, que os jogadores serão suportáveis, que você pode fazer aventuras inovadoras, e, claro, ter muitos jogadores jogando o seu jogo. Jogadores podem ser irritantes. Como esse é um jogo totalmente livre, eles irão achar razões para reclamar. O que é pior é que as pessoas irão geralmente reclamar de coisas contraditórias. Os guerreiros não irão gostar do fato de ser muito difícil subir os níveis, enquanto os mercadores ficarão muito desapontados pelos guerreiros fazerem muito dinheiro com saques. Se você aumentar a dificuldade dos monstros, algumas pessoas ameaçarão deixar o jogo. Se você aumenta-la, as mesmas pessoas não irão gostar do fato de agora até os iniciantes poderem fazer dinheiro facilmente. Deixar como está, não é uma boa idéia. Tem de haver inovações e melhoramentos. Se você decidir mudar alguma coisa, por exemplo adicionar alguns desafios novos para aqueles que manufaturam itens, alguns irão dizer que é muito difícil. Se você não fizer, eles irão dizer que é muito fácil ou que jogar é enjoativo. Você deve ter notado que os jogadores satisfeitos geralmente não irão dizer nada e estarão satisfeitos, enquanto as pessoas problemáticas irão reclamar na maioria das vezes.

A economia é em um MMORPG é mais difícil de ser balanceada que o seu equivalente em singleplayer. Num jogo single player, você pode ter armas melhoradas gradualmente, então conforme o jogador avança ele pode conseguir um equipamento melhor, e abandonar (vender) o velho. Em um jogo multiplayer, por outro lado, esse é um conceito falho desde que todos podem pegar as melhores armas, pulando as armas de baixo nível. A maioria dos jogadores prefeririam não usar nenhuma arma e só ir salvando até que eles pudessem adquirir as melhor arma possível. O projeto da economia merece o seu próprio artigo.

Todas as coisas que eu enumerei até agora, adicionadas com o trabalho extra e com os desafios deveriam fazer você pensar pelo menos duas vezes antes de decidir se engajar em um projeto tão imponente. Você precisa entender as implicações da sua decisão.


Conclusão

Espero que esse artigo tenha dado a você a idéia que você precisava. Meu próximo artigo será sobre como configurar uma economia (mais especificamente, quais erros evitar), e alguma informação sobre como debugar um cliente e um servidor.

Sobre o autor

Esse artigo foi escrito por Radu Privantu, líder de programação e projeto pela Eternal Lands (www.eternal-lands.com), um MMORPG gratuito e com código fonte aberto.