Design patterns for games

[Dries]

I'm looking for a good site or pdf that explains different design patterns for games.

I have been looking on the internet, but I can't seem to find a good site that gives a nice overview of the different game design patterns.

Someone here that knows a good source?

Tx.

[kappa]

http://www.cokeandcode.com has a few nice tutorials that might help.

[Dries]

I know this site, it has some nice tutorials.
But it's not what I'm looking for.

I'm looking for a site that has an overview of what design patterns to use to solve certain gaming problems.
Or a site that has an overview of different gaming design patterns.

Games published by our own members! Check 'em out!

[tom]

Don't know of a site, but this book is just what you are looking for:
Game Engine Architecture

[Dries]

Yeah in my search I found this book.
But before I buy a book, that's not in my mother language, I want to be sure the same info isn't out there on the net.

[tom]

Then your best bet is gamasutra

[Dries]

I found one article about patterns : http://www.gamasutra.com/view/feature/1408/designing_usable_and_accessible_.php

But isn't what I was looking for.

I'm looking for a site that tells you what patterns are best to use in what situation.

A small example :

To implement save games in your game you use best the 'State' design pattern. (Just a random design pattern that I took)

[Orangy Tang]

I'm looking for a site that tells you what patterns are best to use in what situation.

A small example :

To implement save games in your game you use best the 'State' design pattern. (Just a random design pattern that I took)

Yeah, you're not going to find that. How you perform (for example) saving, or any other game task is highly dependant on the type of game and the specifics of that game (an RPG is going to require very different saving mechanisms to an RTS, etc.). And high level functionality (like saving) may or may not require the use of multiple patterns in unison.

It sounds like you're treating patterns as some kind of magical holy grail (which often happens to inexperienced programmers who come across patterns for the first time). If you get too hung up on them you'll end up with an over engineered mess and never actually make anything worthwhile.

[Dries]

I'm a Java Developer as profession and work daily in Eclipse with frameworks like spring/hibernate/struts/J2EE/EJB3/WS ...
These frameworks use patterns and we use patterns in our programs.

Before I start programming I want to create an architecture document of my game.
Coding it self is easy once that's oké.

I know that for rpg, rts or fps other mechanics/patterns are used for certain tasks.

That's why I'm looking for a source that explains game designing on an architectural level.

[Orangy Tang]

Before I start programming I want to create an architecture document of my game.
Coding it self is easy once that's oké.

Big Design Up Front doesn't work well for games (and it rarely works for any other type of programming unless you're doing braindead turn-the-crank CRUD apps).

Just whip up a quick prototype or follow a basic tutorial and go from there. That'll teach you the core update-render loop and set you up for everything else, then you can come back with useful questions we can answer in specifics rather than hand-wavy generalisms.

Games published by our own members! Check 'em out!

[JL235]

Big Design Up Front doesn't work well for games (and it rarely works for any other type of programming unless you're doing braindead turn-the-crank CRUD apps).

I disagree. I think good designing works best for apps where it's not straight forward. I mean, if it's straight forward then why bother designing what your planning to do?

I personally have had to write code to solve very complex problems, and managed to avoid hours of coding by sitting down with Word and typing out all the solutions I could make, weighing up pros and cons, and creating diagrams to help explain those solutions. It helped me to find pitfalls early, and so avoid refactoring (or worse when you end up repeatedly refactoring back and forth between multiple solutions). Even if prototyping works better for you, the fact is that designing also works very well for many people and teams around the world. Although just like you can write bad code, you can also make bad designs.

[Riven]

I disagree. I think good designing works best for apps where it's not straight forward. I mean, if it's straight forward then why bother designing what your planning to do?

I personally have had to write code to solve very complex problems, and managed to avoid hours of coding by sitting down with Word and typing out all the solutions I could make, weighing up pros and cons, and creating diagrams to help explain those solutions. It helped me to find pitfalls early, and so avoid refactoring (or worse when you end up repeatedly refactoring back and forth between multiple solutions). Even if prototyping works better for you, the fact is that designing also works very well for many people and teams around the world. Although just like you can write bad code, you can also make bad designs.

I'm quite certain just about everybody these days realizes how bad 'waterfall' is. Even at college they teach not to, and that's telling, as education normally lags 10 years behind the best ideas.

[Orangy Tang]

I disagree. I think good designing works best for apps where it's not straight forward. I mean, if it's straight forward then why bother designing what your planning to do?

That argument works both ways - if it's not straight forward, what makes you think you can come up with perfectly formed design out of your head with no practical feedback?

Extremes of anything are rarely a good idea, and Big Design Up Front / waterfall represents one extreme. Hacking away at code with no thought represents the other. Iterative design/code/test/refactor is the middle ground which is actually practical and delivers results (with greater or lesser amounts of design on each cycle depending on how experienced you are with the problem domain).

The inital post ("i'm new to games programming, tell me what patterns to use") is firmly in the BDUP extreme, and the author's stated experience (big "enterprisey" frameworks) strongly hints at a mindset where architecture is all-knowing and all-powerful, and should be applied regardless of suitability to the task at hand. That kind of thinking leads to something like Jade (10+ years in development, hundreds of classes, lots of abstract factories and interfaces and adapters, and still nothing that even resembles a release or a playable game).

[JL235]

I'm quite certain just about everybody these days realizes how bad 'waterfall' is. Even at college they teach not to, and that's telling, as education normally lags 10 years behind the best ideas.

I'm not saying everyone should use it, but I've been a part of teams where the Waterfall model has been used successfully.

That argument works both ways - if it's not straight forward, what makes you think you can come up with perfectly formed design out of your head with no practical feedback?

Sometimes you miss large issues just sitting down and coding, until it's really far in. Then you either need to live with a bad design or go back and re-write large sections. Designing first can potentially allow you to highlight those issues and get them solved, earlier. But only potentially.

To help answer the original question, I'm in the mindset that lots of existing technology and design patterns can be applied to games. So I'd recommend just buying a copy of Design Patterns. I personally have applied some of the patterns taught in that book in my own games. For example I often use a Singleton for handling music and sound effects.

Architecture wise; I only have links about multi-threaded architectures. There is a brief overview of three different designs on Gamasutra, another mult-threaded engine on Intel and some slides about Id Tech 5 where towards the end they talk about how they structured their multi-threaded code.

[Dries]

Tx for the links and tip JL235 and next to me I have the Head First : Design Patterns book.

It seems that there is not a really good source, except for the book that Tom has posted.
So I'll have to refactor a bit more while coding :-)