Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

EDIT (2): Since there are two answers and I haven't accepted any of them I figured I'd motivate what I'd consider an answer here: Either something strongly suggesting any such approach would be impossible/not at all useful or, alternatively, a reference to a research (field) or examples of an at least somewhat general such system beyond text adventure games/interactive fiction.

While I won't pretend I've done any deeper investigation I've noticed that all the game engines/frameworks I have looked into seemed to be something like a glorified graphics engine in the sense that they speak of shapes/entities in a two or three dimensional euclidean space with, possibly, some form of concurrency model "tucked on" allowing one to specify some form of logic attached to these "entities".

Game "rules" and narrative is then written in a somewhat ad-hoc (with respect to the engine) way on top of these primitives.

Obviously the above description is rather simplified (take more specialised engines such as the infinity engine which does include some form of quest/narrative system), and I realise that this model can work quite well (a lot of people seem to have used it).

I'm wondering, though, what attempts have been made to create engines/frameworks that take notions such as (high level) description of game rules/logic or narrative (or at least a non-spatial aspect of the game) as their primary basis?

EDIT (4): This doesn't mean that the game would not include any spatial/graphical aspects, just that rather than having spatial entities to which you associate logic, you have a notion of plot (or gameplay or "board game rules") which you then describe a graphical interface to/realisation of.

Especially I'd be interested in any declarative approaches that try to capture some kind of (semi-)formal semantics of some reasonably large class of games, in a way useful for actual implementation (as opposed to, for example, a framework exclusively for qualitative analysis of games/narrative).

What I've seen are some investigations into modeling/analysing narrative with a petri net-based model and some interesting approaches in langauges for writing interactive fiction.

EDIT (1): I figured I'd add a toy example to illustrate.

Say we were interested in creating point & click style adventures (think SCUMM games). One might analyse these as being based on a notion of more or less linear and discrete progression from a starting situation to an end.

Focusing on the notion of discrete progression, and allowing for some non-linearity, one might choose the theory of (bounded) DAGs as ones basic theory. Specifying a game of this type, in its (relative to this theory) most abstract form thus corresponds to adding additional axioms to this theory (either so that the theory specifies a specific graph or simply enough to capture whatever one thinks is required to capture ones "plot").

Turning this into an actual game now turns into the HCI/Interface design problem of embedding this theory into something playable (i.e. building a model of the theory/finding an homo(iso?)morphism of graphs from the collection of user interface states with transitions into the DAG "specifying the game").

In the above hypothetical scenario I can see at least three things that should be possible to capture in libraries. Firstly one needs tools for transforming/reasoning about DAGs or graphs in general. Secondly a user interface library clever enough to help in verifying that our representation of our graph as a playable game actually models the graph (thus for example, at least partially/informally, proving the game has no stuck states, due to the boundedness condition). Finally a collection of higher level libraries for specifying the graph could be given; such as a library for expressing characters and their interaction and generating (parts of) graphs in terms of such.

Why keep the "middle" theory of DAGs, rather than just have the low level implementation with some help libraries on top? The answer is all the usual reasons for a formal semantics. Given that we have decided on a formal foundation we can verify certain properties of the game allowing one to reason about things like optimisations in the low level interface library (as long as it models the DAG we can do what we want), without having to worry about incomparability with the high level description (of characters/dialogue e.t.c.), as those descriptions must themselves describe such structures.

I'm in no way implying the above approach in specific would work, and the idea isn't that a DAG has to be what is actually kept in memory (rather it forms something akin to a computational formalism such as a lambda calculus), but I hope that this illustrates the kind of approach I'm curious about.

In short, I guess an alternative title to this question might have been: How would Dijkstra have written computer games?

share|improve this question
    
Maybe something like Story Bricks? @Kylotan would know more about it. –  Byte56 Jul 27 '12 at 21:07
    
@Byte56 Interesting, I hadn't heard of it before. But, while still relevant (as a way to model narrative), I was wondering more about systems for developing games, rather than games with a configurable narrative (though, of course, its a fuzzy boundary). –  Tilo Wiklund Jul 28 '12 at 0:32
    
your question is ambiguous in the way it juxtaposes "(high level) description of game rules/logic or narrative". An engine that attempted to encode a semantics of game logic across a large class of games is quite different than an engine that models narrative logic. Which are you interested in? –  georgek Jul 28 '12 at 3:29
    
@georgek The notion of "game logic" is, I think, in itself ambiguous. The reason I added modeling narrative was as there as an example of what it could mean (narrative as one of the core aspects of games such as point & click adventures, some RPGs, and interactive fiction). –  Tilo Wiklund Jul 28 '12 at 11:30
    
Storybricks is still very early in production but thanks for the mention, @Byte56! The intention is certainly that it will directly address questions like these. (Although probably not the formal semantics - I don't think formal semantics exist for that class of games.) –  Kylotan Jul 28 '12 at 11:39

3 Answers 3

up vote 4 down vote accepted

A quick note about narrative and game rules: in interactive fiction it can be argued that the game is that of traversing a graph of branching narrative, but ultimately the narrative lives outside of the game mechanic - you could replace all the words with something unreadable and yet the steps to complete the game (or to lose when playing it) would be exactly the same. This in turn implies the narrative is irrelevant to the gameplay, except where a developer chooses to change one to suit the other. In games, the narrative is essentially a façade over the mechanics that can make the mechanics more compelling to a player who enjoys that narrative, but that is all. There are some games (although some don't call them games) where the narrative is the primary form of entertainment and the game mechanics are mostly perfunctory, such as the recent release Dear Esther, but developers don't need a formal method for telling stories any more than fiction writers do, so I won't consider narrative further. Generally speaking, any game which looks like "playable narrative" is a tree or graph of game events that can exist and be discussed meaningfully without the narrative at all.

I've noticed that all the game engines/frameworks I have looked into seemed to be something like a glorified graphics engine in the sense that they speak of shapes/entities in a two or three dimensional euclidean space [...]

Yes, most "game engines" are obviously "video game engines", and their main responsibility over time has been to facilitate the software engineering side of a video game, not the game side. Arguably this makes sense because it is the software engineering that is the newest and most expensive and hence most risky aspect. By comparison, game design in an abstract sense has been done by hand for thousands of years without the aid of tools, which may explain to some degree why that continues to be the case.

what attempts have been made to create engines/frameworks that take notions such as (high level) description of game rules/logic or narrative (or at least a non-spatial aspect of the game) as their primary basis?

There have been few serious attempts, none successful, as far as I know.

Storytron is one. "Unlike traditional interactive fiction, a Storyworld is more concerned with modeling actors' actions and reactions and their emotions and inclinations rather than the game world geography or the mundane objects that populate it." It follows a previous effort called Erasmatron, which didn't really succeed, and Storytron isn't really looking like succeeding either. The following article is a good read on this: Chasing the Dragon

On a less ambitious level, there are lots of people who have come up with simple ways of representing simple games. One paper out of many is this: Multigame — A Very High Level Language for Describing Board Games (link is behind a login, but you may be able to search for it) but all you have at the end is a computer readable set of possible states, state transitions, and victory conditions or score-keeping functions - fine for discrete board games such as Chess or card games such as Poker, but they don't generalise to games with large amounts of continuous state or those with semantics that are more like simulations (eg. shooter games) or sports (eg. racing games). Such games can't adequately be represented via a simple tree of game states.

One way to approach the understanding of these more complex systems is to try and categorise each existing mechanic into one of several basic forms, and then work out how the basic forms can be combined to form more complex gameplay, under the assumption that all gameplay can be comprised of these fundamental units, or combinations thereof. Dan Cook has an article called "What Are Game Mechanics?" and a follow-up "The Chemistry of Game Design" which attempt to document this compositional approach to game design. In theory it might be possible to construct a declarative system on top of that, but in practice the mechanics only form a small portion of the game and so the resulting output would presumably be constrained within a presentation framework that would not be flexible enough to capture the attention of most gamers.

Other attempts at formalising game design concepts are often called "game grammar" - one such article is called "Multiplayer Game Atoms" but that refers back to various previous works.

Say we were interested in creating point & click style adventures (think SCUMM games). [...] one might choose the theory of (bounded) DAGs as ones basic theory. [...] Firstly one needs tools for transforming/reasoning about DAGs or graphs in general. Secondly a user interface library clever enough to help in verifying that our representation of our graph as a playable game actually models the graph (thus for example, at least partially/informally, proving the game has no stuck states, due to the boundedness condition). Finally a collection of higher level libraries for specifying the graph could be given; such as a library for expressing characters and their interaction and generating (parts of) graphs in terms of such.

The problem here is that the computer doesn't add much to the process. Designers of games like this will often draw up exactly this, a graph in digital or physical form, which shows the flow through the game. It's trivial to see whether the game can theoretically be completed or not. Even encoding the various rules for progressing through a point and click adventure are trivial. The hard part is making it follow an interesting narrative, setting it in a compelling-looking world, creating the art and sound assets to portray the game and the interface properly, and the various software engineering tasks that hold it all together. The directed graph of significant states through the game is usually relatively trivial; it's all the stuff around it that is the problem. And this is why there's not much interest in it, except in interactive fiction where (a) the mechanics and presentation are a solved problem, and (b) the typical developer is non-technical.

I personally am currently working with a team on a product called Storybricks which attempts to allow for the construction of interesting gameplay through specifying various rules, and these rules may state a person's initial state, their needs, and so on. It is easy to take these rules and verify whether a person's needs can be met, and if so how, and therefore to declaratively create tasks that need to be completed in-game. However this itself doesn't inherently create interesting gameplay, because once you abstract things down to the level of "X needs Y - fetch it for them" players start to spot the pattern and cease to enjoy it. (For example: people tired quickly of the auto-generated quests in Skyrim, because they could see that there was no inherent meaning to a procedurally generated mission, compared to the designer-crafted ones.) So our job will be to use AI methods to make these situations more interesting, and that is something we're still working on. (Storybricks is still in a very early alpha stage). But our research indicates that few people are attempting anything like this, and that it's a very hard problem.

Another problem with the declarative approach is that it is not very usable. Scientists like it because it is easy to process, for example to prove that a situation is solvable or that a set of logic rules are consistent. But in the real world, neither computer game programmers nor end users are generally as comfortable with a declarative representation that focuses on the results as they are with an imperative representation that tells them how to act in order for the results to happen. The current top 10 programming languages are all imperative, and real world instructions are also generally in imperative form, whether that's how to bake a cake or how to construct furniture. This lack of enthusiasm from either end of the spectrum means there is no commercial incentive to produce formal specifications for modern games, and this looks unlikely to change in the near future.

share|improve this answer
    
An excellent answer! While I don't agree with the "real world instructions are imperative" quote (seen it before, but that's a whole other story). As a kind of nit picking I would say that as the graph structure of the toy example captures certain structural properties of the narrative, I would say that it does specify it (though not uniquely, it might not capture a lot of it though, but I did say it was a trivial toy example to illustrate the issue). All the references sound very interesting and do suggest routes for further investigation (as does your own project). Therefore accepted Thanks! –  Tilo Wiklund Jul 28 '12 at 22:07

I've been considering how to reply for awhile, and I'm not quite sure how to put this.

It's a good question. Unfortunately the answer kind of boils down to that it either doesn't make sense to program anything let alone a game engine this way, or that this is already how things kind of are.


There seems to be this emphasis on graphics, because there needs to be a way to define the physical existence of objects. This is kind of where things start getting existential because what we're really talking about is a representation of dimension, but let's just ignore this for now. The main point is, this is something that really is quite involved. Allowing for the representation of space is going to be something that inherently takes up a lot of the programming of a game engine. And if designers want to make nice scenes they'll need a lot of control over how things are placed. So you're going to see a lot of stuff about graphics.

So, that's the low level side of things. Someone needs to put a lot of deep thought into all of these little technical issues.

As far as narrative and game rules go? That's out of scope of what a game engine is supposed to do. This is the part where the development group comes in.

What's more, it's not like a lot of thought hasn't been put in to how to represent ideas through programming. That's really what the history of computer science is. And, this is why game engines frequently have interfaces to high level languages. It's easier to represent thoughts through them.


So with that in mind, could a language be made specifically for games with a narrative emphasis? I would say probably not. Again this all comes down to representation. The language needs to be able to be able to describe details in such a way that the computer knows what to do with it. If the purpose is to make a language that is specific to game creation, then any design decisions should be centered around that.

And again, there's a lot of choices of languages as is. And more people than just those in the games industry have been developing them. It generally makes sense to use one of those.


In summary you asked an interesting, but very difficult question. And I'm not entirely sure what it is, or if I actually answered it.

*edit: In hindsight, I realize that I was only considering 3D Game Engines, as if they were the only ones that exist. Some games don't have a person acting in a physical space at all. Though in such instances I'm not sure that a game engine would contribute much.

share|improve this answer
    
While a good development of the question I'm not sure I can accept it as an answer. To some extent I agree with your assessment (my initial thoughts before asking the question were something long these lines too), but I can't quite bring myself to see why rules and narrative should fall in the domain of "general purpose programming", while things having to do with spatial representation should warrant extensive and more or less standardised models/methods (apart from there being, historically, a lot more investigation into formal models and computational methods for such, lin. algebra e.t.c.). –  Tilo Wiklund Jul 28 '12 at 11:38
    
Also, if you're still interested, what are your thoughts on languages like inform7.com ? –  Tilo Wiklund Jul 28 '12 at 12:03
    
As I see it comes down to the issue of usability. Would such a system simplify the creation of a game? If it is just an alternate way of representing data and interactions which can already be done in language and syntax one is familiar with (general purpose programming), why would anyone want to use or develop such a system which adds an unnecessary level of abstraction? –  Matthew R Jul 28 '12 at 16:30
    
I don't see why they don't make things easier, just as domain specific languages for any other kind of logic should make it easier to express things in the domain they target. –  Tilo Wiklund Jul 28 '12 at 18:02
    
First of all, I see that things have been made more clear. With a bit more context it's more clear what you're asking. I'm also not sure of how much programming experience you have, so that makes it a bit difficult to explain things as well. On the issue of inform? It doesn't seem exceptionally useful to me, as from my perspective writing text based games is fairly simple. I've done a fair amount of work with parser generators myself. (Writing parsers manually is a horrible experience I wouldn't wish on anyone :P) –  xuincherguixe Jul 28 '12 at 19:07

Early in the history of hobby computing (i.e. the 80's) there were some commercial Game development kits available for both text and sprite based games. The sprite based ones were very like the current "graphics engines".

The other type included things like natural language parsers. This type seems to live on in the modern "level editors". Most of those seem to include support for something like Lua or Python scripting. I would also note that I do not see a lot of activity in open source level editing, but that is because these things are usually very tightly coupled to the specifics of the game in question. I am thinking here about something like the Elder Scrolls construction sets.

The Kinect may bring the parser back. As a fan of the old text-based adventure game, I am excited about Bethesda's direction here as well. It most certainly is proprietary, but maybe some young genius...

share|improve this answer
    
The historical dimension is interesting, do you know how these text game kits differed from modern approaches such as the ones suggested in the SE thread I linked in the question? –  Tilo Wiklund Jul 28 '12 at 18:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.