FunOrb Central: Parte 2 - Desenvolvimento de um Limite (de Memória)
28 de maio de 2009 – Desenvolvimento de um Limite (de Memória)
Esse diário aborda um dos mais importantes problemas envolvidos com o desenvolvimento de jogos do FunOrb e FunOrb Central: consumo de memória.
A memória de um computador forma uma espécie de pirâmide. Na parte superior, há uma pequena quantidade de memória rápida embutida no computador (memória cache). Na parte inferior, há uma memória lenta, com ampla capacidade de memória (o disco rígido, também conhecido como HD). Entre essas duas partes, fica a parte relevante a esse diário: a memória principal. A transferência de dados entre esses três tipos de memória é um aspecto importante do desenvolvimento, pois afeta profundamente a performance.
Quando um miniaplicativo Java (como um jogo FunOrb, por exemplo) está rodando, ele é armazenado na memória principal. Todos os recursos de um aplicativo (gráficos, música, efeitos sonoros, etc.) têm que ser armazenados na memória antes de poderem ser usados. Infelizmente, as versões de Java geralmente instaladas limitam a quantidade de memória que pode ser usada. Esse limite (conhecido como "alocação dinâmica de memória") fica em torno de 64MB, e os recursos de um jogo do FunOrb o excedem facilmente. Um fundo de tela de proporção média ocupa aproximadamente 1MB, e fundos de tela grandes (como um mapa pano de fundo de Arcanistas) ou imagens de animação (como animações de Desafio de Tor) podem ocupar ainda mais.
FunOrb Central nos restringe ainda mais, pois tanto o jogo quanto o FunOrb Central tem que rodar dentro do limite de 64MB. Para atenuar o problema, temos o objetivo de fazer o FunOrb rodar dentro de um limite de 10MB de memória, deixando 54MB livres para o jogo. Como no momento muitos jogos do FunOrb exigem mais do que esse limite de memória, nós teremos que alterá-los. Isso obrigará toda a equipe de desenvolvimento do FunOrb a se ocupar com trabalho técnico.
Essas são algumas técnicas que usaremos:
- Nos livrar de conteúdo que não está mais sendo usado (como, por exemplo, uma sequência introdutória, quando terminar)
Parece simples, mas isso acarreta complicações. Como não podemos prever quando os dados precisarão ser usados novamente, preferiríamos mantê-los na memória por questão de rapidez. Quando isso não for possível, optaremos por uma cópia comprimida. Apesar de mais lenta, essa opção economiza espaço.
- Mudar o formato de dados na memória
Quando temos que decidir como o conteúdo será armazenado na memória e disponibilizado para download, sempre tentamos contrabalançar performance, qualidade e tamanho. Para aumentar ao máximo a velocidade de nossos jogos, nós geralmente optamos pela versão menos comprimida, mas por causa das restrições de memória, às vezes temos que optar por outros recursos, como imagens comprimidas*, por exemplo. O truque consiste em nos certificarmos de que qualquer perda de qualidade ou performance seja imperceptível ao jogador.
Mas nem mesmo o uso dessas técnicas será suficiente para fazer o FunOrb Central funcionar dentro do limite de 10MB. Após conversarmos com Andrew sobre esse assunto, decidimos usar outro subterfúgio... Há uma série de recursos tecnológicos que foram acrescentados à Java há alguns anos, sob o misterioso nome de "NIO" (que em inglês significa "new imput/output" ou "non-blocking input/output"). O objetivo principal desses recursos é permitir que aplicações Java tenham rápido acesso aos arquivos e dispositivos da rede. Mas eles têm uma outra característica interessante: permitir que os aplicativos aloquem um pouco mais do limite 64MB. Com essa técnica, esperamos conseguir fazer com que o FunOrb Central armazene a maior parte dos dados em um "espaço fantasma", extraindo somente as partes que precisamos armazenar na memória, e apenas durante o período necessário.
O outro aspecto do gerenciamento de memória no FunOrb Central é o que fazer quando há memória suplementar disponível para utilização. Os jogadores que ajustaram as configurações de memória para as versões mais recentes de Java têm acesso a mais de 64MB. Queremos ter certeza de estarmos tirando proveito da memória extra, quando estiver disponível. Alguns de nossos jogos atuais já utilizam memória suplementar, através de uma técnica Java que se chama "referências soft". Essa é uma forma de pedir a Java para manter os dados na memória, ao mesmo tempo permitindo que o computador se livre deles caso o espaço esteja se esgotando. Um exemplo é Ataque à masmorra, onde a performance do jogador melhora com mais memória alocada, pois não é preciso descomprimir as animações. Seguindo essa linha de pensamento, queremos que FunOrb Central mantenha jogos inteiros carregados na memória, quando memória suficiente estiver disponível. Isso deverá reduzir o tempo de carregamento, quando versões mais recentes de Java forem utilizadas.
Então, o que isso significa para nós? Em princípio, que o FunOrb Central terá requisitos semelhantes aos dos jogos atuais do FunOrb - se eles funcionam normalmente em seu computador, você não terá problemas. O FunOrb Central usará melhor os recursos de computadores que tenham versões recentes de Java instaladas. Nós daremos detalhes sobre requisitos e recomendações quando a data de lançamento estiver se aproximando. Portanto, fique ligado!
Mod Artifice
Desenvolvedor do FunOrb
