🔒 Locked

Guidance on structuring my code

Started by Defend Jul 1, 2004 at 1:05 PM 8 replies 1.3k views

Original Post

Jul 1, 2004 at 1:05 PM

I haven't made a game before, or any serious app for that matter. I did get off to a good start I think, getting a 2D tilemap and camera to work using D3D quads. But that was using global classes, which have to be avoided if I want to be able to pull the thing apart later, so I'm looking for the general advice and tips I'm missing. Basically I want: A graphics class - all D3D handling is here and nowhere else. A windowing class - that is told how I want it presented by the OS A game class - that deals with various other objects like camera, playable character, etc. What's the best approach to setting this all up so the classes remain completely independant of each other? And can your main/WinMain function start from inside a class? I'm quite a newbie with C++ OO. Cheers.

tomek_zielinski

Jul 1, 2004 at 1:13 PM

WinMain cannot be started from inside a class.

You can use singleton pattern[google it for examples],
or just create hese classes from inside WinMain
and that's all...

In general windowind class and graphics class can't be independent
because of connections between window and rendering contex.

The same is for game class ang graphics class -> gr class renders objects from game class

blue-ice2002

Jul 1, 2004 at 1:13 PM

classes are for object creation and organization,i mean if u want to make a game that's oo than u need to seperate your data and make them sandbox environments so that when u buy a new car u simply learn how to drive it cause every car has different gear system but same control part that is used for not confusing u.

if u make oo game your classes will communicate in that manner ,they will only need to know what they want from each other but not have to know how those accomplish different tasks.

DigitalDelusion

Jul 1, 2004 at 1:14 PM

Read Enginuity I don't agree with everything he says but that's really a good thing, it's a great series that covers a lot of ground in good detail and it's probably the best free article you'll find on the subject.

DigitalDelusion

Jul 1, 2004 at 1:17 PM

As for tucking stuff away in classes, I think ClanLib uses that approach, and on the GUI side MFC does something similar.

The way they work is that they give you a Application class that you derive and then you simply implement (override) some functions to get stuff rolling, that's one way to take with your engine
another is using a more procedural approach, just be sure to choose one and stick with it and document your design.

kburkhart84

318

kburkhart84

Jul 1, 2004 at 1:37 PM

I have done this type of thing recently, but I did it for OpenGL, though the sound/music part of it is DirectX. I can send you the source if you want, so you can get an idea of how I did it. WinMain can't be inside of a class because without WinMain outside of the class, the class is never created for WinMain to run from inside. The windows event loop can be inside of a class, like I did mine. The gist of it is to have each class know about each others existence so they may communicate via function calls. My kbgl class is the heart of it. It makes the window and draws everything. When a class needs to draw something, it recieves a pointer to the window class being used.

Defend

Author

Defend

Jul 1, 2004 at 1:46 PM

Yeah kburk, that'd be appreciated. defendjc@hotmail.com ... email or MSN. :)

Thanks for the link DigitalDel, I'm reading up on that now. Tomek, I'll look into singletons after that. Thanks for the tip.

RichardS

Jul 1, 2004 at 1:49 PM

My suggestion is to try what you first thought, unless you can look at any of the options presented in this thread and truly convince yourself that design X is better (and know why it's better).

The annoying part is that software engineering is probably more art than science, and there isn't a checklist way to do it. Experience is really what matters. By far, the best way to learn is to not plan too far into the future, but come up with a design that suits your immediate goals.

It will then become much more obvious later in your development what's right and what's wrong with your design. Then you look at the problem, refactor, etc. Rince, Repeat.

Go through this cycle a few times, and you'll have a much better idea how to attack your next project.

Defend

Author

Defend

Jul 1, 2004 at 5:41 PM

Well, would passing-by-value out of the game class into the renderer class everytime I need to render something be a bad approach?

Eg.
RenderClass.SetTilemapText(GameClass.GetTilemapFilename());
RenderClass.SetTilePositions(GameClass.GetWorldDataFilename());
RenderClass.DrawTiles(GameClass.GetCameraRECT(), etc, etc);

WindowClass.AdjustDisplayArea(RenderClass.GetDisplaySize());
RenderClass.ChangeDisplayMode(x,y,WindowClass.IsWindowed());

etc etc.

Isn't there some standard, well-known way to structure a 2D platform game, avoiding globals and class interdependency?

kburkhart84

318

kburkhart84

Jul 2, 2004 at 1:01 AM

I just sent you the e-mail with the code to my classes. Let me know what you think.

Topic Locked

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