@ CS...
1- player2 is not from the same subclaass as the default player, and thus does not share the linkage to tGame that the initial player does... the implications of this will become apparent further down the line... a tGame has one and only one default player... and one and only one default view... due to what was stated previously, every game will most likely have at least one player and one view... so it is included as part of the engine... but that doesn't restrict you from adding additional players... just give them a different subclass name...
2- the Player is not a separate class from Player2... all objects in a game belong to the tGameObject class... the PLAYER is a separate subClass from Player2, and they need to be for the reasons just given... that is the only reason to make an additional player subclass, to accomodate another player in the same game...
your idea of a rpg game above is fine, but it is not OO in nature... as i see it you've got the game engine tied to closely to the type of game you are making... in your design, how would i make a game with no map...
do you see any hard references to a map in irrlicht, or any generic game engine... the game engine only needs to know what is necessary to get itself instatiated... and at is basic form, this only requires it to be able to know where on the users hard drive it is, what type of video is there, how much memory is available, and possibly where the win and temp directories are located...
the Map and others stuff are best implemented as separate subclasses classes... and generic enough to allow you to reuse the subclasses in subsequent games...
you're not looking at the big picture... you're trying to cram too much in at once... and this will bite you in the long run... KISS is the rule here... keep each functional component discrete... your approach would have you creating a new game engine for each new game you make... you can make a rpg with my engine design, as well as a fps, a simulation, a chess game, even a racing game... i'm not saying that my idea is the only solution... i am saying though, that yours is only a partial attempt at an OO design... there no real encapsulation, and no real code reuse...
of course not... PLAYER2 is just the name i gave to the subclass... i could've easily called it AUXPLAYER, and thus could have as many as memory allows... and each one could have different keyboard assignments via the \obj instance passed in the update function...
that's the whole point of creating sub classes... the pseudo polymorphhism is implemented in this way...
you just don't see it yet...
@ GA...
wrong... as stated above, there is no inheritance, per say... only a single sub layer of functionality that i would only term a rudimentary form of inheritance... all tGameObjects 'inherit' if you like, the same update function, which, can handle all instances of the same subclass of tGameObject... no matter how many you choose to instantiate... you could have 20 Player2 objects, each calling the same Player2 update function, only differentiated by their \obj arg in the Update function...
regardless of how you want to look at this, it is still OO in nature, providing a rudimentary form of inheritance like qualities, and a rudimentary form of polymorphism by what i just explained to CS directly above...
the OO nature is real... the adherance to strict OOP is lacking, but that doesn't mean it's not OO...
@ Noel...
i just saw your reply... true OO code, theres no such thing... that's just like saying you can't implement OO in c... which is already a well known falsehood... you are confusing OO with OOP, Object Oriented Programming compliant languages... where strict adherance is the goal...
and if you think it already has failed, copy and paste the code, and see how easy it is to create an object...
... or a game with the engine as it is in it's early state.
--Mike
When assuming that player 1 and player 2 are essentially the same players (technically), just different gamers controlling it, I'd stick to one playerclass forever.
this assumption is faulty... and based on incorrect premises...1- player2 is not from the same subclaass as the default player, and thus does not share the linkage to tGame that the initial player does... the implications of this will become apparent further down the line... a tGame has one and only one default player... and one and only one default view... due to what was stated previously, every game will most likely have at least one player and one view... so it is included as part of the engine... but that doesn't restrict you from adding additional players... just give them a different subclass name...
2- the Player is not a separate class from Player2... all objects in a game belong to the tGameObject class... the PLAYER is a separate subClass from Player2, and they need to be for the reasons just given... that is the only reason to make an additional player subclass, to accomodate another player in the same game...
your idea of a rpg game above is fine, but it is not OO in nature... as i see it you've got the game engine tied to closely to the type of game you are making... in your design, how would i make a game with no map...
do you see any hard references to a map in irrlicht, or any generic game engine... the game engine only needs to know what is necessary to get itself instatiated... and at is basic form, this only requires it to be able to know where on the users hard drive it is, what type of video is there, how much memory is available, and possibly where the win and temp directories are located...
the Map and others stuff are best implemented as separate subclasses classes... and generic enough to allow you to reuse the subclasses in subsequent games...
Something like this. The *only* thing you ever need to do is (1) create a core game object,
you're not looking at the big picture... you're trying to cram too much in at once... and this will bite you in the long run... KISS is the rule here... keep each functional component discrete... your approach would have you creating a new game engine for each new game you make... you can make a rpg with my engine design, as well as a fps, a simulation, a chess game, even a racing game... i'm not saying that my idea is the only solution... i am saying though, that yours is only a partial attempt at an OO design... there no real encapsulation, and no real code reuse...
perhaps we'll do more players? Whatyagonnado then? Add UpdatePlayer3(), UpdatePlayer4() etc. ?
of course not... PLAYER2 is just the name i gave to the subclass... i could've easily called it AUXPLAYER, and thus could have as many as memory allows... and each one could have different keyboard assignments via the \obj instance passed in the update function...
that's the whole point of creating sub classes... the pseudo polymorphhism is implemented in this way...
you just don't see it yet...
@ GA...
And you can't inherit so polymorphism has to be hacked. You end up having to make very similar functions to handle similar objects instead of having one function that handles a variety of objects.
wrong... as stated above, there is no inheritance, per say... only a single sub layer of functionality that i would only term a rudimentary form of inheritance... all tGameObjects 'inherit' if you like, the same update function, which, can handle all instances of the same subclass of tGameObject... no matter how many you choose to instantiate... you could have 20 Player2 objects, each calling the same Player2 update function, only differentiated by their \obj arg in the Update function...
regardless of how you want to look at this, it is still OO in nature, providing a rudimentary form of inheritance like qualities, and a rudimentary form of polymorphism by what i just explained to CS directly above...
the OO nature is real... the adherance to strict OOP is lacking, but that doesn't mean it's not OO...
@ Noel...
i just saw your reply... true OO code, theres no such thing... that's just like saying you can't implement OO in c... which is already a well known falsehood... you are confusing OO with OOP, Object Oriented Programming compliant languages... where strict adherance is the goal...
and if you think it already has failed, copy and paste the code, and see how easy it is to create an object...
... or a game with the engine as it is in it's early state.
--Mike