Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kindjie]

For real-time games written in OO style, you'll have a gameloop which updates all the parts of your system. You'll divide your code into modules for rendering, audio, input, resource loading/management, gameplay, etc. and use a prioritized task list for this.

Gameplay will be your glue - the rest of the modules should be as independent from the others as possible. Each module will consist of dozens of classes. Each class should favour aggregation over inheritance, private over protected, protected over public. Each class should have one purpose, and it'd be good if you can separate your interface from your implementation (using abstract base classes, pimpl idiom, etc.). Use RAII when it makes sense (see Boost smart pointers). These are the fundamentals of most design patterns, and it'd be a good exercise to go over them so you don't reinvent the wheel.

A good way to manage content to your game is to use a component based architecture. First paper I know of describing this is from Dungeon Siege (I think this has a link to it: http://www.purplepwny.com/blog/?p=215). Radical Entertainment switched to this system after Hulk for their new game called Prototype - they had a talk about it at GDC Canada this year. We also use it here at Next Level Games. If your game is really simple, don't bother. Just do whatever is simplest to get your content in the game.

If you're just starting out, rely on the C++ Standard Library. It's good enough for pretty much anything you'll be doing. Another good habit to get into is to use Boost, especially their smart pointers. Makes life easier as a beginner. If you run into performance issues, you can always go to a hand written solution.

Most important of all - SCOPE YOUR PROJECT. Keep it simple or you'll never finish it. Have a vision for it and stick to it so you don't go off on coding tangents. Profile your code before you optimize. Have a plan based on milestones with clear goals for each.

If you're stuck, don't beat your head against a wall. Go to www.gamedev.org, do a search, and ask for help if you need to!

~Owen

[Baughn]

Sure, I'll be in there in a bit.

Unfortunately, I'm in europe and going to sleep now. Let's try in, oh, ten-twenty hours or so?

[strich]

MrTk's point to plan is invaluable. I suggest sketching up some 'screenshots' of what you want things to look like with your favorite drawing tool. Then assemble them into a document, and add bulleted lists of what specific behaviors you want to implement in different screens. More detail is better.

If you go into sufficient detail, that document can become an excellent outline of everything you actually have to implement or create.

Aye. For some time now I've been DDoc'ing (Design Documenting) any potential games and ideas, though they are fairly high level.
I think the trouble I have at the moment in relation to DDocs is that I simply don't know how I should program and design the game from a logical point before I'm actually half way through doing it. This obviously comes from a lack of knowledge and experience which I'll rectify over time as I produce small game after small game.

Most game engines use a master "game loop" that processes input, calculates the world, and renders the results to screen.

Yeah actually that interested me quite a bit when I first discovered that. Seems there are quite a few ways to do it as well, each with their own disadvantages and advantages.

DJDD: if you want a peek at DF's source to see how it's structured, you should take a look at the Battle Champs source.  Battle Champs was purposely built like a very stripped-down DF, so that community people could take a crack at optimizing DF's rendering code.

I've had a look at it but unfortunately it does not compile in VS08 (Which I've noted in the thread) so I was unable to really get a good look into it other than just viewing code.

Baughn - RE the programming paradigms:
Firstly, thanks a lot for the explanations. Very insightful. Thus far I've only ever experienced 'spaghetti code' and OO. So far I'm liking OO a lot. But I see where your coming from. I believe OO programming is really only as OO as you make it; That is to say, you can go over the top and completely destroy the reasons behind employing an OO methodology in the first place. One needs to find the happy medium.
I guess in the end its more or less just a style isn't it. They all achieve the same task and while some paradigms lend themselves to certain types of programs it seems to me that the best paradigm is your own mixed bag. Which I guess brings us back to your last point:

The point is, object-oriented programming is just one tool in a very large toolbox, and you need all of them to be a good programmer.

I suppose it's far too late in the game to expect an optimized re-write of the code from the ground up.  I guess this is what happens with a continuous project like this.  When you work on a project for several years I imagine your code is going to start looking like a complete mess.  It's unfortunate that it was started without the tools we have today.

This kind of issue is actually something I've seen quite a focus on in the guides and tutorials I've completed so far. Something I've picked up is that it is a very good idea to make sure your game design is such that your Interface, Game Engine, and Game Logic (Among others) remain independent of one another. Doing so will allow your game to easily (Read: Not have to rebuild from scratch) move between platforms and new technology (For example an upgraded render engine). Its a methodology I definitely want to hone and get a good grasp of as I continue to learn programming.

[eerr]

Object oriented really isn't supposed to cause headaches.

The model: each object worries about itself.

with all parts efficiently divided, it reduces overhead by chopping a complex procedure into smaller procedures that each flow closer to the goal.

tasks once considered almost too complex to think about can be done by deferring responsibility to the next object.

OO is supposed to work by passing the buck, in a well-defined assembly line.

It's really good about avoiding and tracking null Pointer errors, where dwarf fortress can have silent problems, like with patrol routes messing up. DF has problems just organizing it's data in a short list for crist's sake!

On the topic of Dwarf fortress, how did toady build DF from the ground up? why I think this calls for me playing the earliest available version.

[Baughn]

Nevertheless, OO does cause headaches. You can't really argue with experience...

Look, as I said, it works reasonably well in a lot of cases, and excellently maybe 10-20% of the time. It's a great improvement on procedural code, most of the time. I'm not saying it isn't.

It's just that there are more options. Purely-functional programs, for example, despite not normally being object-oriented (they can be, you'll just find that it's not nearly as useful there..) are a lot easier to reason about than impure programs, simply because you know function A in some file somewhere doesn't affect anything that doesn't call it.

[zwei]

Anytime I saw OO cause headaches was because it was big project where code gained lots of entropy as people come and go and requirements change.

That is kinda unavoidable, and I suspect functional code would suffer exactly same kind of rot because no programing paradigm can really solve that, its in the people.

And in the end programing paradinmg does not really matter unless you can structure your algorithm and your data well. For that you need something in which you can express that, it really does not matter what it is. OO is just a one way to make structuring easier both to do and to grasp. It costs "elegance" or "purity", but that is in fact benefit.

Given my few years of working on mainframes, I say: damn elegance, curse you purity, go to hell smart code. You three harlots only cause endless headaches when maintaining software and motivate one to find original author and ...

There is reason why I nearly did not get job when i talked about code purity and prettiness of algorithms to my future-to-be-boss. That is liability outside university.

BTW: OP, just start coding, pick project and try exactly same project with different approaches and different languages. You will discover than in the end, they are all just tools to express your idea which always costrain it by some way. your goals is always to pick the one that constrains you least.

[Gantolandon]

Anytime I saw OO cause headaches was because it was big project where code gained lots of entropy as people come and go and requirements change.

Actually, the main goal of OO is to minimize this entropy...

[Baughn]

Doesn't work too well, does it?

Well, sometimes it does. When you try to shoehorn OO into a problem that really doesn't fit.. not so much, anymore.

[zwei]

Anytime I saw OO cause headaches was because it was big project where code gained lots of entropy as people come and go and requirements change.

Actually, the main goal of OO is to minimize this entropy...

Yes, famous "complexity" curves and software crisis.

To be fair, OO helped a lot. Compared to procedural approach, it is godsend. But it is not ultimate solution because humans simply forget to react on someone elses changes or slack or take shortcuts to make stuff 'work' or just deviate from pattern that rest of coders use and code base slowly rots.