Quote:Original post by M2tM

Quote:Original post by Konfusius

Quote:Original post by ArmchairArmada
What does the overall structure of a well designed game look like?

You'll know once you finished a few badly designed games.

I disagree. You'll know what badly designed games look like if you finish a few badly designed games but you may not even realize they are bad. Often people are blinded to their programming faults because on a surface level the code may work and they may move on without thinking further on the matter. You will not magically become aware of better methods except by deep introspection (I say introspection because the nature of the problem originated from your own mind) into those mistakes or by learning from other more experienced programmers (and books by those programmers.)

That's my opionion, too.

Quote:but you may not even realize they are bad

ArmchairArmada expressed interest in improving his design skills. I think he will keep a critical eye on his work as he makes progress.

It sounds to me like your difficulty is with OOP, and not specifically with C++.
What other programming languages have you used, and which of those are you fluent at?

Quote:Original post by theOcelot
These were very helpful to me.

Single responsibility Principle.

Open-Closed principle.

Liskov substitution principle.

Dependency Inversion Principle.

Thanks, I meant to link all of those, but could only remember the exact name of the SRP off the top of my head while I was writing that response. ++ for being awesome.

I suppose I may have more difficulties with object oriented design than with C++ specifically. I understand classes and objects and how to use them, but I suppose I wasn't entirely certain about how to use them well. I suppose I directed my frustration towards C++ mainly because of the languages I've used, C++ is the only one I've really attempted large scale projects with -- where greater complexities would naturally arise. I may have been a little hasty with targeting C++ specifically.

To answer iMalc's question about the languages I've used I could give a brief history. I began with Commodore 64's basic, moved to QBasic after getting an 8088, Visual Basic, about seven or eight years ago I began using C++, &#106avascript, PHP, and lately I've been using mostly Python. However, programming, being more of a hobby, there have been many times when months have gone by without really doing much programming at all -- I've been hoping to become a little more serious about it, though.

I suppose when using interpreted languages on small personal experiments, just playing around, there is less pressure for doing things well -- it's very different from a large project where quick hacks early on could come back to bite me. The temptation to get things up and running as quickly as possible can be hard to resist.

Thanks for those articles. For a second there I forgot I downloaded them before leaving for work. I'll have to take a look at them.

Quote:Original post by Driv3MeFar

Quote:Original post by M2tM
I disagree. You'll know what badly designed games look like if you finish a few badly designed games but you may not even realize they are bad.

You may not have the prettiest code on the planet. It may have a global or two in it, or have some dirty casts that rely on unsafe assumptions, but it will work. And at the end of the day, the only thing that matters about your code is that it works.

Your first points are all good, so I will simply address this.

The OP is looking for advice on how to become better which, I think we can agree, involves minimizing stuff like this. DOING IS ABSOLUTELY AND ENTIRELY VITAL TO BECOMING A GOOD PROGRAMMER (this is bold and caps so it doesn't get lost.)

That said, I do not believe that you can really transcend the basics without either a -lot- (years and years) of messy code which slowly gets better or alternatively by both applying and learning from others who have already trod that path and figured more graceful solutions to typical problems.

Sure you may have code that works and ultimately getting it done is more important than quibbling about how it could be better. But don't discount advancement in sophistication while also getting things done, because that is an option. It isn't one or the other, doing at the cost of learning or learning at the cost of doing. True masters learn and do in equal measure.

Let me stress that it is important to be unafraid of getting your hands dirty and delving into some code. Ultimately practice is the most important aspect of learning, but temper that with advice and examples from others with more practice than you have (all the while applying what you learn as you learn it) and you will become better quickly.

I just finished reading through those articles that theOcelot posted. They were great. I'm going to have to reread them to let them fully sink in. The last one I read, "The Dependency Inversion Principle," totally blew my mind! This solves so many problems! I can see how purely abstract interfaces could help with making extremely flexible and reusable code.

One great thing is that it would greatly simplify dependencies. It always annoyed me when making small changes caused half my application to need to be recompiled!

Wow. Thanks!

Yes, I rather enjoyed the Dependency Inversion one too. Oh heck, I'll be honest, it blew my mind too.

My only small problem with those articles is that they teach a rather hard-core OOP. Maybe it works, or has to be that way, in Java, but you don't want to go too crazy with all the interfaces and inheritance and stuff in C++. You want to be a little more pragmatic. C++ is a multi-paradigm language. Make the most of it.

Perhaps you would be more comfortable initially just using objects rather than making your own classes. You could program in a procedural way using objects such as those in MFC and the SC++L, then as you get used to how those objects work, and study their source code occasionally, you'll feel comfortable taking the step into writing your own OO code.

I was thinking about game entities and their dependencies. Jdindia suggested having a global application object where the necessary systems could be accessed. I didn't really like this idea, since it sort of ties the dependencies in knots.

Instead I thought it would be better if each game entity was passed a pointer to a systems class which contains purely abstract interfaces to the necessary systems. For example: in entity behavior code I might use something like this->systems->audio.play("explosion"), therefore the implementation of audio doesn't matter to entities, just the name of the sound effect.

Likewise there might be this->systems->entity_manager.add("SomeEntity"), where an entity factory might be used to create new entities in the entity manager.

Things seem so much clearer now. Though, maybe, it would be better optimized to use enums instead of strings -- though it might be more difficult to later allow scripting to add functionality?

[Edited by - ArmchairArmada on January 24, 2009 12:19:16 PM]