Software Engineers

You're partially right. You are correct that Software Engineers implement the code to the specifications developed by the designers of the game. Designers say "I want the player to get a movement speed boost after they jump three times" and the Software Engineer writes the code to make the happen. You are probably incorrect in stating that they are slaves to the developers and have no "control". Often times developers don't even know what they want. Other times they think they know what they want, but after discussing the technical issues known only to the engineers, they realize they don't have the best approach.

No, its not the engineers job to come up with new game mechanics, its thier job to implement game mechanics in the best possible way, which is often done by cooperating and coordinating thier efforts with designers.

Well software developers often are software engineers. But in the sense that when you work for any software company you can't just make it do what you want, you're kind of right. Did you expect they'd let you loose to do whatever you thought would make a nice game?

Quote:

Original post by Arbi Could somebody please explain exactly what Software Engineers do at video game companies? Thanks in advance

Well, we write the software, dont we ? :)

Designers and Engineers each have their own responsabilities, but that doesnt mean that there is no dicussion about the features. Typically, everyone will pitch their ideas about the game, but in the end its the designer's responsability to prioritize the features. I stress the word responsability, because its a pretty harsh one.

One vital role of software engineers beside coding is to help identify the impact that each feature will have on the game. In that sense, they strongly influence the design. Anyway, no one should expect to do both the coding and the design.

Depends on where you work. Where I work (as an AI programmer) the work flow is something like this:

they: this is more or less the behavior we want, what do you think?
me: sounds good.... *starts to implement.... hrm... this might be better
me: hey i changed the behavior to be more like this what do you think
they: good or bad or interesting idea, maybe more like this?

i.e. it is an equal partnership of design and implementation. Typically the engineer establishes boundaries based on tech limitations, but we have as much room as we want to improve on ideas and redirect basic gameplay problems.

it is more or less the same for all the other engineers on the team. we all colaborate with our non-engineer partners. graphics programmers collaborate with lighters, modelers, artists. audio programmers collaborate with audio designers, etc.

But even in the same company in the same building there are teams that operate more like the "do as you are told" model of engineering tasking. IMHO, if you are dumb enough to stay on a team like that its your own fault if you hate it. =)

-me

It depends a great deal on where you work; what I've taken from reading various postmordems, interviews, EA_widow's blog you're half right:

EA has a reputation for treating their programmers badly. Long hours and little voice in development decisions.

Blizzard, on the other hand, seems to take the opinions and ideas of all their employees seriously. In the Diablo II postmordem on gamasutra there is a mention of changing some art rather late in the development game because some employees (not even involved in the development) thought it looked bad.

Those are just two examples, and they just come from the information I've been able to glean as an outsider. They do, however, illustrate the difference between companies that you should expect.

Totally depends on the project.

I remember one project when I worked for this hole in the ground game company. Lol, it was a sort of space racing game for mobile, and you had a set number of lives to make it through the course.

The programmers got in a fight with the designers because the designers wanted loss of life to be random, so sometimes you lose a life, sometimes you don't.... and the kicker, the number of lives left isn't displayed to the player. That game had some of the oddest design decisions, don't think they ever found a publisher for it.

I have worked on video games in a variety of situations -- big companies, small companies, big projects, and small projects. My experience has been that everybody is expected to contribute beyond just doing their job. I've never worked at a place where each person just does their job and doesn't have any influence on the game beyond the work they do.

On a small project or a project with no designers, programmers have a lot of say about the game design. On a large project with a team of designers, everyone can make suggestions, but it is primarily up to the designers to design the game and the programmers to implement the design. Either way, the designers can't just dictate how the game is supposed to work because they rely on the programmers to tell them what is feasible and what is not feasible.

Working for any large team (100+ people) will introduce layers of management.

Let's say you're a game system designer in such environment. You're working on combat design, balancing powers, and actions. You're doing this in coordination with motion capture team, marketing department (the sponsor's logos need to be clearly seen when you swing the baseball bat), networking team (they tell you it's impossible to have latency lower than 250ms), game design team (how the game will feel, move, look), UI design team (how the controls will respond, soft, hard, immediate, with lead-in), .....

And then, after 4 meetings, 17 design sessions, 5 coordination sessions, 2 prototypes, a coder comes up to you and says - this all sucks, combat needs to be like in Super Mario Adventures, I have some cool ideas how to expand it...

It doesn't work like that.

Keep in mind that these aren't some indie dev studios, and that stakes are high. Projects like WoW involve thousands of people, projects like EA's sport simulations and other IP-based titles need to be delivered in the store at day D. Not one minute later.

Here, you need rigid process, shared responsibility, division of work. You cannot have everyone everywhere tell everyone how to do their job. Coding in such teams is a small tiny part of process.

If you have trouble with corporate politics, such environments aren't going to work out for you. Neither will they if you have trouble working on command (do this foobar now) - it doesn't matter what you think, there's 80 people depending on you to deliver your piece here and now.

This is true for much of large-scale software industry.

Whether people in question are really treated as slaves, that depends on individual company, team, manager and title. Sometimes, developers get treated worse than slaves. That to, is part of any software development.

But one thing is true - in large companies, if your title does not include "creative" or "design", your gameplay ideas will not be heard. You are there to write code, or to produce assets. Even artists need to conform to style of the game, they cannot go with ninja/samurai style in a western game.

Quote:

software engineers are just robots and developers do the actual video game part.

What is a software engineer, and who is developer? You have senior AI specialist, lead server designer, lead server architect, assistant UI designer, junior sound systems developer, .......

If all you can do is write code, that's all you will do. Not design complex interactions with impact on everything.

For smaller teams (<50), in any area of software development, this can, and likely will be different - but you'll still have your role.

Look at it otherwise - would you want sales person to tell you which algorithm to use to render 50k triangles on nVidia? This works both ways - it's when people start assuming responsibilities they don't have the big picture of that projects get into real trouble.

Finally, the harsh reality of software development - all programmers are expendable. Writing code has never made any money on large scale (no, it isn't the code that makes Blizzard, IBM, Microsoft, Google, ...). So make sure to look beyond just that, and get involved with a domain, rather than code.

I've pretty much only worked at smaller places, so my experience is probably skewed. But all the places I've worked at have had lots of opportunities for programmers to participate creatively.

Things that work in your favor:

Sometimes designers don't specify every last detail, because they're lazy. It's usually very minor things, like, how does the main menu item selection work? Anything they don't specify is totally up to your discretion. Lots of chances to do fun things there.

Sometimes designers aren't quite sure how/if something will work, because they don't have as thorough an understanding of the technology. They need to talk with programmers to find fun solutions that are technically feasible. This kind of problem solving is infinitely easier when you have a programmer that can come up with creative solutions.

And finally, since you're the closest person to the code, you have the best opportunity out of anyone to just add new features on your own time. This might not be feasible depending on how complex the game is, or how strict your company is, or how tired you are. But at the mobile games place I worked at, they freaking loved it when I threw in "bonus" features.

Re: Antheus

It doesn't really work like that anymore all of the time at the big publishers (at least it doesn't in mine). We're divided up into focus groups basically; peers of shared interest & responsibility.

For example AI group:

myself, another AI engineer
3 lead designers
relevant animator(s)
animation engineer

Within this group, we, since collectively we own the total of the unit behaviors, have pretty much absolute creative control. In this small group there aren't a 100 people to coordinate, there is no beurocracy. The only thing it requires is the team to trust that our isolated group will "do the right thing" for the game.

So when i say, "this behavior is crap, this animation needs work, here's a better way" it doesn't throw the whole team's inertia behind it. It's just 6 people reacting to a problem and/or new idea.

Outside of these little groups there is certainly coordination that comes in to play making sure the collective is focused. But with a strong design group, that's not really a problem (or at least hasn't been yet).

And outside of the groups, at least early in production "this whole system is bad" types of feedback are exactly what people want. Certainly there's no time for that once your cranking to your milestone, but in the beginning it's very important. We've cut and added entire giant and minor features based on collective feedback from the developers.

-me

From what I understand and is why Im going to school for Software Engineering a metaphor for it as a TV production.

Designer are like Writers.
Software Engineer are like the Directors.
Computer Science programers are like the actors.

This is how it was always explained to me by teachers I could be wrong...

Not everything is as clear cut as that. As said earlier, it varies from company to company, team to team.

In my case, the designers are the main driving force in terms of ideas. As a programmer, I would occasionally pitch in an idea or an improvement to them and they would either think on it, reject it or accept it. The designers will involve other members of the team (artists, programmers, sound engineers) that have ideas to give and there will always a couple that are really good.

I appreciate everybody's response! Thats a lot of information and insight. I found out some things about both sides (Software and Designer) that I didn't know (not that I knew much anyway). So it seems to me that my original thoughts about software engineers and developers isn't as black and white as I thought (as some of you said, it depends on the group).

I guess everybody on the video game team can't be responsible for the actual designing or storyline, or what have you. But it seems that it all depends on what you enjoy doing, whether if its programming the game and making it come to 'fruition' on code (if I am correct,which I think is what I would perhaps enjoy) or designing how the characters look. By all means everybody has the right to make their very own game, using their very own ideas, but as a team, the "Lead Designer" or whoever the "lead" guy is thats in charge (I think its the publishers) makes the final decision.

Quote:

Original post by LittleFreak From what I understand and is why Im going to school for Software Engineering a metaphor for it as a TV production. Designer are like Writers. Software Engineer are like the Directors. Computer Science programers are like the actors. This is how it was always explained to me by teachers I could be wrong...

Haha, thats a common misconception among Software Engineering students while they are still at school. Ive never, ever seen or heard of any difference in any software place between Software Engineers and Computer Science programmers. They couldnt care less about which of these two degrees you hold, they care about what you can do. Seriously, if you expect to manage a team of programmers when you get out of school, you will be sorely dissapointed.

In the 'real world', an entry level Software Engineer *is* a Programmer.

Yes, there is absolutely no difference between Software Engineer and Computer Scientist in the job market. The degrees don't even qualify you for different positions: same job, same position, same pay. To be honest, having a math or psych or lit major will end you up in the same programming jobs as well; an intro programming job is an intro programming job. As long as you can program and pass the interviews you may as well have studied interpretive dance. It may be a little harder to get your foot in the door with a non-programming major, but once you're in, your undergraduate degree has absolutely no impact on your career.

Study what's interesting to you.

-me

I think "computer scientist" is a different job than "software engineer", but the former job is much harder to get. A "computer scientist" does more research-oriented work, such as language design. Usually it's only the really big companies (Sun, Google, etc) that hire people in this capacity. And you pretty much need a PhD to have the word "scientist" in your job title.

Bachelors in CS = software engineer.

Also, "Computer Science programmer" is just silly. Don't say that.

Quote:

Original post by pinacolada Also, "Computer Science programmer" is just silly. Don't say that.

I meant a programmer with a degree in CS.

I have not a clue how it works in the real world of programing games, but in the comparison between EA and Blizzard some posts above I really hope that EA starts treating there programmers as Blizzard if that now is the case, sure that others input can be a bit problematic if you have any time frames what so ever on a project (this is always the case). But to limit programmers from thinking free and come with some ideas or features all company's should be afraid of. Cause I was the project leader of my own game and we were a team of 3 people and there input to me greatly improved my game idea. Sadly they did not have the patience to stay in the project and I'm now on my own again. Hopefully I get a new team when I finished of the demo and got the homepage up.
On the note about job, yes its much more easy getting in on a company if you got a degree. I have sadly to much experience of this sense I'm atm unemployed and all because I don't have had the courage to take a second chance on the Microsoft first certificate as I failed bad the first time.

Quote:

Original post by pinacolada I think "computer scientist" is a different job than "software engineer", but the former job is much harder to get. A "computer scientist" does more research-oriented work, such as language design. Usually it's only the really big companies (Sun, Google, etc) that hire people in this capacity. And you pretty much need a PhD to have the word "scientist" in your job title. Bachelors in CS = software engineer. Also, "Computer Science programmer" is just silly. Don't say that.

Wrong. I'm finishing my 3-year Computer Science degree this year. The Software Engineering degree is four years (although the third is an internship year). We get hired for exactly the same jobs they do - although by the time they graduate they've got 1 year of industry experience, so they normally get a little more money. But that doesn't count. The companies meet with our uni (RMIT) and just hire graduates they think are suitable from both.

Sure, this is just one example, but I think it's a pretty typical one.