[Arquivado]Browse Games - Uma Realidade?

[Diogo 29]

Posto aqui um artigo criado por mim para um conhecido que estava interessado no assunto.

 

---

 

Browse Games - Uma realidade?

 

Com o uso cada vez maior da internet e o surgimento da web 2.0, não precisa-se ser muito esperto para prever um futuro onde todas as aplicações rodarão em grandes servidores e ao usuário comum caberá apenas se conectar a um website quando quiser editar uma foto, criar uma planilha ou usar um editor de textos.

 

Há alguns grandes empecilhos óbvios a essa tendência: limite da velocidade de conexão e... jogos eletrônicos.

 

Os grandes jogos de hoje em dia são tão avançados, possuem tantas leis da física embutidos e gráficos tão realistas, que os navegadores web atuais simplesmente não conseguiriam suportar. Eles não foram feitos para isso.

 

Porém, esses mesmos navegadores web, apesar de não conseguirem rodar aplicações tão robustas sem comprometer seriamente o desempenho da aplicação se comparada a uma escrita em C, por exemplo, estão também cada vez mais avançados.

 

Renderizadores mais rápidos, quer sejam de javascript, quer sejam de css, permitem que verdadeiras "maravilhas" sejam feitas com toolkits como Dojo, cuja seção de exemplos do website oficial é incrível.

 

Entretanto, há ainda outro grande empecilho, nesse caso para jogos online, que claramente seriam o verdadeiro objetivo de desenvolver um jogo num browse: o protocolo HTTP.

 

Jogos online como os conhecemos utilizam conexões socket que permanecem ativas enquanto o servidor e cliente se comunicam. Mas o protocolo HTTP não permite isso.

 

Ou melhor, permite em meio termo:

 

Um servidor pode criar uma "conexão eterna" com o cliente simplesmente se recusando a encerrá-la e utilizá-la como uma via única de comunicação. Um exemplo de como isso poderia ser utilizado:

http://www.ueboo.com/files/741852/index.php_369258.php

Obs.: A diretiva output_buffering do php.ini precisa estar definida para o valor "0".

Obs.2: Só roda em Internet Explorer (no caso utilizei o 7).

 

O cliente, entretanto, não tem possibilidades de fazer o mesmo apenas com javacript ou css.

 

Há, porém, no ActionScript 3.0, os sockets xml e os sockets binários.

 

Mas nesse caso caberia ao desenvolvedor criar uma aplicação server/client padrão, utilizando a linguagem que quiser como servidor. Um exemplo utilizando Java e socket XML pode ser encontrado aqui:

http://help.adobe.com/pt_BR/ActionScript/3...90204-7cfb.html

Mais informações podem ser encontradas aqui:

http://help.adobe.com/pt_BR/AS3LCR/Flash_1...net/Socket.html

 

Mas não é esse o universo (que conta ainda com Java applets) o qual contemplarei nesse artigo, por não haver nenhuma inovação sobre o que é feito normalmente.

 

O que fazer quando queremos tratar de um cliente que utiliza o protocolo HTTP, que a única conexão possível com o servidor é através do próprio navegador e não há como o cliente criar uma conexão permanente com o servidor que permaneça ativa?

 

Bom, consigo ver duas maneiras distintas de realizar isso:

 

 

 

1 - Servidor totalmente multi-thread (Java/C++)

 

Utilizando algo semelhante ao exemplo dado em PHP de conexão servidor/cliente sempre ativa, o servidor nesse aspecto agiria como qualquer servidor de jogo, mandando dados atualizados constantemente.

 

O cliente, entretanto, utilizaria AJAX (ou xmlHttpRequest, para ser mais exato) para mandar informações para o servidor.

 

A validação de identidade seria feita por session + ip e, além disso, o servidor poderia mandar uma nova chave para o cliente a cada N segundos/minutos, que deveria ser utilizada em cada requisição do cliente com o servidor.

 

O servidor passaria apenas dados, que o cliente transformaria em informação; ainda utilizando o exemplo dado em PHP, isso seria feito em algo como:

 

12:3:4:5;23:Lala;

 

Quando o servidor mandasse esses dados, o cliente decodificaria:

 

12 - Movimentação

 

3 - ID do personagem para ser movimentado

 

4 - Posição X

 

5 - Posição Y

 

; - Fim do comando

 

23 - Mensagem do servidor

 

Lala - A mensagem a ser exibida

 

Logo após usar os dados para mostrar o que deve, o cliente os exclui para que não haja sobrecarga de informações no código fonte .HTML.

 

 

 

2 - Servidor não multi-thread (ambiente web)

 

Esse seria um ambiente web típico: um servidor apache usando scripts PHP ou coisa semelhante.

 

Nesse caso o PHP precisaria salvar dados de posicionamento e afins em um banco de dados, com o tempo de adição daqueles dados.

 

Uma session seria responsável por determinar a última atualização dos dados do determinado cliente e, a cada atualização, o servidor mandaria todos os dados e/ou informações atualizados para o cliente, priorizando dados (no estilo do proposto para servidores multi-thread) para economizar tráfego e tempo de resposta.

 

No caso, o cliente utilizaria xmlHttpRequest para pedir atualizações a cada X segundos e enviaria dados também por xmlHttpRequest.

 

A grande desvantagem desse método é o excesso de requisições HTTP enviadas e processamento.

 

Entretanto, a grande vantagem é poder utilizar um simples webhosting como servidor para o jogo.

 

Vale lembrar que mesmo servidores multi-threads podem utilizar método semelhante (chamadas do cliente pedindo atualização) se acharem que devem por algum motivo (incompatiblidade de navegador e etc), ainda que não seja aconselhável.

 

 

 

Como acréscimo, vale dizer que plugins como o Greasemonkey para o navegador Firefox poderiam permitir o desenvolvimento de um cliente muito melhor.

 

 

A conclusão é:

 

A menos que utilizemos ActionScript, a realidade dos jogos online utilizando o navegador como cliente é precária e exige adaptação por parte do desenvolvedor.

 

Vale a pena? Talvez.

 

Pode ser que esse seja o momento de surgirem pioneiros nos browse games (de verdade, e não meras aplicações usando uma linguagem de script e banco de dados), mas também pode ser que seja muito cedo. Quem sabe o que o futuro próximo reserva?

 

Meu conselho?

 

Tente; e divirta-se tentando.

 

Diogo Dias Barreiros

 

---

 

Gostaria de opiniões e afins para discutirmos esse assunto que pode vir a se tornar uma realidade num futuro bem próximo.

[Eventide 23]

Com o uso cada vez maior da internet e o surgimento da web 2.0, não precisa-se ser muito esperto para prever um futuro onde todas as aplicações rodarão em grandes servidores e ao usuário comum caberá apenas se conectar a um website quando quiser editar uma foto, criar uma planilha ou usar um editor de textos.

 

Eu discordo, não acho viável você ter que entrar em um site toda vez que quisesse usar um programa, e acho que as linguagens web tem que correr muito para alcançar as linguagens de baixo nível, até pode ser que os aplicativos webs evoluam bastante, mas nunca substituirão por completo os aplicativos "normais"(esqueci o termo certo ), e quanto ao desenvolvimento de jogos web, há exemplos de alguns que são bem interessantes e que até superam outros "normais", vide runescape e the crims..

[Administrador 1435]

@eventide

 

rapaz, a web ta caminhando muito rápido. Falo pelo mundo corporativo, que vivo diariamente, hoje o critério "performance" é muito melhor substituido pelo critério "portabilidade". Hardwares são muito baratos e 70% das médias e grandes empresas que desenvolvem sistemas no mundo corporativo usam JAVA. Bem, java é uma linguagem interpretada, ela roda sob uma máquina virtual e a performance é quase 10x inferior (no geral, salvo em alguns casos) que do C++ que é uma linguagem nativa.

 

Por este pensamento, sou totalmente aliado ao VAL. O futuro é o mundo ser totalmente conectado, até seu HD será WEB, seu SO e tudo mais. Não há escapatória.

 

Abraços

[Eventide 23]

O futuro a deus pertence, quem sabe isso ocorra..

Se acontecer dessa forma, talvez eu diga: "noss, como fui idiota de não ter percebido essa evolução!"

 

Mas acho que essa concepção de TUDO estar ligado a web, já é uma realidade, afinal maioria dos programas(inclusive o windows) fazem atualizações e conexões com a internet para fazer updates e etc..

[Diogo 29]

Eu discordo, não acho viável você ter que entrar em um site toda vez que quisesse usar um programa, e acho que as linguagens web tem que correr muito para alcançar as linguagens de baixo nível, até pode ser que os aplicativos webs evoluam bastante, mas nunca substituirão por completo os aplicativos "normais"(esqueci o termo certo ), e quanto ao desenvolvimento de jogos web, há exemplos de alguns que são bem interessantes e que até superam outros "normais", vide runescape e the crims..

 

Realmente, substituir TOTALMENTE é algo bem difícil, talvez num futuro distante.

 

Agora sobre não ser viável entrar em um site toda vez que quiser usar um programa, veja a própria microsoft que já está criando uma versão "online" do office (ou algo do tipo) para bater de frente com a concorrente Google (com o Google Docs, que eu uso e acho MARA).

 

Quando mais dados por segundo formos capaz de transferir, mais vamos deixar o desktop para trás. O sistema operacional do seu computador vai ser enxuto o suficiente para que você apenas se conecte à internet, ele será como um navegador.

 

Ok, pode ser um pouco forçado pensar nisso agora, mas veja só: quando, há poucos anos atrás, você pensava que existiria um lugar para você fazer upload de vídeos e compartilhar com todos?

 

Aos poucos a internet vem ocupando o espaço de coisas tradicionais como o bom e velho álbum de fotos (qualquer um mostra as fotos diretamente na máquina digital ou passa para amigos pela internet).

 

Quem hoje em dia baixa e-mails para ler quando se é possível ter uma ferramenta extremamente melhor que o Outlook em um ambiente online (GMail)?

 

Daqui dez anos, quando celular for coisa do passado e os aparelhos 3G já estiverem sendo ultrapassados, você vai querer poder ver seus e-mails tanto no seu 4/5G na escola, quanto em casa. Você vai querer poder ver as fotos que estariam no seu PC em casa também no seu 5G, sem precisar copiar seus arquivos. É óbvio que eles estariam na rede.

 

No máximo você teria a opção de realizar backup para visualização offline, como já existe essa opção no GMail (em conjunto com Google Labs)

 

MSN Messenger vai desaparecer por causa do seu peso excessivo. Aplicativos web como Meebo (ou algo desenvolvido pela própria Microsoft) vão substitui-lo, e ele será muito melhor.

 

Visualizar a mesma situação com jogos pode ser complicado com a tecnologia que temos hoje, mas algo do tipo virá, quer a gente queira, quer não.

 

Ao menos é assim que penso

 

----

 

Edit: Como um upgrade para meu ponto de vista:

http://www.eyeos.info/ -- "Sistema operacional" por navegador

Mais sobre o conceito:

http://www.eyeos.org/

http://www.conexaovip.com/blog/tecnologia/...-dados-na-nuvem

Editado Fevereiro 10, 2009 por VaL

[Zafor 1]

Também estou apoiando o VaL e concordo com essa parte Mas acho que essa concepção de TUDO estar ligado a web, já é uma realidade, afinal maioria dos programas(inclusive o windows) fazem atualizações e conexões com a internet para fazer updates e etc.. do Eventide ;P

[u n d e r 110]

É, nada mais nada menos do que unificação então né? Com as transformações, perde-se a verdadeira "identidade" do que aquilo foi desenvolvido para ser útil. Um exemplo prático é dos próprios navegadores.

[kasssspi 0]

; ))))))))))))))))))))))))))

[noobinhu 38]

/\ boa

 

bom, com certeza fazer um jogo em browser é mais fácil de se fazer do que um clássico, o principal motivo é que não precisa de tantos gráficos, eu que já fiz um jogo em browser, curti o resultado do mesmo, porém se fosse feito em linguagens desktop seria um resultado bem melhor.

 

aí vai da equipe que quer criar o jogo, se tiver capacidade, renda (é extremamente mais caro manter um dedicado com suporte a ataques DDOS e etc em relação a um webhost) e paciência para fazer um desktop, que faça, caso contrário, fuja para a opção do browser.

 

eu não fiz o pokémon como um jogo clássico, por 3 motivos: dedicado, falta de designer/spriter e não ter ninguém para ajudar, fazer um jogo sozinho é muito cansativo.

[RedZL 6]

Elvendo, flood/spam¹ é proibido no XTibia.com com pena de alerta. Desta vez estou apenas lhe advertindo pois é a prática recomendada pela administração na primeira vez em que ocorre a infração, entretanto caso volte a repetir eu estarei lhe alertando.

 

¹ - Encaixam-se nesses termos, propagandas não permitidas pela equipe, posts que fogem do assunto original do tópico ou do assunto que está sendo discutido e mensagens sem sentido.

Editado Maio 5, 2009 por RedZL

[Iben 0]

Allessandro é direito! Yours

[Héliton 1]

Utilizando PHP/MySQL e JavaScript/AJAX já é possível criar um jogo igual ao Tibia que seja suportado até pelo IE6.

[Diogo 29]

Aham!

 

O problema é que com Javacript/Ajax não é possível criar uma conexão de sockets, então a "paradinha" server/client não existe e o jogo fica com muito mais chances de ter lag ou coisas do tipo.

 

Talvez o melhor seria usar Flash/ActionScript para fazer essa conexão e Javascript/Ajax para o resto do cliente. É possível fazer essa comunicação Flash/Javascript?

 

A desvantagem do Javascript é que o client fica Open Source, e raramente encontramos um jogo com client Open Source, até por questões corporativas. Ninguém quer que o concorrente copie seu client, modifique algumas coisas e faça algo muito melhor, né!?

 

Imagina, por exemplo, se o client do Tibia fosse Open Source. Os clients de OTServ estariam milhares de anos luz à frente da CipSoft.

[Héliton 1]

Bom, nesse caso quem gera o client é o PHP, então o fato de você ver o client, não quer dizer que você tem o client. hehe

 

Um socket é criado para comunicar A ao B. A web por sí só já comunica A ao B, não é preciso um socket, é só saber usar o banco de dados corretamente. ;P

[Diogo 29]

Um socket já aberto é melhor que deixar a comunicação baseada em:

 

Cliente manda requisição

Abre-se conexão

Troca-se informação

Fecha conexão

 

Dá para fazer, mas até dados inúteis são enviados devido à natureza do próprio protocolo HTTP.

 

E eu falei que o client seria Open Source, porque quem vai fazer a comunicação com o servidor é a página web, e é possível ver tudo que tem nela.

 

Mas acho que não estamos nos entendendo... Dà pra falar mastigadinho o que você quer dizer? xP