Sign in to follow this  

Designing a game

This topic is 4188 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How do you design a game? I am learning UML, but it seems that UML doesnt fit to describe a game? What sort of UseCases I will have? Perhaps if we take some commercial game is an example and maybe you can explain how would you write the requirements, analasys and design of this game then I and many others will benefit from this? So lets take a look at the game battlefield 1942. How would you write the UML diagrams of this game? Thanks in advance

Share this post


Link to post
Share on other sites
if you want to learn how to to this id recomend making a game from start to finish by yourself,
it dosent have to be a big game and you can use something like gamemaker but game design is such a broad area in my mind the best way is to just experiance for yourself what it takes to go from idea to game

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
How do you design a game?
I am learning UML, but it seems that UML doesnt fit to describe a game?


I'm an old-school proponent of the GDD. You can find templates here on GameDev, and I have one on my website too (FAQ 2).

http://www.sloperama.com/advice/specs.htm
http://www.gamedev.net/reference/list.asp?categoryid=23#21
http://www.gamasutra.com/features/19970912/design_doc.htm

Good luck, The.
Tom

Share this post


Link to post
Share on other sites
When I was growing up, before I had gained the ability to really create the ideas in my head, I wrote pages and pages of game design documents. The best way to design in my opinion, is to pick the best model of recording how you think. If you are working with a team, you will need to adjust that model to a way that other members on the team can understand it. UML really doesn't work that well in my experience for anything except class diagrams. If you are list oriented, you can make a lot of lists. If you are a visual sort of person, draw maps and visual diagrams. If you are wordy you can write paragraphs. Using a template is nice to know what kinds of things to keep in mind, but you should format it in a way that can help you think the best.

Since I have gotten into programming, I haven't done much designing, other than fairly general things or fleshing out a system that needs some detail work, as I have found if I do too much top-down design I find out later that some things just dont work in the game as I thought they would, and I have to backtrack a lot. Sometimes its really hard to think around a problem when I have already done extensive design work on it, its harder to get the old idea out of my head if it's been put to the page. So i do a lot of designing in my head, and then I prototype it, and if it fails its out of my head instantly :)

Share this post


Link to post
Share on other sites
I just wanted to see some UML diagrams.
UML diagrams are a standard that every person who have learned UML can understand in some level.
Also, a diagram is usually more comprehensible then some 100 pages text document.
Maybe I was missing something, but I didnt see any UML design techniques used in the links you gave me. Maybe just for the requirements.
I don't want to read how someone have invented a specific method to design a game, I just wanted to see some UML diagrams for games or graphic engines.
Or do you claim that UML is not currently the best method to design a software and that some one else has inveted a better way to do it?

Share this post


Link to post
Share on other sites
UML Tutorial: http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/what_is_uml.htm

Webpage about UML diagrams: http://bdn.borland.com/article/0,1410,31863,00.html

Diagrams: http://www.agilemodeling.com/essays/umlDiagrams.htm

How did I find all these? I don't know UML. I typed "UML diagram" into Google.

Share this post


Link to post
Share on other sites
UML is really just a way to visualize a design - it's not a design method itself. Besides, those diagrams change on a regular base when the code itself is written.

A better approach would be to get experience writing games, because that really gives you the insight you need when designing a game. Without such experience, UML is pretty useless, I'd say. You won't understand why a designer made a specific decision by simply looking at the diagram only, you would have to know the real-life implications of the design.

Share this post


Link to post
Share on other sites
I think the aspects of a videogame that are fit to be described in UML diagrams are boring and not very interesting or important: the use cases are very simple combinations of obvious commands like new game, save, load, quit, edit options and the like; state and interaction diagrams can describe simple game loops and network protocols; class and object diagrams are mostly irrelevant to the low level performance and algorithmic problems, and weakly connected to game rules.
Developing some UML diagrams can be useful for developer orientation documents or as an aid for the design of specific complex mechanisms, but most game code is much more sophisticated than UML diagrams of reasonable complexity.
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?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by ellis1138
UML Tutorial: http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/what_is_uml.htm

Webpage about UML diagrams: http://bdn.borland.com/article/0,1410,31863,00.html

Diagrams: http://www.agilemodeling.com/essays/umlDiagrams.htm

How did I find all these? I don't know UML. I typed "UML diagram" into Google.


Apparently you havnt read what I wrote.
I know UML, I just wanted to see an example of a game in UML diagrams.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by LorenzoGatti
I think the aspects of a videogame that are fit to be described in UML diagrams are boring and not very interesting or important: the use cases are very simple combinations of obvious commands like new game, save, load, quit, edit options and the like; state and interaction diagrams can describe simple game loops and network protocols; class and object diagrams are mostly irrelevant to the low level performance and algorithmic problems, and weakly connected to game rules.
Developing some UML diagrams can be useful for developer orientation documents or as an aid for the design of specific complex mechanisms, but most game code is much more sophisticated than UML diagrams of reasonable complexity.
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




Share this post


Link to post
Share on other sites
UML is a useful *tool* in game design.

It isn't a method *for* game design.

This is an important distinction. Diving straight in to UML before your concept is ready is daft, and unproductive. UML works as a tool at the late technical design document stage - ie to illustrate behaviour of entities to the programmers responsible for turning them into working objects in code.

Typically, there are three 'classic' stages of design documentation, for each and every major feature in the game - for example an economic subsystem, combat resolution, UI 'contexts' (menu 'screens' to 'huds') etc. These are often developed simultaneously, with advances in one document having an effect on others as interfaces between the systems are developed.

The three stages are concept, functional, and technical design. Sometimes you'll hear of revisional documents - these are things altered after the systems are 'done', usually as a result of beta testing or public feedback for a patch. These are important if your product is intended to have a long shelf life or maintenance period - people joining the project at these stages will need to know what if anything has changed from the bulk of the design documentation (which will all be cross-referenced and indexed, won't it?).

So what's in each of these?

Your concept document is effectively a brief pitch for why the subject of the document should be included in the game. I wouldn't expect one of these to run much past three or four pages of text. They explain the purpose of the feature, why it's fun, provide a concept of how it should work in gameplay and so on, including whether it is *intended* to have a major effect on other systems. These often help in deciding which features to include, or cut out as development progresses. There will also be an additional concept document drafted for the whole game, which will refer to the individual feature concepts. Think of these as a 'what and why' document - they say what features there are, but don't go into any great detail as to how the systems function.

The functional document is very much of 'what exactly' to the vagueness of a concept. These explain exactly how the feature is intended to work - down to what options will be on the menus, how events spread through the game world and so on. The functional document should NOT approach code, but some 'technical' work (such as entity normalisation) is done. These documents are used to communicate the design departments intent to the programming department. They have to be detailed, precise and non-contradictory. You could think of these as 'on paper' rules for your game.

When the functional document hits the code design team (where implementation is done) the lead programmer will assign functional documents to code team members to draft technical documents. These are the 'implementation' plans, and will usually include entity normalisation, some kind of formal behaviour specification (UML / SSADM / Z) for the code team to work from. These are 'how' documents, and explain how the functional specification is to be implemented, together with reasons for choices made. It is the responsibility of the lead programmer to ensure that technical documents required exist.

Wow, sounds like a lot of work! And it is. That said in my opinion, it's the second stage (functional design) that is the keystone of the design process. A *good* designer here can come up with a functional spec that reads to a layperson like a concept, and to the code team as a non-contradictory (important to remember) technical spec. The key is not what modelling method you use (UML is the current favorite) but that your design at the end of the day is clear, non-contradictory, and logical.

Looking at a UML diagram doesn't give an idea of gameplay. Especially of a whole game. You'd go mad trying to follow it. Well structured english is as good a medium as any. Simple diagrams are great - if required, but there's no need to draw a picture of every dialog box in your game. You *do* need to state what goes on each though.

Ok, now how many of these documents do you need? This is a question only you can answer. BF1942 is far too complex an example. Lets use Pong.

First, an overall concept document - this explains what Pong is, and how to play it. We won't need any further concepts. For the sake of argument, we want to make a visually appealing pong, so the background of the game will be various interesting 3D scenes.

Next, a functional document - this explains how the players move their paddles, how the ball moves, how it bounces off the walls, how goals are scored, how long a game lasts and so on. It shouldn't (classically) mention screen position, size etc, or any other implementation level detail. The mathematics behind the bounce ARE a functional detail, and so should be included here. They would be the same regardless of the technology used to implement the game.

Finally, the technical document. Here we assign sizes to the paddles, ball and screen. We specify the information each bat requires, whether they are types of a 'pong entity', what that requires, how collisions are detected and handled and so on. Perhaps all the entities are in 3D, and the pong game as per the functional document is played on a single plane, in order to meet the visual criteria set in the concept document. Perhaps we're using alpha blended sprites over a pre-rendered image.

This is a bit of overkill for a Pong clone, but if you were to sit down and write each of these documents as an exercise, and actually think about how each feature is to be implemented, full documentation (including entity modelling at the technical stage) will run to (I'd guess) around 50 pages of text. For a Pong clone.

Bear in mind most games are built around *engines*. Engines are long term, high commitment projects, and involve the bulk of the technical design and implementation work. The thing to remember (other than non-contradiction) is that you can reference other documents - you shouldn't need to define what a 3D entity is if Ogre (for example) already has one - your technical documentation becomes much smaller when it's referencing something else. This of course does mean that you'll need to keep the documentation consistent - ie make sure its for whatever version of the engine you're using, and that if you do upgrade the engine mid-development that any changes to it are compatible with your technical design.

Note that so far this is assuming a pure software design. This simply is never the case for games. Art and audio both have their own design stages as well.

The art side mirrors the code documentation fairly closely. The lead artist is responsible for the creation of a style guide based on the overall concept document. This will have a LOT of pictures in it, not all original, but indicative of the 'feel' of the game. Some may be specially commissioned for the purposes of the style guide, and some may be 'borrowed' from films etc. The style guide usually also includes information on what is considered feasible for the game being developed, in the opinion of the lead programmer - this is used to approximate poly count limits, texture sizes etc, and boils down to educated guesswork.

The style guide is referred to by concept artists working on producing anatomical sketches (where joints are, as well as details) of items and entities to be 'properly' modelled later on. These are then passed on to the art team who perform the final modelling, texturing and animation duties. It is usual for a different artist to perform each of these steps. The concept sketch stage is quite often omitted if there's easy reference material available or the objects are very well known. I can't think of any studios which would require concept sketches for a wooden crate.

Audio design is often sadly neglected. Stock tunes are often used with no thought for the environments or situations they need to portray. Depending on the concept and functional documents of the game there may be a need for leitmotif (thematic) work for characters, in which case the composers will usually appreciate concept art of the character they're writing around to get a feel for them. Often the art style guide is also helpful in getting an overall feel for the game world, so that music can be written to complement it.

For games though, audio is usually the most expensive resource (in terms of file size for distribution, unless using midi). As such it is reused wherever possible, and so tends to be dictated by approximate situation ('combat', 'woodland') rather than precise situation. There have been attempts to make systems that 'improvise' music, but these usually sounded worse than cross-mixed tracks. Designing the audio for a game is mostly a case of identifying situations that are important in the game, and providing the composer with the necessary information to imagine that situation (and the music for it). Getting the audio right can make your game a lot more immersive and enjoyable. Getting it badly wrong can make your game simply irritating.

That covers the bases I can think of right now. I hope this helps!

Share this post


Link to post
Share on other sites
winterdyne, I am afraid you havnt learned how to use UML.
UML may refer to the diagrams, but you dont use UML as some bunch of diagrams to help you in the desgin process.
People have already thought about how you should develope a software starting from the need of the client and ending at the death of the software or becoming abandon.
A software is an evolotional entity. That means that the software has life cycles, each cycle you get some products. And each cycle your software becomes bigger and better.
Until 1990 it was accepted to complete all the design of the software before starting to code it, but although thwy thought about it like this, what really happend was that their software was developed evolutional but in a bad way.
So briefly, how a software can be developed?
The initial documentation you talk about, the concept documentation. Is not directly part of the developement process. It is something given to you by the client, from this you will create your requirements documentation.
In each cycle you use UML and documentation to do the following:
1)Requirements
2)Analysis
3)Design
4)Implementation
5)Integration
6)Deploynment

So each cycle you get new and improved documents, UML diagrams and applications.
Text documents are required, such as in the requirements phase.
However, the conecpt is to trying to have as less text documents and as more diagrams instead.
Becuase Diagrams have a standard, text document dont.
If you can express the same idea with diagrams and text document, but the language of the diagrams is narrower then english, then it is better to use a diagram.
Graphical presentation is usually easier to percept then text presentation, as long as the two express exactly the same concept with the same amount of details in them.
Would it be easy for you to understand this?
A connected to B
C connected to B
D connected to C
A connected to D

Can you see a circle here or not?

Using diagrams and documentation for a big long term project is the way to go.
Using it the way people already thought it should be used and not reinveting the wheel is also the way to go.
It is true that some companies can create software without any of these methods, but their product will be of lower quality and will require double effort to maintain.
Think of it as programming in C++ instead of in C.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.


Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...


Share this post


Link to post
Share on other sites
Guest Anonymous Poster
One thing that strikes me is that for anything complex the diagramming becomes unwieldy as a visualization method. Our computer screens are just too small (cant see enough at once) and methods of traversing/zooming complex diagrams is much too clumsy.

Extended paper sheets on the wall/floor/drafting table are still called for (and have their own problems). The 3D virtual interfaces seem to have fallen flat (eyestrain...). For small diagrams there is no problem, but games are often of the class of problems that can have very high complexity. Even with divide and conquer (hierarchical diagram sets) the flipping between contexts and inability to search/look quickly between multiple diagrams on the computer still is a fundamental problem.


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) ???

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Quote:
Original post by LorenzoGatti
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?

You are right, this was pretty bad.
I should have not put controller yet inside.
I didnt think about it too much.
I ment the AI of the ghost (and pacman!) to be inside the actor, i.e. it was not yet part of the system in this "diagram".
Thats because pacman and the ghost may be AI or a replay of a "recorded" game.
How would you describe pacman in text?

Share this post


Link to post
Share on other sites
I have asked my lecturer about real time systems, and he said that there is a version of UML that is more suitable to real time systems.
For example in the use case diagram you can put time as an actor.
However, I didnt inquire him too much for reference about Real time UML related material.
So do you know any concepts related to real time UML so I will know where to look for information about it. Or is there a name to real time UML design?

Share this post


Link to post
Share on other sites

This topic is 4188 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this