What Do Programmers Want from Designers?

[Jedi QuestMaster]

I'm a designer. I haven't taken a programming class, I don't meddle with code outside of simple romhacks, I've never made a homebrew.

I have experience in graphic design, my hobbies revolve around sketching, drawing, scanning, pixel art, photoshop, creating logos, animating, writing, and I dabble a little bit in music.

So here's my question: As a designer, what can I do to make your job easier as a programmer?

I know this question is vague. I'd like to delve into working on homebrews, and I want the process to go as smoothly as possible.

For example, should I convert all my images to 4-colors? Would it help if I broke them up into tiles? What format should they even be in? Should I do all my music and sound in FamiTone (or whatever you need them to be)?

I guess this could also be a pet peeves thread (and isn't just limited to NES), but I'd like to hear input from programmers.

[Kasumi]

As a designer, you can ask all the questions you need to know about the NES early in the project. And then actually learn them.

You can make some effort to try to solve problems yourself. Like if I give you a tool that tells you whether your image/music/whatever falls in the restrictions of something, and the tools tells you something doesn't work... spend a little time looking for why. Don't immediately ask. Definitely don't send me the broken thing. In this hypothetical situation, I made the program that tells you about errors specifically so I wouldn't have to deal with that.

Basically my pet peeve is when I feel someone's not putting in actual effort, and expecting me to make up for it. It's fine to ask questions. But if you don't seem to be learning from what the answers are (i.e. the same mistake is sent multiple times), that's a problem. If the answer I gave wasn't clear enough, ask then rather than staying quiet if you didn't undestand and resubmitting something with the same problem.

That said, for any project you provide what you want, and we provide what we want. It differs on the project. You should do all your music and sound in Famitone if that's what your programmer wants. They may not.

It can be helpful if you break your image up into tiles/whatever, but only if you do it correctly. If you don't know how to, we'll do it or make a program that you can use to do it. If we want help with it. We may not.

Assuming you're planning on hiring someone to program and you want to design the game... well... make sure you're actually designing the game.

If you give us a design document that says something like, "Character should have variable jump height.", realize that there are like eight ways to do that. If we have to pick, we're the ones designing the game. (Which isn't necessarily a problem, if you're paying us or aren't calling yourself the project's game designer.) If you're not super familiar with programming, you can still be specific. "Variable jump height like Mega Man." Because that's very different from Yoshi's Island variable jump height, which is different from Super Mario Bros. variable jump height, which is different from genesis Sonic's variable jump height.

Not being specific isn't a problem by itself, though. Not being specific and then making us tweak it a bunch of times might be. "Variable jump height." *implements Megaman style* "No, more like Mario." *implements Super Mario Bros. style* "No, specifically New Super Mario Bros." which could have been the first thing you said. (But really a good team mate would probably ask you for more details immediately.) Think about the questions we'll ask, and make your statements more specific to preemptively answer those questions, especially if the communication isn't in real time.

There aren't really good general answers to questions like this. See this topic about music.
The limitations of the NES are one thing, but there's usually additional limitations of the game engine. So what the programmer needs/wants changes depending on the project.

Edit: Oh, man. Thought of an actual pet peeve. If we say we can't do something, or it will be very hard, don't say, "But game X does it!" Game X probably had a legit budget, maybe a team, maybe they're just better programmers than us. Regardless, we're telling you we can't or don't want to do something. Don't try to talk us out of it. (Maybe you can talk us into something hard if you're paying us. There are things I wouldn't do for a collaboration that I'd do for a project I'm making money on.) But if we say it's impossible, it may actually be impossible within the confines of our engine, even if there does exist some game that does it.)

[dougeff]

should I convert all my images to 4-colors?

I say sprites should have a maximum 6 colors. (2 layers of sprites, 3 colors each)

Bg...each 16x16 block can have 4 colors, but the whole screen can have 13 BG colors. Don't restrict your game to 4 colors...that would be kind of dull.

Would it help if I broke them up into tiles?

Maybe. It would at least help you understand the size limitations. Try working with a tool like NES Screen Tool.

FamiTone

Ask your programmer. I'd advise, write the song in whatever medium helps you write better, then convert it later to whatever format the programmer wants. Personally, I like to just sit at the piano/keyboard and play, record, then redo it on the computer.


What kind of games did you want to make?

[Sik]

• Don't start demanding major "critical" changes at last minute after everything was implemented. I lost the count of times this has happened. (incidentally this is why now they tell you to iterate on barebones prototypes as fast as possible, to get in all the major changes before the code design is set in stone)
• What's easy for a human is hard for a computer (and vice versa). Don't start throwing ideas just because something is "simple", because it's very likely that's not the case.
• Learn your tools. Sure, I could write an automatic PNG-to-tiles converter for you so you don't have to deal with extracting tiles manually, but make sure to use the grid from your painting editor to actually check they're aligned. Having absolutely no redundancy because everything is misaligned by one pixel is awful. (had this happen before)
• If the programmer tells you there's a hardware limitation, then there's a hardware limitation. Don't go around looking for excuses to somehow cram it in anyway, because not only you won't get what you want but also you'll waste time. (discussing alternatives is OK - in fact Donkey Kong's design was pretty much Miyamoto constantly looking for workarounds until something would fit)
• Subtle one: don't try to push too much in one place. Sure, maybe you made a large object that has carefully optimized sprite usage on every line... then throw in another one into the mix and suddenly it doesn't work. Oops. If you know something is likely to be used together with other things, try to be as conservative as possible with resource usage, just in case several things try to use the same resource simultaneously.

[calima]

• Don't start demanding major "critical" changes at last minute after everything was implemented. I lost the count of times this has happened. (incidentally this is why now they tell you to iterate on barebones prototypes as fast as possible, to get in all the major changes before the code design is set in stone)

Excellent list. I'd put all these under a more general heading "don't waste their time". Of course, if you're paying by the hour, you're welcome to waste my time as much as you want, heh

That means make up your mind. No huge direction changes after a week's worth of coding. If you say "make this character jump like this", and they do it, coming back with "oh it needs to be like this, now that I think about it", where the new way takes another week of coding because it changes everything... You just threw away a lot of their work.

Ie. unless the pay is by the hour, we expect specs set in stone. No weekly mood changes like a teenage girl. This is common to all programmers everywhere, up to huge billion dollar govt contracts - they have penalties for changing plans for a reason. Then we branch into "agile", but that is essentially pay by the hour.

[Myask]

What Do Programmers Want from Designers?

money. :laugh:

As a designer, what can I do to make your job easier as a programmer?

Oh. That's a very different question! More what the others said: don't change up the design document.

Don't start throwing ideas just because something is "simple", because it's very likely that's not the case.

On the other claw, these sorts of things are far more likely to be simple when included as initial design constraints, because then the programmer can go "okay what assumptions does this make" and include the assumed qualities in your programmed product. But human-simple is very different from computer-simple, yes.

[Sik]

"Make each face of this cube a button the player can click"
*go on trying to explain the hell that's trying to determine what face is under the cursor, especially for something like a menu that would be otherwise quite trivial*

That kind of stuff. I doubt that including it early would help =/

[thefox]

Ie. unless the pay is by the hour, we expect specs set in stone.

Oh. That's a very different question! More what the others said: don't change up the design document.

This would be ideal, but rarely is achievable in practice. Some kind of iterative approach is usually needed since you don't have all the information when you start a project. That said, the non-technical persons in the team should be sympathetic to the fact that even seemingly small changes can lead to huge amounts of extra work on the programmers part. And it's not only about the time it takes; having to redo code or to throw away a lot of work can also wear you down mentally.

[Jedi QuestMaster]

Don't start throwing ideas just because something is "simple", because it's very likely that's not the case.

What kind of games did you want to make?

Simple games.

Ie. unless the pay is by the hour, we expect specs set in stone.

Oh. That's a very different question! More what the others said: don't change up the design document.

This would be ideal, but rarely is achievable in practice. Some kind of iterative approach is usually needed since you don't have all the information when you start a project. That said, the non-technical persons in the team should be sympathetic to the fact that even seemingly small changes can lead to huge amounts of extra work on the programmers part. And it's not only about the time it takes; having to redo code or to throw away a lot of work can also wear you down mentally.

Unforeseen circumstances aside, then it would probably be a good idea to agree on short-term deadlines throughout the project (and then realize further on that you won't make these goals ). If anything, it at least ensures that the project is moving along. We don't want to make a shoddy product, but we also don't want the project to hang indefinitely.

This reminds me of this discussion:

viewtopic.php?f=5&t=13733 (<- highly relevant!)

I always cringe when money is involved, because it changes the entire outlook on the project: are the people who are programming doing this because they believe in the project or are they only looking for money? I would honestly like a situation where it's both: you love my ideas and I compensate you (especially if it's my project). If it were a group collaboration from the beginning, that might be different. We all want to be content creators, but how often would we want to work on other people's projects?

[thenewguy]

The thing is that "designers" need programmers, but programmers don't need designers. So programmers don't really need/want anything from designers. Programmers do need people with specific skills such as artists and musicians, but these people seldom have much influence in the design of the game.

If you want to design games, you either have to learn to program or you have to pay a programmer, and programmers are not cheap.

[dougeff]

programmers don't need designers

I disagree. If you do all the level design... say, in Tiled. And/or do all of the sprite graphics... it would make the game development go 100% quicker than if the programmer was expected to do both.

[Sik]

The thing is that "designers" need programmers, but programmers don't need designers.

Most programmers suck at graphics (hence "programmer art").
Most programmers suck even more at composing music.
And nearly every programmer knows absolutely freaking nothing about UX (hence why most people still find computers hard to use).

And that's not even getting into the less obvious details.

That said:

So programmers don't really need/want anything from designers.

Most programmers are also delusional about this and think they can go on their own. The huge slew of shitty indie games with poor graphics, random bleeps as sound and nearly unplayable gameplay (or at best horribly boring) should be good proof of this. It fares just as well as you'd expect.

[tepples]

Programmers do need people with specific skills such as artists and musicians, but these people seldom have much influence in the design of the game.

Then you might be surprised. Haunted: Halloween '85 was almost completely artist-driven, with the primary programmer input being what is possible or impossible given the engine and chosen mapper.

As for Sik's criteria: I can program, and I can compose music. That leaves art, UX, and iterative play testing. In cases where the idea comes from a programmer who has completed a playable prototype with programmer art, how is such a programmer supposed to find competent artists and other people to polish the idea?

[rainwarrior]

I think the premise of this question is a little bit broken, but I'll try to answer. This might be more generally about game design roles.


In general I just want a co-worker to be competent, and communicate well. Someone who can adequately explain their ideas, as well as listen to suggestion. That's not just "designers", though, that applies to everybody, basically. I want to work with someone I can trust, always.

Nearly everyone working in games has some interest in design, this applies to programmers, but also artists, producers, QA... you name it, they all have design opinions on the project. In small game companies, usually everyone wears several hats, and design is a collaborative effort.

The structure of authority is very important for maintaining coherent design, usually it flows from the source of funding (publisher), into someone who is trusted with creative control of the game (the lead designer). Depending on the company, that person might also be a programmer, or some other position, but sometimes they really are dedicated to design. This person has design control (to be overruled by the publisher at any given whim), but they must also delegate design tasks to others, and make sure these tasks can be fit together into the complete game.


When you give a design idea to a programmer, it's becomes a collaboration; they are necessarily involved in its design. If you don't have open communication with them, they will have quite a lot of design control over it, and it will probably come out a lot different than what you were expecting. Everything you didn't specify is something they had to come up with on their own, and since you're not the programmer you probably have little idea of the myriad of design decisions involved in making it work.

So yes, this means you should listen to the programmer. You give them an idea, and they'll probably say "here's three other ideas that I don't think are exactly what you're asking for, but I think they would work better". You, as the designer, should consider these things. Ask questions, and think about how they would fit with the overall game. It's your job to maintain a coherent design plan, and it's the programmer's job to maintain coherent code. The programmer might understand the overall design plan (they don't necessarily have to, but it helps, and some will make that effort), but as a non-programmer you probably don't understand the code concerns; when a programmer says "i don't think that's a good idea", they're talking about what a mess it will make in their hidden workplace (the code).


You should ask for impossible things now and then, by accident or on purpose. That's perfectly normal-- you're not really expected to know what's possible-- and sometimes the programmer will have a moment of inspiration and realize it's not actually impossible. What you shouldn't do is continue to demand something your implementers are telling you is impossible, or shouldn't be done.

If you have the authority you can simply force a programmer to do what you insist, or you can go bend the ear of your boss and have them step in to make a call. That happens, and sometimes that's necessary to resolve a difference of opinion. Nobody wants to be told what they have to do by the boss, but as a professional you should be able to suck it up and carry on. That's part of the job too. If the boss looks at the situation and tells you that your idea isn't going to happen, it's now your job to find a different solution. (In amateur projects with no clear authority, differences of opinions often become impassible and destroy the project.) Maybe goes without saying, but don't hold a grudge when someone gets the boss to tell you no; you still need to work with them, so you'd better get over it.


That's really the heart of it: there's a lot of different realizations of any idea, and its hard to know which versions will work best, or even how many versions exist until you actually build something that works. If you have a good collaboration with a programmer, together you can probably find a lot of different things that might work, and try different ones until one seems to fit. Good ideas are found by being flexible enough to be able to spot the right combination.

The worst thing you can do is to demand one specific thing and remain intolerant of any deviation from it; if the implementer doesn't think it's going to turn out good, why would you expect them to be capable of making it good? If they think it's bad, from their perspective you've just made it their job to "make something bad", and they probably will. Good ideas are only useful when they actually work. It's better to try something else, than ruin a good idea by forcing it.


Other than that stuff, if you want to work in games, make games. Learn to do every part of the job at least a little. Learn to code at least a little. Learn to use a 3D modeller, and photoshop. Learn to edit sounds, make music. All of these skills are important to game design, even if it's not your job. You need to have some idea of what you're asking other people to do, and if you don't know, try to listen and understand when they try to explain it to you. All of these people end up making design decisions too, like replace "programmer" with "animator" or "producer" or "sound designer" in the above discussion and it's still fairly relevant.

[thenewguy]

Most programmers suck at graphics (hence "programmer art").
Most programmers suck even more at composing music.
And nearly every programmer knows absolutely freaking nothing about UX (hence why most people still find computers hard to use).

And that's not even getting into the less obvious details.

Most programmers are also delusional about this and think they can go on their own. The huge slew of shitty indie games with poor graphics, random bleeps as sound and nearly unplayable gameplay (or at best horribly boring) should be good proof of this. It fares just as well as you'd expect.

Here are a few NES games made by programmers: Battle Kid, Battle Kid 2, Candelabra: The Mad Wizard, The Rise of Amondus, (also the non-NES games of Nifflas and Locomalito) etc.

There's a lot of emotion and anger in your post. I understand that the idea that programmers don't need designers can be upsetting, but it's the truth.

Part of the charm of an old system like the NES is the fact that a single guy (or two guys maybe) can create something of commercial quality. You say "most programmers are delusional about this and think they can go on their own," but I would say it's actually the opposite, that most "designers" think they can somehow convince a perfectly competent programmer to work on a project for them.

You're wildly over generalizing programmers. They're people not stereotypes. Lots of people who know how to program are also very good at creating graphics and music. Sivak, for example, is a notoriously excellent musician. The programmer for Axiom Verge is a serious artist in his spare time. As for UX design, most books on user interface design are written by programmers for programmers, so that should tell you something right there.

You say that "most programmers are delusional ... the huge slew of shitty indie games ... should be good proof of this." This is also a huge over generalization, and it's completely subjective (one guy's shitty game is another guy's favorite game). Programmers also are seldom "delusional," that's just hyperbole. I hope you realize that you're talking about people like Sivak who made the NES homebrew scene what it is today.

Again, I know it may suck as someone who can't program to realize that you need to learn to program (or pay someone) if you want to make a game, but that's how it is. You need someone to program for you, and a programmer can go it alone. Why would they work on your game instead of on the game they want to make? They wouldn't.