1-year milestone. Part 3.5: My beef with artists/coders/producers

This is the second to last thing I want to write about. All the complaints I can think of about the other team members and their line of work.

My “head count” so far:

A luxurious number of artists: 5 different artists with their skills ranging from high to low.

2 Programmers who both were brilliant.

2 producers who together can be considered as much as 0,8 producers. It’s was a complicated situation. One of the producers hated this line of work, we were informed of that and didn’t consider him a producer but rather an extra member of the team. The other producer dropped half way through the project.

A good design is a design you don’t notice. Same thing goes to this blog post. I only write about stuff that disrupts the process of work. And from my “stats” it is not a surprise that I have most to say about the artists. But I will be fair and try to mention as much as I can about programmers and producers.

Also, since I am a designer, I can’t really write much about designers. I have already discussed extensively how I see this line of work. But if you have some tips and pointers about your beef with a designer – please share.



Sketching, work in progress, sharing. I think I have mentioned these separately in other places and now I will mention these in the direct context of team members who don’t do this properly. If you, artsy people, don’t do these 3 things thoroughly it will result in one thing only – the designer saying, “This is a great picture, but it’s not what we need”. The designer feels like crap for dismissing your work, you feel like crap for having your work dismissed. Everyone feels like crap. It doesn’t have to be this way.

  • Learn to sketch: When you are told to draw something, you need to not present a single picture (unless there is ABSOLUTELY no room for a misinterpretation) but a series of simple drawings. The point is to experiment with the idea and the picture. If you are asked to draw a frog – make three or five or ten sketches of different frogs.
  • Learn to show your work in progress: Once a sketch is chosen, you can start coloring and filling in the details. If you worked on something for several hours, I assume there will be more than just a sketch by that point. And as a designer, I want to see which direction your progress is going so I can intercept you in case you strayed too far from the course. To prevent this, I NEED to see what you are doing. This isn’t just for me to complain. I might have miscommunicated something or didn’t give detailed enough description, or left some area of the idea blank and need to go back to specify it. Seeing your work in progress is as much important for the designer as it is for the artist. This isn’t a freaking competition, we work together. And this will prevent the need to send you back to your tablet when you bring me something finished that is not what I asked you to draw.
  • Learn to share: I personally would love to see everything in our shared folder! Any sketches, any progress on the picture at the end of the day. But what I, sure as hell, want to see in there are the finished pieces. Jesus Christ, how hard is it to upload you finished work? Must I ask 3 times to do this? If you are suddenly hit by a car while caring your laptop with all your work and the laptop is destroyed – all your work is gone. We can find another artist, but it would have been great to not get thrown back to square one because someone was sloppy at uploading. Sorry for sounding cynical, but that is the truth of it. You need to make sure your work is shared and saved somewhere where other can have access to it in case something happens to you. Preferably .PSD thx!

Some people are shy and unsure about their work (see Imposter syndrome) but you need to find a way around this. These three things aren’t just a matter of the workflow. They also show that you as an artist is working and contributing. If you hide your work from me, I will assume that you are slacking. This doesn’t apply to just artists, but also coders/designers/producers.


Polish that never happened. I have heard a lot of times us say “it’s good, we will also polish it in the end” and then that polish never took place. You are, obviously, not required to give us assets that are 100% finished. But you must be aware of the things that need to be done later when all the visual assets are brought together. This is something a producer should keep track of, but also you yourself. If only 1-2 weeks are left, you must go back to your assets and inspect them and make finishing touches. Preferably something that is detectable by us, simple mortals, otherwise one can again assume that you are slacking.


Criticism towards the art or criticism towards the design? It is true that artists are the highest authority in the questions of Art. However, an artist needs to realize that someone else who isn’t an artist could give a legit critic about the artistic side of the artifact. In other words, someone who isn’t primarily an artist may have some knowledge about the technics and the theories that are within the domain of Art. Another thing to consider is when the critic is directed not towards the art side of the picture, but towards the design. And if this critic comes from, let’s say a designer, then you, an artist, are no longer in the position of power. No matter how good you have drawn that horse of yours, if a designer asked you for an elephant, you have clearly missed something.

While we are on the subject of deeming someone’s art, you know what else? I don’t give a flying fuck about how many people in what high places deemed that horse of yours as brilliant. Did those people examine your horse as an isolated piece? Or did they examine it as a part of a chain of assets? Did they read our concept document or talk to the designer about the vision of the game? If someone said that this horse is a pinnacle of the artistic expression – put it into your portfolio and go draw my damn elephant. While artists can judge the craftsmanship of the picture, I can judge whether you follow my design or not. And since I know my design best because it is MY design, opinions of all the experts in the world are secondary. But I am always open for a discussion, of course.


Unconscious design. When an artist shows me a picture or a sketch of something that looks strange or intriguing but not as I imagined, I will ask them as to why this picture looks the way it does. And you know what a good artisan shouldn’t answer? “Because it looks cool”. To me, such an answer is the demonstration of the fact that the person wasn’t actually thinking about what they were doing. Perhaps there was some reason to it, but the artists didn’t bother to formulate it and understand it. I want to hear your reasoning, your thought. Perhaps there is something in this that escaped my understanding. Share your feeling, sell me your vision. But if you don’t even know why you are doing things, there is a little chance that I will know why you are doing those things. Any explanation that connects the picture to our concept or to the other existing elements is better than hearing “Because it looks cool”. And this might work if you give the designer a dozen of pictures/sketches. Then the designer can look through them and choose something that is closest to his vision, cool or not. But if you only deliver one image and even that you can’t motivate, you have clearly been slacking.



Unconscious design, only worse! While an artist must interpret and understand what a designer wants, a programmer deal inside a very strict frame. It is much easier to draw a diagram for a programmer to work with, rather than to draw a sketch for an artist. Remember that you are finding a code solution to a specific problem. To get from a programmer some mechanic that wasn’t intended because the programmer thought it is cool is ten times worse than an inability from of an artist to motivate their creating. Something that an artist thought was cool could be erased in a matter of seconds and doesn’t influence the product yet. Something that a programmer thought was cool sends a cascading wave when the new mechanic interacts with EVERYTHING in the concept, dynamics, aesthetics. The problem usually is that none of this was accounted for by the designer so the results could be disastrous. For this reason, if you come up with something that you think is cool, first tell about it the designer. Perhaps make a separate prototype file where you show this mechanic so that the designer could inspect it without worrying about the whole game client collapsing. And the same thing applies, as with the artists, motivate why you think it is a good idea. Don’t say you find it to be cool…


Ask for help. As a programmer student, no one expects you to know the most optimal solutions to your problems and the code you are asked to create. It’s ok to not know how something can be made to work. Ask your fellow students and teachers for their opinions and advice once you are stuck. DON’T go for a week trying to find a solution on your own. Spend a reasonable time on thinking on your own and perhaps searching the internets, then turn to others for help. I’m sure the teachers can help with most of the things you could possibly have trouble with. Also, if you can’t understand something that the designer asks you to code, ask the designer to show an example in another game or to make a paper prototype.



I tried to think of something to write here, but there is nothing. I had no experience of a real administrator watching over my shoulder the whole project so I can’t really say anything. Except that I know for a fact how much easier it is when there is someone dealing with all the routine like schedule, a place to work, keeping track of progress, deadlines, individual effort etc. I know that the first year the Project Management program run was not a smooth ride, but this goes to all of us being the first people who got the taste of the 4 courses. I hope that the feedback GAME got was sufficient enough to make adjustments.

If you have something you can say about the producers, please do. But don’t rant about producers who were clearly not doing what they were supposed to do in their role as a producer. I would rather like to hear about a producer who gets the job done, but could do it better and interfere with the workflow less. Warning flags of a disruptive behavior and such.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s