As such I can see it might be useful for established companies, but I don''t see it would help much for the average small team. [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
UML in game development
Plasmadog, that''s an interesting usage, but it''s addressing the game development process system, rather than the system created by the game development process. As such I can see it might be useful for established companies, but I don''t see it would help much for the average small team.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
As such I can see it might be useful for established companies, but I don''t see it would help much for the average small team. [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
quote:As such I can see it might be useful for established companies, but I don''t see it would help much for the average small team.
Unless it''s a new team of course.
UML is useful for any team, so long as the project is atleast of moderate size.
Step back and look at all the side-effects you get with UML... 1. Documentation, 2. A better design (because you are able to look at the whole and not just the micro view), 3. A standard way to communicate your software to anyone (like team members), 4. Inherant reusability that comes with good design, and solid documentation on how to re-use. And the list goes on.
The problem with software engineering is it is NOT programming. Talented programmers assume that if they know programming they should be able to pick up software engineering in 2 seconds. When they don''t see it''s uses in 2 seconds, they assume software engineering isn''t worth it.
It took you a long time to do programming in a useful way, it takes some time to learn to use UML and software engineering in a useful way. It wasn''t until my second large project using UML that I started to see it''s usefulness.
Step back and look at all the side-effects you get with UML... 1. Documentation, 2. A better design (because you are able to look at the whole and not just the micro view), 3. A standard way to communicate your software to anyone (like team members), 4. Inherant reusability that comes with good design, and solid documentation on how to re-use. And the list goes on.
The problem with software engineering is it is NOT programming. Talented programmers assume that if they know programming they should be able to pick up software engineering in 2 seconds. When they don''t see it''s uses in 2 seconds, they assume software engineering isn''t worth it.
It took you a long time to do programming in a useful way, it takes some time to learn to use UML and software engineering in a useful way. It wasn''t until my second large project using UML that I started to see it''s usefulness.
quote:Original post by shaft
Step back and look at all the side-effects you get with UML... 1. Documentation, 2. A better design (because you are able to look at the whole and not just the micro view), 3. A standard way to communicate your software to anyone (like team members), 4. Inherant reusability that comes with good design, and solid documentation on how to re-use. And the list goes on.
1, I don''t need, not in the way that UML provides it. The documentation it produces is largely useless for me. That sequence diagram you showed above could probably be represented in 1/5 the space with a simple description of the algorithm.
2. I don''t need diagrams to envisage a system. You need to be able to envisage it to draw it anyway, so this is is a vacuous claim in my opinion.
3. This is true.
4. Just 1 and 2 reworded. I never needed UML to achieve reuse or good designs now, and using UML has not helped me do so. Maybe it brings a less skilled system architect up to my level, which I can''t comment on, but it has not made me any better.
quote:When they don''t see it''s uses in 2 seconds, they assume software engineering isn''t worth it.
Where 2 seconds equals many months in my case. I wouldn''t sell any other concept to anyone on the basis of "just try it; you''ll see I''m right in the end", so why sell UML on that basis? I have good reasons to recommend OOP to people. I have good reasons to recommend the STL and generic programming to people. I have good reasons to recommend patterns, abstraction, the RUP, C++, so on. But I have no good reason to recommend UML to single game developers. Simply because none of the so-called benefits of UML seem to apply to me, and no-one else seems to give any concrete examples of benefits beyond standardisation. Is it so hard to produce a good argument in its favour?
Summary: I really don''t see the point apart from the communication benefits. Can anyone give me a good rebuttal with some actual content? I wouldn''t labour the point if I didn''t want to be proved wrong.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
quote:Original post by Kylotan
2. I don't need diagrams to envisage a system. You need to be able to envisage it to draw it anyway, so this is is a vacuous claim in my opinion.
If you do any sort of drawing when designing software, you are doing a diagram. You might not be using a standard notation (i.e. UML), but you're doing a diagram. Your first design is never as good as the final design, anyway, so what you envisage initially is not your best because you need to be able to see it and go through its parts..particularly as the system gets more complex. I imagine that you do some sort of iterative design process anyway.
Now something to think about.. (because I'm rather positive you draw your designs out.. I don't know any programmer that doesn't ).. do you use the same notation everytime you design? If you do, then wonderful, and kudos to your self-implemented syntax, but chances are that you don't. So let's say you come up with an elegant design to a difficult solution, and you have this diagram on a piece of paper that you whipped up while trying to solve the problem. A few years pass, and you come across the same type of problem again, and you remember that you have this solution for this problem, so you get out this piece of paper with the design (i.e. the purpose of design patterns). You start looking at it, but the notation that you use for your designs has changed over the years, so you don't know exactly what you meant by a particular symbol, line, or even text in the diagram. What do you do? Design from scratch? Dig out the code and reverse-engineer the design? Try to remember what you meant by this diagram? Whatever you decide to do, I personally think it would be much easier if you had used a notation that has been consistent for about 7 years now, that has good documentation on the notation itself (so you could look up things if needed), and that will be viable in the future - UML.
** appended below **
UML is nothing revolutionary. Its primary benefit is standardization. There are plenty other OO design notations out there (OMT, Booch, Rumbaugh, etc), but UML is good because it provides different views of the system in a coherent and standard way. That may explain why people are having trouble coming up with an argument other than standardization - THAT is the primary goal of UML.
Kevin "Khawk" Hawkins
CEO and News Director, GameDev.net
Author, OpenGL Game Programming
Developer Diary
I guess I just don''t find anywhere near the need for diagrams that you guys do. No, I hardly ever draw diagrams for programs. I don''t need to. I find object organisation trivial compared to algorithm implementation. Drawing such diagrams reminds me of maths exams back at school when we were told to "show your working-out". I already know the answer, so why draw it? Just so someone else can understand it, I presume. So yeah... useful for communication, but less so for the design or implementation processes themselves.
Your mileage may vary - and from the sounds of it, it does.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
No, I hardly ever draw diagrams for programs. I don''t need to. I find object organisation trivial compared to algorithm implementation. Drawing such diagrams reminds me of maths exams back at school when we were told to "show your working-out". I already know the answer, so why draw it? Just so someone else can understand it, I presume. So yeah... useful for communication, but less so for the design or implementation processes themselves.Your mileage may vary - and from the sounds of it, it does.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions ]
UML brings an average developer to your level?
Ahh I love the arrogance of programmers.
Do not consider that fact that uml has made me a better designer, as a weakness that I was a bad designer before. I''ve been programming for 15 years. I''m just wise enough to know that no matter what your skill, you can always be better. The second you assume you are the best, you cease to improve, and that''s when the rest of the world passes you by.
Ahh I love the arrogance of programmers.
Do not consider that fact that uml has made me a better designer, as a weakness that I was a bad designer before. I''ve been programming for 15 years. I''m just wise enough to know that no matter what your skill, you can always be better. The second you assume you are the best, you cease to improve, and that''s when the rest of the world passes you by.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement