@ Cyg... not yet, been too busy getting the sub class and it's controls finished and tested... i've looked at your stuff though,and a lot of what you're doing seems similar to what i have implemented already so it shouldn't be too hard to do once i'm ready to focus on that again... i'll let you know how it goes... should be in a few days...
@ Eurythmia... hey there Paolo... what's the latest on Tecno, any new news...
as far as my lil thing goes... the engine is basically a big main loop that contains a few nested loops that continuously calls the update functions for each 'class' of objects in the game...
when you create a class, you give it the a classname, then you write up one function which you register with the game engine... like this...
this is the only place where you have to edit the engine code...
this function will contain all the functionality for that 'class', and any object instatiate from the class will behave according to what is coded in this function...
as you can see, each instance of a particular class is passed to the classes update function so that each one can be treated as an individual... they all share the same update function, naturally, right, because they are all of the same class and share the same basic functionality... so you write this once, and it applies to all object created from that class...
an important point when coding objects... i don't think in terms of playing against the PC... the PC is an abstraction to the game engine, and it is only aware of the PC in the game.system class, where it is necessary to know certain things about the hardware and the directory structure... otherwise, the PC doesn't exist as far as the game engine knows...
the player is also an abstraction... it does not exist as part of the actual game, but only an entity outside of the game... merely as an interface for the user to interact with the game...
the OOP way of approaching this is to think in terms of one class of objects playing against another class of objects...
for example... if i wanted to have two groups of soldiers playing against each other i would implement 2 classes of soldiers... a redTeamSoldier class and a blueTeamSoldier class... then i would code each teams functionality based on what i want them to do... the one function, as mentioned before, which is continuously called by the engine's mainloop...
a simple ai example would be to have both classes search for members of the other class, and keep track of the distance from each one it finds... here's what the BlueTEAMSOLDIER class logic might look like...
and so on...
when the game starts up, the Player can choose which side he/she wants to be on, and the player object is attached to one of the object from either the RED or BLUE team classes... this dictates that each class has a provision for detecting whether or not an instance has a parent of the tObject type, and is of the PLAYER class, and would then not follow the ai portion of the code, but would run the segment of code that allows the player to control the object...
is any of this making any sense Paolo... i know it can be a lil convoluted...
in short, there is only one function that implements what each instance of a class can do... this is the classes update function. it can be written so that each class can detect members of another class... properties are merely DIMmmed variables that are linked to the objectID (each object of a certain class automatically gets a unique objID when created) and are available globally...
doing things this way simplifies the coding process in that all the functionality is coded once, and in one place... then, once the games objects are implemented, all you have to do is code your game like i mentioned in the top post... you can add as many soldiers from each class as you like... attach the player to one of em... and sit back and watch em all run around the place...
it's just a surface layer implementation of OO, and a loose one at that... but it helps keep my code, as well as my thinking organized...
i'll whip up a simple demo soon...
good hearing from you by the way... been a while...
--Mike
@ Eurythmia... hey there Paolo... what's the latest on Tecno, any new news...
as far as my lil thing goes... the engine is basically a big main loop that contains a few nested loops that continuously calls the update functions for each 'class' of objects in the game...
when you create a class, you give it the a classname, then you write up one function which you register with the game engine... like this...
For obj.tObject=Each tObject Select obj\subClass ;------------------------------ default player updating - DO NOT ALTER Case "PLAYER" UpdatePlayer(obj) ;------------------------------ default sky updating - DO NOT ALTER Case "SKY" UpdateSky(obj) ;------------------------------ default game logic updating - DO NOT ALTER Case this\Title TheGame(obj) .YOUR_UPDATE_FUNCTIONS ;------------------------- ADD YOUR NEW UPDATE FUNCTION REFERENCES BELOW AS A CASE CLAUSE ; THESE POINT TO YOUR NEW SUBCLASS'S UPDATE FUNCTIONS Case "ACTOR" UpdateActors(obj) Case "OCEAN" UpdateOcean(obj) Case "BOUYANTBOX" UpdateBouyantBoxes(obj) Case "GATOCLASSSUB" UpdateGatoClassSubs(obj) Case "REFLECTION" UpdateReflections(obj) ; ;----------------------------- COMMENT OUT OR REMOVE UNUSED FUNCTION REFERENCES End Select Next
this is the only place where you have to edit the engine code...
this function will contain all the functionality for that 'class', and any object instatiate from the class will behave according to what is coded in this function...
as you can see, each instance of a particular class is passed to the classes update function so that each one can be treated as an individual... they all share the same update function, naturally, right, because they are all of the same class and share the same basic functionality... so you write this once, and it applies to all object created from that class...
an important point when coding objects... i don't think in terms of playing against the PC... the PC is an abstraction to the game engine, and it is only aware of the PC in the game.system class, where it is necessary to know certain things about the hardware and the directory structure... otherwise, the PC doesn't exist as far as the game engine knows...
the player is also an abstraction... it does not exist as part of the actual game, but only an entity outside of the game... merely as an interface for the user to interact with the game...
the OOP way of approaching this is to think in terms of one class of objects playing against another class of objects...
for example... if i wanted to have two groups of soldiers playing against each other i would implement 2 classes of soldiers... a redTeamSoldier class and a blueTeamSoldier class... then i would code each teams functionality based on what i want them to do... the one function, as mentioned before, which is continuously called by the engine's mainloop...
a simple ai example would be to have both classes search for members of the other class, and keep track of the distance from each one it finds... here's what the BlueTEAMSOLDIER class logic might look like...
;---------- search for enemies for enemy.tObject=each tObject if obj\className="REDTEAMSOLDIER" ...code to add the obj and it's distance to a list (an array of foundEnemy types could be used) endif next ;--------- determine closest for x=0 to 5 (only search for 5 candidates) if foundEnemy(x)\distance < selectedTargetDistance selectedTarget=foundEnemy(x)\obj selectedTargetDistance=foundEnemy(x)\distance endif next ;---------- track towards pointentity... blah, blah, blah
and so on...
when the game starts up, the Player can choose which side he/she wants to be on, and the player object is attached to one of the object from either the RED or BLUE team classes... this dictates that each class has a provision for detecting whether or not an instance has a parent of the tObject type, and is of the PLAYER class, and would then not follow the ai portion of the code, but would run the segment of code that allows the player to control the object...
is any of this making any sense Paolo... i know it can be a lil convoluted...
in short, there is only one function that implements what each instance of a class can do... this is the classes update function. it can be written so that each class can detect members of another class... properties are merely DIMmmed variables that are linked to the objectID (each object of a certain class automatically gets a unique objID when created) and are available globally...
doing things this way simplifies the coding process in that all the functionality is coded once, and in one place... then, once the games objects are implemented, all you have to do is code your game like i mentioned in the top post... you can add as many soldiers from each class as you like... attach the player to one of em... and sit back and watch em all run around the place...
it's just a surface layer implementation of OO, and a loose one at that... but it helps keep my code, as well as my thinking organized...
i'll whip up a simple demo soon...
good hearing from you by the way... been a while...
--Mike