Gameloop para J2ME "turn-based" jogo

votos
6

Edit: Isso faz muito mais sentido para mim agora que eu tenha dado um passo de distância do código, obrigado pela ajuda.

Só encontrei estouro de pilha no outro dia através Coding Horror e parece incrível. Figura que eu pediria a comunidade sobre um problema que estou atualmente tentando descobrir.

Estou desenvolvendo um roguelike sortof jogo usando J2ME para telefones MIDP 2.0. O projeto ainda está nos estágios básicos do desenvolvimento como eu descobrir como ele vai funcionar. A parte que eu estou atualmente preso em tem a ver com threading.

O jogo tem um costume HaxCanvasde classe que se estende GameCanvas e Implementa runnable. Chamadas de método É administrado redesenhar () e, em seguida, acomoda para 50 ms, o que resulta em uma taxa de quadros de 20 fps. Isso me permite escrever o resto do jogo sem ter que colocar repintar toda parte e deve fazer animações e efeitos mais fácil de fazer mais tarde. (pelo menos em teoria).

O fluxo do jogo é controlado por uma classe GameManager, que percorre todo o NPC no mapa, tomando suas voltas, até que ele é a vez do jogador. Neste momento eu preciso para obter a entrada para permitir que o jogador a mover coisas ao redor e / ou de ataque. Originalmente, eu estava chamando gameManager.runUntilHeroTurn()no keyPressedmétodo da minha HaxCanvas. No entanto, após ler sobre tópicos do sistema J2ME percebi que colocar um método com o potencial para ser executado por um tempo em uma chamada de retorno é uma má idéia. No entanto, devo usado keyPressed para fazer entrada handeling, desde que precisam de acesso às teclas numéricas, e getKeyStates()não suporta isso.

Sofar minhas tentativas de colocar o meu gameloop em seu próprio fio resultaram em desastre. Uma estranha ArrayIndexOutOfBoundsException uncaught sem nenhum traço de pilha mostra-se após o jogo foi executado por vários turnos.

Então eu acho que minha pergunta é esta:

Para um baseado em turnos jogo em J2ME, qual é a melhor maneira de implementar o loop do jogo, permitindo a entrada de handeling somente quando é a vez do jogador?

Publicado 26/02/2009 em 05:45
fonte usuário
Em outras línguas...                            


2 respostas

votos
5

Embora não J2ME especificamente você deve capturar a entrada do usuário, a estratégia geral é a fila de entrada-lo até o seu tempo para processar a entrada.

input ---> queue <---> Manager(loop)

Desta forma, você pode até mesmo entrada roteiro para fins de depuração.

Então, você não precisa de um novo segmento. Cada vez que o usuário pressiona chave que você armazená-los em um buffer e, em seguida, processar o conteúdo do buffer quando necessário. Se o buffer jogador não tem entrada, o gerente deve ignorar tudo o jogo, fazer animações e, em seguida, começar de novo (uma vez que o jogo não é um jogo de ação).

Respondeu 26/02/2009 em 06:44
fonte usuário

votos
3

Gostaria de evitar rosqueamento para a lógica de jogo como J2ME threading, dependendo do fabricante, é claro, não faz um grande trabalho de partilha dos recursos limitados. muitas vezes você vai ver pausas enquanto um segmento faz processamento pesado. Eu só recomendaria tópicos para carregar ou conectividade de rede recursos como neste caso você só vai estar dando o usuário "Carregando ..." básico feedback.

Para lidar com isso, eu não teria sub-lacetes para atualizar cada um dos AI em um quadro. Eu faria algo como seguir na função prazo:

public void run() {
    while(true) {
        // Update the Game
        if(gameManager.isUsersTurn()) {
            // Collect User Input
            // Process User Input
            // Update User's State
        }
        else {
            // Update the active NPC based on their current state
            gameManager.updateCurrentNPC();
        }

        // Do your drawing
    }
}

Você quer evitar ter tudo atualizado em um quadro como 1) a atualização pode ser lento, resultando em nenhum feedback visual imediato para o usuário 2) você não pode animar cada NPC indivíduo como eles fazem a sua ação. Com esta configuração, você poderia ter estados NPC, NPC_DECIDE_MOVE e NPC_ANIMATING, que permitem que você mais controle do que o NPC está fazendo. NPC_ANIMATING seria basicamente colocar o jogo em um estado de espera para a animação a ter lugar, evitando qualquer processamento adicional até que a animação está completa. Em seguida, ele poderia passar a vez do próximo NPC.

Além disso, eu teria apenas um gameManager.update () e gameManager.paint (g) (pintura seria chamado de pintura), que iria lidar com tudo e manter o método de execução fina.

Finalmente, se você olhar para flushGraphics ()? Com a GameCanvas você costuma criar um objeto Graphics, desenhar tudo para isso e, em seguida, chamar flushGraphics (), e depois esperar. O método que você menciona é a maneira de enfrentá-lo para a classe Canvas. Só pensei que eu iria falar isso e postar um link: Jogo Canvas Basics

Respondeu 26/02/2009 em 15:48
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more