Game design patterns, any pointers?

[Breakfast]

People are reluctant to apply Software Engineering practices to video game development. When I see video game project, I rarely see any UML or architectural documents.

In the real world a whole lot of stuff gets written without any UML or architecture documents, but I follow your point. I suspect if you look behind the scenes at somewhere like EA you would find a whole load of documentation that produces the solid and predictable sequels that all EA fans have come to know and love.

The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says "hey check out this neat effect I've just found how to do" but it's not in the architecture document or given it's own corner of the UML then it's out, regardless of how much it would add. In games writing more than pretty much any other area of software development you need a bit of room for sponteneity and that is something that Architecture-first development doesn't allow for. My experience is that it's actually too rigid for any non-trivial development task, but I have never worked for a Fortune 100 software company and it probably works great for them.  My view would be that a more Agile approach would be better suited to game development, but then I've never worked for one of the major game development houses either so I have no idea whether or not that is what they are doing, that's just what my programming experience suggests. I can imagine that a comprehensive test suite that you could apply on lots of different hardware and OS combinations would be a big help with the basic QA stuff so your testing team could work on the more sophisticated things.

[K.I.L.E.R]

Here's a tip, never do this:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21

/**     * Adds a rule     *     * @param rule     */    public void add(Rule rule)    {       int divisor = rule.ruleNumber % 2; //ruleNumber is final             if (rule == null) {          return;       }       else if (divisor == 0) {          maxEvenNumbers++;          super.addSibling(rule);       }       else {          maxOddNumbers++;          super.addChild(rule);       }    }

[purpleguitar]

The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says "hey check out this neat effect I've just found how to do" but it's not in the architecture document or given it's own corner of the UML then it's out, regardless of how much it would add.

For what it's worth, my limited experience shows that wise application of design patterns yields architectures that are more adaptable to change.  After all, this is one of the major goals of patterns, and reusable code promotes agility.  I think you're looking at two different issues: the application of patterns early in the design process vs. laying down an immutable architecture during the design process.

@lukemasters: I'm curious about your experience.  I observed the same phenomona (lack of good software engineering practices) through a survey of books on game programming, but I do not have much exposure to the commercial development world aside from books.

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

[lukemasters]

I'm no game development guru or software development guru. Nor do I have tons of years of experience in gaming. I'm also aware that companies like EA and Ubi might not used architecture or UML document.

But it's not because they don't do it, that we should not. I also am fully aware that a waterfall approach (Architecture-first development) is not adequate for games and software development projects to.

If my project works out, I want to promote an Iterative approach that put the emphasis on an evolutive design, architecture and patterns.
As for agile development, you must remember that Agile does not mean no design. On the contrary if an agile project is done they way it should be done, there should be UML and Architecture documents.

One of the main pitfalls to avoid is developing huge architecture documents. In my opinion architecture documents should be short and sweet.

[Mr_Light]

UML and architectural documents are traditionally about communication.
over the years it has found it's way into the process.

it's diffuculd to express but the short sum of it is that design or documentation has little to do with processes as waterfall agile and that whole pile.

if design is written down or not doesn't mean there's no design anypiece of code is written by some design sure the perspective level and amount of overview differs, but design is there.

documentation is always there from a list of machine code to highlevel  programming language to skeches on a paper. it all discribes the program and is thus documentation for human beeings not or hardly interpaterable doesn't matter it is documentation(yes sure is (piss) poor documentation).

Working togetter is hard no matter what the common consensus is. Esp. in area's without references, such as cutting edge and creative processes.

In the real world a whole lot of stuff gets written without any UML or architecture documents, but I follow your point.

heh, those must be doing the projects who bring the stats down in one of those carts of standardish group.

1   2   3   4   5

int divisor = rule.ruleNumber % 2; //ruleNumber is final             if (rule == null) {          return;       }

because your accessing an object and then you check for null?

The problem with that is that if you have your plan and your UML doc and everything else and one of your engine guys comes in and says "hey check out this neat effect I've just found how to do" but it's not in the architecture document or given it's own corner of the UML then it's out, regardless of how much it would add.

the problem is in your decision making not in your uml part. next to that your achitecture probely isn't an good achitecture to begin with, it's should guide the program allow parts to work togetter and allowing parts to work if it restricts you from adding or using parts then your "achitecture" goes against everything it's suppose to stand for.

[Breakfast]

the problem is in your decision making not in your uml part. next to that your achitecture probely isn't an good achitecture to begin with, it's should guide the program allow parts to work togetter and allowing parts to work if it restricts you from adding or using parts then your "achitecture" goes against everything it's suppose to stand for.

Look into how games are written by the big companies. They put together a design document, give it to the development house and expect it to be matched exactly. That may not be how we want to imagine it works, but it is how it does work for the majority of professional game developers; here's the document, here is your deadline; build it in time for the Christmas market. No leeway, no room for experimentation. One of the main reasons that when EA bought up Bullfrog a few years back (they were based just round the corner from me) pretty much all the Bullfrog developers, who had been used to a more creative environment, quit within a few months.

[Mr_Light]

EA is wrong on so many levels  lets not start that subject.

A design document is not an achitectural document, thats more a manual or specification as to how your program should be put togetter. a software design document may comtain a chaper or probebly should contain a chapter on architecture but that describes how it fits in one, and usually that one is predefined in the achitectual documentation. We might have had a glitch in our communication there.

that a design document is Law and absolute, well there is nothing against that imo. Thats perfectly fine as it's your nexus or medium for communication between programmers requirements engineers and the likes. If some programmer wants todo something differendly then the document should be changed and then he can follow up. This is the way it should go cause other programmer will be basing there parts on the document and you might get problems glue stuff togetter. Where the problem is that 'the creative programmer' in question is unable to change the document. Which can be because the process is wrong or that the process is based around that programmers don't profide input. Although I'm pritty sure against the latter it can be justified depending on your view, but this is turns into policial mombo-jumbo quite quickly.

In games technical changes often also lead to changes outside technical consideration/implementations so it also has to go around another document(which everyone seems to name differendly)

anyways these process usually get slow esp in big(er) companies and is what the agile movement is out to cut down on. Some are not as transparent to apply in game development I gues as your typical user or usergroups even are difficuld to indentify. And theres the whole the-consumer-doesn't-know-what-he-want-till-he-has-it part. Figuring out what the user want before he knows it probebly makes making games exciting.

[K.I.L.E.R]

It is pretty stupid of me eh? 

because your accessing an object and then you check for null?

[Mr_Light]

will you trust me wenn I say that thats nothing? 

[blahblahblahh]

Look into how games are written by the big companies. They put together a design document, give it to the development house and expect it to be matched exactly. That may not be how we want to imagine it works, but it is how it does work for the majority of professional game developers; here's the document, here is your deadline; build it in time for the Christmas market. No leeway, no room for experimentation.

Huh? Not in the companies I've worked at. The developer writes teh design doc themselves, that's what all those designers are on the payroll for .

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

[Eliwood]

I think he means a requirements document which spells out all the features and functionality they want, not a technical document.

[Breakfast]

Almost certainly what I meant. Every organisation I have ever dealt with seems to have a different set of names for the major documents that the development process is built around.