| |
| Acadêmico(a): Daniel Presser |
| Título: Protótipo de Motor de Servidor de Jogos Online em Massa |
| |
| Conclusão: |
| O protótipo implementado representa um exemplo de servidor de jogos online em massa. Ele possui boa parte das características esperadas de uma aplicação deste tipo, como a escalabilidade proporcionada pelo modelo de publicador-assinante juntamente com a utilização dos IOCP, a extensibilidade disponibilizada através da integração com o interpretador de scripts Lua, e a disponibilidade e tolerância a falhas conseguida com a separação das camadas no servidor. Entretanto, uma aplicação como um servidor de jogos online em massa não é uma tarefa trivial, nem mesmo uma tarefa que possa ser executada por uma única pessoa. Servidores comerciais são resultados de times de profissionais de diversas especializações trabalhando por vários meses, e até anos, unicamente num produto deste tipo. Ainda assim, as técnicas e ferramentas utilizadas demonstraram um resultado satisfatório aos requisitos definidos para este projeto. Além disso, o grau de extensibilidade conseguido permite que muitas outras funcionalidades sejam implementadas, sendo possível conceber enredos relativamente complexos e que apresentem muitas outras características de MMORPGs além das alcançadas no caso de uso implementado. Dos objetivos e requisitos declarados para este projeto, exceto pela implementação de uma camada cliente no formato de API, todos foram alcançados. A camada cliente acabou sendo desconsiderada pois, além de se distanciar do escopo do trabalho, provou-se uma ferramenta desnecessária, já que o protocolo especificado ficou simples o suficiente. Além disso, uma camada cliente destas, no caso da implementação de um jogo real, tornaria-se um problema por permitir que clientes não autorizados fossem implementados com muita facilidade. Clientes não autorizados, para jogos online podem ser um problema por darem vantagens desleais aos jogadores que os utilizam. Dessa forma, embora seja tecnicamente impossível impedir que seja criado um cliente que simule o cliente oficial, não é interessante facilitar isso. Embora seja difícil encontrar parâmetros para comparação, já que os motores de jogos existentes são proprietários e têm seus dados mantidos em relativo sigilo, as vantagens apresentadas pelo protótipo estão na sua própria arquitetura. A utilização de IOCP se demonstrou satisfatória, tanto do ponto de vista do desempenho, quanto do gerenciamento propriamente dito das conexões. A linguagem de scripts Lua se mostrou poderosa o suficiente para aplicações deste tipo, e a arquitetura de publicador-assinante, além de restringir satisfatoriamente o tráfego de dados, garantiu a escalabilidade e tolerância a erros esperada. Além disso, a simples criação de uma aplicação como esta já mostra-se como um desafio vencido, já que há muito pouco conhecimento estabelecido sobre os assuntos relacionados. No entanto, o protótipo desenvolvido possui algumas limitações, como as listadas a seguir: a) não permite inimigos que não sejam outros jogadores, e nem dá possibilidades de implementação disto através dos scripts de extensão; b) não permite a definição de mapas em formatos que não retangulares, e a definição de áreas não transitáveis no mapa precisa ser definida com scripts; c) não possui interface para configurações do servidor, como mapas, servidores de sessão e localização, etc., sendo que estas configurações precisam ser feitas diretamente no banco de dados; d) o sistema de autenticação não é seguro, pois a senha trafega aberta até o servidor; e) embora a tolerância a erros seja garantida pela arquitetura do servidor, a implementação das camadas não trata este tipo de erros adequadamente. Com isso, caso algum erro aconteça, normalmente o ambiente só se reestabelece de maneira adequada após o reinício de todos os servidores; f) não há ferramentas nem a figura de um administrador do servidor, portanto, a única maneira de desconectar um cliente, por exemplo, é finalizando os servidores; g) a mensagem de chat possui tamanho fixo, fazendo transitar dados desnecessários em mensagens curtas; h) o gerenciamento de memória e de sincronização entre os threads não é eficiente. Para memória, aloca-se e libera-se conforme a necessidade, sendo que o recomendável seria utilizar algum tipo de pool. Já para a sincronização, utiliza-se sessões críticas, que também poderiam ser substituídas por alternativas mais rápidas, embora mais complexas. |
| |
|
