programmers...
polycounter lvl 18
rule of thumb on programmers..
1. if a programmer adds a useful feature, its most likely by accident, and will be fixed in the next version.
2.telling programmers what to fix is a game of whack-a- mole. whenever a bug is fixed, another one gets unfixed.
3.programmers loves switches, and UI buttons. the more, the merrier. preferably, the switches that work, should be buried inbetween 15 buttons that do not work, or mess up whatever you're trying to do.
anyone else got some experience with programmers?
1. if a programmer adds a useful feature, its most likely by accident, and will be fixed in the next version.
2.telling programmers what to fix is a game of whack-a- mole. whenever a bug is fixed, another one gets unfixed.
3.programmers loves switches, and UI buttons. the more, the merrier. preferably, the switches that work, should be buried inbetween 15 buttons that do not work, or mess up whatever you're trying to do.
anyone else got some experience with programmers?
Replies
We also have a great graphics programmer who implements new engine features and helps the artists set up any scripting, and guides us through new pipeline processes. He also adds new graphical features to the engine if an artist asks for it and it's feasible.
Our other few programmers are very helpful and friendly guys who, 99% of the time, will fix up any bugs very quickly, and help out when pipelines or tools become confusing.
Sounds like you've had some bad experiences with programmers...
1. make sure he knows
2. well bound to happen in bigger projects
3. if pressed on time there is little to no time on making stuff nice, you just provide functionality and thats it. making nice GUI, workflow friendly stuff takes a lot time, too. normally someone else should go over the GUI and make it user-friendly, but I take there is no such someone else. Big companys like Epic, CryTek and other technology sellers make sure their editors look neat, because good tools are a selling point. One gets easily spoiled by that.
communication is everything,
if you do the layout for the GUI on paper, so that coder just needs to transport the values, it saves him time, too. It might look like a simple task, but it does take time, and also experience in using these kinds of editors, which might not always be the case.
dont let the "versus" thing boil up, it just ruins things for everyone.
Artists = seem to be interested in moving forward, making progress, adding better things and making the game look better, even if it means more work.
Programmers = seem interested in doing as little new stuff as possible since they will have to bugfix it later, are completely resistive to adding anything new or working with artists to come up with ways to make the game look better.
I know this is a generality, and I have had the privilege to work with a few programmers that bucked this trend, but as a whole, all the programmers I've worked with have been very VERY resistive to implimenting anything new.
Artists = seem to be interested in spending ages tweaking details, and satisfying artistic cravings by adding tiny things that the gaming public will never notice, even if it means the release date gets pushed back a year or so.
Programmers = seem interested in doing as little new stuff as possible since they have realistic expectations of how long it will take to implement, control and bugfix whatever crazy buzzword feature the artists have asked for this week.
[/ QUOTE ]
Fixed
[ QUOTE ]
Artists = seem to be interested in spending ages tweaking details, and satisfying artistic cravings by adding tiny things that the gaming public will never notice, even if it means the release date gets pushed back a year or so.
Programmers = seem interested in doing as little new stuff as possible since they have realistic expectations of how long it will take to implement, control and bugfix whatever crazy buzzword feature the artists have asked for this week.
[/ QUOTE ]
Fixed
[/ QUOTE ]
Wrong. I'm constantly trying to keep the budget, dev time, and target audience in mind. I've always been the one pushing for smaller maps and more frugal poly limits, in order to get the game done. I'm talking about large scale issues that if the game lacks, it won't be able to compete on a graphical level with it's competitors. Most of the time they are things I'm told cannot possibly be done (by the programmers) then the following week I see the exact feature being done in another game on the same console as we're doing stuff for.
But nice try.
Poop: I think you missed my point - both what you posted and what I posted were gross generalisations based on our experiences. I entirely appreciate that you're always keeping the budget, dev time and target audience in mind. I don't doubt that at all.
However, you can't say I'm "wrong", and you're "right", about a sweeping generalisation. There are different artists and different programmers all over the world who will range from the laziest, most useless types, to the most pro-active, awesome types. You simply can't generalise on the level that you did in your first post, which was kinda my point.
Artists = seem to be interested in moving forward, making progress, adding better things and making the game look better, even if it means more work.
Programmers = seem interested in doing as little new stuff as possible since they will have to bugfix it later, are completely resistive to adding anything new or working with artists to come up with ways to make the game look better.
[/ QUOTE ]
Much that I hate to generalize, I (largely, but with some notable exceptions) had that experience at a certain large company and it was infuriating at times to be met with resistance at every corner instead of a common feeling of wanting to make something special.
That said, I think that was largely due to the sloppy codebase and the lack of time. The thing about engineering is, that they're often doing a lot of clean up work behind the scenes that isn't necessarily particularly obvious or visual. Sometimes entire chunks of code were rewritten with no obvious impact. After years and years of reworking the same titles, one can only imagine how nasty the codebase can get. Legend has it that even recent Fifa soccer builds have Megadrive (Genesis) specific code in them.
I had the opposite experience at Bullfrog actually. There engineers were uber keen to push and push, (and many of the artists seemed pretty lazy) and I'm thankfully in that situation again where I am now (except the lazy artists bit
as stated by Daz before, a lot of coding won't have any visual effect on the total thing, at best that you have 1-2 fps more than before...
Another thing that artists must be aware of is the difference between demo, and full blown game engine. Yes there is tons of sexy effects, and you got to see demos on them by nvidia or other places and they have those über shadows and so on. But there is just one model, or in other ways a very reduced scene complexity. While in the game engine, a lot more interaction, diversity and so on must be possible. So introducing new stuff must not break the rest, but integrate with it. And that process can be extremely work heavy, as interfaces might need to change and so on. Though as with art, with experience, high motivation and so on, stuff gets done faster. And as with all people, some have more "drive" than others, as Eric mentioned. And well in small teams people are pressed a lot more with differnt taks and must play on safe a bit more in individual tasks, I guess.
maybe with better communication in which the "other side" gets to know about fundamental issues of either side's problems, would help to gain a bit respect.
as stated by Daz before, a lot of coding won't have any visual effect on the total thing, at best that you have 1-2 fps more than before...
Another thing that artists must be aware of is the difference between demo, and full blown game engine. Yes there is tons of sexy effects, and you got to see demos on them by nvidia or other places and they have those über shadows and so on. But there is just one model, or in other ways a very reduced scene complexity. While in the game engine, a lot more interaction, diversity and so on must be possible. So introducing new stuff must not break the rest, but integrate with it. And that process can be extremely work heavy, as interfaces might need to change and so on. Though as with art, with experience, high motivation and so on, stuff gets done faster. And as with all people, some have more "drive" than others, as Eric mentioned. And well in small teams people are pressed a lot more with differnt taks and must play on safe a bit more in individual tasks, I guess.
[/ QUOTE ]
I understand there are difficulties. I just have always gotten a feeling of resistence from programmers, instead of an attitude of moving forward. Even if the end result was the same, getting the feeling that the programmers were trying just as hard as the artists to make the game look great, would make me happy. As it seems now, it's a bunch of downy clowney's poo-pooing everything without even seemingly trying. It's the attitude more than the end result.
Suggest new thing:
Artists = Ok, let's give it a whirl, see if we can get it done.
Programmers = No, it will never work, I'm not even going to investigate it.
Generalisations like that based on personal experience and anecdotal evidence simply do not hold water, unless you're specifically talking about your own experiences. I think it's unfair to tar all people with the same brush based on a limited range of interactions.
Suppose if you have a good technical artist as a buffer between the art team and the coding team, then things tend to run a bit more smoothly.
Also some coders have an interest in graphics, whilst others could n't care less.
Lastly there is the communication thing,artists in general have a different way of doing thing from coders and a different way of expressing themselves, which often leads to misunderstandings.
Like I said, there are exceptions, and if you feel that doesn't apply to your studio, great! That's awesome, I'd like to work at a studio like that. You are seeming to argue against my anecdotal evidence with anecdotal evidence of your own.
This is my opinion, which I'm loath to state obviously, since it should be obvious that it is just my opinion, based on my own experiences, since there really isn't anything else to go on.
Edit number whatever: I don't like an "Us vs them" mentality, I really don't, but I've never worked on a team, where I felt part of the dev team as a whole, except possible Warthog, and that was more because of it's small size than any great organization. I've always felt a part of the art team, but there has been so much separation, missunderstanding, and poor communication between art and design, and art and programming, that I've never felt like I understood what they were doing, how our jobs interacted, or even how we were supposed to interact. I hardly think the companies I've worked with are isolated in that aspect. I would love to feel like a brother amongst the programmers, I'm just saying that I've never felt even close to that type of comeraderie before, and I blame it on the infrastructure, not on me being shy or for lack of want to communicate.
Sometimes it feels as if it's a fight, when LD's want something but artists want something else... after that though, it feels really good when the teams reach a compromise and learn to work well with each other.
I just had a designer come over to my desk earlier today and say how much he liked working with one of my texture sets. It's that sort of stuff which helps bring a team together, I think - mutual appreciation of the others' skills.
That said, I think that was largely due to the sloppy codebase and the lack of time. The thing about engineering is, that they're often doing a lot of clean up work behind the scenes that isn't necessarily particularly obvious or visual. Sometimes entire chunks of code were rewritten with no obvious impact. After years and years of reworking the same titles, one can only imagine how nasty the codebase can get. Legend has it that even recent Fifa soccer builds have Megadrive (Genesis) specific code in them.
[/ QUOTE ]
I think this is an important point. I work on similar codebases, and I have no doubt whatsoever that this 'legend' is a cold hard fact the programmers live with every day. It gets difficult after a while to add things to such a codebase. If the code is new, and maintained well, then adding things is much easier, and less error prone. The coders' attitude will be greatly influenced by this I think.
off-topic: I never realized there were so many coders here!
It becaue on the whole artists are better looking and sexier, therefore the envy thing comes in to play.
[/ QUOTE ]
Wth? I'm fucking hot.
As long as I keep it level-headed and positive, I find the squeaky wheel gets oiled, things usually change for the better. If I get personal or negative, it tends to get worse. True when dealing with artists or programmers.
No one appreciates when it's broached negatively, but people usually appreciate constructive criticism. I suspect you know this already, but sounds like communication may be at fault somehow where you're at.
Sometimes it takes awhile, but eventually either the bad egg moves on, or he/she changes course thru pressure from above or from their peers.
When it works, it's awesome. I get so much support from the coders here, part of what makes this my dream job.
I hope I can show you a bit of understanding between the coders and the artists and the conflict which can appear between those caracters. I have something like a coder history, I got very deeply into that for some years, guess I can say that I lived it like a total freak in that time + I currently live a artist life. Its a personal view out of my experience & may not represent the thoughts of each individual caracter.
the coder:
As a coder you can start your work first when you know the inputs and the outputs of your mission and how they are related. You need to understand the language of each of this inputs/outputs and how they are related. You build up a huge information base and check the extremes of each of that information. Before you do not know this you will not begin the first line of code.
The root of that is based on the "IF" which simpified is the key element of coding. Ferg has a great sentence in his signature: "If you want to make an apple pie from scratch, you must first invent the universe." -> thats the mission of the coders, to invent the universe.
Coding only has the IF (simpified) to build up the universe, but how to invent the universe with a IF? hmm... he cant do that with the IF because the IF needs something to check, he needs to bring the universe down to the simple case of apple-pie cooking without all the sudden things that randomly happen in the universe and are not totally relevant to the "want to perform" action. The more relations the more IF´s will be needed(guess that not linear, thats exponentially growing).
For example: A program for a bird who will fly around in a enviroment. In real life the bird is totally related to the universe in all his actions, he needs his food, he needs sleep... whatever, its a neverending case because of the relation to the universe. To start the program you need to bring the universe of that bird down to a simple case of your enviroment and your goals of that bird, you cant start before, otherwise you will never come to an end with your IF´s.
A coders mind needs to simpify, otherwise he cant bring something about.
the artist:
guess I leave that open, because everyone of you will have a other understanding and theory of your artists mind, but at least one something from myself: In most cases I only find the art of myself great (and the process) when I start in a free condition. This means not that I cannot go along certain subjects/styles... but a "cant be" is a killer in the process of creating something even if it never reaches that condition. As a artist I deal with illusion when creating something, understanding that its never real what I create, so I see it as a job to compensate that with something like getting the feel along.
If I keep the "cant be" the final product will represent the "cant be" which was not the goal of the "cant be".
Everyone will have its own strategy to work around the "cant be", if there are too many its hard for the artist not to fail in his job.
So on one side, the coder needs closed conditions, on the other the artist needs open space.
The key was allready told to solve that problem: "Communication!". All two caracters are sitting in the same boat. Sometimes its needed to take a step backward on one side, sometimes its needed to step forward on the other side. The conflict is that the coder and the artist are not the same person -> cummunicate!
If a certain level of communication is reached, the pressure solution can totally fall appart. Everyone will see influence and relation and will act intelligent.
hmm... something to end that posting:
Bob Dylan does not have the greatest voice, he cannot reach all those octaves/notes/whatever..., maybe one can hear the cigarretes/drinks he enjoyed in his life, he also plays the guitar not in a perfect form, he does not have a orchester in his band..... but he is able to produce totally great songs with only a guitar and his voice, covering a huge varanty of moods/feelings.....