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).
UML diagrams for video games
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?
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.
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.
UML is a massive waste of time. It's designed for overzealous bureaucrats so that they can draw stick figures all day in order to make sure that no actual work accidentally gets done.
The best part about UML is that the people involved with it think that "standardized" simply means, "Just do it my [highly technical] way." Since it's exposed to the whole wide world of bureaucrats and academia that means that there are actually about a a hundred different "standards" for every person who has ever used it, which in turn means that no matter how you do it you're going to be "wrong" to pretty much everyone in the world, including yourself, and the ways in which you are wrong make no sense to anyone in the world.
Thus you need to review whatever text or guide your professor has provided and follow that as closely as you can, since it's probably at least vaguely similar to whatever protean gibberish serves as a standard for your case. If you're very lucky then they're asking for class diagrams, which is basically a way of writing a C++ header that takes 50x longer and doesn't run the risk of being worthwhile, since you can't compile it. If you're unlucky then they're asking for use cases, which is a way of masturbating in public without being arrested. In that case you may as well just get it done and over with and look at the syllabus to see if you can make up the points elsewhere. If the assignment doesn't bear any significant weight then an example use case is this:
[attachment=33638:uml diagram.jpg]
As braindigitalis mentioned, this is not a real-world tool unless you're planning on working for "THEM", so please forget whatever they've told you about it as soon as possible, wash your hands thoroughly, and go back to just writing in plain language and free-sketching ASAP.
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:
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.
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.
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! :)
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! :)
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
