Jump to content
  • Advertisement
Sign in to follow this  
saifmnasri

UML diagrams for video games

This topic is 790 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

i'm a student and i want to develop a project (video game), and the "UML" is mandatory. When using a game engine, how do you "uml" these abstracted parts (physics, tweening, audio players, etc).

Share this post


Link to post
Share on other sites
Advertisement

Personally, i've never seen UML used to create diagrams and design of a game or engine.

 

UML is generally used more as an enterprise level diagramming tool for object oriented design and personally the only place i've ever had the displeasure of using it was at university (Note: I didn't do a games development related course).

 

Perhaps some of the other forum members who work for large game development studios can prove me wrong here.

 

Is your course a game development related course, or general computing/computer science?

Share this post


Link to post
Share on other sites

Just the other day on Reddit, a google engineer stated that no one in Google uses UML. Honestly I was surprised.

But if you think about it UML might really make things harder special that design keeps changing while the development is happening, and keeping an updated UML could be a nightmare.

I'm really curious if Microsoft uses UML internally.  

Share this post


Link to post
Share on other sites

Microsoft is a huge company with many different teams. Some might use UML to varying degrees. None of the (game development) teams I worked with while I was at Microsoft ever did anything with it.

 

Similarly, I have been in this industry for over a decade and never seen anybody use formal UML for anything. Sometimes you see some rough, UML-like box-and-arrow sketches on a whiteboard, but they are crude and transient.

 

As for your actual original question: you'd build the UML diagrams for the engine the same way you'd build them for any other piece of software. A game engine is just software, at the end of the day, and there's not really a whole lot special about it. If you are unfamiliar with the process for turning an abstract design into a UML diagram in the form appropriate for your class, you may want to review your course notes.

Edited by Josh Petrie

Share this post


Link to post
Share on other sites

I'm joining the club of having never seen or used a UML in any of the gaming companies I've worked for. Neither on any non-gaming company I've worked for, for what it's worth. But the theory behind drawing a UML diagram should be quite simple, what are you struggling with exactly? What is the problem with adding the engine APIs you are using, either as regular classes or boxes with the name of a system of the game engine, and have arrows to those boxes from the other classes that depend on them?

 

For the record, what I understand as a UML diagram is this:

 

large_umlClassDiagram.png

Share this post


Link to post
Share on other sites

To be honest I like UML. I would only ever use the bits that I need, but it's a clear way to show class hierarchies and also to show complex sequences of operations. I would love to start on a game project and have a clear diagram of how the bits relate to each other, instead of having to spend ages choosing 'Go To Definition' and trying to work it all out.

Share this post


Link to post
Share on other sites

To be honest I like UML. I would only ever use the bits that I need, but it's a clear way to show class hierarchies ...
I agree here, class relations and member variables are much easier to read in 2D.

 

Occasionally, I also write the main methods into it, and that's all I do with UML.

Share this post


Link to post
Share on other sites
I have had exposure to tools that convert uml into readable executable code.

For example, opendds does this so that non programmers can create class designs, which is used for high performance distributed peer networking.

It's uses are few and far between though, you'll likely see it in Java shops, which create tons of internal docs before developing much, think SSADM and tons of red tape.

Enjoy! :)

Share this post


Link to post
Share on other sites
the "UML" is mandatory.

Lecture your teacher on how these are not used in the industry (see many posts above), and for very good and obvious reasons.

Within such a modular grouping of code, logical connections between related code need not have diagrams for them to be clear to the people who matter.

Trying to use UML to explain the entirety of an engine or game is note only a waste of resources but counter-productive as it is nothing more than clutter in a programmer’s already-scrambled brain.  If I am working on AI, why do I need to know the entire class hierarchy of the entire game, including the UI, renderer, etc.?  If I need knowledge on parts of another system, talking to people directly is most effective, and in-house Wiki’s (the standard in the industry) are more maintainable.

 

A scoped UML diagram is pointless since people not-only don’t think that way but programmers tend to know their own scope anyway.

A non-scoped UML diagram of an entire project causes detail to get lost in the clutter and serves only to overwhelm everyone.

In either case, it takes time and resources to keep these up-to-date and representative of the actual code-base.

UML promotes a strict  unchanging design that is incapable of adapting to new needs as they arise for 2 reasons:

#1: They make it a pain in the ass to implement any changes, since time has to be added to update the UML diagrams.

#2: One of the ideas behind UML is to design first and then code, which is an approach that implicitly lends itself to a set course that is hard to change.

 

Not only that, but my biggest gripe is that UML uses wrong symbols.  According to UML, an empty arrow from one class indicates that that class inherits from the class to which the arrow points.  This is wrong.

Diagram <------ ModelDiagram

UML says that ModelDiagram inherits from Diagram.  But the arrow points the wrong way.  According to the arrow, “ModelDiagram goes into Diagram,” when in fact it is the opposite—ModelDiagram comes from Diagram.

Diagram ------> ModelDiagram

This is how UML should look.

 

 

 

We have tried this in my first company and we dropped it for a reason.  It doesn’t work, it doesn’t easily convey what it is meant to convey, it is hard to scope properly, and it is easy to abuse into a cluttered mess.  It takes man-hours and costs companies money.

 

 

But if you have to do it, I have no suggestions.  Just know how futile it is.

 

 

L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!