@ jason...
well said j...
also... i'm usually up at 5 am coding myself... when most of the world is in the throws of that lucid dream sequence
@ unitech...
yeah... a noob (like me
) might benefit from looking at the code and how it's structured... i agree... no doubt...
also... regarding the id handlers... a simple id factory in the core class (i have it as a method in my
Game class) can consist of nothing more than incrementing a private variable whenever a new id is required... the base class for all objects in my framework (the
GameObject class) includes a variable called objNumber, so that every new object of a class derived from
GameObject can reference it... in the constructor for each new Gameobject derived class, i make a call to
Game->GetNextObject(); which provides the new instance of the class with the next available object number, and stores it for later use...
since this is done automatically, you never have to worry about overlapping or duplicate object numbers causing problems...
i also do the same thing for meshes (mesh numbers), images (image numbers), memblocks, effects, anything that requires the use of a unique number identifier...
this way the entire number thing becomes transparent after the class is written, and i never have to worry about it again...
@ everyone...
yeah... this is a good discussion... lots of good input from all over...
OO development is more than just coding... it's your whole approach toward a project... the way you visualize the entire thing in your mind... since everyone envisions things differently, unless you are working as part of a team, following someone elses visualization and logic may not be the best idea... in short, this is one case where a few different wheels is not necessarily a bad thing...
me, for example, i do things a lil off the cuff... since i'm naturally lazy, i have my declarations and implementation all in one file (the .h file)... bad practice, but it works for me...
also... i use a single event handler (generated by the
Game class which raises a universal update event in order to provide each object (class) with the ability to auto update itself...
also, i don't use a linked list structure for my framework, which, i think, would be the best way to whip up an OO framework... i may adopt something like this later...
my general approach is to keep everything simple... to keep my classes as small and as single purpose as possible... write it, test it, make sure that one lil piece of functionality works, then build up upon it, deriving new related classes from already validated ones...
that's my only reluctance to employing huge, all encompassing wrappers...
--Mike