And a passion for games...

[nef]

Originally Posted by Zooch

I'm going to be honest. I read the posts that had my name in them, but that was it.

I'm really starting to think we're just arguing over semantics. You're correct in that I'm predominately a designer, but it's my job to know every aspect of the game design process, including code. I've had to learn my way around Python, C++ and lua.

I didn't master any of them (of course), but I learned enough to understand what to ask of the programmers (and how to ask it). I assume that when a programming position says "passion for games", they mean that the candidate should love what he does. I think putting the code together to implement a new feature is part of building a game, which is what they're telling you to be passionate about.

You're right, I think we are going over semantics now. Regardless, here in lies my point. A passion for games does NOT mean you love what you do. What I mean is, what i do is write code, design systems, implement design features, build schedules, delegate tasks, give time estimates, research new technologies. I do not "make games" in the real sense. I take a game that has been thought out and designed by someone paid to do just that, and I work w/ it. It's my job to make sure the vision of the designer comes through. Yes, I can offer my input, but I'd rather have an excellent coder w/ no input than a terrible one w/ tons of input. I have to work w/ what they produce, and if they produce shit it makes the job of all the coders that much more difficult.

Originally Posted by Zooch

A lot of design positions will ask that you have a passion for games, but will also ask that you are always up-to-date on the latest games and competition. They might sound redundant but they're two different things.

Well, that makes total sense. Why would you want someone who's duty is to create a fun game not be passionate about these games and not be up to date w/ the latest features attempted by other developers?

But I ask, why is it that the engineer needs to also be passionate about the game? Technically, he has no input on the game or it's features. Now, I know lots of smaller companies/projects will take input from all the faculty, but it's silly to have a requirement for a position that really has no say in how a game is designed (generally).

To me, the designer is the visionary. I'm glad you've bothered to dabble in code. I personally think it's important for a designer to have a little technical experience, it helps them realize what it is exactly they are asking for. But in the end, I think it's you whose responsible for the "fun" factor. Granted, if the animation is sloppy and has glitchy issues, yea that's the programmers fault. Had you hired someone passionate about code, they would have had a bit more pride in their system and you wouldn't be seeing glitchy animation interpolation

[nef]

Originally Posted by sdornan

The programmers are often directly responsible for the quality of the final product. If a game feels unpolished and unfinished, it might be because the programmers made the wrong decision when deciding how to budget their time, or made the wrong decision when choosing how to implement major aspects of a game's design.

Another quick point here. Assassins Creed. Some people may think this is an awesome game, personally I was bored after killing the third "boss".

Everything technically about the game was flawless to me. I still play it from time to time just to watch the animations and the beautiful view, but the game sucks. It's repetitive and boring. The programmers did their job, should they also have chimed in, "Hey, this is boring. How about we add some variance to the gameplay so that the players aren't doing the same thing the first 5 minutes of the game to the last!"

Maybe they should, but I wouldn't make it part of their job. If so, I want a GIGANTIC pay raise Programmers aren't designers and they shouldn't be. Most programmers I know are so technically minded they don't care about little things like the fact that something isn't "black enough" to mesh in w/ the scenery. There is a reason we have designers. A programmer is not hired to create fun features.

If a game feels unpolished you can't say it's the programmers fault. Maybe it is, but there are so many other factors too. Maybe marketing couldn't figure out exactly what they wanted and requested so many changes that the initial deadline for what was thought of upfront had to be modified, but hey we can't change release dates! So many things happen during the development cycle of a game that it's really impossible to put a hard deadline on things. Many companies don't get that and expect changes to take a minute. Blizzard does understand this idea, which is probably why diablo2 took 1+ more years to release than scheduled and they now lable release dates as "when it's done"

[dominicds]

I think you may be placing too much weight on the designer's shoulders here.

The goal of most game projects is to make something that will sell. A common assertion (backed by plenty of empirical evidence) applied by studios is that there is a strong correlation between how fun a game is and how much it'll sell. Therefore, a studio's approch to reaching the goal is frequently to make the game as fun as possible.

Requirements docs can almost never include everything that makes a game fun. You can't expect a designer to think of everything in preproduction any more than you can expect a programmer to produce bug-free code without the help of QA.

Sure, an iterative approach will allow the designer to catch mistakes and oversights; but programmers often have a unique perspective that can be valuable. A programmer who really cares about making the most fun game possible can frequently go out of his way to improve its quality in ways that the designers may not have considered for one reason or another. Maybe they don't have an intimate understanding of how the software functions; maybe they haven't thought about every possible path; maybe they were short-sighted (it happens). Similarly, a really dedicated artist can often add a little bit of extra polish that no one else ever thought to ask for.

[EvilLlama]

So essentially, the problem with some people who are "passionate" about games here is that there's a risk they get too distracted by the other elements of the game to make sure their part contributes to the game in the best way possible. Suggestions to designers are fine during lunch breaks, but a programmer who agonizes for hours over features to make the game more fun due to his "passion for games" instead of coding is worse than a programmer who trusts the designers to think up of the fun factors and focuses on good code.

However, I think the whole line "passion for games" in the job description should stay, since it is balanced out by "works well in teams". Part of being on a team is trusting other members to their best at their jobs while understanding they are trusting you to do the best at yours.
The programmer who does not focus on creating the best code possible is not a good team player, since they are not trusting the other members (designers in our scenario) and not doing his/her/its task the other members trust them with.

[dominicds]

Yeah I agree. Teamwork is key. In this situation however, I think teamwork requires a lot more collaboration than you're describing.

Open communication between gameplay programmers (I'm talking specifically about gameplay programmers here) and designers is very, very important. The way I see it, a gameplay programmer's job is not just implementing the features requested by a game designer, it's solving the problem that those features were intended to address.

As I said in my last post, requirements docs (if they're even created) are nearly always incomplete. A programmer who receives a list of features from a designer, then disappears for a month, "checking off" each of those features from the list, will likely return with something that doesn't really solve the designer's problems. That's not good teamwork. In my opinion, that gameplay programmer isn't really doing her job unless there is an open dialog between her and the designer.

Having a "passion" for making fun games will help create what the designer really wants much more quickly than being able to produce maintainable, defect-free, optimized code will.

[nef]

Originally Posted by EvilLlama

The programmer who does not focus on creating the best code possible is not a good team player, since they are not trusting the other members (designers in our scenario) and not doing his/her/its task the other members trust them with.

I agree, but does a passion for games equate to a passion for good code? That's my point anyways.

[nef]

Originally Posted by dominicds

Yeah I agree. Teamwork is key. In this situation however, I think teamwork requires a lot more collaboration than you're describing.

Open communication between gameplay programmers (I'm talking specifically about gameplay programmers here) and designers is very, very important. The way I see it, a gameplay programmer's job is not just implementing the features requested by a game designer, it's solving the problem that those features were intended to address.

This is an interesting take on the job of a game programmer. I'll have to agree w/ you on this to an extent. Maybe I just don't know enough about design, but i would like to think a good designer understands the technical as well as artistic limitations of his own vision. In this respect, I would hope he would take it upon himself to consider the problems his features may cause.

As a programmer, If i implement a feature and notice an unintended side affect, yea I'll definitely bring it up. But I would hope that the designer is doing his best to consider these side affects as well. I don't like to think that any/all side affects or secondary issues that weren't thought of should fall on the programmer. I want a designer that does his best to come up with solid designs. To me, a good designer will do his best to look at all possible outcomes of a decision and see how it affects the overall product.

Obviously he can't be perfect, coders don't write perfect code and artists make mistakes too. But I don't want a designer who doesn't consider the possible side affects of what he decides to implement. To me a "perfect" designer would foresee all of this. Of course, a perfect coder would be able to implement any ridiculous task in a day These aren't possible and I fully understand that, but I a designer that doesn't at least try or puts that work on the coder is just lazzy imo.

Originally Posted by dominicds

As I said in my last post, requirements docs (if they're even created) are nearly always incomplete. A programmer who receives a list of features from a designer, then disappears for a month, "checking off" each of those features from the list, will likely return with something that doesn't really solve the designer's problems. That's not good teamwork. In my opinion, that gameplay programmer isn't really doing her job unless there is an open dialog between her and the designer.

Your right. But the designer isn't doing his either. It should be the responsability of both to openly communicate about how things are coming along.

Originally Posted by dominicds

Having a "passion" for making fun games will help create what the designer really wants much more quickly than being able to produce maintainable, defect-free, optimized code will.

This makes some sense then. But i still have to wonder, there are many more important applications being written out there. Why is it games is something you need to be passionate about to code? I don't still think someone who is excellent at what they do would be a greater asset than someone who loves the product they are creating. Obviously a love of what you are creating is a boost, but I wouldn't sacrifice it for actual competence.

If you are going to request a passion for games, then request a passion for good code and coding practices too. Be fair here

[dominicds]

I agree that if designers were perfect, maybe programmers would be better off focusing on nothing but writing the cleanest code possible. And of course programming ability shouldn't take a back seat to "passion for games". But I don't think that passion is an irrational thing for studios to look for in their programmers.

Originally Posted by nef

...i still have to wonder, there are many more important applications being written out there. Why is it games is something you need to be passionate about to code?

I think the reason having passion is more important for games than say, word processors, is because a game has to be more than just the sum of it's features. It should be an experience.

Take that bad gameplay programmer from my previous example. The one who just disappears for a month, slaving over her keyboard to implement every feature on the list. If she's working on the new version of Word rather than the new Halo, I say she's probably doing a good job.

Think of it like comparing a movie to a toaster. If a movie (or Halo) was created as a bulleted-list of features:

• Car Chase
• Romantic Scene
• 10 Running Jokes

...It probably wouldn't be very good. However, a toaster (or Word) does it's job pretty well if it's nothing more than a collection of features.

[nef]

Originally Posted by dominicds

I think the reason having passion is more important for games than say, word processors, is because a game has to be more than just the sum of it's features. It should be an experience.

Take that bad gameplay programmer from my previous example. The one who just disappears for a month, slaving over her keyboard to implement every feature on the list. If she's working on the new version of Word rather than the new Halo, I say she's probably doing a good job.

Think of it like comparing a movie to a toaster. If a movie (or Halo) was created as a bulleted-list of features:

• Car Chase
• Romantic Scene
• 10 Running Jokes

...It probably wouldn't be very good. However, a toaster (or Word) does it's job pretty well if it's nothing more than a collection of features.

I duno. I think your logic applies to both Word and a game. Both really are a collection of features. What if some of the features for word are hard to find, confusing to use or generally irritating to the users experience? (Papper clip?) Same for games, you implement a gameplay feature and you need to make sure it's worth keeping, or is fun. The requirements for the features may be different, what I mean is for a game they should be fun and for a Word app they should be easy to use and helpful.

Why are games so special that you can't do your job on them w/o being passionate about them, while other software doesn't seem to need this? (Hah, or maybe they do and that's why there are terrible apps?)

[nef]

I guess what I'm getting at is, no creative input from a programmer I don't think should be a bad thing, but if he does give input that's a good thing. To me, the designer is the one responsible for checking out the features as they are implemented and making sure they server their purpose, not the programmer.

What is something that a programmer could give input on to make the game more fun, that a designer couldn't, or shouldn't even be expected to be able to see? Nothing as far as I can tell :/