Skip to main content
gamedev.net
🔒 Locked

Objects, Objects and more objects...

Started by hammerstein_02 Aug 5, 2002 at 6:09 PM 2 replies 200+ views
Original Post
hammerstein_02
hammerstein_02
I have recently decided to do something I have never decided to do before, that is sit down and try and design my program before I code.. and I know that I can''t be the only one that gets myself in this situation.. you sit down, you code each idea as you get it, you bend and twist your code until you can''t actually do much more with it except rewrite massive chunks of it. I started with creating a base object, cObject from which I derived cButton. Now I want a cObject to have functions for clicking and mouseover events, however I ended up having to place a DirectDraw Surface in there.. which I wasn''t too happy about. I wanted the object to be very general, and adding a directdraw interface kinda defeated my original idea. I had next and prev pointers in my object so that I could add an object based on cObject into a list, which would iterate through and display the object, which meant I had to put the basic surface into the main object. How do you guys go about designing you software? I have never found any really valuable object orientation tutorials, and would appreciate some advice as to how I should structure my general code. Code would be helpful I think, although a general method with a small outline of a structure I could aim at would be helpful. Thanks for your help peoples.. Hammer =*= If things seem bad, think that they can get a whole load worse, and they don''t seem so bad anymore =*=
uncutno
uncutno
A way that works:

CCore(includes) (CXxxxx = class)
CScreen //Screen init/exit
CInput //Input init/exit/get_input
CSound //Sound init/exit/playsound...
...
CGame //Game init/exit/loop

then you define the CCore object inside your WinMain, and send a pointer to the CCore with all inside core functions! (that need core accses)! NOW this is not good if you want your Mesh class to accses the D3DDevice, or something like that... (alot of overhead, i think the name is...) thats why you instead of creating a CSurface class, that handle surfaces, you create a CSurfaceManager class, and includes it inside the core!

CSurfaceManager
CTextureManager
CSoundManager //instead of CSound
CMeshManager

The thing, is that you only need to create CCore managers for your low level elements, that uses the hardware! Later if you create a CButton, you dont need to put a CButtonManager in the core, because the CButton itselfe dont need hardware connections!
BUT Inside your CButton, you have a link to the propriat CSurface inside the core!

This is how i do it! :-) I dont know if its the greatest way, but its clean, and it work...

Core = API/OS Dependent stuff
Game = API/OS Independent stuff

The reason why i inlude CGame in the core, is because there is no better place to place it! (dont like globals...)

I would also like to read how others do this...

[edited by - uncutno on August 6, 2002 6:37:31 AM]
-Anders-Oredsson-Norway-

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.