Pensando no sistema de update
Nada muito grande mas como se trata de um jogo que pode levar muito tempo até chegar no final uma opção é realmente os updates.
Bom, como abrir um jogo e receber um aviso: "Favor atualizar seu cliente" é uma coisa chata até no cliente do World of Warcraft.
Então vou tentar incorporar a carga durante a execução do jogo. Teoricamente é simples e usando a experiência adquirida com sockets e threading desses últimos messes será "pá-pimba".
Isso também representa problemas como o desses desenhos: do jogador entrar num cenário, sair, fazer uma quest e voltar e encontrar um cenário modificado.
No entanto usando a arquitetura de database fica mais prático fazer isso do que com estruturas de arquivos, além de poder ter um controle de versionamento do jogo nas mãos do jogador!
É um rascunho de ideia meio doida mas coerente.
Estou adicionando essa ideia no documento de de coisas boas e ruins sobre jogos. Lembram-se dele? É uma tabela colaborativa que eu disponibilizei esses tempos aqui.
Como adotei a ideia de banco de dados como estrutura de arquivos, essa estratégia deve ser fácil de ser adotada, nem que represente clonar uma tabela que esta sendo usada em tempo de execução para realizar o update de forma suave.
(Sim tenho um certo vicio em databases, afinal são quase 15 anos de programação web XP )
Esses tempos eu me estressei com o recurso das "migrates" do framework Rails, e agora estou eu aqui pensando em montar scripts Lua para fazer o mesmo!!!
Teoricamente é só mandar código que automatize a migração de maquinas de estado dentro e fora do jogo. Bom o tempo dirá se essa teoria é de fato tão simples quanto parece.
^^
Bom, como abrir um jogo e receber um aviso: "Favor atualizar seu cliente" é uma coisa chata até no cliente do World of Warcraft.
Então vou tentar incorporar a carga durante a execução do jogo. Teoricamente é simples e usando a experiência adquirida com sockets e threading desses últimos messes será "pá-pimba".
Isso também representa problemas como o desses desenhos: do jogador entrar num cenário, sair, fazer uma quest e voltar e encontrar um cenário modificado.
No entanto usando a arquitetura de database fica mais prático fazer isso do que com estruturas de arquivos, além de poder ter um controle de versionamento do jogo nas mãos do jogador!
É um rascunho de ideia meio doida mas coerente.
Estou adicionando essa ideia no documento de de coisas boas e ruins sobre jogos. Lembram-se dele? É uma tabela colaborativa que eu disponibilizei esses tempos aqui.
Como adotei a ideia de banco de dados como estrutura de arquivos, essa estratégia deve ser fácil de ser adotada, nem que represente clonar uma tabela que esta sendo usada em tempo de execução para realizar o update de forma suave.
(Sim tenho um certo vicio em databases, afinal são quase 15 anos de programação web XP )
Esses tempos eu me estressei com o recurso das "migrates" do framework Rails, e agora estou eu aqui pensando em montar scripts Lua para fazer o mesmo!!!
Teoricamente é só mandar código que automatize a migração de maquinas de estado dentro e fora do jogo. Bom o tempo dirá se essa teoria é de fato tão simples quanto parece.
^^
Comentários
Postar um comentário
Como fiquei sabendo que um pobre blogueiro foi processado por um comentário anonimo esses dias, so me resta me precaver contra a ineficácia da legislação em tratar o meio online. Mas eu prometo que libero rapido ^_~