Sign in to follow this  
ErUs

C++, Laying out a game...

Recommended Posts

ErUs    136
ok, hello again. i now know C++ well, but i have real problems laying out classes for any sort of game. for instance; i don't know what to put in classes and what not to and i don't know how to set up a system were different classes can look at other classes when i try and make stuff scalable ( array of classes ). i would like to see how you guys set up your games. do you have a MainLoop function in a class? do you put rendering code in its class own class? input? menu/ingame? thanks alot ( i know its a hard post to reply to but i really cant simplify what im saying. ) [edit] class layouts - in ascii graphics or graphs :)

Share this post


Link to post
Share on other sites
Kuladus    380
Try not to get stuck by considering too far ahead. My projects always go downhill as I try to get the best design for everything, when in fact there is no "best" design. Just design your first couple of projects incrementally and soon you'll pick up the knack for joining the parts together. [smile]

Share this post


Link to post
Share on other sites
ErUs    136
i dont think you guys got what i was saying...

i end up doing stupid stuff like

if( gamemode == TITLE1 ) {
doTitle1();
} elseif( gamemode == TITLE2 ) {
gamemode = title3;
} elseif( gamemode == TWOPLAYER ) {
blah blah

and its very very messy :(

Share this post


Link to post
Share on other sites
Darkneon    166
Shannon Barber and Squirm, I think he was talking in general.

You can search about refactoring, which is basically modifying the design of your code before writing new code. Design pattens might help too.

Listen to Kuladus, he's right. There is no such thing as best design. This doesn't mean you shouldn't design, it means you can't design everything and think everything will flow. Again, as Kuladus said you should not "consider too far ahead". Designing and coding goes hand in hand; you design a little, you program a little. Repeat the process until completion.

As with everything, the more you do it, the better you get at it. The more you design, the better you will become at it. You will notice patterns, and/or you will be able to create new designs from past designs.


Darkneon

P.S What I mean by design is diagrams and pseudocode.

Share this post


Link to post
Share on other sites
Nypyren    12065
I vote for a multiple-pass approach: first, just use whatever techniques come to mind to actually make working features (don't think about the code design too much at first). You will run into problems in the design, but when you look at what you end up writing, you learn what went right and what went wrong.

After you understand a lot of things that work/don't work, look up books on "Design Patterns". Basically, they are compilations of various "what works and what doesn't" that are really common in programming. After you let all of that information sink in, you should be able to figure out really good ways to design your overall game systems.


Note: This process took about 8 years for me (from when I started using C++ as a newbie to what I know now)

Share this post


Link to post
Share on other sites
ErUs    136
ok thanks guys.

im gonna try and design a bit; code a bit; repeat;

and get a few books.

also i looked at function pointers and state paterns and i will apply where necessary

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Just to add my (admitedly anonymous, the registration function seems broken) voice to the chorus, "best" is the enemy of "good". This can't be overstated, attempts to hit the "best" design usually result in a train wreck.

Share this post


Link to post
Share on other sites
capn_midnight    1707
Start writing a program, any program. If you get to a point where you can't decide on the best way to do something, flip a coin and continue. You're probably going to end up writing a lot of code that you will decide "ah, hell, that doesn't work" and throw away. But that's exactly the point.

Some important words from Thomas Edison

"I am not discouraged, because every wrong attempt discarded is another step forward".

"Nearly every man who develops an idea works at it up to the point where it looks impossible, and then gets discouraged. That's not the place to become discouraged."

"I have not failed. I've just found 10,000 ways that won't work."

Share this post


Link to post
Share on other sites
goldenpanda    180
I'd like to say this has been a very high quality thread. I have just one thing to add for ErUs. With books like "design patterns", put it away if you feel you're not getting much out of it.. but *make sure* to find the time to *go back* to the book after you've done more coding. Then put it away again, code more, pick up the book once again, repeat!

The reason is this. It's useless to discuss software technique as a purely logical matter. There just isn't enough "symbol space" in our brains to reason about an entire software system. To appreciate the technique of patterns, you have to *feel* them -- and the only way to acquire that feeling is through relentless repetition and experience.

Share this post


Link to post
Share on other sites
dbzprogrammer    100
Oh, and don't stop in the middle of coding and think "how am I going to do this?" when all it is is a stupid loop function that copies a string. If you find yourself there just code it. One of the parts that makes you good at coding is you just keep at it at all aspects. As you were saying. In a game you have data and functions. With C++, we can keep those together, but you find yourself often that it doesn't exactly work to well like that. For example, you could have a list of objects to render. You can either send them to a renderer, or include the render code in each one. One works better than the other, not at everything, but at some.

Share this post


Link to post
Share on other sites
stylin    758
Quote:
Original post by ErUs
ok, hello again.

...i have real problems laying out classes for any sort of game.
...i don't know what to put in classes and what not to
...i don't know how to set up a system were different classes can look at other classes...

i would like to see how you guys set up your games...

Not sure if you have read these Fine articles, but they might be what you're looking for. The first is here:

http://www.gamedev.net/reference/articles/article1947.asp

:stylin:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this