Is it really like...

#1 Well, I've never used UML, or any formal notation. I've always been intrigued about them, and have occasionally read up a little, but I've never taken the time to seriously learn one (I guess these days, there is only one.) I think it would be useful to know UNL. I don't always lay out my code designs on paper, it depends on the size the project, it's complexity, and whether I've tackled that particular problem before. When I do though, I sometimes wish I had something better than my "custom" diagramming.

As for seeing it used by others... I've worked, or interviewed, with a few companies over the years and only one talked about using Booch notation. I certainly don't know of any game companies that use formal notation, but then most game companies don't use anything formal :)

Seems like UML could be a useful tool to know, but I wouldn't worry about being grilled about it.

#2 Here's my personal opinion on UML - it doesn't work. Not that it's a bad idea, but in a fast-paced environment such as (for example) web development (where I've had to use it), it's usually just a mad rush to get the site done. For example, when I was working on the Flash section of http://www.allroad-quattro.com (Audi's new SUV-type thing), we had it all mapped out, storyboards, flowcharts, everything. Then, once we started doing it, we realized most of the info was completely useless and we devised our own (rather free-form) method of putting the project together, and the UI ended up being figured out on the fly. So, in total, we probably wasted 2 weeks using the UML paradigm. That's just my experience, maybe someone else has had a better one. I, for one, will not bother with it again, at least not in a very strict sense. A storyboard document, and possibly a functional spec (although I've never read one when handed to me) is more than enough when dealing with web development.

- Nick Robalik
http://www.digital-soapbox.com

#3 I too work in Internet consulting and web development and would have to disagree entirely. I've successfully used UML on a couple of projects and in all cases it was extremely helpful. Not only do I think better code came out of it, but it has greatly increased the possibility of usabilty of that code.

I think the problem with UML is that people expect way too much of it, mostly because they don't understand it. UML is NOT a methodology, although it does lend itself to certain methodologies better than others. It also does not ALL have to be used. I use only specific diagrams for complex pieces of the application. I don't generate sequence diagrams for every little process I might have.

Another problem is that the tools that are out there are very complex, and assume you understand everything about UML before you start. In many cases this frustrates new users and they immediately return to their old methods.

Still another issue is that users need to fully understand object oriented programming. OO is relatively new to those folks doing web development, as many of the tools didn't support it, or supported it poorly. However, with J2EE and .NET entering the enterprise, OO web development is not only becoming a reality, its becoming inevitable. And UML helps support that.

UML is a diagramming tool. It is meant to be a standard so that two developers that understand UML can talk to each other and understand an architecture and how it works. A really good use of UML is for describing "patterns". (look up patterns, I'm not going to describe them here) Since patterns are language independant, you need a way to describe them visually. UML does this perfectly and lets a Java developer or a C++ developer or a SmallTalk developer understand the pattern very easily.

UML could, and probably should be used in the game industry. With companies developing engines and selling those engines, planning and describing the engine in a common format with UML would make everyone's lives easier. It would also force more thought into the design of the system so that it can be easily extended later.

But its gotta be used correctly. And that will just take everyone getting experience with it, which will just take time.

#4 Since it's on the computers here at Tech, and we had some guys from Rational come in for a one-day overview, I've started to use Rational Rose. I find that it helps get my point across to people who wouldn't otherwise understand what the hell I'm talking about.

UML is a good tool, but it can't be used in every situation yet. I would like to see the day when it is, and I would love to fully understand how to use it. Hopefully Tech will pay for the three-day course on it.

At the moment all I can use is the logical view (I think that's what it's called). It allows me to map out my classes, their functions and variables, and how the interact with each other. This has allowed me to find two major flaws in my projected game design (Annoying, but I'd rather find em now).

I will agree that it takes too much time at the moment to build a full UML wotsit (Ahhh, technical jargon)

#5 Well, at Team17, weve been from the "fag packet" design to the "UML out the ass", and I dont think we've actually managed to ever produce a proper "finished" design.

The problem is, that for games of any complexity (read: all), then basically, you havent got time to UML them to the n'th degree. Mainly because of management and publisher expectations on seeing something moving. :))

Basically, most games work on a system of milestone deliverables, to really work, you have to hide some "real" work, behind some clearly visible code (i.e. hide the entity system behind the "we have explosions working" code :))

The problem is, if you sat down and did 6 months of UML, you'd probably be lined up against a wall and shot, even if the project worked better after it.

We've basically come to this: noun verb analysis and class description. Basically, take the design doc, chuck out all the "its going to be great" crap, analyse the actual mechanics, write all "noun" words you see as possible classes, write all "verb" words you see as possible methods.

Its actually reasonably useful. But still incomplete.

Phil.

#6 Those UML and flowcharting software is used abundantly in the "real world" of programing..read non-game related...insurance companies, local utilities, banks, etc...But thats because they usually have dozens of programers working on the same project...which is to modify "legacy code" originaly written in 1983 or so :P

Some of these "real world" programers haven't got a clue as to programing a game...let alone a sort routine!...And, as in classic Dilbert situations, such programers are presided over by an even more clueless boss...

True story: I work at a company that produces custom electrical equipment...things like GPS units for fleet vehicals...recently the programing department was notified that they can no longer use Break in Case-select statements!..nor could they use Break near/far..as the manager did not understand them!...these programers write code for integrated systems...they useually only have a few K at thier disposel for the executeable...but all is good and well now, as one of the programers turned in his work written in assembler...so Break was promptly returned to active duty :)