Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / Professional Game Design Methodologies

Author
Message
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 14th Jan 2006 15:22
Does anyone know of any industry standard game design methodologies? Aside from UML, which may or may not be used in OO platforms, does anyone know of something that game dev companies might use? Basically, I'm hitting the design phase of my dissertation (game dev project) now, and really need to take on a professional and documented approach if possible.

Any ideas?

Ian T
22
Years of Service
User Offline
Joined: 12th Sep 2002
Location: Around
Posted: 14th Jan 2006 15:27
The "go slow and steady and then freak the hell out and have crunch time for three months before the release date" method seems to be fairly popular

Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 14th Jan 2006 15:33
That's good, because I'm already well into that one!

adr
21
Years of Service
User Offline
Joined: 21st May 2003
Location: Job Centre
Posted: 14th Jan 2006 15:55 Edited at: 14th Jan 2006 15:57
Oddly enough, in my new job (hooray) we're discussing professional design methodologies. Unfortunately, they don't really apply to game design. I mean - can you really flesh out a "business case" document? The case is that you wanna make a game and it'll make money if it sells. Hmm.

There are two sides to what you're asking: The technical design, and the game design. I assume you wanna do both. For technical, only certain aspects of UML may fit - class diagrams may not be appropriate because DBPro isn't OO-based; you can't generalise or aggregate other DBPro "objects", but I guess there's no reason you can't just group a set of functions relating to the player and present it in a nice little picture. Another UML design tool that springs to mind is Use-Case documents - Unfortunately, they're very business process oriented: You write out each stage of the process you want to acheive, and at each point, if there's a possible deviation, you document that alternative route. Very intensive, but in theory, gets you thinking about every possibility.

As for game design documentation, it's what you'd expect. Every non-technical aspect needs to be documented: Storyline, Concepts, Target Demographic, Influences, Possible successes and failings of the game (i.e. ingenuity is a double edged sword)

This make any sense/use?


----------------------

You may wanna check out DSDM as a Design Methodolgy - it costs £600 to be a licensee so I'm just suggesting checking out the ideas. The main premise is that you can't hope to deliver everything on time for a project with moving goalposts, just the essentials. It promotes a modular, iterative approach.

[center]
iv tryed everything!!!!!!!!!! could u please just add The gun and shooting Code thats All!!!!!!!!!
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 14th Jan 2006 18:14
Hmm, you might have a point. Maybe I can take a bit from everything, including UML and just adapt it to my design. I'm gonna need a lot of sketches etc. for artwork design I suppose. Arghh .. I can't believe I have to think about my design methodology AS WELL as do the design!

Tinkergirl
21
Years of Service
User Offline
Joined: 1st Jul 2003
Location: United Kingdom
Posted: 14th Jan 2006 18:44
For what it's worth - agile methodology is gaining some followers. I know some companies use the 'Scrum' method. *shrugs* Whether it's any use to you, I don't know.
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 14th Jan 2006 18:48 Edited at: 14th Jan 2006 18:49
Cheers Tinks. All suggestions help, so I will definitely look into that. I just need to find some reliable (as far as unis consider it) sources for this sorta info, so books and whitepapers etc. Gonna venture down to the *shudders* library tomorrow. Will keep my eyes peeled.

adr
21
Years of Service
User Offline
Joined: 21st May 2003
Location: Job Centre
Posted: 14th Jan 2006 19:33 Edited at: 14th Jan 2006 19:40
DSDM is falls under the "new" agile development methods.

As well as SCRUM, there's eXtreme Programming and RUP.

Unfortunately, all these design methods assume you're conversing with a customer. You update them on your progress and they play an active part in the project's direction. That really isn't for you.

I believe the idea behind RUP/UP is that you identify modules, design and build them then when you've finished, compare the finished module to the original requirements. It's likely (especially in your situation) that the requirements will have changed by the time you finish developing a module, so you update all your design documents, analyses and then go back into implementation. These are called iterative design methods, for obvious reasons. Hopefully, the subsequent iterations don't require you to scrap the code. It needs to be modular such that you can then move onto the next chunk without your design choices from other modules having any great effect.

What'll really score you some marks is to mention MoSCoW timeboxing. You could carry out the iterations 4 or 5 times to get the module perfected. However, you'd have overrun by about 6 months. Set yourself a very strict time period in which to finish the iterative process for a particular module, say 2 weeks. If it isn't finished, roll back to your previous iteration and move on. The idea being that you have *something*, which may or may not fit the requirements.

The MoSCoW part comes from prioritising the elements of the requirements analysis which are most important, down to "probably not going to make it in". If you finish a module early, then you can perhaps implement the more desirable, but not essential features.

Like you suggested, take applicable parts from all methodologies and use them to your advantage. Wikipedia is surprisingly helpful in describing all the Agile Methods.

[center]
iv tryed everything!!!!!!!!!! could u please just add The gun and shooting Code thats All!!!!!!!!!
Tinkergirl
21
Years of Service
User Offline
Joined: 1st Jul 2003
Location: United Kingdom
Posted: 14th Jan 2006 22:45
Actually, in the Scrum method, you have to write "User Stories" - for example...

"Gerald is a level artist and will be working on the Volcano level. He requires a detailed description of the gameplay present in that level, and how it will affect any geometry decisions he might make."

Is a User Story for the task "Design the Volcano level design doc".

Your 'customer' in Scrum may not nessesarily be the end player - it can be people from the team, you in the future, your publisher, etc etc.

The only problem is - they're PHENOMENALLY dull to write up. *sighs* I use Scrum at my work (in game dev). It's alright. Going through teething problems, but it's better than the older system.
Dave J
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Feb 2003
Location: Secret Military Pub, Down Under
Posted: 15th Jan 2006 04:11
Quote: "Aside from UML, which may or may not be used in OO platforms"


UML is completely geered towards OO, I'm not even sure if it's relevant in a non-OO approach. Some of the main features of a UML diagram display inheritance, interfaces, abstract data types, and cardinality relationships. None of which are relevant in procedural programming, so I'm not sure how useful it would be if you're using DBP.

As far as other design techniques go, there are State Transition Diagrams. Personally, I've never been a fan and can't see much use for them (too slow to create them and they don't really display anything all that meaningful) but I know a few software companies swear by them. However, I doubt game devs would even consider using them because there are way too many different objects and transitions going on in a game.


"Computers are useless, they can only give you answers."
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 15th Jan 2006 12:25
Yeah, I had to reread my post then and rack my brains as to why I typed that sentence. I've been using UML for around 4 years, so I know it inside out. Must've been a major brain slip.

... however. I'm going to use a bit of it for my development. I dont see any problems with drawing up a class model to at least represent the different objects in the game, and how they'll related. I can show inheritance etc. even if I have to model it differently in DB.

Hmmm, gonna have to take a bit from all these ideas I think and put them together.

Dave J
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Feb 2003
Location: Secret Military Pub, Down Under
Posted: 15th Jan 2006 12:45
True, you can always use it to represent theoretical classes, and group methods yourself despite not being able to physically place them all within the confines of a class.


"Computers are useless, they can only give you answers."
Fallout
22
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 15th Jan 2006 15:15
Yeah, I mean in DB I have a very loose OO style implementation anyway. Every "class" has it's own source file and "methods". I used global variables to simulate properties. The only thing is, you have to obviously work with a lot of for loops instead of instances of objects. I'll end up with a particle source file, which has function called create, destroy, process, etc. It's not OO, but it's structured in a similar way. So I think the class model will port to the implementation to some degree.

Login to post a reply

Server time is: 2024-11-16 10:06:39
Your offset time is: 2024-11-16 10:06:39