it's a lot more than that Josh... i see where you are coming from, but you are just slightly missing the main point here... as are a few of the people responding to what you are saying are equally missing the point...
this is not so much the syntax, or the differences in organization... OO coding goes far beyond that...
OO represents a paradigm shift in the way you think about coding your projects...
this is the key to the whole thing... most of us are adept enough coders to pickup on the syntax and doctrines regarding the mechanics of coding in an OOP environment... but a lot of us miss the more subtle, but equally as profound aspect of thinking OO...
ok, what i mean is this... look at the example you discussed above... you talk about a myEnemy class, as if it were something that you would just pop into your program without any aforethought... exactly in the same manner that a Blitz3D procedural coder might do... even if he/she was using an OO type hack of Blitz3D... or, for that matter, any procedural BASIC language...
and this is where the problem lies...
in an OOP environment, as i see it, the above examples and points shows that you are not thinking OO here... you are merely using OOP facilities in a half a$$ed, hybrid fashion, to come up with something that is a lil better than procedural methods, but still a lot less than it could be...
any remote thought about a myEnemy class should've started a long time ago... while you were in the process of coding, or developing your gameEngine class... a base class that every game should spring from... after all, every game should be it's own engine, ideally based on a generic set of members, methods, etc that enforce a universal set of doctrines, so that you can use it as a jumpoff point for every game you write in the future...
in turn... myEnemy should be a descendant of gameObject, which itself, should be a member of your gameEngine class...
and, like Koriolis said above, then you could derive specific behaviors at this point, for specific types of enemies... trolls, marines, whatever... all inheriting the behaviors and properties of their descendants...
just like real objects in the real world... virtual object in the OO world have ancestors... and inherit qualities, even instincts one might say :)
am i getting my point across here in a way that can be seen... what i'm trying to say is that you've gotta start to think OO if you wanna code OOP... you've gotta abandon those imgrained ideas of functions and subroutines and procedures...
... you've got to adapt a new mindset, not just a new tool set.
--Mike
this is not so much the syntax, or the differences in organization... OO coding goes far beyond that...
OO represents a paradigm shift in the way you think about coding your projects...
this is the key to the whole thing... most of us are adept enough coders to pickup on the syntax and doctrines regarding the mechanics of coding in an OOP environment... but a lot of us miss the more subtle, but equally as profound aspect of thinking OO...
ok, what i mean is this... look at the example you discussed above... you talk about a myEnemy class, as if it were something that you would just pop into your program without any aforethought... exactly in the same manner that a Blitz3D procedural coder might do... even if he/she was using an OO type hack of Blitz3D... or, for that matter, any procedural BASIC language...
and this is where the problem lies...
in an OOP environment, as i see it, the above examples and points shows that you are not thinking OO here... you are merely using OOP facilities in a half a$$ed, hybrid fashion, to come up with something that is a lil better than procedural methods, but still a lot less than it could be...
any remote thought about a myEnemy class should've started a long time ago... while you were in the process of coding, or developing your gameEngine class... a base class that every game should spring from... after all, every game should be it's own engine, ideally based on a generic set of members, methods, etc that enforce a universal set of doctrines, so that you can use it as a jumpoff point for every game you write in the future...
in turn... myEnemy should be a descendant of gameObject, which itself, should be a member of your gameEngine class...
and, like Koriolis said above, then you could derive specific behaviors at this point, for specific types of enemies... trolls, marines, whatever... all inheriting the behaviors and properties of their descendants...
just like real objects in the real world... virtual object in the OO world have ancestors... and inherit qualities, even instincts one might say :)
am i getting my point across here in a way that can be seen... what i'm trying to say is that you've gotta start to think OO if you wanna code OOP... you've gotta abandon those imgrained ideas of functions and subroutines and procedures...
... you've got to adapt a new mindset, not just a new tool set.
--Mike