|
»
»
« Return to Thread: Graph based game model
Re: Graph based game model
by Christian Walther
::
Rate this Message:
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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Pipmak-Users mailing list
Pipmak-Users@...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users
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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Pipmak-Users mailing list
Pipmak-Users@...
news://news.gmane.org/gmane.games.devel.pipmak.user
https://lists.sourceforge.net/lists/listinfo/pipmak-users
« Return to Thread: Graph based game model
| Free embeddable forum powered by Nabble | Forum Help |
