Existe algum mecanismo / framework focado na narrativa (ou pelo menos não no espaço-temporal)? [fechadas]

EDIT (2): Como existem duas respostas e eu não as aceito, imaginei que motivaria o que consideraria uma resposta aqui: algo sugerindo fortemente qualquer abordagem desse tipo seria impossível / nem seria útil ou , alternativamente, uma referência a uma pesquisa (campo) ou exemplos de um sistema pelo menos um tanto geral além dos jogos de aventura em texto / ficção interativa.

Embora eu não pretenda fazer uma investigação mais profunda, notei que todos os mecanismos / estruturas de jogos em que olhei pareciam algo como um mecanismo de gráficos glorificado, no sentido de que eles falam de formas / entidades em dois ou espaço euclidiano tridimensional com, possivelmente, alguma forma de modelo de concorrência "dobrado", permitindo especificar uma forma de lógica anexada a essas "entidades".

As "regras" e a narrativa do jogo são então escritas de uma maneira um pouco ad-hoc (com relação ao mecanismo) sobre essas primitivas.

Obviamente, a descrição acima é bastante simplificada (use mecanismos mais especializados, como o mecanismo infinito, que inclui alguma forma de sistema de busca / narrativa), e eu percebo que esse modelo pode funcionar muito bem (muitas pessoas parecem tê-lo usado) .

Estou me perguntando, no entanto, que tentativas foram feitas para criar mecanismos / estruturas que usem noções como descrição (de alto nível) das regras / lógica ou narrativa do jogo (ou pelo menos um aspecto não espacial do jogo) como principal base?

EDIT (4): Isso não significa que o jogo não inclua nenhum aspecto espacial / gráfico, apenas que, em vez de ter entidades espaciais às quais você associa a lógica, você tem uma noção de enredo (ou jogabilidade ou "regras do jogo de tabuleiro" ) para o qual você descreve uma interface gráfica para / realização de.

Especialmente, eu estaria interessado em qualquer abordagem declarativa que tente capturar algum tipo de semântica (semi-) formal de uma classe razoavelmente grande de jogos, de uma maneira útil para a implementação real (em oposição a, por exemplo, uma estrutura exclusivamente para análise qualitativa de jogos / narrativa).

O que eu vi são algumas investigações sobre modelagem / análise de narrativa com um modelo baseado em rede de Petri e algumas abordagens interessantes em idiomas para escrever ficção interativa .

EDIT (1): Pensei em adicionar um exemplo de brinquedo para ilustrar.

Digamos que estivéssemos interessados ​​em criar aventuras no estilo aponte e clique (pense nos jogos SCUMM). Pode-se analisá-las como sendo baseadas em uma noção de progressão mais ou menos linear e discreta de uma situação inicial para um fim.

Concentrando-se na noção de progressão discreta, e permitindo alguma não-linearidade, pode-se escolher a teoria da (limitada) DAG s como aqueles teoria básica. A especificação de um jogo desse tipo, na sua forma mais abstrata (relativa a essa teoria), corresponde a adicionar axiomas adicionais a essa teoria (para que a teoria especifique um gráfico específico ou simplesmente o suficiente para capturar o que achar necessário para capturá-los) "enredo").

Transformar isso em um jogo real agora se transforma no problema de design do HCI / Interface de incorporar essa teoria em algo jogável (isto é, construir um modelo da teoria / encontrar um morfismo homo (iso?) De gráficos da coleção de estados da interface do usuário com transições no DAG "especificando o jogo").

No cenário hipotético acima, posso ver pelo menos três coisas que devem ser possíveis de capturar nas bibliotecas. Primeiro, é necessário ter ferramentas para transformar / raciocinar sobre DAGs ou gráficos em geral. Em segundo lugar, uma biblioteca de interface do usuário inteligente o suficiente para ajudar a verificar se nossa representação de nosso gráfico como um jogo jogável realmente modela o gráfico (assim, por exemplo, pelo menos parcialmente / informalmente, provando que o jogo não possui estados de bloqueio, devido à condição de limite) . Finalmente, uma coleção de bibliotecas de nível superior para especificar o gráfico pode ser fornecida; como uma biblioteca para expressar caracteres e sua interação e gerar (partes de) gráficos em termos disso.

Por que manter a teoria "intermediária" dos DAGs, em vez de apenas ter a implementação de baixo nível com algumas bibliotecas de ajuda no topo? A resposta são todas as razões usuais para uma semântica formal. Dado que decidimos sobre uma base formal, podemos verificar certas propriedades do jogo, permitindo pensar em coisas como otimizações na biblioteca de interfaces de baixo nível (desde que modele o DAG, podemos fazer o que queremos), sem precisar se preocupe com a incomparabilidade com a descrição de alto nível (de caracteres / diálogo etc.), pois essas descrições devem descrever essas estruturas.

Não estou de forma alguma implicando que a abordagem acima em específico funcionaria, e a ideia não é que um DAG deva ser o que é realmente mantido na memória (em vez disso, forma algo semelhante a um formalismo computacional como um cálculo lambda), mas espero que isso ilustre o tipo de abordagem que me interessa.

Em suma, acho que poderia ter sido um título alternativo para essa pergunta: como Dijkstra escreveria jogos de computador?

Uma observação rápida sobre a narrativa e as regras do jogo: na ficção interativa, pode-se argumentar que o jogo é o de percorrer um gráfico de narrativa ramificada, mas, em última análise, a narrativa vive fora da mecânica do jogo - você pode substituir todas as palavras por algo ilegível e ainda assim, as etapas para concluir o jogo (ou perder ao jogá-lo) seriam exatamente as mesmas. Por sua vez, isso implica que a narrativa é irrelevante para a jogabilidade, exceto quando um desenvolvedor escolhe mudar uma para se adequar à outra. Nos jogos, a narrativa é essencialmente uma fachada sobre a mecânica que pode tornar a mecânica mais atraente para um jogador que gosta dessa narrativa, mas isso é tudo. Existem alguns jogos (embora alguns não os chamem de jogos) em que a narrativa é a principal forma de entretenimento e a mecânica do jogo é quase sempre superficial,Caro Esther , mas os desenvolvedores não precisam de um método formal para contar histórias, assim como os escritores de ficção, por isso não considerarei mais a narrativa. De um modo geral, qualquer jogo que se pareça com "narrativa jogável" é uma árvore ou gráfico de eventos do jogo que podem existir e ser discutidos de maneira significativa sem a narrativa.

Percebi que todos os mecanismos / estruturas de jogo em que olhei pareciam algo como um mecanismo gráfico glorificado, no sentido em que falam de formas / entidades em um espaço euclidiano bidimensional ou tridimensional [...]

Sim, a maioria dos "mecanismos de jogos" são obviamente "mecanismos de jogos de vídeo", e sua principal responsabilidade ao longo do tempo tem sido facilitar o lado de engenharia de software de um videogame, não o lado do jogo. Indiscutivelmente, isso faz sentido, porque é a engenharia de software que é o aspecto mais novo e mais caro e, portanto, mais arriscado. Em comparação, o design de jogos em um sentido abstrato foi feito à mão por milhares de anos sem o auxílio de ferramentas, o que pode explicar até certo ponto por que isso continua a ser o caso.

que tentativas foram feitas para criar mecanismos / estruturas que usem noções como descrição (de alto nível) das regras / lógica ou narrativa do jogo (ou pelo menos um aspecto não espacial do jogo) como sua principal base?

Houve poucas tentativas sérias, nenhuma bem-sucedida, até onde eu sei.

Storytron é um deles. "Ao contrário da ficção interativa tradicional, o Mundo das Histórias está mais preocupado em modelar as ações e reações dos atores e suas emoções e inclinações, em vez da geografia do mundo do jogo ou dos objetos mundanos que a povoam." Segue um esforço anterior chamado Erasmatron, que não teve muito sucesso e o Storytron também não parece ter sucesso. O seguinte artigo é uma boa leitura sobre isso: Chasing the Dragon

Em um nível menos ambicioso, muitas pessoas criaram maneiras simples de representar jogos simples. Um artigo dentre muitos é o seguinte: Multigame - Uma linguagem de nível muito alto para descrever jogos de tabuleiro (o link está atrás de um login, mas você pode encontrá-lo) mas tudo o que você tem no final é um conjunto legível de computador possível estados, transições de estado e condições de vitória ou funções de pontuação - são válidos para jogos de tabuleiro distintos, como xadrez ou jogos de cartas, como pôquer, mas eles não generalizam para jogos com grandes quantidades de estado contínuo ou com semântica mais como simulações (por exemplo, jogos de tiro) ou esportes (por exemplo, jogos de corrida). Esses jogos não podem ser representados adequadamente por meio de uma simples árvore de estados de jogos.

Uma maneira de abordar o entendimento desses sistemas mais complexos é tentar categorizar cada mecânico existente em uma das várias formas básicas e depois descobrir como as formas básicas podem ser combinadas para formar uma jogabilidade mais complexa, supondo que toda a jogabilidade possa ser constituído por essas unidades fundamentais ou suas combinações. Dan Cook tem um artigo chamado " O que são mecanismos de jogo ?" e um acompanhamento " A Química do Design de Jogos " que tenta documentar essa abordagem composicional ao design de jogos. Em teoria, pode ser possível construir um sistema declarativo além disso,

Outras tentativas de formalizar os conceitos de design de jogos são freqüentemente chamadas de "gramática de jogos" - um desses artigos é chamado de " Átomos de jogos para vários jogadores ", mas que se refere a vários trabalhos anteriores.

Digamos que estivéssemos interessados ​​em criar aventuras no estilo aponte e clique (pense nos jogos SCUMM). [...] pode-se escolher a teoria dos DAGs (limitados) como a teoria básica. [...] Primeiramente é preciso ter ferramentas para transformar / raciocinar sobre DAGs ou gráficos em geral. Em segundo lugar, uma biblioteca de interface do usuário inteligente o suficiente para ajudar a verificar se nossa representação de nosso gráfico como um jogo jogável realmente modela o gráfico (assim, por exemplo, pelo menos parcialmente / informalmente, provando que o jogo não possui estados de bloqueio, devido à condição de limite) . Finalmente, uma coleção de bibliotecas de nível superior para especificar o gráfico pode ser fornecida; como uma biblioteca para expressar caracteres e sua interação e gerar (partes de) gráficos em termos disso.

O problema aqui é que o computador não adiciona muito ao processo. Designers de jogos como esse geralmente desenham exatamente isso, um gráfico em formato digital ou físico, que mostra o fluxo no jogo. É trivial ver se o jogo pode ser teoricamente concluído ou não. Mesmo codificar as várias regras para progredir em uma aventura de apontar e clicar são triviais. A parte difícil é fazê-lo seguir uma narrativa interessante, definindo-a em um mundo de aparência atraente, criando recursos artísticos e sonoros para retratar o jogo e a interface corretamente, e as várias tarefas de engenharia de software que mantêm tudo unido. O gráfico direcionado de estados significativos durante o jogo é geralmente relativamente trivial; é tudo o que está ao seu redor que é o problema. E é por isso que não há muito interesse nisso,

Pessoalmente, atualmente estou trabalhando com uma equipe em um produto chamado Storybricksque tenta permitir a construção de uma jogabilidade interessante, especificando várias regras, e essas regras podem indicar o estado inicial de uma pessoa, suas necessidades e assim por diante. É fácil seguir essas regras e verificar se as necessidades de uma pessoa podem ser atendidas e, em caso afirmativo, como e, portanto, criar declarativamente tarefas que precisam ser concluídas no jogo. No entanto, isso por si só não cria uma jogabilidade interessante, porque uma vez que você abstrai as coisas até o nível de "X precisa de Y - busque por elas", os jogadores começam a identificar o padrão e deixam de se divertir. (Por exemplo: pessoas se cansaram rapidamente das missões geradas automaticamente em Skyrim, porque podiam ver que não havia um significado inerente a uma missão gerada processualmente, em comparação com as missões criadas pelo designer. ) Portanto, nosso trabalho será usar métodos de IA para tornar essas situações mais interessantes, e é nisso que ainda estamos trabalhando. (O Storybricks ainda está em um estágio alfa muito inicial). Mas nossa pesquisa indica que poucas pessoas estão tentando algo assim e que esse é um problema muito difícil.

Outro problema com a abordagem declarativa é que ela não é muito utilizável. Os cientistas gostam disso porque é fácil de processar, por exemplo, para provar que uma situação é solucionável ou que um conjunto de regras lógicas é consistente. Mas no mundo real, nem programadores de jogos de computador nem usuários finais geralmente se sentem tão à vontade com uma representação declarativa que foca nos resultados quanto com uma representação imperativa que lhes diz como agir para que os resultados aconteçam. As dez principais linguagens de programação atuais são imperativas , e as instruções do mundo real também geralmente são imperativas, seja para assar um bolo ou como construir móveis. Essa falta de entusiasmo de ambos os lados do espectro significa que não há incentivo comercial para produzir especificações formais para jogos modernos, e parece improvável que isso mude no futuro próximo.

Estou pensando em como responder por um tempo, e não tenho muita certeza de como colocar isso.

É uma boa pergunta. Infelizmente, a resposta se resume a que não faz sentido programar nada, muito menos um mecanismo de jogo dessa maneira, ou que já é assim que as coisas são.

Parece haver essa ênfase nos gráficos, porque é preciso haver uma maneira de definir a existência física dos objetos. É nesse ponto que as coisas começam a ficar existenciais, porque o que realmente estamos falando é uma representação da dimensão, mas vamos ignorar isso por enquanto. O ponto principal é que isso é algo realmente envolvido. Permitir a representação do espaço será algo que inerentemente ocupa grande parte da programação de um mecanismo de jogo. E se os designers quiserem criar cenas agradáveis, precisarão de muito controle sobre como as coisas são colocadas. Então você verá muitas coisas sobre gráficos.

Então, esse é o lado de baixo nível das coisas. Alguém precisa pensar muito em todos esses pequenos problemas técnicos.

No que diz respeito às regras narrativas e de jogo? Isso está fora do escopo do que um mecanismo de jogo deve fazer. Essa é a parte em que o grupo de desenvolvimento entra.

Além disso, não é muito pensado sobre como representar idéias através da programação. Isso é realmente o que a história da ciência da computação é . E é por isso que os mecanismos de jogo frequentemente têm interfaces com linguagens de alto nível. É mais fácil representar pensamentos através deles.

Então, com isso em mente, uma linguagem poderia ser criada especificamente para jogos com ênfase narrativa? Eu diria provavelmente não. Novamente, tudo isso se resume a representação. O idioma precisa ser capaz de descrever detalhes de maneira que o computador saiba o que fazer com ele. Se o objetivo é criar uma linguagem específica para a criação de jogos, qualquer decisão de design deve ser centrada em torno disso.

E, novamente, há muitas opções de idiomas como estão. E mais pessoas do que apenas as da indústria de jogos as estão desenvolvendo. Geralmente faz sentido usar um desses.

Em resumo, você fez uma pergunta interessante, mas muito difícil. E não tenho certeza do que é, ou se realmente atendi.

* edit: Em retrospectiva, percebo que estava considerando apenas os motores de jogos em 3D, como se eles fossem os únicos que existem. Alguns jogos não têm uma pessoa atuando em um espaço físico. Embora, nesses casos, não tenha certeza de que um mecanismo de jogo contribua muito.

No início da história da computação por hobby (ou seja, nos anos 80), havia alguns kits comerciais de desenvolvimento de jogos disponíveis para jogos baseados em texto e sprites. Os baseados em sprites eram muito parecidos com os atuais "mecanismos gráficos".

O outro tipo incluía coisas como analisadores de linguagem natural. Esse tipo parece viver nos modernos "editores de nível". A maioria deles parece incluir suporte para algo como scripts Lua ou Python. Eu também observaria que não vejo muita atividade na edição em nível de código aberto, mas isso ocorre porque essas coisas geralmente estão muito ligadas às especificidades do jogo em questão. Estou pensando aqui em algo como os conjuntos de construção de Elder Scrolls.

O Kinect pode trazer o analisador de volta. Como fã do antigo jogo de aventura baseado em texto, também estou empolgado com a direção da Bethesda aqui. Certamente é proprietário, mas talvez um jovem gênio ...