Just in case you were wondering

[@\NightandtheShape/@]

That's QA not programming.

 

If the programming was done right there wouldn't be a need for QA.

 

Spoken like a true ignorant whelp!

[Sand]

Spoken like a true ignorant whelp!

 

All I care about is when I install a game that it works. If it doesn't, its bad programming. If it does, then its all good.

 

As a game PLAYER what else do I need to know?

Edited February 7, 2008 by Sand

[Tigranes]

*cough*

 

While we discuss the line where bugs become big evil nasty bugs of game-breaking doom, maybe we forgot about the line between arguing and handbags.

 

Now, I can perfectly sympathise with the logic that even the best of codes will always have bugs, and QA exists precisely because it's not possible for a genius programmer to just have a wee glance and say "a-yep, there's a game-breaking bug right there". I can't program anything myself, but I think I get that. I'm not rubbishing Sand's argument either, though to me it feels like his complaint should be better directed against the development team itself and its mode of organisation, rather than the programmers; it would still be a valid complaint to raise against Tim Cain/Troika. You can program really well and still have game-breaking bugs; you can QA extensively and there can still be serious bugs; but the sheer quantity and ferocity of the bugs encountered on all three of Troika's productions are perhaps better attributed to the way in which Troika scheduled and organised its QA, and had its programmers react to the QA. I mean, I suppose it could have been that the code was so full of back-doors and work-arounds that the more they touched it the more the sand-castle fell apart, but I can't possibly make that assertion without having even looked at the said code.

 

Or am I even farther off the rails here?

[Istima Loke]

Spoken like a true ignorant whelp!

 

All I care about is when I install a game that it works. If it doesn't, its bad programming. If it does, then its all good.

 

As a game PLAYER what else do I need to know?

 

 

You need to know that the the bug is, technically speaking, the programmer's fault (though it's impossible to not happen) but the fact that you bought a game with bugs is QA's fault.

Edited February 7, 2008 by Istima Loke

[Nick_i_am]

That's QA not programming.

 

If the programming was done right there wouldn't be a need for QA.

 

Okay, you've officially just dropped from 'hooting peenhole' to 'jibbering idiot'.

[Gorth]

That's QA not programming.

 

If the programming was done right there wouldn't be a need for QA.

 

Okay, you've officially just dropped from 'hooting peenhole' to 'jibbering idiot'.

He does have a point you know. Problem is just that he places the cause of faulty programming squarely on the shoulders of the programmer.

 

Programs can have bugs for a number of reasons, errors in the logic on a design level, poorly written specs, sloppy programmers, simple accidents (misread specs, typos etc.), poor QA procedures, bad time constraints (a management problem), unskilled programmers, poor task coordination/project management... a long list really

 

It can be the programmers fault, it can also be any number of other people involved in the process' fault.

[@\NightandtheShape/@]

There are bugs and there are bugs. Minor bugs I don't care to much about. I can still play the game and get some fun out of it. Bugs that makes a game fail to load or constantly crash, which should be a glaring clue something is not right with the code, should be caught prior of release if the programming staff were competently skilled.

 

Okay, let me explain this to you in simple terms. When I write a program I write it using the hardware, and software which is on my current machine. That goes for driver, api's, redistributables etc... PC's have an amazingly large amount of different setups in both a hardware sense, in regards to motherboards, graphics card vendors, hard drives, processors etc... And a software sense. But when you run that software it is likely to be on an utterly different machine with a different setup entirely.

 

To track down every possible occurance of a bug software much be tested on EVERY available setup, this is both impractical and impossible, though companies due try to ensure that they test on as many machine setups as possible. There is always a matter of 3rd party software which can be thrown into the mix which is unknown, and may have an effect on the outcome.

 

Interestingly enough I haven't suffered the same problems with ToEE that you have it runs perfectly fine for me on all my systems, which all have different setups, but for you the game fails. You say that it is bad code, but it can't be all bad as it works fine for me, I too am a user and it runs, and is stable. Your setup is entirely different, and in that case it doesn't run, it was most likely never tested on your exact setup, the difference between my machine and your machine could simply be who developed the graphics card. An example of this experience was experienced by myself when I bought 2 seperate gfx cards, which had exactly the same chipset, the none brand GPU which was cheaper wouldn't run Black and White 2, where the PNY GPU was happy to run Black and White 2.

 

It is for these reasons that in general console development is seen as a good thing by developers because they're working upon identical hardware, hopefully using identical firmware.

 

You claim that the reason ToEE doesn't work for yourself is because of bad programming, it is more accurate to say that the code must be fine as many people have infact managed to play and finish the game with only minor hiccups, another testiment to this would be that I was unable to finish NWN's upon release without the entire game breaking, where Volo had 0 problems. To this day NWN's will not run on my old laptop using the onboard sound, it runs fine with an external sound card. I do not attribute this to the fact that NWN is coded badly, it's because the onboard sound chip is actually crap, having crap drivers etc...

 

Even in the event that a company managed to test a game on every single setup and possible configuration, of which would take many many years, it may very well be that what fixes the software for one machine then breaks it on another machine. And you have to bare in mind that the amount of code that exists within a game is infact rather large, so the desire is to get the game to work on as many setups as possible.

 

Its very easy to write a program that functions perfectly well on one machine with absolutely no hiccups, but when its on another machine it reboots the computer, I've actually managed to do this. Is it because my code was bad, or was it that the second machine didn't exactly have the correct specifications, or better still was it a combination of both... The truth of the matter is that the second machine didn't have enough video ram, and that I hadn't coded any memory management so it was infact a problem with both the code and the hardware despite the fact that it worked flawlessly on a different machine with higher specifications.

 

So let this be a lesson to you, always buy quality parts, always keep gaming PC's unbloated and always without a doubt DON'T DOWNLOAD PR0N!!!!

[Sand]

Nice assumption you made there. I don't download porn. At all.

 

Using my gaming rig I only go to trusted sites, such as this one, and I do take have various safeguards in place. My gaming rig, and my gaming rigs in the past, have been clean and hard drives defragged weekly. Also I only get hardware from manufacturers I trust. ATI, BFG, Creative, EVGA, and Western Digital are manufacturers I use in each rig. I only go back and forth on AMD and Intel depedning on prices. I also only buy hardware from one source. Newegg. They have been damn reliable. Given all that I very much doubt it was a hardware problem.

 

You say you had no problems with the game. Fine. Good for you. I can only go by my experience with the game and my experience only. In my experience with the game, in my opinion its bad programming. You are not going to change that opinion nor my opinion of Tim Cain.

[kirottu]

Edited February 7, 2008 by kirottu

[Darth Drabek]

Okay, let me explain this to you in simple terms...

 

Very informative post. Interesting thoughts about why some programmers prefer consoles.

 

It seems like these days PC gaming is a whole lot of work for not enough of a reward. I don't want to have to finagle with my virtual memory or tweak my antialiasing settings to get a game to run well.

 

Viva la console!

[Sand]

That is one of the reasons, as a game player, I am moving towards consoles. I spent my PC upgrading money on a XBox 360 Elite and I have absolutely no complaints.

[Nick_i_am]

Programs can have bugs for a number of reasons, errors in the logic on a design level, poorly written specs, sloppy programmers, simple accidents (misread specs, typos etc.), poor QA procedures, bad time constraints (a management problem), unskilled programmers, poor task coordination/project management... a long list really

 

It can be the programmers fault, it can also be any number of other people involved in the process' fault.

 

I suspect that those saying 'it can be the programmers fault' are those who've never actually done any real programming. It's not passing the buck, there is such a thing as bad programming, but programmers DO check their own code. The real problem comes with conflicts with other peoples code and conflicts with hardware on which the code hasn't been tested. Full games that havn't been properly QAed are ALWAYS unstable, ALWAYS. Look at KotoR2, look at Hidden and Dangerous.

 

Likewise, the reason why console games are so relatively unbuggy is the fact that the hardware is standard, so hardware conflicts are nil.

 

Point is you can no more blame a programmer for real bugs in a game than you can blame a bus driver for being delayed by traffic and any notion to the contary simply shows a general ignorance of the process.

[Sand]

Since Tim Cain was the Lead Designer and Project Leader it was his responsibility to release a working product. Also it looks like Troika didn't have a QA team on this which falls on the Project Leader's head. I guess ToEE's failure in design and programming is shared by Atari and Tim Cain, but still I don't see how people can give such praise to a man who has only one good game under his belt in 10 years.

[Nick_i_am]

Yeah, i'm not defending the guy and don't care if his leadership abilities compounded the fact that there was no money available for QA or not.

[Dark_Raven]

Since Tim Cain was the Lead Designer and Project Leader it was his responsibility to release a working product. Also it looks like Troika didn't have a QA team on this which falls on the Project Leader's head. I guess ToEE's failure in design and programming is shared by Atari and Tim Cain, but still I don't see how people can give such praise to a man who has only one good game under his belt in 10 years.

What are you faping about? If the publisher tells them to release a playable version (doesn't mean bug free) of the game, release they must. Same went with K2 with Obsidian. Deadlines have to be met whether its bug "free" or not.

 

Troika

 

Bloodlines Read the sections under development and patches.

[taks]

that's why there are contracts, which would also fall on the developer to stick to...

 

taks

[@\NightandtheShape/@]

I certainly wouldn't try to absolve trokia of their mismanagement... I also forgot that sarcasam is wasted on sand.

 

If Tim Cain's role was Lead Designer and Project Leader, then he had nothing to do with day to day coding standards. So he as an individual cannot be credibley fingered as a bad programmer by your own definition. as he would have had nothing to do with the programming aspects and more to do with development timeframes, and general overall game design.

 

Console's are more stable to develop for but they have their own pitfalls as the code generally has to be tighter due to the general constraints of the machine, but also in effect you tend to be able to do more with what you have and the main issue is then that of memory.

 

Opening up the power of all those core's on the 360 isn't an easy job, and the fact the processor is also in order also presents its own challenges in regards to optimisation.

 

Core Design were a fine example of how a company can go from being extremely rich, to being bought out by another company entirely, due to mismanagement...

[taks]

as he would have had nothing to do with the programming aspects and more to do with development timeframes, and general overall game design.

100% correct and a large portion of why i always felt troika failed. if he is such a good coder, that's what he should have had a larger role with. #1 rule of business: stick to the knitting (i.e. do what you're good at). good programmer != good developer. heck, even having good ideas about games, apparently fallout being one of them, is not sufficient for good game development.

 

taks

[@\NightandtheShape/@]

as he would have had nothing to do with the programming aspects and more to do with development timeframes, and general overall game design.

100% correct and a large portion of why i always felt troika failed. if he is such a good coder, that's what he should have had a larger role with. #1 rule of business: stick to the knitting (i.e. do what you're good at). good programmer != good developer. heck, even having good ideas about games, apparently fallout being one of them, is not sufficient for good game development.

 

taks

 

While this is often very true, sometimes it's rare but sometimes programmers make excellent producers, and managers.

 

I've seen it so I can believe it, but I don't think its common.

[Sand]

Well, with the exception of Fallout, a game 11 years old, what examples of Cain's programming work do we have to determine if his skill is "fine" or not?

[@\NightandtheShape/@]

Well, with the exception of Fallout, a game 11 years old, what examples of Cain's programming work do we have to determine if his skill is "fine" or not?

 

Articles in programming books that I've read, that's mostly where I formed my opinion of him as a programmer...

[taks]

While this is often very true, sometimes it's rare but sometimes programmers make excellent producers, and managers.

 

I've seen it so I can believe it, but I don't think its common.

don't get me wrong, i'm not trying to imply that they can't be good at both, just that being good at one is no measure of an ability in the other.

 

what always irks me in the engineering world is that often the managers are promoted out the rank and file engineering staff. on the surface, this seems like a good idea, but rarely does it work out in practice. in fact, often the managers weren't very good engineers, either, which is why they went in to management in the first place. then you end up with someone running the show that's both a bad engineer and a bad manager. ugh. you can even see the same problem in sports. the best coaches weren't necessarily the best players (or players at all). talents seem to be confined to very specific skill sets and management doesn't overlap with implementation very well in many cases.

 

taks

[taks]

my guess, btw, would be related to the whole "right brain," "left brain," idea, for whatever that's worth. i.e. some people are really good at resolving the highly analytical tasks related to solving algorithmic problems (i.e. math), while others are good at tasks related to organizational and human behavior problems (management is both).

 

personally, not that it matters, i'm terrible at the latter so i have no idea what that should involve.

 

taks