no... that's not what i'm saying...
that would be the immediate approach, and not really OO compliant thinking... remember what i said in the old
thread about thinking out a solution in OO terms before rushing to code it...
hear me out for a second...
first, the point you brought was better than i first thought... the concept of each new object being an instance of tGameObject
didn't go far enough... while it is still valid, it needs to take into acount that each new tGameObject will also be a sort of sub class,
identified by the class member field (which i will change the name to subClass) in TGameObject...
so you would simply add a new a new tGameObject, and then in its Create() method, i would assign the sub class name... "PLAYER2"
to it's class field (the second arg)...
now it can live in the engine as a tGameObject:PLAYER2 object...
wait a second... lemme see if this works...
*** added***
ok... it works... again for each 'subclass' of tGameObject you need to...
1- write an update method (function) for it
2- add a select clause that points to it's update method via its class field, so that the engine is aware of it...
look at the new code for myGame that adds this second player...
and the added code to implement the new subclasses update functionality (right now all it does is initialize it)...
as you can start to see, all the functionality for Player2 is in one spot and can be coded and maintain all in one spot...
and the engine will make sure it is taken care of...
and the only revision needed to the core game engine code would be the addition of the new select clause in the run method... as is mentioned in the code comments for that section... and removing that select clause if the function is not defined in the next game you make... this is a must do for all new subclasses of tGameObject...
ok... it looks like this...
now that whole update section of code looks like this...
so, now to sum things up... we've created a new subclass for tGameObject, added its update function, and made teh engine aware of it...
this is the simple process that will be repeated when a new object is added to the game...
simple eh... well organized, everything is right where you expect it to be... encapsulated, with no globals all over the place...
the beginnings of an object oriented framework...
yes... no...
--Mike
that would be the immediate approach, and not really OO compliant thinking... remember what i said in the old
thread about thinking out a solution in OO terms before rushing to code it...
hear me out for a second...
first, the point you brought was better than i first thought... the concept of each new object being an instance of tGameObject
didn't go far enough... while it is still valid, it needs to take into acount that each new tGameObject will also be a sort of sub class,
identified by the class member field (which i will change the name to subClass) in TGameObject...
so you would simply add a new a new tGameObject, and then in its Create() method, i would assign the sub class name... "PLAYER2"
to it's class field (the second arg)...
now it can live in the engine as a tGameObject:PLAYER2 object...
wait a second... lemme see if this works...
*** added***
ok... it works... again for each 'subclass' of tGameObject you need to...
1- write an update method (function) for it
2- add a select clause that points to it's update method via its class field, so that the engine is aware of it...
look at the new code for myGame that adds this second player...
Include "../samples/OBGameEngine.bb" myGame.tGame=createGame("Invaders") player2.tGameObject=createGameObject(myGame,"PLAYER2","") run(myGame)
and the added code to implement the new subclasses update functionality (right now all it does is initialize it)...
;----------------------------------------------------------------------tGameObject Player2 Update method ; Function UpdatePlayer2(this.tGameObject) ;-------------------------------------- initialize the new subclass object here If begin=0 this\hEntity=CreateCube() HideEntity this\hEntity begin=1 Else ;--------------------------- normal game logic processing goes here... EndIf End Function
as you can start to see, all the functionality for Player2 is in one spot and can be coded and maintain all in one spot...
and the engine will make sure it is taken care of...
and the only revision needed to the core game engine code would be the addition of the new select clause in the run method... as is mentioned in the code comments for that section... and removing that select clause if the function is not defined in the next game you make... this is a must do for all new subclasses of tGameObject...
ok... it looks like this...
Case "PLAYER2" UpdatePlayer2(obj)
now that whole update section of code looks like this...
;------------------------------------ continually call each objects update() method here ; ; [[[ NOTE ]]] ; ; add a new case select for each new class in the game ; so that its update() method can be called by the main ; loop ; For obj.tGameObject=Each tGameObject Select obj\class Case "PLAYER" UpdatePlayer(obj) Case "PLAYER2" UpdatePlayer2(obj) End Select Next
so, now to sum things up... we've created a new subclass for tGameObject, added its update function, and made teh engine aware of it...
this is the simple process that will be repeated when a new object is added to the game...
simple eh... well organized, everything is right where you expect it to be... encapsulated, with no globals all over the place...
the beginnings of an object oriented framework...
yes... no...
--Mike