Tough question.

UMLs are reeeaaaally good in teams. It helps to know exactly what sort of interfaces you will have ahead of time. And how data will flow around the program.

I personally do a lot of planning, and make use of UML of all forms religiously for larger projects.

It also helps you find certain architectural problems before you code. Diamonds of death is something you probably want to avoid. And having too many redundant classes with the same sort of data is just bad OOP.

In analysis and design phases I used a lot of UML language.

Spoken like a diligent student. :-)

they taught me that UML must be used only of it helps to make ideas clearer and not for "documents' sake".

Good.

UML is a communications tool. If you are using it for communications with others, and that communication is necessary and useful to the project, then all is wonderful. Many of the charts and diagrams that were combined in the UML are useful to communicate.

If you are being required to communicate for communications sake, or create documentation for documentation's sake rather than out of it being necessary and useful to the project, then it is a problem, that isn't what the tools were meant for.

About 15 years ago there were some tools that attempted to take all the computer code and embed it as UML diagrams. Each part of the UML diagrams had a little code snippet attached, and the tools could convert the fancy diagrams into generated source code, compile it, and make runnable programs. That type of tool is of limited use, don't go there. Fortunately most of those have died off in the crucible of the marketplace.

If you are using the diagrams to help you understand your product, or to help you figure out a design for your product, then good for you. That was the intent and reason for the initial project.

So, how much UML should I use when I develop a game? I know that game development is usually a fast one but if I shouldn't use UML what I have to use to give a structure to the game?

Usually on a project I'll see a dozen or so UML diagrams over the course of a year that are used by the team. Some years I may see a few more, other years a few less.

You use enough to help communicate what needs to be communicated. You might instead ask how much text you need in a design document, or how many pieces of concept art you need to establish a concept.

Sequence diagrams and communications diagrams are probably the most common I see, they're very useful for the people working on networking and on complex system interactions. A team might put together some documentation that includes a sequence diagram showing the game handshake, or the sequence of dealing with hard-to-follow events traveling through the product.

Class/component diagrams are sometimes useful in figuring out how abstractions work in systems, so sometimes a team will build one or two to help figure out some tricky parts or some things that represent core systems, but they're only useful so far as they allow people to communicate about it. Once it is communicated and understood, it is enough.

Other diagrams may be helpful to communicate ideas. If you need them, use the diagram. If you don't need them, don't.

There is a tool that might interest you, DRAKON Editor, it can be used for creating diagrams and also for visual scripting.

First of all, thanks everyone for the answers.Another question is that with the "usual" software development I have a sequence of steps that I follow every time (use case diagram, analysis class diagram...).A game is a more interactive software and I don't know if my usual developing model it's right.Anyone has got some examples in developing games with UML? Like indie games or something so. For example, when I develop a general purpose software I know the question that I have to make in order to define the uses case diagram (who will use the software? What features should the sw offer?); when it is a game, I will need a systematic and disciplinate developing model too.

Up to this point, the thread has been about GAME DESIGN (so should have been in that forum). Now, if it's going to veer off into a programming discussion, I'll leave it in For Beginners.