Re: Graph based game model

[Christian W. <cwa...@gm...>]

Interesting theory!

The location graph seems a natural concept for a Pipmak game, judging  
from my own and rivenwanderer's use of it. My intention is that one  
day you will be able to view and graphically manipulate that graph in  
Pipmak itself.

Your idea of extending the graph to the game state is interesting,  
I've never thought of that. I might have to spend a bit more thought  
on it to recognize its usefulness. Can you give some more examples of  
problems that your final software would help solve? I mean, "can the  
game be finished at all?" is an interesting question from a  
theoretical point of view, but I doubt that anyone would design a game  
complex enough that they would need the help of specialized software  
to arrive at the answer "yes". Would your software somehow display the  
graph, or is the graph only a theoretical concept used internally?  
Does it even need to explicitly know the full graph (derivation of  
which seems like a non-trivial problem in itself), or can some insight  
be gained already from abstract graph theory, with limited input? What  
kind of input would it take, anyway?

Some questions spring to my mind right away: What if the effect of  
some user action does not only depend on the current node and the  
state table, but also on time or on a (pseudo-)random number or  
something like that? Does your model cover that too? If it does, is  
the resulting graph still small enough to be of any practical use?  
What if some dimensions are continuous? Does graph theory apply to  
graphs with uncountably many vertices? Or are you relying on the fact  
that in a digital representation, all dimensions are necessarily  
finite? Does your system for determining what to render take into  
account that some of the dimensions that apply to a particular node  
can be "separable"? E.g. when I have a lever with two states, and on  
its handle a light that can be either red or blue, then I need to  
render patches for all four combinations (the whole cartesian  
product): on-red, off-red, on-blue, off-blue. But when the lever and  
the light are in different parts of the screen, I only need to render  
two images, one with both on, one with both off, and can get two  
independent patches from them that together can represent all four  
states. Rendering all four combinations would still work, but in a  
situation of realistic complexity would be a gigantic waste of  
resources.

   -Christian