[Pergunta retórica] room em constante mutação

Essa pergunta é só pra saciar minha curiosidade, não tenho nenhum projeto dependendo dela ser respondida, nem planos pra isso.

Certa vez, joguei um joguinho em flash que era um capa-e-espada de um caval(h)eiro que tinha que salvar uma mocinha, provavelmente princesa. Side-view, beat-em-up. Se eu nunca tivesse escrito um script, não veria nada demais no jogo, mas ele tem umas características que me deixam tonto.

Primeiro, ele tem dúzias de inimigos. O cara investiu pesado na diversidade.
Tá, isso não é muito impressionante. O impressionante mesmo é o level design. O jogo todo acontece numa torre ou coisa parecida, com vários andares e escadas nos cantos. Você sobe e desce o tempo todo, dependendo do que acontecer. E acontece muita coisa ao longo do jogo.
Ainda não é impressionante. Mas calma.

O lance é que a arquitetura da torre muda diante dos olhos do jogador. Muitas vezes. Pisos seguros se transformam em gelo escorregadio quando o mago foge. Outro piso, de um andar superior se transforma numa parede de escombros no andar de baixo, quando o dragão entra. Depois, um terremoto e três andares desabam, deixando apenas algumas pedrinhas pro jogador pular. Tudo influenciando a jogabilidade.

Sempre com os tijolinhos mudando de lugar diante dos olhos do jogador. Algumas vezes eles eram criados, outras vezes eles sumiam, mas sempre diante dos olhos. Aí vem minha dúvida. Como você acha que o desenvolvedor fez isso? Qual a forma mais fácil (ou menos difícil) de chegar a esse resultado?

Eu gosto muito de pensar na idéia de que, na verdade, existem muitas rooms no jogo. Que a situação no final de uma animação é a mesma situação inicial da room seguinte. Afinal, eu não lembro se o jogador tinha uma posição fixa pra acontecerem as animações, mas tenho quase certeza de que não há inimigos na tela, nessa hora. Assim, os tijolos caindo são só uma coisa visual e a interação da personagem com a situação posterior é por causa de objetos invisíveis colocados estrategicamente na room.

Eu NÃO gosto de pensar que o desenvolvedor planejou tudo, todas as animações, todas as situações, num objeto só que fica mudando todo mundo de posição em função do que o jogador conseguiu completar.

Mas as duas explicações têm um ponto fraco, no que diz respeito à facilidade de programar. A primeira exige uma fase de testes muito criteriosa, pra não deixar passar nenhuma diferençazinha entre uma fase e outra. A segunda exige um hercúleo esforço mental pra não enlouquecer com tantos objetos a serem controlados, sem esquecer nenhum pra trás.

Como VOCÊ acha que isso foi feito?

Bônus: Você sabe de que jogo estou falando? Se sim, tem um link?

Eu provavelmente faria planejando "tudo, todas as animações, todas as situações, num objeto só que fica mudando todo mundo de posição em função do que o jogador conseguiu completar."

O motivo?

"A primeira exige uma fase de testes muito criteriosa, pra não deixar passar nenhuma diferençazinha entre uma fase e outra."

Talvez criar arquivos que guardem informações de como os objetos devem se comportar seja uma boa ideia. Seria algo do tipo: 'room1.txt', 'room2.txt'.

Assim, o trabalho seria apenas definir o comportamento (algo necessário nos dois casos), sem se preocupar com "diferenças" e outros obstáculos.

Bom, acredito que os dois modos sejam viáveis, e o 1° seja o modo mais fácil de projetar, pensei em algo do tipo 'guarde a posição do jogador e na outra room jogue o jogador nela'(1°exemplo) isto me pareceu que seria algo fácil, e não teria que ter um grande cuidado.
O 2° modo seria mais difícil de criá-lo, mas o resultado final seria melhor, acredito, porque possibilitaria facilmente o jogador voltar para tráz, e o jogo esta tudo como deveria estar(no outro modo, você teria que colocar o que tinha atráz novamente, e isso seria desperdiço).

Mas como não sei de que jogo se trata, fica difícil dizer algo por certo.

Abandonei o tópico porque não tinha como dar seguimento ao debate sem saber qual era o jogo. Mas agora, achei o danado. Foi custoso. Eu sabia que tinha visto ele na página do haznos, mas não lembrava quando foi isso, nem o nome do jogo. Tiny Castle.

Agora, jogando de novo, eu fiquei com a impressão de que são várias rooms criadas uma a partir da outra. O cara sabe como vai estar o final de uma, vai e adiciona as modificações pra próxima.
Achei muito bem feito, de qualquer forma.

Só podia ser um jogo da Nitrome!
Não sei da onde eles tiram tanta criatividade na hora de desenvolver a jogabilidade.

Você achou o sistema desse jogo interessante?
Tente imaginar como esse aqui foi programado.

Bom quanto ao tópico,
Pra mim a equipe deve ter planejado e montado as fases baseado apenas na posição que o jogador estaria, as animações foram adicionadas só depois, afinal com a estrutura pronta, só bastaria mover as coisas certas até os pontos certos.

Animação funciona basicamente assim.
Primeiro você desenha a primeira e a ultima frame para depois desenhar o que esta entre eles.

Kabeção escreveu:Só podia ser um jogo da Nitrome!
Não sei da onde eles tiram tanta criatividade na hora de desenvolver a jogabilidade.

Eu não conhecia a Nitrome. Nunca prestei atenção nos jogos deles a ponto de lembrar o nome dos caras. Mas realmente, eles merecem uma atenção. Agora eu vi.

Kabeção escreveu:Você achou o sistema desse jogo interessante?
Tente imaginar como esse aqui foi programado.

Cara, eu criei o tópico pra matar uma curiosidade e você me arruma outra! Não faço idéia de como o "fault line" foi programado! Pensei em views, desativação de instâncias (e/ou PARTES de instâncias, já que o jogo é em flash e eu não conheço as regras envolvidas) e clones do player. Muito legal a idéia, muito legal o resultado, muito legal o jogo!
Agora esse passou a ser o tema do tópico, ok?

Kabeção escreveu:Pra mim a equipe deve ter planejado e montado as fases baseado apenas na posição que o jogador estaria, as animações foram adicionadas só depois, afinal com a estrutura pronta, só bastaria mover as coisas certas até os pontos certos.

Animação funciona basicamente assim.
Primeiro você desenha a primeira e a ultima frame para depois desenhar o que esta entre eles.

É, eu tinha ficado com a impressão que era tudo uma room só, mas depois que reencontrei o jogo, ficou bem fácil supor que são um monte de rooms parecidas, com animações na transição. Um scriptzinho rápido pra marcar a posição e situação do player no instante de transição e voilà.
Resolvido? Teria sido se não fosse o "fault line". Agora eu quero saber como você faria.

No primeiro eu acredito que seja como o Pedro falou. As animações foram todas pensadas e quando algo ativa elas, tudo acontece.

Esse segundo é meio tenso de mais xD. Mas se você for ver, é como se eles tirassem uma parte do mundo fora, porém apenas o player interage com esse "corte", na fase 2(Edit: Na verdade, é na fase 4) a plataforma chega a sumir pois ela está nesse ponto que não existe para o player. Seria algo parecido com o portal, do jogo Portal. O problema seria fazer a posição do player ser algo válido e desenhar a sprite do personagem sem que ela seja cortada assim como a plataforma.

AHA! É um jogo com espaço não-euclidiano, exatamente como no jogo Portal. E por puro reflexo me lembrei desse teste que o criador do mod Portal Gun (mod para o Minecraft) fez:

https://www.youtube.com/watch?v=-wjPLSIIvg4

Outro jogo que teria um efeito parecido seria o AntiChamber, já que também é um jogo que usa um espaço não-euclidiano.