Is there more generic approach for this?

Monkey Forums/Monkey Programming/Is there more generic approach for this?

MikeHart(Posted 2012) [#1]
Hi folks,

when I have designed fantomEngine, I didn't thought about that there could be the need to extend the object class by the user. One now tried to do this and how I have build the engine, I think it isn't possible atm. Maybe it isn't possible at all, but my OOP knowledge is pretty slim so maybe someone can give me a hint.

Here is basically a very slim version of how I have the classes connect to each other. I wonder how I have to set it up so it works when someone wants to extend the object class without going into the engine code

Here is the myEngine.monkey file:




And here is the engineTest.monkey file:



So my questions is, how do I have to change the engine, that I can let the user extend the object class and use this, still be able to use the normal update and render calls of the engine?


Rone(Posted 2012) [#2]
Hi,

I guess the simplest way is to provide a constructor for ftObject, in order simplyfy extending ftObject and provide also a way for adding and removing ftObjects from ftEngine...



If you do not want to provide constructors and force the user to use the ftEngine.CreateXX functions, I suggest to provide a factory for each ftObject type... -> ftEngine.CreateObject( ftEngine.otBox, x,y,...)



all pseudocode


MikeHart(Posted 2012) [#3]
The problem is the casting between the engine and the objec t (or an extended) class. How do i do it, so it works? Maybe it isnt possible.


Ferdi(Posted 2012) [#4]
Hi Mike, hopefully this is what you are looking for in a solution. I am not quite sure about your question. But your problem is this line:

Local obj:cObject = New cObject  '<<< you are basically creating the root / base object all the time.


This is how I modified it (sorry I put it all in 1 file, lazy to create 2 files =P):



Just on a side note and not to derail this thread, you may run into trouble in the future, if you structure it like this. Read this article he explains it best:

http://www.rtsoft.com/wiki/doku.php?id=proton_entity

I believe you are bullet number 2:

Create a giant entity class hierarchy where each kind of thing gets its own class. A bird might be derived like: Object -> Visual -> MovingObject -> NPC -> Bird or something ridiculous like that. End up using virtuals everywhere.
VERDICT: Slow to add new things, too difficult to refactor, maintenance is a hassle.


If you are interested, I am using t-machine entity system, which I have ported to monkey. I can share that code, it seems to work, but it is probably still buggy =)


Rone(Posted 2012) [#5]
definitely, the best example of God object / blob pattern

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
http://stackoverflow.com/questions/1901251/component-based-game-engine-design


MikeHart(Posted 2012) [#6]
Hi folks,

thanks for all the input. Based of Ferdis last suggestion I found a method that fits into the existing workflow of my engine.