Archived

This topic is now archived and is closed to further replies.

wenching

UML diagrams for games development!

Recommended Posts

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

Share this post


Link to post
Share on other sites
quote:
Original post by wenching
I just wondering whether is it necessary for a person to draw UML diagrams (design and analysis) before moving into implementing the game itself.

Every minute spent with UML is a waste of time that could be spent on something useful.
quote:

I normally use pseudocodes and flow chart to do my coding?

Why don''t you use code to do your coding? Why must you spend ages modelling the code you are going to write, only to later recast it into another form which can be executed and verified?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
quote:
Original post by MelvinElvin
I agree with you on many of your points, but not on the way you convey them.

If I''d made an unwarranted personal attack on someone, I''d be more inclined to sympathise with your complaint, but given that I haven''t done anything of the sort, you are simply whining.

quote:
Original post by Deficite
There is nothing wrong with UML [...]

The assumption behind UML is that the classes making up a project are the only thing that matters, and the procedural stuff sitting behind the classes is irrelevant detail. Yet it''s the code which makes the software work, and where any bugs will be found. UML isn''t about software design, it''s about money. As such, it caters to the most lucrative areas of the s/w market and relegates all others as invalid by not recognising them in the so-called "Universal" Modelling Language.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

The essence of design is in making the problem and solution meet. Too many people believe that this convergence must occur somewhere close to the solution domain, which is what happens when you spend all your time working with tools which force such a situation.

The way UML spewing designers tend to work is like this... any problem which can''t be directly modelled in UML is plain wrong, and is simply waiting for a knowing developer to recast it into structures that UML can model. This involves thinking in terms of the few languages which UML can actually map to and then reconstituting your mental image of what the code must look like as UML constructs. There''s no possibility of actually making your solution look anything like your problem (other than sheer coincidence), so the problem must be made to look like some sort of solution before it can be regarded as a valid problem for implementing a solution to.

This process is a colossal waste of time.
quote:

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.

Well, that''s the thing. The potential bugs are mostly in the "interesting" bits - the bits that UML doesn''t capture - the bits which make the software "do stuff".
quote:

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.

I don''t know about the percentages, but not all of the time spent coding has to be put into writing production code. Or, perhaps, some percentage of the time can be spent making a solution domain which looks more like the problem domain.

Share this post


Link to post
Share on other sites
Hello,

I know that heavy software design is an enormous waste of time and money, but if you do it in a small scale I believe it''s a good thing. I have no real life experience with huge game development projects, but rather with a small demo I made with some friends. There were 6 of us and we sat down and just talked the design through. Didn''t take more than 2-3 days and when we were finished we hade a rather good idea of which parts were gonna connect with which parts etc. This did of only involve the large parts of the projects, but when we got down to coding it was a really good design and very helpful. My point, as stated before, is that a small design effort will be more useful to a software project than a massive hacking effort. Maybe not on the short run, but rather when it comes to refactoring and continuing the work.

Regards,
Deficte

Share this post


Link to post
Share on other sites
I agree with SabreMan. I use UML to design my current game, and I really feel the lack of the "glue", the stuff that connecting those classes with external libraries, the loop, the if statements, the steps.

"OK, this class will do the rendering. It has these those and that." but how? how will it do it? Just having some imaginary code (or even a flowchart) while looking at the UML design isn''t really helpful at all. I need to do/see the actual code, see how things work, what are the stuff that needs more attention, what are the potential bugs if I use the current model.

So, the way I do it is I treat UML just like another programming language. I design a hierarchy, and code to see if it works or not (should be) and just to get the "feeling" of the design in the lower level. So that when I see my code and all the classes, the design comes to my mind.

Coding without UML sucks. Heavy use of UML also sucks because you are going nowhere. So you need to balance them, just use UML as a helping tool, not a development tool.


Current project: A puzzle game.
% completed: ~0%
Status: Active.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
UML is a fantastic wasy of designing application/games and modelling real world systems. The code inside the classes is less of a problem and should not need so much design this is because after the UML design is complete you can just say "OK, this class has this method and these are its inputs, it needs to do this and return that" you should already have a knowledge of programming to be able to get from A to B.

You just need to start thinking about something other than procedural programming to see the benefits.

Share this post


Link to post
Share on other sites
I find UML pretty useful, but I''ve never really gone all the way and applied the whole formal process. Usually I just put up some use cases and some class diagrams, until I have a clear idea of what I am trying to build. From then on, I rarely look back at the diagrams I created(Unless I engineer some diagrams from the source, that is).



"To assert that the earth revolves around the sun is as erroneous as to claim that Jesus was not born of a virgin."
-- Cardinal Bellarmine

Share this post


Link to post
Share on other sites
quote:
Original post by Arild Fines
I find UML pretty useful, but I''ve never really gone all the way and applied the whole formal process. Usually I just put up some use cases and some class diagrams, until I have a clear idea of what I am trying to build. From then on, I rarely look back at the diagrams I created(Unless I engineer some diagrams from the source, that is).

That sort of use is fine, but I have no idea why some organisations feel compelled to give so much money to Rational (or whoever) in return for what amounts to the high-tech equivalent of sketching designs on a bit of scrap paper. It''s just money for old rope.

Share this post


Link to post
Share on other sites