Hello everyone. I just wondering whether is it necessary for a person to draw UML diagrams (design and analysis) before moving into implementing the game itself. I normally use pseudocodes and flow chart to do my coding? Do you use UML for this NYG competition? I really had no idea is it necessary for game development (well, c++ is object oriented), I only know it is suitable for software development? Any help please? Regards, Chua Wen Ching

Hello,

There is nothing wrong with UML, but you need to balance it. You wouldn''t want 70% of the development time going into modeling. But a bit of modeling is really helpful, it saves you from having to re-write stupid logical errors. Just make a good basic structure in UML, think it though and get down to coding.

Regards,
Deficte

i''m sorry sabreman, i don''t want to post flamebait here and i know this is off topic, but i just really find it annoying that you constantly post about these forums speaking as though yours is the word of god. Please try to use some tact in your posts. Something like "In my opinion, UML is a waste of time in development for the following reasons:" might have come off as a little less arrogant. I agree with you on many of your points, but not on the way you convey them.

To do something more on topic, I do believe UML has a place in game development. It really can save a lot of time in coding. Not taking the time to model a design can lead to many more spent hours just staring blankly at the screen, in my experience. I have a feeling one of the moderators or perhaps owners of gdnet (maybe dave astle?) wrote an article once on the pros of using UML. Might be worth having a look for it (i may have imagined this, does anyone else remember an article like that?). Hope that helped.

Part of UML''s usefulness is a standard to communicate with other programmers. If you both know what a class diagram is, you can very quickly explain objects.

That said, I generally don''t follow standards as such for design diagramming - ''flowchart class diagram thingies'' are more expressive.

Don''t go overboard - you might find the software engineering adage "build one to throw away" (i.e. prototyping) will do you better - and it certainly will on lower levels.
I do think architectural design is worthwhile though - and this coming from having written 13,000 lines of C++ in the past 9 months, essentially without much change to my plans.

You mean prototyping is a better choice. I thout prototyping is a methodology like RUP or Spiral model right?

Anyway got anyone in the game industry ever use rational rose to reverse enginner the uml diagrams -> C++ templates for their game development?

Or they prefer to code by themselves...

Anyway thanks for the reply!

Regards,
Chua Wen Ching

quote:Original post by wenching
Anyway got anyone in the game industry ever use rational rose to reverse enginner the uml diagrams -> C++ templates for their game development?

I never touched UML while I was in the industry. If you go the whole UML route (sequence/actor/activity/collaboration/class diagrams, Use Case models, blah, blah, blah, you''ll spend so much time on designing the game you''ll never get it done in a decent amount of time. And with the pressure to push games out the door ASAP, it would be virtually impossible to use a significant amount of UML on a project.

That said, a little designing up front is almost always necessary to avoid wasting time while coding. A basic design of the classes you think you''ll use and their interaction is pretty nice to have. A UI framework flow is something else that might be nice, depending on how much UI you have in the game.

In summary - a bit of design is a good thing, but don''t let it get out of hand.

quote:Original post by Machaira
I never touched UML while I was in the industry. If you go the whole UML route (sequence/actor/activity/collaboration/class diagrams, Use Case models, blah, blah, blah, you''ll spend so much time on designing the game you''ll never get it done in a decent amount of time. And with the pressure to push games out the door ASAP, it would be virtually impossible to use a significant amount of UML on a project.

That said, a little designing up front is almost always necessary to avoid wasting time while coding. A basic design of the classes you think you''ll use and their interaction is pretty nice to have. A UI framework flow is something else that might be nice, depending on how much UI you have in the game.

In summary - a bit of design is a good thing, but don''t let it get out of hand.

I haven''t heard of many people in the game industry use UML, either, but I have to disagree that doing "the whole UML route" would make it difficult to get the game done in a decent amount of time. The reverse is actually true. The more detail that goes into the design, the easier it is to transfer the design to code. Of course, you run the risk of the design working properly, but if you''re doing that much design anyway you should have discovered any potential problems.

Having said all this, I''ve had the best results (least amount of defects in the code) when approximately 40-60% of my time was spent in design and analysis, resulting in only about 15% of my time spent in code. That doesn''t necessarily mean 40-60% of UML documentation, but rather analysis of the problem and a design implementation of the problem.

Anyway, any design is a good thing, but like anything else in software, too much of it is bad. If you''re spending 90% of your time in design, I sure hope you''re using code generation tools, but at the same time, if you''re spending 80% of your time coding, it sounds like you need to design more because from my experiences, I''d bet that >50% of your code is rework.

p.s. A UI framework can be modelled pretty handily through a combination of statecharts, activity, and interaction diagrams.

quote:Original post by Khawk
I haven''t heard of many people in the game industry use UML, either, but I have to disagree that doing "the whole UML route" would make it difficult to get the game done in a decent amount of time. The reverse is actually true. The more detail that goes into the design, the easier it is to transfer the design to code. Of course, you run the risk of the design working properly, but if you''re doing that much design anyway you should have discovered any potential problems.

There is such a thing as going overboard with design if it''s not useful, however. The more I''ve been forced to work the UML, the more I''ve seen this to be true. Spending weeks writing Use Cases when the same information could be obtained quicker and easier with other methods seems silly to me.