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

28

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.

Skeith
fonte

Respostas:

19

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.

Joseph Mansfield
fonte
abordagem interessante e eu gosto que ele terá que experimentá-lo, mas como você acompanharia missões secundárias que não dependem da progressão da história?
Realmente depende de quão complexa é a sua história. Pode ser mais fácil ter vários FSAs (um para cada subestado) ou você pode precisar de uma ramificação complexa. Você precisa sentar e desenhar sua história como um roteiro. Quando você entender como tudo se entrelaça, pense em como você pode armazenar o estado atual (ou estados, se ele puder estar em mais de um de uma vez). Algumas coisas precisarão ser armazenadas separadamente, como as posições dos NPCs (se você precisar que elas sejam salvas) e a saúde de certos personagens, porque eles não dependem da história.
Neste FSA você fala, onde eu encontraria uma explicação disso, de preferência simplificada e sem outras teorias entrelaçadas.
Skeith
Você pode aprender tudo sobre máquinas de estado em todo o lugar, mas 99,9% das vezes não fala sobre jogos. Um livro introdutório sobre computação o ensinará sobre eles, mas você realmente não precisa de tantos detalhes. Você só precisa entender o conceito de estar em estados e se mover entre eles quando certos eventos acontecem. A resposta do @ pwny é realmente apenas dizer a mesma coisa de uma maneira diferente. Ler sobre os FSAs será uma ótima maneira de aprender os conceitos de máquinas de estado. Basta procurar no Google uma introdução às máquinas de estado!
Joseph Mansfield
7

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

pwny
fonte
isso é possível, mas tenho certeza de que os profissionais têm um melhor desempenho, pois o que você exige envolve centenas de milhares de booleanos e ints (eu tentei). Eu simplesmente não vejo isso como uma abordagem realista para um jogo em grande escala. Obrigado pelo link
Não necessariamente, imagine 5 estados sobrepostos independentes. Você obtém 32 possíveis ramificações por 5 booleanos. Eu acho isso razoável. Além disso, os sistemas de gatilhos são usados ​​em muitos jogos profissionais, especialmente porque você pode criar um script de comportamento usando uma série de gatilhos.
Pwny #
2

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.

3Dave
fonte
Neste exemplo, imagine uma cidade. Eu tenho um arquivo que contém o layout da telha, bem como o gráfico e tamanho, listas de NPC e coisas gerais como essa. adicionando um arquivo, uma nova câmera da cidade é adicionada ao jogo, permitindo que outras pessoas contribuam ou o plano era o mesmo, mas o arquivo está se tornando um pouco completo e complexo. se eu entendi, eu colocaria os eventos que podem ocorrer nessa cidade nesse arquivo com bandeiras para acompanhar o progresso?
Skeith
@ Sim, isso soa como uma abordagem razoável.
precisa saber é o seguinte
0

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.

Benjamin Lindley
fonte
isso soa como o tipo de sistema usado na série de criadores de jogos de rpg. mas e se esse bloco tiver 5 eventos diferentes, com base em quanto tempo você está na história?
Skeith
@Skeith Não pode. Cada bloco possui apenas uma zona associada a ele. E cada zona possui apenas uma função de script que chama. Isso não é um problema. Lembre-se, você tem uma linguagem de programação completa aqui. As informações sobre o quanto você está na história seriam armazenadas em uma variável (ou várias). Portanto, decidir o que fazer é uma simples questão de testar essa variável no script e executar a ação apropriada com base em seu valor.
Benjamin Lindley
@ Skeith: Embora você possa adicionar a opção de alterar a qual zona um bloco pertence.
Benjamin Lindley