Why do game programmers never use formal methods or software engineering?

I think the biggest issues are time, uniqueness, and modifiability.
Time, do you have time to engineer something? could that time have been better spent just doing it a different way?

Uniqueness. How many times CAN i reuse this code before the player realizes that everyone does the same old crap? If i can't reuse it, why over engineer it.

Modifiability. Playtesting shows that feature X doesn't work. how much time will it take to rewrite the whole designed behavior for it? If it is just a few functions, might not take so long. If it is a few systems all tied together with lots of little classes and overrides needed just to make it work more of the time might be spent working on baseline code before the behavior can even start to get rewritten.

It may not be formal process, but I do indulge in a fair amount of planning and design - then again, I am a CS major, albeit originally self-taught.

Before I start a serious project (usually in C++), I tend to outline the basic specs and requirements, make a rough sketch of the UI (if a UI is needed), and outline the overall structure. In terms of reuse, I have a couple of distinct modues (math, debug/logging, memory management, lightweight opengl renderer), that float along with and are used and refined in almost every project.

Most small stuff I code pretty much from scratch, in Python - particularly prototypes. These tend to be not more than a few source files, and pretty much throwaway after they have served their purpose, so I don't see the need for a bunch of planning.

Its not only game programmers.

In my opinion its because it just takes too much time and hardly anyone bothers to read and understand UML and design documents when something needs to be done by yesterday (as usual). It really seems that the people who come up with those methods never really got their hands dirty on a real project.

Making a habit of writing understandable code and properly commenting it goes a long way though.

Then again, programmers shouldn't be writing those things, a designer should, who hands it down to the programmer to implement, if you have no system designers who just design, going through the whole process becomes redundant.

Quote:

Original post by riruilo none of then are computer scientist, so I think they don't know what UML means. Thay are self-taught, and I'm starting to think this is a problem.

And there you have your answer. how do you use something that you don't know exists? For the most part it sounds like you lack coding standards and "best" practices. That is a design and code philosophy that comes from your lead devs. We don't have UML for most things here but we do have certain coding guide lines you are expected to follow so I can look at a piece of code I have never seen before and tell you how it works in general because we have standard ways of doing things.

Yes, it's possible to create games (and other complex software) without good engineering. I've seen it done many times in many fields. That doesn't mean the resulting product will be good - in fact, it usually sucks pretty bad (and this applies to my own projects as well [wink])

In my experience, game programmers are hardly alone in this. In fact I would go so far as to say that there's roughly equal proportions of "design slackers" in both game and non-game fields. The only possible difference is "crunch mode" in the game industry, where quality of all kinds goes out the window in order to get a project finished.

Being self-taught isn't necessary the problem either. I'm self-taught, but I've been consistently introducing new ideas in design and development methodologies to my current team, for example. A couple of the university-educated guys have been as well, but for the most part, the big push to implement good design and methodology practices has been coming from people who have learned it the hard way - out in the trenches.

My personal opinion: every environment has some problems; no position is perfect. It just so happens that good practices are often sacrificed for various reasons: time, money, and so on. Of course, those reasons are rarely good reasons, but so it goes [smile]

Some programmers do use formal methods. Turbine supposedly uses a lot of formal methods; but they are developing with long term objectives, and are probably several generations into their code. They can emphasize stability, rather than meeting milestones.

Restating some of what's already been said, it depends on the life cycle of the the code, allotted time to develop the code, and weighing the benefits of a 'proper' design.

Let's not forget that most people simply aren't aware of formal methods or software engineering. I myself have a degree in Software Engineering, to which I've yet to utilize in my own projects [lol], and it's a specialized field. Most indie developers who are starting out in their programming journey are young, 13+ who have no idea of the proposed formal methods or software engineering practices. As a result, they go upwards to 5 years or so without having ever used them, perhaps go through college and don't learn them there either, and then get to the work place and have to learn it there. That is not true of everyone, but a majority. So, your comment about them being self taught hit the nail smack dab in the middle of the head.

There is not as much awareness or emphasis on SE or formal methods. It's just code, code, code. How to use OpenGL, how to use DirectX, how to program in C++, how to program in C#, etc... There aren't any resources that really go over the need for using formal methods and SE concepts before you get started. A few will go over the importance of designing and stuff, but it's such an over simplification of the concepts that it's quickly dismissed or written off as not important.

Quote:

Original post by Drew_Benton There is not as much awareness or emphasis on SE or formal methods. It's just code, code, code. How to use OpenGL, how to use DirectX, how to program in C++, how to program in C#, etc... There aren't any resources that really go over the need for using formal methods and SE concepts before you get started. A few will go over the importance of designing and stuff, but it's such an over simplification of the concepts that it's quickly dismissed or written off as not important.

I don't think it's necessarily the case that people don't try to communicate these concepts; I think the problem is that communicating how to do good software creation is hard. We don't have a vocabulary for it. We don't have good examples. We can't explain most of the problems to beginners because beginners won't be able to understand why problems are problematic until they've been bitten. See the endless discussions about whether or not goto is "really" evil (or, on a slightly more meta level, whether or not C++ is good for beginning programmers).

IMHO the real problem is that the people who have good experience and knowledge in the realm of software engineering and creation in general have no good way to share that experience with the general masses.

What is the definition of the formal software engineering method? It seems to change every few years depending upon the lastest buzz words. Writting software is iterative, not just the coding itself but the process and overall design of it. After a few iterations people usually settle down upon a workable system for themselves and their organizaition.

Game programmers in general are specialist, they usually stick to a particualr sub-domain of game programming for years, slowly aquiring a level of expertiste. Due to this it's rare that any given programmer has to worry about or write large pieces of software(ie 100k+lines), they ususally work within a smaller domain which doesn't nessitate the overhead of more formalized software models ( ie producer/consumer/tester cycles ) or they use a much truncated form of that cycle.

Attempts at imposing a formal software methoddology on game programming I've seen, ususally fail becuase those implementing it haven't themseleves have worked with or are sufficiently knowledgable about those models, thus leading to eventually breakdown and return to the old methods.

-ddn

Oh, they're using a software development process. In fact, it's the oldest and most widely used method to date:

         +---------------+  +----->|     CODE      |  |      +---------------+  |             |  |            \|/  |             `  |      +---------------+  +------|   FIX/DEBUG   |         +---------------+        

1. Do you see a 'documentation' step? Nope!
2. Is there a 'design' step? nope!
3. Is there a 'requirements/spec' step? nope!

This method has it's pro's and con's to it; The con's heavily outweigh the pros. You could give your team members a link to SWEBOK or buy them a copy of "Code Complete, 2nd Edition" and make them read chapter 1 & 2.

The initial cost of time and money will be returned many times over. ;)

Thanks for replies. Very interesting.

BTW, What does "hit the nail smack dab in the middle of the head." mean?

I forget to discuss about the requirements stage, previouss to design step. This step is also ignore by my workmates. How can somebody do something without knowing what you are going to do.

I agree with this topic http://www.gamedev.net/community/forums/topic.asp?topic_id=510205.

Thanks.

[Edited by - riruilo on October 8, 2008 2:25:09 AM]

Quote:

Original post by riruilo BTW, What does "hit the nail smack dab in the middle of the head." mean?

It means "you are exactly right" [smile]

Well there a lot of reasons:

1. No Knowledge of formal methods - the coder might be self-taught, very rarely are formal methods things people have spent time learning! Or they could just have a useless Univeristy course that didn't teach any, like mine!
2. Lack of guiding design - How do you formally evaluate a design proposal when it consisted of an idiot waving their arms in the air whilst saying "Y'know like World Of Warcraft" and pointing at something they drew in MSPaint... that's a real-life example btw.
3. Time constraints - properly design things does take time, it's time well spent and I'd love to do it more often but frequently my task are allocated like this:
Boss->"Andy we need this by FRIDAY!"
Me->"WHAT! That'll take me a MONTH to write why wasn't it in the design?!?"
Boss->"We have a design? But it can't have been in the design because the designers only just stole it from XXXX game last night! Just get it done".
Btw the I'm replying to this whilst doing something EXACTLY along these lines and have been for 6 months.
4. Anything that I do design I'm going throw away next week - this is much the same as #2 in that if I spend time designing a system to work on way, as I did at the start of this project, it will be completely thrown away by another team member during development anyway as what I will have designed will not be what the games designers want by the end only no-one will know that at the start.

I'd LOVE to design things properly, I'd love to know much about formal methods and doing things the right way. I'd also dearly love it not to be so pointless and for others to do their damned jobs properly.

It's all wishful thinking at this point.

Andy

Quote:

Original post by riruilo Hi out there. Why do game programmers never use formal methods or software engineering?

Some do. Some don't. It largely depends on the context and experience.

Formal design methods may have a role in sports sim franchises, where the codebase rarely sees more than a few nips and tucks between releases, but this technique relies on a fixed, well-known problem-space and a rock-solid design specification. Games designers are still blundering about in the dark; they simply cannot produce such a design specification up-front, so this industry tends to use an iterative approach instead.


Personally, I don't see programming as "engineering" anyway: I see it as writing. I can think just as easily in Modula-2 and Motorola 680x0 assembly language as I can in Italian or English. Whatever it is in my brain that deals with this stuff clearly makes no distinction between natural and artificial languages.

Back when I was programming the Atari ST and Commodore Amiga, I was able to code up a sprite routine without even thinking about it at a conscious level: I've written such routines so often, it's become almost instinctive. The architecture of a 2D game is also trivial: player I/O, game rules, sprite routine(s), effects, scrolling, tilemaps, etc. are all known problems and have been solved over and over again. I built a complete, 2D, vertical-scrolling (with parallax) platform game, with simple physics, in less than two months. (Including the graphics.) The third month was spent fine-tuning the gameplay and building the 160-odd levels.

Today's games may look complicated, but they're not. While the details have become more difficult, the overall architecture of a game has changed little: we still need player I/O, file I/O, a rendering engine, a sound handler, a model of the game's rules, something to manage the asset database itself, and so on. The list is 90% identical to that of an older, 2D game from the early or mid-'90s. The individual components will be more complex, with more virtual knobs and buttons to twiddle, but that's about it.

Many developers use ready-made game engines and other libraries to handle most of the heavy lifting. This leaves them time to focus on the actual gameplay, instead of figuring out how to load 3D model data from a DVD or hard drive on multiple platforms. Many of these libraries will, to some extent, influence the architecture of the game, depending on how they were designed.

By far the biggest problem in game development today is resource management. The asset databases have exploded over the past 10 years or so. The asset production workflow is now at least as big a bottleneck as the coding itself.

I find this to be my own problem, but I do not seem to get how to do the engineering part. Like how do i take the general idea of the program i have in my head and break it down to UML or class lists or whatever.

Can you guys provide some good resource to learn this stuff from the very ground up? Preferably something very simple and understandable. Thanks.

kost.

Perhaps the problem is UML itself.

It does not actually show the program - only the classes and how they are related. A finished application is much more then this, and managers have a difficult time interpreting class relations to business logic to user interfaces.

The drawback with UML is the lack of User Interface descriptions; this is still 80% of the programming time in a typical Win32 application, and the user interface predominately drives the internal software project for commercial software.

More important to me is that with the framework I use, the application has full runtime dependency injection of objects. Objects are truly independent, and can be reused with different parent to child inter-object relations within different parts of the same application instanciated as the application is running across the enterprise. The UML model is constantly being updated as the application is dynamically evolving; it is easier to view the application data schema where the relations are created then transferring to yet another document and code model.

Quote:

Original post by riruilo Why do game programmers never use formal methods or software engineering? ... They are self-taught, and I'm starting to think this is a problem.

I think the question should be "Why do self taught programmers never use formal methods?" - and then the obvious answer is because they haven't had formal training.

Quote:

My question is: do you have they same problem in your enviroment?

Yes, most senior people here got their Comp-Sci/Soft-Eng degrees 20 years ago, and haven't had any training since.
As far as I'm concerned, this makes them "self taught" even though they do have a degree. Best practices have changed a lot over the last 20 years.
For one thing, most people try not to write their games in plain C any more...

Quote:

Is it really possible to create games without software enginering?

Yes, but they will be buggy.

Quote:

Do you use it?

The best I can given the surrounding environment... The last guy who tried to incorporate unit-tests into our process ended up quitting and getting a job at google ;)

Here at work we use a process called iterative development. What this means is you make a design for what you want to build the next 2 months (tops). Then you start. At the end of those 2 months, you have a finished product. Yes it is supposed to be a finished product, something you can test for real and everything. Then, after testing it, you evaluate it and decide if it is still exactly as planned, or if your ideas have changed.
Then you make a new design for the things you want to do the next 2 months. This could include a (partly) rework of what you did before or it could include new functionality. Mostly a combination of the two.
This way, you have designs but you frequently update them to keep them up to date with the latest developments. This also means that any changes that pop up during an iteration can be easily incorporated either in this iteration or the next.
And if you have time left at the end, or are short on time during an iteration you can shift tasks to or from the next iteration as needed.

The main thing to remember here is that the design team starts working on the next iteration the moment the development team starts working on the current one.

Thanks for replies.

I can't program or develop without any methodolody, I'm an engineer, not an artist. If I don't do that, I will have a spagetti plate (I guess you understand me)

What do you think about thi method, http://www.gamedev.net/reference/articles/article1940.asp, for instance.

Thanks.