programação de eventos da história do jogo

Eu desenvolvi um mecanismo de jogo em c / c ++ e DirectX.

Eu tenho um mecanismo de blocos para os mapas, sprites animados de jogador / npc, conversando com o npc, menus e mudança de nível, mas não há jogo, apenas parece vazio.

Eu olhei em volta e continuo ouvindo respostas de palavras-chave, mas quero saber como implementar uma história no meu jogo.

Algumas pessoas disseram que um arquivo salvo contém bandeiras que governam todas as ações / estados possíveis disponíveis no jogo, mas isso parece ridículo.

É um pouco ambicioso, mas pretendo começar um jogo como os antigos jogos Pokemon / Final Fantasy.

Alguém sabe como esses jogos funcionam ou a teoria usada?

Estou procurando há algum tempo e realmente aprecio qualquer opinião que as pessoas tenham.

A história do seu jogo provavelmente deve estar na forma de um autômato de estado finito (ou algum tipo de FSA estendido). Quando certos eventos acontecem, você deve passar para um novo estado. Dessa forma, você só precisará armazenar o estado atual e as informações necessárias para saber para onde avançar na FSA (junto com os detalhes do jogador, como posição, saúde etc.).

Por exemplo, se simplificarmos demais os jogos de Pokemon, os crachás de academia formam o ramo principal da FSA. Você começa no estado 0, onde não tem emblemas e, à medida que derrota os líderes da academia, passa pelos estados, para o estado 1, para o estado 2, etc. eles para olhar para o estado atual. Por exemplo, um NPC fora do 3º ginásio verificaria em que estado você está, veja se está no estado correspondente a ter 3 insígnias e responderia de acordo (talvez com um "Bem feito!").

Você não precisa armazenar o estado de tudo no mundo; apenas o estado da história. As próprias entidades sabem como reagir, dependendo do estado atual.

Você pode usar um conjunto de estados possíveis em que seu jogo está. Seus NPCs e seu mundo estariam cientes desses estados e reagiriam / seriam exibidos de acordo. Você também pode definir um conjunto de gatilhos que seriam ativados por algumas ações / eventos.

Por exemplo, vencer um determinado oponente ativaria o gatilho A, que adicionaria o estado S ao seu mundo e no estado S seu personagem é eletrocutado quando sai do covil do oponente. Ou está chovendo lá fora. Ou você encontra um doce raro. Você entendeu.

Com essas duas simples adições ao seu jogo, você pode torná-lo muito mais "vivo".

Crie também um plano de fundo rico para o seu mundo, personagens e enredo e verifique se o jogo é consistente com esse plano de fundo. Planeje sua história primeiro.

Tente também Gamedev

Como o sftrabbit mencionou, este é um aplicativo perfeito para uma máquina de estado.

Essencialmente, você tem uma espécie de estrutura em árvore. Cada folha / nó contém informações sobre o estado atual e regras para avançar para o próximo estado. Cada nó pode conter várias saídas, dependendo da complexidade do fluxo de plot / play.

Um bom, muito análogo a isso, é um livro Escolha sua própria aventura . Cada página contém algum texto descrevendo parte da história e as decisões que o jogador pode tomar. Cada decisão leva a outra página. Algumas páginas podem ter links para páginas visitadas anteriormente, etc.

Os antigos jogos de aventura em texto, como Zork e Leather Goddesses of Phobos , e os infames jogos Sierra * Quest ( SpaceQuest, estrelado por Roger Wilco, o zelador do espaço é um dos meus favoritos ) usavam uma versão muito simples desse tipo de sistema. Cada sala de um mapa era um estado, com saídas vinculadas a outros estados ou salas. A aquisição de um item define um sinalizador em um objeto de estado global. Cada sala verificaria essas bandeiras para determinar quais caracteres ou itens estavam disponíveis em cada sala.

Portanto, seus estados podem ser implementados como uma classe ou estrutura, cada um com propriedades para:

Lista de ativos - lista de indicadores para gráficos de segundo plano e qualquer outra coisa que você precise para exibir a sala / estado / nível.

Condições de entrada - conquistas que já devem ter sido alcançadas para entrar em um nível

Saídas - links para cada possível "próxima" saída. Norte, Sul, Leste e Oeste são alguns exemplos disso, mas você também pode incluir Porta1, Teleporte, etc. Ao tentar sair de uma sala ou determinar se uma saída / porta está "aberta", seu jogo pode verificar o próximo estado para ver se suas condições de entrada foram atendidas e alterar a maneira como a saída é exibida na tela, ou simplesmente não permitir que o jogador se mova nessa direção.

Se você quiser se divertir, pode incluir uma versão diferente de um estado com diferentes condições de entrada, o que alteraria a maneira como a sala é apresentada ao jogador ou as ações disponíveis nessa sala.

Sua tela inicial, tela de morte / game over etc. podem ser estados no sistema, semelhantes à maneira pela qual você pode navegar pelas telas de menu. De fato, se você tiver um sistema de menus assim, poderá usá-lo para isso. Em vez de setas para cima / para baixo e "entrar" para navegar em um menu, você procuraria eventos específicos na área de jogo, como pisar em um bloco de teleporte, sair do lado direito da tela etc.

Do ponto de vista do administrador, considere se você pode ou não se beneficiar da criação de uma ferramenta de administração que permita criar a máquina de estado. Adicione salas a um mapa, crie links entre elas, atribua ativos como imagens de plano de fundo etc. Isso provavelmente é um exagero na sua primeira tentativa; é muito fácil absorver a criação de ferramentas administrativas e nunca terminar o jogo. Lembre-se - você não está escrevendo middleware, mas um jogo.

Espero que isto ajude.

Eu costumava usar esse mecanismo de jogo chamado VERGE . Brinque com isso e veja como ele lida com eventos, eu realmente gosto disso. Também é de código aberto, para que você possa ver como eles o implementam aqui . Aqui está uma breve descrição.

Cada mapa possui uma variedade de camadas. As camadas gráficas, das quais pode haver várias. A camada de obstrução. E depois há a camada da zona. A camada da zona é o que é importante aqui. *

Cada bloco possui um número para indicar de que zona faz parte. Cada zona pode ser ativada de duas maneiras básicas. A zona é ativada quando o jogador entra nela ou tem o que é chamado de ativação adjacente. Ativação adjacente significa que, quando o jogador está adjacente a um dos ladrilhos da zona e pressiona alguma tecla especificada como chave de ativação, a zona é ativada.

O que acontece quando uma zona é ativada é que ela chama uma função de um script. Portanto, você precisa incorporar algum tipo de linguagem de script. O VERGE possui seu próprio idioma, chamado VergeC, e também permite lua. Eu mesmo prefiro usar python.

Depois de superar esse obstáculo, agora você tem um poder tremendo nos scripts de eventos. Você tem uma linguagem de programação completa na qual pode armazenar e atuar em dados como estatísticas do jogador, marcadores de história, etc.

* Há também uma camada de entidade. As entidades agem como zonas ativadas adjacentes móveis.