by date
When your day job teaches you a lesson......
When your day job teaches you a lesson......
| Name: | Mark Berry |  |
|---|---|---|
| Date Posted: | Nov 17, 2006 | |
| Rating: |  Not Rated | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Mark Berry |
Blog post
Ok, so I'm specifying a software solution for a customer based on our in house solution, and deliver a preliminary software requirements specification which describes the solution. Customers happy, programmers happy so I'm happy.
Its a fairly simple addon, basically it allows tools to be tracked not only in the automated storage tower which is standard, but extends it to track the items to a CNC machine on the shop floor, and allows operators to switch tools between CNC machines. Simple. But takes a 45 page srs doc. Thats just the first stage of documentation, specifications comes next.
With the srs document, we all know what the system should work like, so we are all going in the same direction. Its written in what technical authors like to call 'natural language', so it avoids technical descriptions, ie no "We'll use a blah sorting algorithm to do x y and z". The technical doc next has loads of that.
It got me thinking about my own "design document" for the game I want to be working on, and just how inadequate it really is and how I really should know better.
How many game developers create a use case for their games, or scenarios describing play from the users perspective or indeed the monsters/aliens/space ships? Could anyone pick up your design doc and understand what its going to be like? Does it describe not only the intended mechanics, but how it should work from a players pov?
I guess its not an issue for a solo developer who can hold everything in his/her head, but if you are in a team, it could be a big issue.
Has anyone run into this kind of problem, where one person has one understanding of the project and another looks at it entirely differently, and how did it affect your project?
Looking at some of the design documents for games out there, my own included, they do a decent enough job of laying out what assets etc are needed, but skimp on the details like how the user is going to work though the play, interface etc.
I'd be especially interested in hearing from anyone who has hit this problem and reolved it by using the 'standard' way of documenting a project used by most in business type applications. Or are game developers different, and dont need that kind of project management?
Its a fairly simple addon, basically it allows tools to be tracked not only in the automated storage tower which is standard, but extends it to track the items to a CNC machine on the shop floor, and allows operators to switch tools between CNC machines. Simple. But takes a 45 page srs doc. Thats just the first stage of documentation, specifications comes next.
With the srs document, we all know what the system should work like, so we are all going in the same direction. Its written in what technical authors like to call 'natural language', so it avoids technical descriptions, ie no "We'll use a blah sorting algorithm to do x y and z". The technical doc next has loads of that.
It got me thinking about my own "design document" for the game I want to be working on, and just how inadequate it really is and how I really should know better.
How many game developers create a use case for their games, or scenarios describing play from the users perspective or indeed the monsters/aliens/space ships? Could anyone pick up your design doc and understand what its going to be like? Does it describe not only the intended mechanics, but how it should work from a players pov?
I guess its not an issue for a solo developer who can hold everything in his/her head, but if you are in a team, it could be a big issue.
Has anyone run into this kind of problem, where one person has one understanding of the project and another looks at it entirely differently, and how did it affect your project?
Looking at some of the design documents for games out there, my own included, they do a decent enough job of laying out what assets etc are needed, but skimp on the details like how the user is going to work though the play, interface etc.
I'd be especially interested in hearing from anyone who has hit this problem and reolved it by using the 'standard' way of documenting a project used by most in business type applications. Or are game developers different, and dont need that kind of project management?
Submit your own resources!| Tom Bentz (Nov 17, 2006 at 05:04 GMT) |
| Jeppie (Nov 17, 2006 at 05:24 GMT) |
| Thomas \"Man of Ice\" Lund (Nov 17, 2006 at 07:05 GMT) |
Can you spec out a complete design doc for a game? No - I dont think so anymore.
Can you write use case descriptions of a game? To a large degree I think so - it would definitely clear out a lot of issues in the menus (very business sw like anyways), the control interface and the overall mechanics.
I dont think you can design "fun" - or details.
But especially on a team it makes ppl move in the same direction instead of fumbling in the dark
| Tony Richards (Nov 17, 2006 at 14:48 GMT) |
Chapter 1.5 in MMGD - Describing Game Behavior with Use Cases by Matthew Walker @ NCSoft takes you through some great examples.
I'm incorporating a lot of his ideas into my current MMORPG game... the use cases are stored in a database and they're directly used by the game engine in conjunction with scripting... pre-conditions, post-conditions and the basic steps are script calls with optional parameters.
Although it might seem overkill, it's not. Without this, a huge game will eventually get outside of the scope of any small team, but with it a small team can easily create and maintain a huge game with hundreds of thousands of use cases... it's all about the organization.
| James Lupiani (Nov 21, 2006 at 21:42 GMT) |
So I guess my answer is: in my experience, they're a helpful tool when used in moderation.
You must be a member and be logged in to either append comments or rate this resource.
