Questões técnicas

Como codificar a lógica de jogo no menor espaço?

• Usar uma linguagem de opcodes semelhante a uma linguagem de máquina, onde verificações e operações ("o avatar está na sala nº X?", "o objeto nº X está presente?", "RND(1)*100 <= X?", "colocar objeto nº X na sala atual", "escrever mensagem nº X" etc.) estariam representadas por números (opcodes), e os parâmetros viriam a seguir. Seria preciso programar uma "máquina virtual" para interpretar essa linguagem de opcode. {Emerson Costa}

  • Acho que a máquina virtual consumiria quase todos os recursos, sobrando pouco para utilizar no jogo em si. {Arthur Lopes}

• Criar uma linguagem de script (ou utilizar uma já existente) e um compilador que transformasse os comandos desta linguagem em código Assembly específico das diferentes plataformas. Assim seria feito um motor de criação de RPGs multiplataformas, o que permitiria que muitos outros jogos fossem criados com facilidade e não apenas um. {Arthur Lopes}

  • Acho essa ideia muito mais viável que a de um interpretador de bytecodes em tempo real. Uma opção alternativa seria fazer algo na linha do LLVM (tá, menos): vc. pega código C, compila para um bytecode intermediário e depois gera o Assembly / código de máquina nativo. No entanto, acho mais prático e direto uma linguagem que, ao ser compilada, já gere o código para a plataforma de destino, um super compilador cruzado. Mas aí acho que pode virar vapor, além do fato de que mudaria o foco do projeto: fazer um RPG multiplaforma, e não uma linguagem + bibliotecas multiplataformas. {Robson França}

• Usar a linguagem de script não apenas para a lógica de jogo, mas para toda a especificação do RPG. Quem desejar fazer um port para a plataforma XYZ criaria um arquivo com os "defines" específicos da plataforma em questão.

  Como exemplo, um arquivo para o Master System definiria coisas do tipo:

  graphics=TMS9918 (e quem quiser que implemente para esse chip os métodos de acesso ao vídeo do script do jogo)
  sound=SN76489 (idem para o som)
  graphicsMaxX=256
  graphicsMaxY=192
  mem=8KB
  videomem=16KB
  

  etc, etc. {Leonardo Roman da Rosa}

Como codificar os mapas no menor espaço?

• Criar as telas proceduralmente, permitindo ultrapassar a limitação de memória sobre o tamanho do mundo e liberando mais memória para ser utilizada em outras coisas. Eu toparia fácil o desafio de criar um editor de mapa que já convertesse o mapa para uma forma procedural aproximada.

  Basicamente, ao invés de, dadas as coordenadas X e Y, calcular a posição de memória que contém o valor do elemento a ser desenhado e depois ler este valor, você tem uma função F(x, y) cujo resultado é o valor correspondente ao elemento a ser desenhado. Chutando um valor para exemplificar, digamos que uma determinada função dessas tenha 96 bytes de tamanho, e que tanto X quanto Y possuem 2 bytes cada. Então, com 100 bytes você criaria um mundo de 65536x65536.

  Mas há dois problemas com esta técnica: se a função for muito complexa (grande), vai gastar muito processamento, pois ela será executada para cada ladrilho de cada tela; e ela é mais fácil de usar quando você não tem nada e quer gerar algo, mas quando você já tem um mapa pronto e quer criar a função que vai reproduzir este mapa, aí é osso (e é exatamente neste segundo caso que eu mais me interessei). {Arthur Lopes}

• Preenchimento de polígonos: criando uma "meta-linguagem" bem justinha pra descrever as telas, acho que consegue-se fácil socar uma tela inteira em 1Kbyte.

  Uma técnica não elimina a outra - gasta-se um pouco mais de espaço, mas nada impede que se dê suporte para "shapes" ou "tiled maps" também. {Lisias Toledo}

Como armazenar texto e caracteres no menor espaço?

• A disponibilidade de letras minúsculas e letras acentuadas vai depender de não haver escassez de memória. {Emerson Costa}

  • Eu sugeriria só letras maiúsculas e sem acentos (em um padrão de 4x8 a legibilidade já fica comprometida, acrescentar maiúsculas e minúsculas). {Giovanni Nunes}

• Precisaria ver se haveria (ou não) a necessidade de um algoritmo para comprimir o texto (já que não teremos acentos, dá pra colocar as 128 sílabas mais comuns no ASCII de 128 a 255). {Giovanni Nunes}

  • Uma possibilidade de algoritmo de compressão é o LZ77, implementado no ZX Spectrum no programa ZX7.

Como realizar carga de cassete no menor tempo?

• Implementar o OTLA para esses micros. {Lisias Toledo}

Qual o layout da tela?

• Os primeiros dois terços da tela (4KiB) ficariam reservados para o desenho do cenário enquanto o terço restante (2 KiB) para o texto (32x8 caracteres). Para ganhar alguma velocidade no desenho do cenário a primeira e última linhas são descartadas, dando uma área de 16x14 tiles (poderia ser feita uma redução horizontal mas ai complicamos a rotina de desenho em troca de uma claustrofobia pro herói). {Giovanni Nunes}