deV( )id Games | because we're tired of no return;

Sep/09

26

Fundamentos deVoid(2) – Cliente/Servidor

Antes tarde do que nunca!

Jogos têm algo muito importante que, apesar de ser em parte meio subjetivo, ainda pode ser medido por características gerais: o Replay Value, ou seja, o quanto as pessoas vão jogar aquele jogo de novo. Existem várias características que podem influenciar isso, como IA avançada, caminhos diferentes a serem tomados, finais diferentes…

Mas no fim das contas, sempre recai no que a gente falou aqui: diversão. Você pode ter uma história genial, gráficos excelentes, mas se a experiência de jogar for igual a várias outras, as pessoas não vão voltar pra mais. Isso acontece porque temos mais prazer ao passar por experiências novas, experimentar gameplays diferentes, cenários diferentes, situações diferentes. E foi aí que apareceram dois grandes caminhos que são, teoricamente, focados no replay value:  jogos “abertos” e jogos multiplayer.

Jogos Abertos

Um jogo aberto talvez até fuja um pouco da definição normal de “jogo”, já que ele não é planejado pra haver um ganhador, e sim pra ser “vivenciado”.  Alguns são “open-ended“, ou “sandbox“: podem ter um objetivo definido, mas existe um mundo a ser explorado e você completa a história só se/quando quiser. Um grande exemplo disso é a série The Sims: você cuida dos seus bonequinhos, compra coisas pra eles e, pra muitas pessoas, mais ainda: projeta seus desejos no mundo virtual. “Nossa, eu sempre quis ter uma casa gigante e uma mesa de bilhar no meu quarto!” – e um klapaucius depois, lá está tudo isso.

"O meu nome vai ser Mindy e eu vou ter um pônei rosa! ^^"

"O meu nome vai ser Mindy e eu vou ter um pônei rosa! ^^"

A idéia é criar várias simulações de situações, ou de personagens, que façam cada “passagem” pelo jogo parecer diferente da outra – mesmo tendo um set finito de acontecimentos possíveis, quanto mais complexo o seu mundo e os seus habitantes, mais chances existem de acontecerem coisas diferentes. E nisso as séries como The Sims, Grand Theft Auto e SPORE se tornaram especialistas.

Jogos Multiplayer

Qualquer coisa que não seja Single-player é multiplayer, ok. Mas na era dos videogames de 16 bits, você só jogava com duas pessoas, e em 99,9% dos casos, ela tinha que estar na mesma sala que você (pra quem não sabe, a SEGA tinha um serviço de multiplayer via modem, onde você podia até baixar jogos).

Quando os PCs se tornaram plataformas mais populares, ficaram mais comuns os jogos que suportavam multiplayer ponto-a-ponto: você ligava com o seu modem diretamente no do seu amigo pela linha telefônica e os dois jogavam remotamente. Só mais à frente, com a popularização da Internet, o multiplayer de vários jogadores se tornou mais viável. E isso aconteceu mais ou menos na época em que os FPSs eram os grandes jogos de sucesso da indústria. E foi aí que perceberam que, mesmo que o seu single player seja algo muito legal, mas que só tenha graça de ser jogado uma vez, se você colocar um multiplayer excelente, isso aumenta o seu replay value – e o valor do seu produto.

Quake, da iD software, foi uma revolução não só nos gráficos, como também na idéia de multiplayer. Fundou a era dos “FPS’s de verdade”, que contou com sucessos como as séries do Unreal e do Half-Life. E o multiplayer dele até hoje é jogado. Lembrando que o jogo vai fazer 14 anos ano que vem, tão antigo que até as suas duas seqüências já tiveram o código fonte liberado.

Minha primeira namorada.

Minha primeira namorada.

E qual a grande sacada disso tudo, do ponto de vista da arquitetura? No Quake, mesmo o jogo Single Player era como se fosse uma conexão a um servidor local. As regras eram diferentes, mas o management de jogadores era o mesmo. E isso é muito importante, porque abre muitas portas, principalmente em relação a código. A grande essência da coisa é: mesmo que os jogadores estejam na mesma máquina, eles são clientes.

Mas eu não preciso fazer isso pro meu jogo, ele é só single player!” – Concordo com você. Se ele não vai ter nenhuma faceta multi-jogador, realmente é completamente fora do escopo. Mas no nosso caso, como não tivemos nenhuma idéia de puzzle genial, não temos um artista genial, e nem uma IA genial (ainda) e muito menos dinheiro pra contratar uma equipe maior (e genial), decidimos fazer crowdsourcing do trabalho duro e colocar a diversão na mão dos jogadores :D

É sério. De preferência bolo.

No nosso framework, tanto os jogadores (locais ou remotos) como a IA são tratados como “clientes”. O código do servidor instancia o núcleo do jogo e espera por conexões. Isso possibilita que todo o código de controle seja o mesmo para todos os tipos de personagem. Assim, o que acontece não é definido pelo tratamento no código do jogo pra cada tipo de entidade, e sim pela reação das entidades ao ambiente (isso envolve filosofia e cartas-na-manga pro futuro, então não é o foco do artigo, mas um dia eu explico).

E quais as outras grandes vantagens dessa abordagem?

  • Os clientes funcionam como “terminais”, ou seja, podem haver mudanças no servidor sem que isso afete o código do cliente, não sendo necessário fazer deploys de versões novas a cada mudança ou ajuste. Isso é essencialmente importante pra fazer fine-tuning da jogabilidade e do balanceamento;
  • O código de jogo é completamente reutilizado no que tange a lógica do mundo. Não existem checagens se o jogo é multiplayer ou não, só é preciso bloquear a entrada de jogadores caso não seja esse o intuito;
  • O servidor é o juiz: somente as checagens básicas do jogo são executadas no cliente, mas as decisões reais de regras acontecem no servidor. Isso permite maior segurança contra cheats. Claro que quando o sevidor está em um cliente, ele pode sofrer algum tipo de modificação, mas a idéia é sempre fazer coisas reutilizáveis – quem sabe até a época em que você arrume grana pra pagar um servidor dedicado.

Nosso primeiro projeto será essencialmente multiplayer. Talvez vá ser adicionado single player no futuro, mas a IA tem que ser melhor estudada antes de ser plugada – como cliente do servidor local ;)

Curiosidade de sobremesa: reza a lenda (contada por ele mesmo) que quem inventou o conceito de jogos pela internet foi o Al Lowe, criador da série Leisure Suit Larry, em 1990. Confira o causo aqui!

RSS Feed

1 Comment for Fundamentos deVoid(2) – Cliente/Servidor

Denilson | 08/10/2009 at 5:07 pm

Só para mostrar como a solução cliente/servidor pode ser implementada de maneira “diferente” (contrária àquela citada neste post):

Alguns anos atrás, o jogo Cube (e a sequência, Sauerbraten) tinha toda a lógica programada no cliente, enquanto o servidor era extremamente burro. Com isso, infelizmente, algumas pessoas começaram a mudar o código-fonte e atrapalhar outras pessoas nos jogos online.

Mais recentemente, algumas checagens mais básicas já foram incluídas no servidor do Sauerbraten, mas, até onde sei, a maior parte da lógica continua no cliente.

Leave a comment!

<<

>>

Busca

Tema baseado no jQ por devolux.org