2. While the above ( see "First thoughts on navigation API" Thread ) visualized version is
relative simple to implement for the developers of pyzzle and its corresponding users,
the continuation of that navigation improvement seems to be more complex.
Nevertheless it could be quite useful :)
Image the following situation. You are the lead designer of a riven-clone.
As every morning you are going to boot up your machine and check out the hottest news
in game industry. Yesterday the press version of exile was released and very
well rated, it comes with never seen 360 degrees pictures ... holy shit, they
are using 360 degrees pictures and we are still using a primitive slide technique :(
Just finished off reading that news, the phone rings - the management!
They have read the article as well and want you to implement that technique,
but not an identically clone ( due to copyrights ). They want a mixture
of the old slide technique and the next generation 360 degrees one.
So you start to think about the current design ...
In the actual version of pyzzle, the navigation constellation is fractionally stored as array
placed in the slide objects. While this concept matches with the oop patterns,
its not very handy for further techniques.
My idea was to abstract that whole data structure, instead of using arrays,
a tree-like structure could come in handy.
( This name is slightly inaccurate because, as you will see soon,
the same branches of that tree could break up and merge again )
The first thing comes in mind is a scene-graph. Common scene-graphs partition
the world/scene into some type of usable data structure ( bsp, octree ... )
optimized for the type of scene ( indoor, outdoor etc. ).
Well, that sounds great! But if you rethink this solution, you should notice,
that a common scene-graph is not practical for our situation.
For the very reason we are going to use multiple types of scenes.
We need some kind of abstract high-level navigation graph, which
links different type of scene-graphs together. Using polymorphism
this should be relative easy to implement.
We could implement generic programming to avoid the virtual functions
of polymorphism ( base classes ).
At the moment this super-scene-graph concept is still whirring in
my head. I will give you a basic class overview etc. in a little while :)
Just mull over the following problems :
- generic visitor pattern?
- how to implement that different behaviour per node ?
- should scene graph objects have access to the API ? or visitors ?
- how to arrange the graph nodes ?
- we need to know which direction of that graph we have to go ? the actor
could move backwards ?
- to be continued ...
A tree-like data structure would allow some basic improvements :
- A visitor could walk through the next possible branches of the tree
and pre-allocate the needed resources like images, models or sound etc.
- The structure is not bound to slide objects, we could attach every type of
resources ( references to models, videos ... ) or even different views
( 360 degrees, normal slide, ... )
- Its compatible for further techniques and next generation APIs.
You can even attach objects like cameras, 3d models, zbuffer-map
( for syberia like games, as you will see soon )
- Its easy to (re)store, a stream object could be passed on from parent to child nodes
or we could use a visitor object
- to be continued ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool, I like that idea, it sounds very cool and fun to implment.
I am not very familar with sceen-graphs, but they do sound like the money.
You might want to take care with makeing a slide heirachy though. I found they become quite messy. Try some pencil + paper scetching and you will see what I mean. But a tree should work ok.
Preallocating resources should not be an issue at the moment, I never hade any problems with them on a 3yo pc. But with more fancy gfx it could be a good thing.
Nice idea.
Andy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually did it, before i came up with the tree/graph idea :)
A slide hierarchy would be a real mess, but we can abstract a bunch of
slides related to their postions.
The nodes of that tree are presenting the linkage between positions.
A position-node could hold just any kind of ressource ( for example slides )
so we dont have to link each single slide,
but the groups of slides ... eh, yeah :D
I will do some graphical stuff, its hard to explain ...
( cause my knowledge of english is very limited )
:)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
2. While the above ( see "First thoughts on navigation API" Thread ) visualized version is
relative simple to implement for the developers of pyzzle and its corresponding users,
the continuation of that navigation improvement seems to be more complex.
Nevertheless it could be quite useful :)
Image the following situation. You are the lead designer of a riven-clone.
As every morning you are going to boot up your machine and check out the hottest news
in game industry. Yesterday the press version of exile was released and very
well rated, it comes with never seen 360 degrees pictures ... holy shit, they
are using 360 degrees pictures and we are still using a primitive slide technique :(
Just finished off reading that news, the phone rings - the management!
They have read the article as well and want you to implement that technique,
but not an identically clone ( due to copyrights ). They want a mixture
of the old slide technique and the next generation 360 degrees one.
So you start to think about the current design ...
In the actual version of pyzzle, the navigation constellation is fractionally stored as array
placed in the slide objects. While this concept matches with the oop patterns,
its not very handy for further techniques.
My idea was to abstract that whole data structure, instead of using arrays,
a tree-like structure could come in handy.
( This name is slightly inaccurate because, as you will see soon,
the same branches of that tree could break up and merge again )
The first thing comes in mind is a scene-graph. Common scene-graphs partition
the world/scene into some type of usable data structure ( bsp, octree ... )
optimized for the type of scene ( indoor, outdoor etc. ).
Well, that sounds great! But if you rethink this solution, you should notice,
that a common scene-graph is not practical for our situation.
For the very reason we are going to use multiple types of scenes.
We need some kind of abstract high-level navigation graph, which
links different type of scene-graphs together. Using polymorphism
this should be relative easy to implement.
We could implement generic programming to avoid the virtual functions
of polymorphism ( base classes ).
At the moment this super-scene-graph concept is still whirring in
my head. I will give you a basic class overview etc. in a little while :)
Just mull over the following problems :
- generic visitor pattern?
- how to implement that different behaviour per node ?
- should scene graph objects have access to the API ? or visitors ?
- how to arrange the graph nodes ?
- we need to know which direction of that graph we have to go ? the actor
could move backwards ?
- to be continued ...
A tree-like data structure would allow some basic improvements :
- A visitor could walk through the next possible branches of the tree
and pre-allocate the needed resources like images, models or sound etc.
- The structure is not bound to slide objects, we could attach every type of
resources ( references to models, videos ... ) or even different views
( 360 degrees, normal slide, ... )
- Its compatible for further techniques and next generation APIs.
You can even attach objects like cameras, 3d models, zbuffer-map
( for syberia like games, as you will see soon )
- Its easy to (re)store, a stream object could be passed on from parent to child nodes
or we could use a visitor object
- to be continued ...
Cool, I like that idea, it sounds very cool and fun to implment.
I am not very familar with sceen-graphs, but they do sound like the money.
You might want to take care with makeing a slide heirachy though. I found they become quite messy. Try some pencil + paper scetching and you will see what I mean. But a tree should work ok.
Preallocating resources should not be an issue at the moment, I never hade any problems with them on a 3yo pc. But with more fancy gfx it could be a good thing.
Nice idea.
Andy
I actually did it, before i came up with the tree/graph idea :)
A slide hierarchy would be a real mess, but we can abstract a bunch of
slides related to their postions.
The nodes of that tree are presenting the linkage between positions.
A position-node could hold just any kind of ressource ( for example slides )
so we dont have to link each single slide,
but the groups of slides ... eh, yeah :D
I will do some graphical stuff, its hard to explain ...
( cause my knowledge of english is very limited )
:)
hotspots can refer to slides or other "position" nodes, which use a default view ... ( predefined slide or whatever )
hotspots can be used in 3d view etc. so its
not really clever to link slides directly, slides should be handled like "position" nodes ...
maybe its wiser to use a behavoir class, which handles this forwarding stuff ...
The next days I will have some fun with blender and python, sdl etc. :)
Ok, bought a nice pyhton book and definitly had some fun with blender :D I`m impressed !
Currently i`m running out of time :(
This tree idea got more complex then expected,
but its still a clean and easy design :)