Playstation 1 era Software development methodologies?
category: general [glöplog]
Wait... You did *start using* CVS? You mean voluntarily?
I guess it's better than no version control at all, but a 2 week old sandwich is also better than nothing if you're starving
I guess it's better than no version control at all, but a 2 week old sandwich is also better than nothing if you're starving
I can comment on the three PlayStation 1 games I've been working on:
- Time Commando
- Little Big Adventure (ported from PC)
- VRally 2
The two first have basically been written by two coders, and are possibly bug free (ie: bugs have not been found), while the third one which was made by at least 8 programmers can be crashed by at least 3 different methods before you even started playing (just going in and out of the menus will make it crash with a red screen).
The two first have been through the SCEE validation process only once, while the third one has been at least twice (and I suspect that some money was given to sony to let it pass).
I don't know if it tells much about processes, but in the first team we were working with MSDOS on a novell-network share, using the default sony provided compilers and debuggers, while on the third project we had source control, windows 98 with visual IDE's and code warrior...
- Time Commando
- Little Big Adventure (ported from PC)
- VRally 2
The two first have basically been written by two coders, and are possibly bug free (ie: bugs have not been found), while the third one which was made by at least 8 programmers can be crashed by at least 3 different methods before you even started playing (just going in and out of the menus will make it crash with a red screen).
The two first have been through the SCEE validation process only once, while the third one has been at least twice (and I suspect that some money was given to sony to let it pass).
I don't know if it tells much about processes, but in the first team we were working with MSDOS on a novell-network share, using the default sony provided compilers and debuggers, while on the third project we had source control, windows 98 with visual IDE's and code warrior...
little big adventure was such a great game! :-) i loved it!
Quote:
- Little Big Adventure (ported from PC)
ditto that - awesome game!
How can you create games that are so bug free they don't need patching?
a) you must.
b) fear of master disk testing.
shipping bugged games is not an engineering problem, it is a business decision.
it is important to understand the power of master disk testing. imagine a QA department that has the absolute power to kill the game if they find a serious bug, with no responsibility to your budget at all.
it is a bad business decision to send a buggy game to master disk testing. when sony / nintendo / microsoft disapproves your game, they don't care weather you run out of money or not. and they will disapprove it again, and they will get even pickier and a bit mad if you fail too often.
a) you must.
b) fear of master disk testing.
shipping bugged games is not an engineering problem, it is a business decision.
it is important to understand the power of master disk testing. imagine a QA department that has the absolute power to kill the game if they find a serious bug, with no responsibility to your budget at all.
it is a bad business decision to send a buggy game to master disk testing. when sony / nintendo / microsoft disapproves your game, they don't care weather you run out of money or not. and they will disapprove it again, and they will get even pickier and a bit mad if you fail too often.
Most important: Skilled developers have abandoned game developing because of low salaries and alot of (unpaid) over time.
Not so important: More graphics and architectures built upon old architectures and so on.
Not so important: More graphics and architectures built upon old architectures and so on.
Also, do not listen to the techy people here involved in game developing. They would prety much get their ass kicked if they told you why *their* games are buggy at shipping.
How can you create games that have so few bugs that they don't need patching?
i heard the argument "more time is not the solution". it's the wrong argument. patching a game after shipping is just "more time", therefore patches are not a solution? there are patches. what is the problem patches solve?
making patches costs money. more precisely: fixing bugs after shipping costs more money than fixing bugs before shipping. at least two times i would guess. at least.
the only reason why capable businessman want to pay twice for the same thing is the fear of missing a deadline stated in a contract. time. patches mean more time without penalty payments.
the solution to fear is more fear: master disk testing. just force your boss to shut up. it will pay of long term anyway, unless you run out of money meanwhile ...
just one hint: why was GTA3 on PS2 so buggy? because sony wanted that game. i imagine sony QA had pressure to pass GTA3. i can't imagine any of my games to pass MDT with reproducible crashes.
*** software bugs are a business decision, not an engineering problem. you can survive in software industry with bugs. ***
my father spend all of his professional life doing mechanic calculations of houses and industrial buildings, and not one of them collapsed (till today). if there is a business pressure not to fail, you will get it right. your boss will want you to get it right. a building company that builds houses that frequently collapse would be out of business soon.
i heard the argument "more time is not the solution". it's the wrong argument. patching a game after shipping is just "more time", therefore patches are not a solution? there are patches. what is the problem patches solve?
making patches costs money. more precisely: fixing bugs after shipping costs more money than fixing bugs before shipping. at least two times i would guess. at least.
the only reason why capable businessman want to pay twice for the same thing is the fear of missing a deadline stated in a contract. time. patches mean more time without penalty payments.
the solution to fear is more fear: master disk testing. just force your boss to shut up. it will pay of long term anyway, unless you run out of money meanwhile ...
just one hint: why was GTA3 on PS2 so buggy? because sony wanted that game. i imagine sony QA had pressure to pass GTA3. i can't imagine any of my games to pass MDT with reproducible crashes.
*** software bugs are a business decision, not an engineering problem. you can survive in software industry with bugs. ***
my father spend all of his professional life doing mechanic calculations of houses and industrial buildings, and not one of them collapsed (till today). if there is a business pressure not to fail, you will get it right. your boss will want you to get it right. a building company that builds houses that frequently collapse would be out of business soon.
mmm this thread is getting more and more interesting, thanks to game developers for sharing their experience and (sometimes) wisedom :p
chaos kind of nailed it. not only GTA3, but almost all "launch titles" for a console sometimes suffer even the most obvious bugs (e.g removing a disc during a loading screen causing the whole thing to hang up, now that's just 1-0-1 stupid) -- a calculated risk was taken (who takes them out anyway?) and the thing was released anyway. with 10 more of such bugs.
but hey, it's a in a box, it's in a store and it generates sales.
but hey, it's a in a box, it's in a store and it generates sales.
The problem also lies with the customers, because they buy buggy games. I mean, at least with Gothic 3, a couple of magazines didn't give a review score or subtracted 10 points because it was soo buggy. But if there are still millions of customers buying the game when they exactly know that it won't be really playable until version 1.3, it confirms the business decision of putting out a buggy version in the first place.
Do people return games they've bought because of bugs?
In the cell phone biz, when managers guestimate return rates, they usually end up at like 10%.. though the bulk of that is due to hardware errors.
I remember back in 2007 that there was a bug on the RTL SW that under some circumstances could fuck up parts of the file system, which would make you lose all audio during calls - requiring the phone to be reflashed (oops!). A few hundred thousand phones had already been flashed with that SW by then iirc..
In the cell phone biz, when managers guestimate return rates, they usually end up at like 10%.. though the bulk of that is due to hardware errors.
I remember back in 2007 that there was a bug on the RTL SW that under some circumstances could fuck up parts of the file system, which would make you lose all audio during calls - requiring the phone to be reflashed (oops!). A few hundred thousand phones had already been flashed with that SW by then iirc..
I have no figures to back it up but I think: no. More returns will be because of defective discs (resulting in disc errors, allthough this also might very well be because of a faulty console -- then again I'd test my console with multiple discs) or people just flat out not liking the game they bought (in most countries it's your right to return something within 14 days or so). This might be because of a bug, but not often I guess. Some creepy releases aside, most games do not ship with bugs that are either friggin easy to reproduce or consistently adversely affect gameplay. Unless you're talking about shoddy framerate of course :)
Quote:
consistently adversely affect gameplay
This of course is very subjective (*cough* GTA *cough*)
Also, PC market is different as there are no vendor checks you *have* to go through. This is different if you want that 'Games for Windows' stick on your box but I'm not sure if that's comparable to a console vendor check. From what I remember it used to be more about installer / ease of use issues, but it might have evolved and become a bit more serious.
i still love that EVE Online bug where they somehow managed to fuck up the boot.ini :D
Ouch.. yes.. the cert process for console games can be a nightmare if it's not done correctly, but in theory it *should* catch all serious game bugs and ensure that games follow certain guidelines (ingame speech to have subtitles, animated loading screens so that games doesn't appear to have hung, etc) before they are released.
However, as others have said, it really does vary from company to company. I've worked at places that have bad relationships with certain console license holders and they have had a lot of trouble getting through cert while games for other companies (usually big titles from 1st or 2nd parties) breeze through with glaring bugs and violations. Still, I work 1st party now so I'm looking forwards to seeing how cert works this time ;)
However, as others have said, it really does vary from company to company. I've worked at places that have bad relationships with certain console license holders and they have had a lot of trouble getting through cert while games for other companies (usually big titles from 1st or 2nd parties) breeze through with glaring bugs and violations. Still, I work 1st party now so I'm looking forwards to seeing how cert works this time ;)
it can be politics yeah -- what i've tried to do for the few games where i was supposed to look after most/all cert rules (ports, mostly) is really focus on getting the basic rules right (startup time, loading screens, always proper disc error handling, consistent messages, 'luxury' screenwipes and taking care of audio/inputas properly as one can)
at least ms and nintendo really seem to like that extra effort, makes them overlook some other glitches quicker than they would otherwise. but that's just from a few experiences where i was directly busy with the submit process / reviewing vendor bug reports.
at least ms and nintendo really seem to like that extra effort, makes them overlook some other glitches quicker than they would otherwise. but that's just from a few experiences where i was directly busy with the submit process / reviewing vendor bug reports.
oh and lets not forget the 2 bigger bitches: saving/loading and network issues.