Seeing the awesome stuff that the designers get up to with my code. It's a constant battle - trying to pull back from feature bloat but also move forward to adding more cool things for designers to use, but in the end it's worth it, and I view my code as being something that enables designers to realize their visions, something that allows them to go that extra step from "functional and fine but a bit meh overall" to "OMFG, no f--king way!"

I would say that to varying degrees, I am driven by all 3. If I had to pick one it would be solving problems. The biggest high I get from programming is coming up with elegant solutions to problems. I also like creating powerful features and bringing something to life that I have imagined/designed.

From programmer's perspective the best designers are the ones who don't change their mind, or if they are going to change their mind, they give warning to such. So basically plan out what you want, how it relates to other features in the game and how it ties in to the game experience as a whole; before you call code billy over to get cracking on it. As to the changing your mind thing: If a designer gives a programmer enough of a warning that they just want something prototyped to see how it could work, the programmer wont waste a bunch of time creating an architecturally beautiful bit of code that is just going to be bastardized and thrown out.

Other than that, tell a programmer that you want an architecturally beautiful bit of code for important system A or B, in case later on possible/non-mandatory system C or D will be tied in with it, and they'll probably enjoy that, a nice clean system to be proud of, in a field where so much is just hacks or spaghetti code thanks to time constraints and bad planning.

From programmer's perspective the best designers are the ones who don't change their mind, or if they are going to change their mind, they give warning to such.

That isn’t really wrong, but it isn’t the best designer there is. That is just a designer who knows how to compensates for an inexperienced programmer.

Naturally programmer frustrations go down when the designer behaves this way, but I wouldn’t ask him or her to do a worse job to compensate for my inability to create a flexible product that could easily be expanded to meet his or her needs.

These days I am not really bothered by a designer who changes his or her mind, even without warning, as I tend to expect it anyway and simply code the most logical solution for whatever feature is being implemented. I use the word “logical” here because to me that is what you would call the most flexible system. You sit down, you think about why the system exists, check against your in-head database of all games you have played that share the same or similar feature, consider what the designer was thinking when pondering this system, and consider how he or she might be tempted to change that system in the future. Then code.

If you know of a super-fast way to code it but it will prevent a certain level of upgrade, talk to the designer about it first and make sure he or she understands perfectly clear that “if you are willing to wait a while, X feature could be possible in the future, but if you agree to never ever under any circumstances decide to add X, I can get it done in just a few hours.”

If the designer then decides to add X, you can stand against him or her on very firm ground, and it is likely management will be on your side, or at least blame the designer instead of you if they decide to add X anyway with a delay in the project.



I would say the best designers are the ones who can motivate the team.
Which basically boils down to having good ideas for the game.
When programmers want to see the end result just as much as the designer, they will be much more proficient.

I would go so far as to say that the designer actually puts a hard cap on the energy, anticipation, and motivation of the rest of the team.
#1: I have worked on a project where the designer was a total idiot, and was very excited to release a crap game. The company put $70,000 into it for God-knows-why while I protested all along. The net return was about $300. After 2 years.
#2: On the other hand, I have worked on a game that seemed to have some potential, but the designer wasn’t really into it, so how could I get into it? I made suggestions but he didn’t want to bother, so I always knew a good premise for a game would turn out to be a crappy implementation of it.


The designer might be more excited than you, but never the other way around. You can’t be more excited than the designer, so the best designers are the ones who know that, and can motivate the team, make them share the vision, and keep pumping out good ideas for gameplay. He or she also listens to input from people who have a strong sense of a “good game”, even if that person chose to do programming instead of designing.


From the programmer’s perspective, I might be a little annoyed if I have to make a major change to my code, but if I can agree with the designer’s vision and am as excited about the new system as he or she is, I will do it happily.


L. Spiro

Well, as a designer who learned programming for instrumental reasons you won't be able to understand what makes us enthusiastic. Actually, it would be very weird if you did Think of us as women. You can't understand the true soul of a woman, and you even should not. The same goes for programmers.

The deep hidden enthusiasm in our souls is the love of coding. At least for those who stay programmers in the long run. We love coding. If we don't have a game to code we would code "something". There is many of us who simple get an urge to code something, and if we happen to have no project of any kind we try to think up something. We could go on some forum and answer someones coding question (obligatory posting our version of the code of course).

There is also a lot of standard enthusiasm reasons which are identical to designers (like pride of finishing the game, customer/player's satisfaction, etc).

Actually, we don't care if you understand us or not. It is not important. What is important is what we HATE. We do love programming because we love programming and no amount of your motivation tricks could change that. We don't need or want you to care about our enthusiasm. We do care about you not making problems and obstacles. That's the key. You are worrying about programmers being motivated, but you know, we are worrying about the designers too. Personally (which means it can be completely untrue) I think programmers have much higher inherited enthusiasm than designers (because we love both coding and making games, while you can only love games, therefore our enthusiasm should be double of yours ).

Don't worry about our entuhusiasm. Worry about you not wasting our effort. Worry to not make us throw away big hunks of the code (we are perfectly fine with throwing away smaller parts, we do know that designers are the pesky annoying creatures by nature and we hold no grudges because of this), worry to not change the requirements in the middle. Just tell us before we start coding everything you can and don't change your mind later. We will love you then


(I'm both programmer and a designer and I code what I designed. Oh, how many times the programmer in me wanted to kill the designer in me for wasting my effort...)

It's the dance of the data.

I'm the choreographer, and I make the data dance. Just like human in a real dance, each datum has its own individual moves that doesn't mean much, but when you stand back and look at the gestalt, the whole is bigger than the parts. It's art. Explain art.

Booze, mostly.

#3 and #4 for sure