UML (or other) analysis methods in game development?
Am I the only one who finds it interesting that people somehow think that programming games is "different" than programming anything else, and that standard analysis and design tools, like UML, don''t really apply?
Author
Yeah.. I think they apply quite well in most cases. What I''m interested to know is if these tools are used or not. BTW, thanks for the links guys! I''ll test them tonight after school.
Jarkko
Jarkko
Some people treat games developement different from general application development, yes, and I think it is so for two reasons:
1. Game programming was earlier not accepted among professions as being "professional" or as being a "proper" profession by the university people. As a result many programmers that had taught themselves programming became game programmers without any formal education in design. I no longer think that gaming is frowned upon - at least at my university they are not - my Master''s Thesis is about game developement and my Professor enjoys the subject very much.
2. Games programming is the first thing that many people have a wish to program after they learn a little programming. As a result there is many people which has very wrong ideas about what game programming is a what commitment it takes - because in reality it is not much different from any other commercial development project.
Let''s admit it - it is because of this novice group of programmers that Microsoft decided to add DirectX support to VisualBasic - and lets face it - Visual Basic will never be used to develop a commercial game; Visual Basic doesn''t even support inheritance.
B.Sc. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/
1. Game programming was earlier not accepted among professions as being "professional" or as being a "proper" profession by the university people. As a result many programmers that had taught themselves programming became game programmers without any formal education in design. I no longer think that gaming is frowned upon - at least at my university they are not - my Master''s Thesis is about game developement and my Professor enjoys the subject very much.
2. Games programming is the first thing that many people have a wish to program after they learn a little programming. As a result there is many people which has very wrong ideas about what game programming is a what commitment it takes - because in reality it is not much different from any other commercial development project.
Let''s admit it - it is because of this novice group of programmers that Microsoft decided to add DirectX support to VisualBasic - and lets face it - Visual Basic will never be used to develop a commercial game; Visual Basic doesn''t even support inheritance.
B.Sc. Jacob Marner
Graduate Student of Computer Science, The University of Copenhagen, Denmark.
http://fp.image.dk/fpelisjac/rolemaker/
quote:Original post by johnhattan
Am I the only one who finds it interesting that people somehow think that programming games is "different" than programming anything else, and that standard analysis and design tools, like UML, don''t really apply?
Although I agree that the game development community should probably look to traditional methods, object orientation, algorithm and data structure study (if I see another person doing everything with arrays I may scream), if only to reduce these 20hr working days etc, there are often some crucial differences which I believe mean the ''traditional'' or ''formal'' methods are not as suited to the task:
You sometimes have to work at a lower level to get optimum performance. How do class structures represent assembly code?
Many ''normal'' programs are made by a company who is both publisher and developer and therefore do not have the same degree of publisher pressure. Most normal software comes out late anyway, so formal methods are not the saviour here.
Traditional software rarely requires up-to-date hardware knowledge, and the accompanying ability to be able to change direction and the feature list at very short notice (your competitor just added dynamic shadows and 3D sound - if you don''t, your product will bomb). Competitors for the latest office suite, finance package, or operating system are rarely more common than once or twice a year. Whereas hundreds of games are released each week and you have to consider each competitor when it comes to the features you want to implement.
Game programming often covers a wider variety of disciplines than any one ''traditional'' program (sound, graphics, input, physics, networking, AI) and therefore there are more cross-dependencies between modules, more globally visible objects needed, etc. In my opinion, only operating system programming could really claim to cover as many bases, and look what we have there? Fully-featured but very buggy (Windows) or stable yet lacking some up-to-date features (Linux). Games, on the PC at least, appear to drift towards the Windows model as game buyers like pretty things and like to get some use out of their specialised hardware.
Finally, games have to be fun. I don''t think there are any formal methods defining fun or indeed how to make something fun
Perhaps there would be some merit in exploring ways to make the traditional methods more applicable to game design, or even formulating game design methodologies? I believe it was Doug Church (of Looking Glass?) who noted that game design really lacks a good vocabulary in which to express concepts and ideas? If this bridge was crossed, maybe better design would follow.
While Doug Church makes a number of valid points, it''s not a good idea to try nailing down terminology at this stage.
The computer games industry is _not_ mature yet. We''re still dogged by a technology base that isn''t so much a moving target as a bunch of zoom-lines accompanied by a "whoosh!" sound effect.
The TV and movie industries took many decades to mature; Hollywood didn''t tie their jargon to the mast until _after_ sound and colour had arrived on the scene.
Yet we''re still designing and developing games for target platforms tied to display technology that predates ENIAC. Tying ourselves down to the terms and philosophies of today will only leave us with the task of replacing them soon after with those of tomorrow.
--
Sean Timarco Baggaley
Technical Author
Criterion Technologies
The computer games industry is _not_ mature yet. We''re still dogged by a technology base that isn''t so much a moving target as a bunch of zoom-lines accompanied by a "whoosh!" sound effect.
The TV and movie industries took many decades to mature; Hollywood didn''t tie their jargon to the mast until _after_ sound and colour had arrived on the scene.
Yet we''re still designing and developing games for target platforms tied to display technology that predates ENIAC. Tying ourselves down to the terms and philosophies of today will only leave us with the task of replacing them soon after with those of tomorrow.
--
Sean Timarco Baggaley
Technical Author
Criterion Technologies
UML is one of the greatest things to come out since sliced bread! The one point that most people don''t realize is, if you do your designing right (should take 80 - 90% of the time) the coding is incredibly simple. The coding is actually the boring grunt work. Now I know alot of people that read that are going to think that I am crazy, but that just goes to show they don''t understand the power of proper design. It is amazing when you sit down and try to plan out everything a class is supposed to do and be resposible for, thinking you know exactly what it is to do, and you sit there for a half hour to fourty five minutes trying to put it down on paper. Just think of all the times you wrote a class, went on with other parts of the program, just to find out that the "mega super important class" you already wrote needs to be re-written just because you didn''t think about a certain aspect of the game. We all have been there. It is great when you can sit down design the game, and not have to go back and re-write alot of code!
If you can''t win, make sure the one that beats you breaks the record!
If you can''t win, make sure the one that beats you breaks the record!
Kylotan, you are right that there is many differences between normal program development and game development, but this does not mean that we cannot benefit from many of the techniques developed for non-game programs.
The gap is generally closing between games and application with regard to the low-level-ness of the programs. Today it is fairly rare (from what I hear from people) that game code is being written in assembler if just for a few percent of the code. This the requirements for more functionality and content in games and the need for high level programming is increasing every day. I would actually not be surprised if game development some day in the future would use some very high level programming language such as ML (a functional programming language that is even more high level than Java). It is true that performance is important but it is so in nay application area. Nobody wants to use a word procesing program that is slow. People wants speed in all areas of their system - not only games.
The need of up to date hardware knowledge is also less important than before. Today most of us is using (fairly) device independent interfaces such DirectX for our work. There is no need to learn the intricities of a bunch of video cards as it was in the DOS-days.
It is true that other programs does not have to be fun, but isn''t this just another way of putting the goal of having an application having to fulfill the needs of the user. By making usuability testing and other tradtional techniques we can get a long way.
You state yourself that games may need to be changed in the last moment before the release in unpredicable ways. This is really just yet another reason to try to structure the development proces in a more formal way. This way you can better anticipate change when it comes. If you optimize your code to much then this will be nearly impossible.
I agree, though, that there is some differences.
One difference is that the market can accept many new games and the life time of a game is quite short compared to other applications. How ever heard about anybody being 2-3 word processing programs a month? Some people actually do this with games.
The gap is generally closing between games and application with regard to the low-level-ness of the programs. Today it is fairly rare (from what I hear from people) that game code is being written in assembler if just for a few percent of the code. This the requirements for more functionality and content in games and the need for high level programming is increasing every day. I would actually not be surprised if game development some day in the future would use some very high level programming language such as ML (a functional programming language that is even more high level than Java). It is true that performance is important but it is so in nay application area. Nobody wants to use a word procesing program that is slow. People wants speed in all areas of their system - not only games.
The need of up to date hardware knowledge is also less important than before. Today most of us is using (fairly) device independent interfaces such DirectX for our work. There is no need to learn the intricities of a bunch of video cards as it was in the DOS-days.
It is true that other programs does not have to be fun, but isn''t this just another way of putting the goal of having an application having to fulfill the needs of the user. By making usuability testing and other tradtional techniques we can get a long way.
You state yourself that games may need to be changed in the last moment before the release in unpredicable ways. This is really just yet another reason to try to structure the development proces in a more formal way. This way you can better anticipate change when it comes. If you optimize your code to much then this will be nearly impossible.
I agree, though, that there is some differences.
One difference is that the market can accept many new games and the life time of a game is quite short compared to other applications. How ever heard about anybody being 2-3 word processing programs a month? Some people actually do this with games.
A very complete list of UML modeling tools is here. Only complaint is that they don''t give prices, so you''ve gotta drill down into the various pages before you find out that the tool costs $5000.
My favorite one on the list is "Plastic 1.1 Lite". It''s very simple, very fast, and free. Reminds me of my previous favorite --Booch Designer. Unfortunately, BD was purchased by Rational and re-sold as Rose for Windows after adding a code generator and a 500% price increase.
There was another very good free one on the list, but it did about a thousand things I didn''t need, so I stuck with Plastic.
Ahh, I think it was the Simply Objects free modeler that was also quite good, but a bit too much for my needs.
quote:Original post by felonius
and lets face it - Visual Basic will never be used to develop a commercial game; Visual Basic doesn''t even support inheritance.
You seemed to be level headed up until this final remark. You can''t write a commercial game in a language that doesn''t support inheritance? Heck, Quake 3 was written in straight C.
And there have been commercial games written in Visual Basic. One I can name off the top of my head is "Sporting Clays," which had a lot of shelf space at the Circuit City I used to frequent.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
