I stopped to wrap all dgDK commands inside my classes, but use more complex and specific methods that use the db...commands inside the methods.
For "pure" db...commands I use the ID from the objects (which is stored inside the classes).
I found it quite great to have the objects stored inside a custom map-container.
Then I use commands like "dbPickObject(...)" somewhere in my code.
The ID range I get from my containers, for example, the ObjectContainer for "Item"-objects.
And the ID returned by it (->dbPickObject) I use with the map-container to get the pointer to the actual object.
The object has attributes like Color, a unique name, a tag, etc
So, with the example, if dbPickObject returns a value > 0 then I KNOW that it is a "Item"-object and also can get the Unique Tag, the "name", the color, the texturename, .. everything I decided to store inside the object-class.
But I dont put commands like dbMoveObjectDown() etc into my classes,
first, this will be only a wrapper so it probably steals some frames from my app. (imagine thousands of objects) (Maincode calls method of object, object calls DarkGame library.) I decided to call them directly. (Maincode gets id from object, maincode calls db-command( ID))
But I implement methods that describe a more complex behaviour of the object which then will use several DarkGame commands to do it.
Unfortunately, the dgSDK isnt OOP.. in the newest beta though, you will get the STRUCTURE (in this case, a class with only public attributes (and methods?)) of the object which provides good informations already.
(as described in the posts above)
Well,... It took some time for me to figure out what framework I have to setup. IDGenerators, IDManagers, then base-classes, the Objectfactories etc etc. but it works quite well!!
//Awards: Best DM at NeverwinterConventionIII (NWCon3)
//Sys: Pentium IV 3200E/Prescott;800Mhz FSB;HT;WinXPPro;ATIR9700PRO;1024MB RAM(2x512MB"DualChanneled"
;VC++7.net;Delphi6;ADSL512;