Quote:

Original post by The C modest god How do you design a game?

Unfortunately for you, you're largely getting the answer to that first question you've asked from everyone; you typically design a game using such techniques as Design Documents and Storyboards.

What you seem to actually be interested in is the software implementation side of things - which is not typically what people will think of when they see "game design", and probably isn't best suited to this particular forum. In this area, yes, UML could be useful. I don't use it myself and therefore can't provide you with any examples, but I can suggest that you might get a better response in the Software Engineering forum.

UML can be great when you're designing how the code will work, but probably isn't all that useful with actual gameplay.

I thought desing also include the designing of the actuall software and not only the initial concept of the software.
For example design patterns refer to implementation designing.
But you are correct, this thread is more suitable to the software engineering forum.

Sure, it's just that most people will assume you're referring to the gameplay/level/setting design rather than the software implementation in this particular forum.

Quote:

Original post by The C modest god winterdyne, I am afraid you havnt learned how to use UML...

That's an assumption on your part. Never assume - verify or approximate, but do not assume. The classic three stages of documentation arise as the *easiest* way of incrementally taking a project from concept to implementation. I mentioned UML arises in the late technical documentation stage - at this point there are precise rules and datasets in use. Subsets or aggregations of these may have been used earlier (and UML (and a decent CASE tool) can help identify these), indeed some use cases may be explored at the functional stage, but it's VERY unlikely that a complete chain of dependencies will be discovered until the functional documentation is almost complete. It's also a point of fact that documentation isn't complete before moving on to the next stage - portions of a technical document may well be complete well before certain stages of the concept - for example going for a cel-shaded look will imply certain features be required in the engine. In this case the documentation set for the engine would have a cel-shader feature added.

In my experience, getting a fully developed concept from the client has *never* happened. It didn't with GW for Warhammer (and they've been developing that for over 20 years), and it hasn't in my consultancy since then. We get a few requirements 'um, guys, we want it to *feel* like warhammer', but this is pretty much as far as I've seen things go. There's often a lot of room to move in the concept a client gives you. There has to be a lot of communication to get something that the developer feels will work, and the client is happy with.

Stating that the concept stage isn't a part of the development process is like saying being conceived isn't part of your life cycle. All those drunken meetings in the pub to discuss the numerous evil ways of disposing of adventurers are an essential part of starting a project. Having the development team itself involved at this stage results in a more enthusiastic, dedicated team.

Completing all design before starting to code isn't going to happen. Completing the *documentation* isn't going to happen, especially when you bear in mind revisional documents late the life of an engine.

Re-reading my post, I realise that one important point wasn't made clear - documentation exists *separately* for each feature and major system, as well as an overall document for the project as a whole. Each document may reference at some point the same UML model to specify interfaces, but each system is documented (and effectively developed) as individual components.

I wholeheartedly agree that diagrams are an essential part of the design and documentation process, but I have to point out that most non-programmer designers are neither used to a system like UML, nor particularly interested in learning it. Having a strict method of communication (like UML) is only ever going to be useful if people can and will adhere to it. I've seen more (actually good quality) psuedo code come out of designers than UML. Similarly, the design team on a large project usually have a good amount of input *post-production*, so having them able to understand documentation is a requirement. Text documentation *has* to accompany diagrams.

The 'development life cycle' you hear about at university is very different in the real world. Shockingly so. Documentation that implies implementation (such as UML initiate cases) is so often invalid or poorly maintained against the actual implementation as to be almost worthless. Less rigid documentation that explains the purpose to the implementation (the functional documentation) often sheds much more light and proves more useful in an implementation task. Appropriate technical information detailing what was done is created afterwards.

UML is a lot like hungarian notation (in the late 90's) in my opinion, it's exceedingly useful (in its place) but it has a tendency to be over-used and wielded club-like by its evangelists.

I don't think you want to start implying that using UML *will* result in a better product - it can help, but it's certainly not the only, or necessarily the best, tool for the job.

In my experience, following a text-description of a gameplay mechanic with a graphical diagram expressing the same as the text did, often makes it easier to understand what the text tried to convey.

I seriously doubt I'd ever go to the stage of setting up diagrams for classes, use-cases, sequences, collaborations, statecharts, activities, components, deployments, etc; especially not so if following an iterative lifecycle with increments, where you upgrade all the documentation at each iteration. It sounds counter productive to me.

As winterdyne said, some programmers might prefer to set up class diagrams and the like for technical documentation, but this could be done at the programmers’ own leisure.

The important thing when writing the design for a game is to convey it's content as clearly and logically as possible. I think using diagrams following text descriptions of a gameplay mechanic helps the reader understand what he is reading, but one has to draw the line between what becomes productive design, and what becomes counter-productive design.

Ok.
So I didnt uderstand what is the role of the documents you talked about, or you stated several roles to the documents.
Some documentation is of course very useful, such as comments in the code, stating who made this method, what it does and things like that.
Or a catalog of all the art work in the software.
I didnt refer to those kind of documents, I refered to specificly analysis and design tools. The stages before coding.
But what are all the roles of the documents you refer to? and in what stage of the developement does these documents belong?
About the evolutional model of a software, not all the cycles of a software produce equal amount of product from every type.
The first cycles will produce less code and more documentation and diagrams for instance.
Its not symmetric.
I dont think every text documentation is self explnatory. What is worse, things can be understood completly different by two different people from the same document. Especially when you dont have a standard form.
Also, a non standarized text document may be not compatible for maintaining. Its like writing a software, if you use the same explicit number 3.14 instead of a constant M_PI in your software it may be very hard to maintain aftwerwards.
You can make the same types of mistakes in a text document, and it becomes worse becuase you use the english language which does not bound you, as opposed for a programming language for instance or a UML diagram.

Code commenting is NOT documentation. Doxygen etc are useful in building code reference, but they're no use at all when planning or evaluating something. It's not what they're for - code commenting (and comment-generated documentation) is a maintenance and integration asset. Yeah, it's useful if you haven't looked at your codebase in weeks and you're just starting off again but it doesn't give you the 'big picture' that you sometimes need.

The thing you have to remember about your design documentation is that it ISN'T (and really cannot be) limited to one stage of development. It's constantly in use, being referred to or having details modified (especially in technical documents) (whilst the particular feature it's related to is involved in development), almost right the way up to release.

I've mentioned that a set of documentation exists for most major features of a game (assuming a somewhat more complex game than pong). Concept documents are answers to 'what is it?' questions. Functional documents are 'what does it do?', and technical documents are 'how does it do it?'. It pretty much is as simple as that. Additional documents are drafted as required - ('hmm, we need an economic system') and basic concept documents are drafted detailing as many major subfeatures are are wanted or required. These subfeatures in turn can generate additional documents. It isn't required that *every* feature has precisely one concept, one functional and one technical document. This is simply anal, and counter-productive.

You have a point in mentioning constants - and this is another reason for the segregation of technicality from concept - 'a deep space game with newtonian physics' is that whether we use a double precision coordinate system based on a single origin, or a floating origin system and floats. The mathematical model behind it is (for most intents) a technical issue, and has little or no bearing on the actual function of the game. What if we want to implement the game in a non-typed language? The technical documentation may need to be revised, but the functional docs should be fine as they are, acting as a layer of abstraction between the concept and the implementation level documents.

I'm trying to get across that assuming your development will follow a cleanly defined cyclical pattern is not a great idea - people don't work that way - writers have creative spurts then block for a while, coders have off days, etc. A pattern of task and dependencies is usually used in the production lifetime - with many people working on quite different tasks. Everyone is saying the same thing - just text is not enough - there WILL be diagrams, sketches, the occasional flowchart - anything to make sure that nothing is ambiguous or misunderstood. If everyone's familiar and comfortable with UML, use it! But you can bet they're not.

I know it all seems a bit vague (and to some extent it is), so to take the life cycle as you describe it:

1) Requirements - this is the initial generation of concept documents for the overall project / game. Some important subsystems will have concept documents written for them.

2) Analysis - taking the concepts will give choices of function - skill or class based RPGs actually *operate* in very different ways, regardless of how the classes and entities are modelled. All this is described in functional documents.

3) Design - First draft functionals are given to the code team, who draft first draft technicals, most likely in conjunction with testbed R&D code work. Feedback from these is used to draft 'working' functional documents. These are evolutionary, and will represent the 'current' thoughts on how the concepts should work.

4) Implementation - Working functional documents are used by the code team, along with first draft technicals and any other relevant research results to draft a 'working' technical document. This details *precisely* how things work, not necessarily down to types (especially if such types are the responsibility of an overall model elsewhere). Production code is started.

5) Integration - By now the production code is coming on well, and there are 'firm' technical and functional documents. Firm documents are mature and don't change much. These assist in the integration of separate systems both from an abstract sense (by observing the cross references in the functional document) and in a technical sense (by implementing the interfaces suggested in the technical documents).

6) Deployment - Hah, think you're done? No - you've just hit alpha. Time to test it and see if you can break it. Then beta, where you get more people to do the same. Round about now, your client'll come along and say they've changed their mind about the style of the game...

Quote:

Has anyone yet made UML applications that have hyphertext like abilities to assist with the hierarchical traversals (and maybe multi-screen or multiple computer links to drive multiple screens to increase the visual area) ???

I haven't used it, but I was under the impression that Visio did that.

@OP - Listen to Winterdyne, he has given a very accurate representation of the game/technical design process. It is not all UML and strict flowcharts.

There was definitely a CASE tool in use at my uni (back in 95 ish) that allowed hierarchical and duplicate entity relationships (divide and conquer) visualisation for SSADM, so I can't really see any reason a similar package couldn't be designed around the UML standard. I'd be very dubious about using CASE tools to develop (code) class hierarchies for a game project though - too often the precise specification doesn't get finalised till very late, so there's a good chance of the package throwing in something that can break a required interface. Without a package that actually integrates into the IDE you're using this could be more hassle than it's worth.

In my opinion, it's this lack of firm specification that is responsible for much of the 'difficulty' associated with large projects (especially games). Often (in industry) there is pressure to have functional code up and running very early in the development process (for publisher milestones, marketing) which leaves the developer no time to develop a proper model that correctly produces the required behaviour. Instead, we're often left with prototype products that somehow have to be cobbled into a saleable product.

Yes, this is bad practice for complex project development. Yes, this sucks as far as software architecture and engineering are concerned. Unfortunately this is a direct result of developers in general trying to hit a relatively fluid market. At the end of the day we're producing disposable, 'consumable', (and if you consider technology) 'perishable' products. As independent developers, we have more flexibility in how we approach our projects, which can give us more of an opportunity to actually *apply* proper software engineering methods.

Quote:

Original post by Anonymous Poster Quote: Original post by LorenzoGatti [...] For example, suppose you make an object oriented Pacman clone. How would you describe, in UML, critical features like the movement strategies of the four ghosts or the timing of Pacman and ghost movements? How could a clever card castle of OCL, annotations and contrived classes be more readable, useful and easy to produce than a simple text document with explanations and tables of figures? Ok, how would I make a pacman use case. I think I will have two actors: pacman and ghost. The use cases would be: * Move character That would be connected both to pacman and ghost actors. * Eat pacman That would be connected both to pacman and ghost and will include mpve character * Select direction That would be connected both to pacman and ghost * Eat super dot * Eat dot and etc... Class diagram: * Pacman Connected to controler * Ghost Connceted to controler * Maze Connnected to controler * Controller Connceted to Maze, Pacman, Ghost. What do you think of this design? Its also a simple way to convey an idea

Your sketch, while not at all wrong, is almost devoid of information yet near the ceiling of reasonable UML usage, confirming my previously stated opinion; it is a not quite simple way to convey no useful idea.

I think casting Pacman and the ghosts as use case actors is rather contrived. Maybe a state diagram for each of the five characters could better describe what they do and offer assurance that the rules are complete.

The two important elements I mentioned are neglected: movement speed and timing is completely left out and ghost AI is removed to the "Controller", not described.
What you describe are instead the game entities and basic mechanics that can be more easily expressed in words and diagrams of the playfield.

Note also that classes "Pacman","Ghost" and "Maze" (and the implied "Dot", "Large Dot" and possibly others) belong to the abstraction level of game rules, while "Controller" belongs to the lower level of game implementation. Which of the two levels are you describing?