Preview Worthplaying previews Oblivion

[HardCode]

This is the problem with the industry now, you get people designing and making games that aren't expert in their implementation. I know he's a programmer, not a designer, but still this implies a disconnect.

No, it implies you are ignorant of the programming profession. While not a game programmer, I am a programmer by trade. We are given specifications, from which we design the software. We need to care less WHY it is being designed this way, just that we need to actually make it work that way.

If the Bethesda specifications tell Steve to create a system that does X, Y, and Z, he doesn't need to know that from an RPG point of view it's stupid and dumbed down. He just needs to make it happen.

Non-programmers should STFU about critizing the programmers. It's different if the combat system is buggy as all hell, then let MSFD have it both barrels. But as far as the design, bitch to the game designers and those who could overrule their decisions, but don't.

 

[pseudo intellectual]

This is the problem with the industry now, you get people designing and making games that aren't expert in their implementation. I know he's a programmer, not a designer, but still this implies a disconnect.

No, it implies you are ignorant of the programming profession. While not a game programmer, I am a programmer by trade. We are given specifications, from which we design the software. We need to care less WHY it is being designed this way, just that we need to actually make it work that way.

If the Bethesda specifications tell Steve to create a system that does X, Y, and Z, he doesn't need to know that from an RPG point of view it's stupid and dumbed down. He just needs to make it happen.

Non-programmers should STFU about critizing the programmers. It's different if the combat system is buggy as all hell, then let MSFD have it both barrels. But as far as the design, bitch to the game designers and those who could overrule their decisions, but don't.

While it may be unecessary for a programmer to understand the "why", I believe it improves the output if he does. The execution of design is a tad different in the game world as there's the added dimension of having to make the product "fun".

 

[Tintin]

pseudo intellectual, there's been like 3 people now who've made you look stupid, why don't you just quite while you're...not too far back.

 

[pseudo intellectual]

pseudo intellectual, there's been like 3 people now who've made you look stupid, why don't you just quite while you're...not too far back.

 

[Twinfalls]

original, NOT

 

[Micmu]

pseudo intellectual, Titintin is gonna send you to that infamous bookstore.

 

[Chefe]

Don't steal my Tintin insulting techniques, dumbfuck.

 

[Section8]

For characters, we have worked our system of facial animation into the Speechcraft skill. Whereas in Morrowind persuasion was simply an invisible die roll against your skill, we’ve created a persuasion system where you look carefully at an NPC’s expression to determine how they’ll react to certain forms of persuasion.

It's interesting, but something about it bothers me. I know that realism shouldn't take precedent over gamism, but that persuasion system goes completely against any normal form of communication. Precognitive reactions from NPCs?

To me, it seems a more reasonable abstraction that speechcraft is the art of climbing out of a hole you've dug yourself by saying the wrong thing, and not simply knowing the right thing to say, or doing so in a manner that mitigates a negative response.

"Have you heard the one about the orc in a party dress?"
"Must you be so crude?"
"Oh sorry, I should have realised your sense of humour was more sophisticated. How about a daedroth in a party dress?"
"Now that I gotta see! <closes up shop to point and laugh at the daedroth>"

 

[HardCode]

While it may be unecessary for a programmer to understand the "why", I believe it improves the output if he does. The execution of design is a tad different in the game world as there's the added dimension of having to make the product "fun".

You're missing the point. The programmer does NOT "make the product fun". He looks at the written system specifications and he follows that TO THE LETTER. It's not his job to add his own creativity in the game as he is following the design specifications. Now, that doesn't mean that the programmer does not offer input in meetings and such, and those suggestions are approved by moronic game designers and PR personnel, but fuck him if he decides on his own to change things as he writes the code. He'd be out of a job very fast.

 

[pseudo intellectual]

While it may be unecessary for a programmer to understand the "why", I believe it improves the output if he does. The execution of design is a tad different in the game world as there's the added dimension of having to make the product "fun".

You're missing the point. The programmer does NOT "make the product fun". He looks at the written system specifications and he follows that TO THE LETTER. It's not his job to add his own creativity in the game as he is following the design specifications. Now, that doesn't mean that the programmer does not offer input in meetings and such, and those suggestions are approved by moronic game designers and PR personnel, but fuck him if he decides on his own to change things as he writes the code. He'd be out of a job very fast.

Thanks for being reasonable Yes I see your point. This is usually the case in a larger organization, however in a small studio setting programmers have more leeway in making decisions on a micro level on how to implement game mechanics within the larger design framework. They have this freedom due to the fact that there may not be more than one designer, or the producer is the sole designer.

Another thing to remember is that in the game industry the programmer can often be the primary designer. Chris Taylor and Brad McQuaid come to mind. This is perhaps the optimal scenario, certainly based on conversations I've had with programmers.

 

[Tintin]

pseudo intellectual, there's been like 3 people now who've made you look stupid, why don't you just quite while you're...not too far back.

JUST FOR YOU !$@%

lolzolzolz

 

[bryce777]

While it may be unecessary for a programmer to understand the "why", I believe it improves the output if he does. The execution of design is a tad different in the game world as there's the added dimension of having to make the product "fun".

You're missing the point. The programmer does NOT "make the product fun". He looks at the written system specifications and he follows that TO THE LETTER. It's not his job to add his own creativity in the game as he is following the design specifications. Now, that doesn't mean that the programmer does not offer input in meetings and such, and those suggestions are approved by moronic game designers and PR personnel, but fuck him if he decides on his own to change things as he writes the code. He'd be out of a job very fast.

Hahaha.

Again, where you get this silliness on what programmers do, I don't know.

There is always some element of design for a programmer, no matter how low level they are.

Also, in fastpaced environment 'specifications' are so loosely defined as to be nonexistent. You cannot spend years designing the project and then code it all up in the last 4 weeks, and game companies don't have the size and busines plan for it to make sense to make a big design document and then hire 30 coders to spend 6 months implementing it but they have to have a small team that works constantly.

It is also impossible to define requirements 100%. For instance you can't say "The animation shall move on the screen at a rate of 10% of the screen length per second at full speed." Programmers have to do a lot to fill in the blanks, and there are always areas where a system design document will fail. The key is to know what is important to have defined from the start and to get prototypes out as soon as possible to make adjustments.

 

[Balor]

This + this = Tintin.

 

[Tintin]

This + this = Tintin.

I agree with the first one.

I don't see how I am the second one. I can make a list of all the things I don't like about Bethesda if you wish.

But I guess since I don't hate Oblivion and make don't make stupid sarcastic remarks 24/7 - FANBOI !!!

 

[kingcomrade]

This + this = Tintin.

That site rules.

 

[MrSmileyFaceDude]

Hm, I've put a lot of input into how my systems (combat & magic) were designed, from gameplay and game systems standpoints as well as technical. I've suggested unrelated features that have ended up in the game, as well. We're all encouraged to provide input. So I'm not going to claim that I'm programming solely from requirements -- I helped to define a lot of the requirements for my systems. And a lot of what went into those suggestions came from feedback about Morrowind, internal and external, in addition to my own experiences with the game.

It's certainly helpful for a game programmer to have knowledge about the game beyond just the technical aspect, and the level of importance is dependent on what that programmer is working on. I know a lot more about The Elder Scrolls and about RPGs in general than I did when I started working for Bethesda, and I'm doing what I can to learn more -- which is one of the main reasons I frequent this site.

Now pseudo intellectual, if you still want to call me to task for that, I think that's unreasonable.

 

[Balor]

Well, you can hardly blame someone for wanting to learn - only for not wanting to learn hard enough, I guess .
You have my respect for that, MSFD. For real .
...
If only game designers were as open-minded as you... or cared for more then sales figures, for that matter.

 

[caveyboy]

yeah the first matches him but not the 2nd

 

[caveyboy]

im more of a
http://redwing.hutman.net/~mreed/warriorshtm/bigdogmetoo.htm

 

[Tintin]

caveyboy should have admin powers.

 

[pseudo intellectual]

Hm, I've put a lot of input into how my systems (combat & magic) were designed, from gameplay and game systems standpoints as well as technical. I've suggested unrelated features that have ended up in the game, as well. We're all encouraged to provide input. So I'm not going to claim that I'm programming solely from requirements -- I helped to define a lot of the requirements for my systems. And a lot of what went into those suggestions came from feedback about Morrowind, internal and external, in addition to my own experiences with the game.

It's certainly helpful for a game programmer to have knowledge about the game beyond just the technical aspect, and the level of importance is dependent on what that programmer is working on. I know a lot more about The Elder Scrolls and about RPGs in general than I did when I started working for Bethesda, and I'm doing what I can to learn more -- which is one of the main reasons I frequent this site.

Now pseudo intellectual, if you still want to call me to task for that, I think that's unreasonable.

I think if you review my comments you'll find that I've never taken you to task for your abilities or performance. I merely questioned your motives for being here. I'm satisfied at this point that your stated reasons are plausible.

 

[Chefe]

I think if you review my comments you'll find that I've never taken you to task for your abilities or performance. I merely questioned your motives for being here. I'm satisfied at this point that your stated reasons are plausible.

What are your "motives" for being here?

 

[Balor]

This, I bet.

 

[Tintin]

Hey come on Balor, not ignoring my reply now are you?

 

[voodoo1man]

I've been programming for over 26 years...

So when it comes to designing software, I damn well know what I'm doing.

There's plenty of COBOL weenies that have managed to hang in longer than that. I wouldn't say they know what they are doing. Certainly I think you should make a distinction between being a programmer and being a software designer. Implementing a program from specifications is most certainly not software design - it's programming at best, a task for your trained force of H1B code monkeys at worst. And that's why software sucks so much - the programmers don't get involved in design, and as a result have absolutely no motivation to make a good product (passing all the tests does not make it a good product), and that's assuming the specification itself is reasonably complete, which never happens. So you end up wasting over a billion dollars with nothing to show, like our wonderful government of Canada did on their super-duper-nazi integrated electronic gun registry.

I mostly agree with bryce777. I've done some small contract and part-time programming jobs, and know a few people who do it as a career, and from what I see I want to stay as far away from this system as possible. I don't know what it was like in the 70s, but it seems to me like the "software crisis" never really went away.