i agree whole heartedly here... if your code is a mess using OOP, then it never would never even have stood half a chance using procedural methods...
think about it for a second Alberto... say you are creating a tank game in B3D, no OOP hacks or anything... most people would open a graphics screen, place a camera and a skybox... load up a terain mesh, create a tank, and procede to flesh out the logic to make it all work... most will give up before the game is done, frustrated by a seemingly overwhelming amount of logic that they've gotta implement...
a few will see it all the way through, and get it done... but waht about maintainence, bug fixes, small changes, the next game...
now, if they applied OO coding practices... not only would they have been able to start off with their last game engine class and their last game object member of that class, and build upon that... taking each step at a time...
gameobject (already done and validated) derives vehicle... vehicle derives tank... if you don't already have a vehicle class, concentrate on making one... once that's done, a new sheet of paper, and tank extends vehicle...
what could be simple... what could be more easy to code and debug... you only have to go as far back as the last object you are designing... all the stuff prior to that is test bug free and working (or it should be :) )
even if it's not entirely free of bugs, as long as you don't destroy the interfaces, you can clean up newly discovered bugs in ancestor classes (admittedly, they may be harder to locate), and the fixes will trickle down to all descendants...
this is the way to code... in the beginning it's gonna seem like a lot of work because you are establishing your groundwork... your base classes, and their functionality... but very soon it will start to become easier and easier...
enough preaching for one post :)
--Mike
think about it for a second Alberto... say you are creating a tank game in B3D, no OOP hacks or anything... most people would open a graphics screen, place a camera and a skybox... load up a terain mesh, create a tank, and procede to flesh out the logic to make it all work... most will give up before the game is done, frustrated by a seemingly overwhelming amount of logic that they've gotta implement...
a few will see it all the way through, and get it done... but waht about maintainence, bug fixes, small changes, the next game...
now, if they applied OO coding practices... not only would they have been able to start off with their last game engine class and their last game object member of that class, and build upon that... taking each step at a time...
gameobject (already done and validated) derives vehicle... vehicle derives tank... if you don't already have a vehicle class, concentrate on making one... once that's done, a new sheet of paper, and tank extends vehicle...
what could be simple... what could be more easy to code and debug... you only have to go as far back as the last object you are designing... all the stuff prior to that is test bug free and working (or it should be :) )
even if it's not entirely free of bugs, as long as you don't destroy the interfaces, you can clean up newly discovered bugs in ancestor classes (admittedly, they may be harder to locate), and the fixes will trickle down to all descendants...
this is the way to code... in the beginning it's gonna seem like a lot of work because you are establishing your groundwork... your base classes, and their functionality... but very soon it will start to become easier and easier...
enough preaching for one post :)
--Mike