As I craft the Ping Game Framework I have hit an interesting design challenge - on the one hand I would love to make my own virtual class (IPingBlock) that includes all the game object features I want in my system (physics nodes, event reactors, scripts, controllers, etc) and then make a game object that derives from ISceneNode and IPingBlock - only problem is that irrlicht derives many types of SceneNode for character, FPS cameras, etc - so i cant just make my game object from the base class. i would have to make a new class for every variation of Scenenode
anyone have another solution that would let me add my Block virtual api to scenenodes in general - it would be great if my block could build off the scene graph model already there - i thought about doing it as a form of animator but that doesnt give me access to the innards of the scenenode which i also want
suggestions?
Game framework - deriving from SceneNode??
thinking a bit more - i dont see any way to do this - the best approach i can think of is to make a new virtual class of my own that includes the right SceneNode in it for each major element in irrlicht - so i would make:
PingEmptyNode
PingMeshNode
PingAnimatedMeshNode
PingCameraNode
PingBillboardNode
PingParticleNode
PingTerrainNode
dont know what i would do with ShadowNode?
problem here though is that irrlicht add event processing in with some of these base classes - i dont really want to necessarily use the event receiver class embedded in the scenenodes - i would rather make a controller class that was added later - this way i can make different kinds of cameras without making subclasses
PingEmptyNode
PingMeshNode
PingAnimatedMeshNode
PingCameraNode
PingBillboardNode
PingParticleNode
PingTerrainNode
dont know what i would do with ShadowNode?
problem here though is that irrlicht add event processing in with some of these base classes - i dont really want to necessarily use the event receiver class embedded in the scenenodes - i would rather make a controller class that was added later - this way i can make different kinds of cameras without making subclasses
-
Gorgon Zola
- Posts: 118
- Joined: Thu Sep 18, 2003 10:05 pm
- Location: switzerland
hi powerpop
maybe i can give you an idea.
why don't you build your own scenenode class that takes an irrlicht-scenenode as a delegate. in your class you just implement all scenenode methods you need so that they call the corresponding methods in your irrl.-delegate object.
then you write a factory (scenemanager in irrlicht) that assembles your nodes with the requested delegate type...
I haven't thought about this in detail but maybe this helps you anyway.
cheers
Tom
maybe i can give you an idea.
why don't you build your own scenenode class that takes an irrlicht-scenenode as a delegate. in your class you just implement all scenenode methods you need so that they call the corresponding methods in your irrl.-delegate object.
then you write a factory (scenemanager in irrlicht) that assembles your nodes with the requested delegate type...
I haven't thought about this in detail but maybe this helps you anyway.
cheers
Tom
-
crazedlunatic
- Posts: 7
- Joined: Mon Mar 08, 2004 7:17 pm
Idea
First - what is IPingBlock? Is that essentially an encapsulation of the Tokamak information and functionality?
I think Gorgon Zola is on the right track.
Why can't you:
(1) just inherit from IPingBlock only and have a member pointer to ISceneNode in this class.
(2) Overload the constructor for this new class with a version that takes a pointer to each of the irrlicht node subclasses.
(3) Spawn your objects from the engine by creating the node in the engine and calling the appropriate constructor of your class
This could be exactly what Gorgon Zola meant by "delegate". I'm not 100% brushed up on C++ vocab, but this seems like a decent compromise to get the most functionality with minimal effort. There might be some odd cases where there are different node types in the same graph - but you could either make that a restriction for now or I'm sure there is a solution to that.
Maybe I'm out in left field on this - I'm just getting into game development and learning alot still.
Another idea I had on this - If you create a low level graph loader that takes in a graph script in an XML format, you could include the irrlicht node type and tokamak geometry information in there, and call this loader to set up all nodes or graphs. The loader would return an ISceneNode pointer to the parent node. Call the loader from the constructor of your class and set its ISceneNode pointer. You could look at these graphs as having the irrlicht links AND tokamak joints for the ultimate in flexibility. This would cripple some freedom since you'd have to go through this XML format - but it would make everything very easy to use once it's complete. Making the assumption that everything will be done this way, you may not need to spend as much time on abstracting/encapsulating everything in ping and just use irrlicht itself in the implementation code. I guess that is an issue of what you'd like to see extensible and what you'd like to set in stone. Another nice feature of this is you could, in turn, create a writer method for this and it would be pretty darn easy to create a scenegraph editor for irrlicht using irrlicht (and the new 0.6 changes). I'm pretty psyched about this sort of capability - let me know if you'd like help. If I can find time maybe I'd join the ping effort.
Alright - enough rambling. I suppose my username is fitting for this scale of rambling. I'm just excited to see where ping.net is going!
I think Gorgon Zola is on the right track.
Why can't you:
(1) just inherit from IPingBlock only and have a member pointer to ISceneNode in this class.
(2) Overload the constructor for this new class with a version that takes a pointer to each of the irrlicht node subclasses.
(3) Spawn your objects from the engine by creating the node in the engine and calling the appropriate constructor of your class
This could be exactly what Gorgon Zola meant by "delegate". I'm not 100% brushed up on C++ vocab, but this seems like a decent compromise to get the most functionality with minimal effort. There might be some odd cases where there are different node types in the same graph - but you could either make that a restriction for now or I'm sure there is a solution to that.
Maybe I'm out in left field on this - I'm just getting into game development and learning alot still.
Another idea I had on this - If you create a low level graph loader that takes in a graph script in an XML format, you could include the irrlicht node type and tokamak geometry information in there, and call this loader to set up all nodes or graphs. The loader would return an ISceneNode pointer to the parent node. Call the loader from the constructor of your class and set its ISceneNode pointer. You could look at these graphs as having the irrlicht links AND tokamak joints for the ultimate in flexibility. This would cripple some freedom since you'd have to go through this XML format - but it would make everything very easy to use once it's complete. Making the assumption that everything will be done this way, you may not need to spend as much time on abstracting/encapsulating everything in ping and just use irrlicht itself in the implementation code. I guess that is an issue of what you'd like to see extensible and what you'd like to set in stone. Another nice feature of this is you could, in turn, create a writer method for this and it would be pretty darn easy to create a scenegraph editor for irrlicht using irrlicht (and the new 0.6 changes). I'm pretty psyched about this sort of capability - let me know if you'd like help. If I can find time maybe I'd join the ping effort.
Alright - enough rambling. I suppose my username is fitting for this scale of rambling. I'm just excited to see where ping.net is going!
good idea on the delegate thing - only issue i see there is that for each type of scenenode there are functions that need to be accessible to the game developer - i was hoping that the game developer would only have to deal with ping classes/types and not have to use handles to irrlicht or tokamak classes directly - so i might do the delegate thing but actually make separate subclasses to pass through the functions in each scenenode that seem relevant
the other thing i want and need to do is make my PingBlock class (which is the base game object in ping) able to deal with the scene graph AND a notion of containership - its a notion i have been playing with for quite a while - most often in your game you want to work with collections of objects that have some relationship to each other - but not a strict hierarchical one - for instance with flocking you have a set of bird objects that share behavior - but you really dont want to put them all under one scenenode
so i am making PingBlock so it primarily deals with containership - and inside i am allowing objects to be snapped to each other (using the scenegraph) so you get the best of both worlds
and it would be great to get help on many fronts - once i start publishing some of the base framework it will be easier to see where extensions can be carved out
the other thing i want and need to do is make my PingBlock class (which is the base game object in ping) able to deal with the scene graph AND a notion of containership - its a notion i have been playing with for quite a while - most often in your game you want to work with collections of objects that have some relationship to each other - but not a strict hierarchical one - for instance with flocking you have a set of bird objects that share behavior - but you really dont want to put them all under one scenenode
so i am making PingBlock so it primarily deals with containership - and inside i am allowing objects to be snapped to each other (using the scenegraph) so you get the best of both worlds
and it would be great to get help on many fronts - once i start publishing some of the base framework it will be easier to see where extensions can be carved out