pouët.net

Well the reported 100 million dollar production budget for GTA IV had to go somewhere. ;)

it didn't go into porting the mostly perfect 360 version to PC, that's for sure! the retail windows version was surprisingly buggy as hell...

If you refuse to accept answers from people who are involved in professional game development in this thread (kb, torus, niels, gargaj, evilpaul and myself at least), why not just make up your own arguments and call it a day, then?

For the record, having development methodologies that dictate how meetings are held, who should be responsible for what to whom or who should write what bit of code or documentation doesn't really change the basic method of making games. It's still "designer designs -> artists do art + programmers program -> QA tests -> if not happy, iterate more, else ship". I've been through several different of these "cool new methodologies" and none of them have been a magical solution to programming errors, short schedules, lack of proper funding and project mismanagement. It's that only in books that are filled with snake oil. This is not to say that some of that stuff might not have its advantages, but..

I would like to add that one thing that plagues game development probably more than than any other software industry is that you can't just build game up to specifications and then be happy with it, unlike you could build let's say an e-mail client or a some bit of banking software that generates reports or whatever. You have to be able to realize when some approach isn't going to work, rethink, iterate a lot and try to find the fun in it. This puts its own pressures onto the process.

Lets just say that, indeed, methodologies to keep tighter track on development are (mostly still slowly) being introduced -- the need for this, and here it is again, because rapidly growing project scale left little room for oldschool individualism, self-management and simple management in general. As for bugs, almost all studios now use quite advanced bug tracking software controlled in a certain chain of command. As regular large-scale software development probably already did years before.

But somewhere I get the feeling that you just don't want to listen and are waiting for an answer you'd like to hear or maybe even want to give yourself? What is up with that..

as a gamer i know TEH ultimate soluce, specially for multiplayer games : 'when it's done' postponement and more or less public beta testing :p

see Blizzard or Valve, they have enough power (cash, management, popularity) to trigger long shipping delays and long beta testing periods :)

Actually.. I think that game development methodolgies have changed massively for the better since the times of the PS1 - these days we have Post It notes in colours other than yellow

just like Duke Nukem Forever, eh?!

Well lets not forget my original question.



I'm not fishing for specific answers. I'm just wondering what types of differences there are between now and then. I think the bugs are getting worse, regardless of the complexity. This is my opinion, bash all you want :P

I think the answer to the bugs problem is time. Everyone wants to do more faster, to make more profit, minimize cost, etc. Given enough time you can eliminate most if not all critical bugs in a system. Perhaps ps1 games got more dev time, or more testing done, whatever.

I asked a very simple question to begin with, and I had a very bad feeling about answering the question asking what my research was about. I'm interested in hearing about what people think, and getting new/wider perspective on the problem. But, for whatever reason, it all seems to turn personal.

All of a sudden, damn me for not agreeing. There is no way someone who doesn't agree could have ever worked on a big project. Wtf does that even matter!?

If it seems that I don't want to listen, its because my question is being taken out of context, or maybe I'm just not asking my question in the right wording.

Errr.. while the definitions may be new, the concepts are old. Really old.

Where I work, we adore to the "basement style" process, which is essentially an even more agile form of "agile development". We rely heavily on iterations, everything is constantly changing to meet new requirements, testing is central to the development, our documentation is spread across an internal Wiki (bad idea btw, but that's another story) and post-it notes and so on. This is the way most indy developers work (at least in my experience), and it's the way it's been done since the 80's. The game dev industry might have been/is miles behind those "fancy" processes the traditional software industry utilize, but the game industry has always been miles ahead when it comes to "organized chaos" ;).

And also, those I've talked to from major first/second party developers confirm that there is still quite a lot of the same mentality nowadays even with the big guys, but mostly on the development tier (which is the relevant one in this case).

The bugs are getting worse because the software is more complex and the interactions between the different parts of the software are both more complex and more unpredictable. The relationship between project size and bugs is not linear. Also, with PC software, you need to take account the huge number of different configurations of hardware it runs on. That cannot be compared to an uniform development environment, and it causes its own problems when doing stuff that's running both on PC and XBOX or whatever, not to mention mobile development. There's also an issue of using and integrating third-party libraries such as FMOD or Scaleform or Unreal Engine whatever, it's not about banging hardware with assembler anymore.



Yes, that is what doing business is all about. Also, I would wager that game developers by average are older now, with families to feed and mortgages to pay off, and can't afford churning out games in their basements out of pure passion and hope of a publisher taking it some day.



What, exactly, was wrong with the answers you got, except that they don't "feel right"?



Because it gives you perspective and hands-on experience on things you wouldn't think have any relevance, but actually do. The amount of bureaucracy and stuff quite unrelated to the actual development (=programming) cannot be underestimated, nor can the effect of working on a team, having actual project management, company politics and so forth. Personally, after becoming a professional developer, this stuff caused me all kinds of amusement, grief and other assorted emotions from the entire human range. The actual technical part was a breeze, the amount of nontechnical things starting from how a source control should work in our company to the documentation processes and coding conventions were where I both did my worst mistakes and had the most to improve on. And they really are things that a guy working alone or with a couple of friends doesn't need to care about.

Developers don't lead software projects. Managers (and often several levels of them) do, according to processes. Sometimes with more common sense and understanding, sometimes with less. Also, publishers make requirements that you might need to fulfill, or market research shows that the stuff you're working on might not just make sense, and so on. There are all kinds of issues that are not encountered in smaller projects.



What would be the "right context" then? You asked why games seem to have more bugs today, a bunch of actual professional game programmers with experience on the industry answered. What more could you want?

Well when you put it like that... So game from that era are just more simple. Its not that developers or methods got any better or worse, they just started having to do more and more complex tasks.

We already put it like that on the first page though :)

the buzzwords are new, and some don't even apply (there's not much RAD on any embedded platforms, as a general rule).

the one big reason has been mentioned already several times, which is the far lower complexity of ps1 games compared with the current crop. and that doesn't just mean gameplay, the complexity increase of the hardware itself is already mind-boggling. the original PS1 libraries offered you a couple of functions to transform and project vectors and draw individual triangles - that's the level 3d was at at the time (of course, optimized engines would do this themselves, but they'd still be working on individual triangles).

the PS1 had a 33mhz R3000, 2MB of RAM, and a graphics chip whose capabilities peaked at "texture and gouraud shading simultaneously". everything you could fit in there was a lot simpler than anything you have in any game today, because it had to be. and the less code there is, the less things there are that could go wrong with it.

the average xbox360/ps3 game has more bytes in compiled shaders than most ps1 games had in overall code. i don't think there's much need to explain beyond that.

What about middleware? Does it take off significant workload, do you guys [game dev people] use it at all, how widespread is its use today?

Wait, what? This isn't the Random Girl with Hardware Thread thread?

Nice comparison btw :)

Damn Baz, good call! Thats my fav thread. =D

I found the answer to this. I was reading ch 16 from The Art of Unix Programming, and suddenly I realized the answer. Today there are more people peddling closed source libraries and addons. Your boss buys em and tells you to work with them. Weather the library your boss bought was made for the task at hand, or not, or if it is not a good solution you have to "find a way" to make it work. This leads to bugs.

I had a personal experience with this. I was working on some business management software and the company I worked for had purchased the Telerik Rad tools. These "rad tools" are a kludge at best, and it took a lot of time to get them working like they were supposed to. I found myself writing layers of code between the rad tools, and the software I was working on, just to sort of "wedge" the rad tools in. It was buggy and slow ( I could have avoided some of the bugs if I had more time ).

If I had the src to these tools, or some documentation, It would have been tons better, and a lot of bugs could have been avoided ( and in less time ).

I think the game industry now days must be like this. You end up working with libraries where you cant see the source, or know whats going on behind the scenes. Too many "black boxes". I'm willing to bet back in the ps1 games era, there were far less people peddling low quality closed source libraries and things like that.

I just have to add that this is not "THE" answer (I don't think there is a single answer), but I think its a big part of the problem. It is also a good answer to my original question. Back then, there were less people selling and using closed solutions.

Yes, that must be it.

No that can't be it, because if the all mighty all knowing, seasoned professional Preacher does not agree, then to hell with it. If Preacher says that the answer is that software these days is more complex, and had nothing else to say on the topic, than GOD DAMNIT thats it!!! There is no other answer than what you have to say man. Whatever.

Xteraco: you are totally right and Preacher is wrong of course.

Listening to the theories of Sir Eric S. Raymond who probably never wrote a full commercial game is wiser than listening to those people who posted here and who actually work in the videogame industry and who deal with all those problems on a daily basis.

this thread has the fun factor!

xteraco, if you are not interested in the opinions of other people, why did you start this thread anyway?

you can be glad, that you got any serious answers, and that this thread is not yet pouetized

It just won't stick!