Learned something - Dealing with artists from a programmers perspective.....
by Sean Brady · in General Discussion · 03/19/2011 (5:54 pm) · 16 replies
Exactly what it says, as my understanding of low level languages increased dealing with artists in a team setting has really opened my eyes to the benefit of lone wolf development. I was always aware how much teams suck but being the programmer instead of the artist has really nailed it home... It has a given me a new respect for programmers managing projects and also encouraged me to work alone as both an artist and programmer as much as possible. Dealing with someone who has a lack of understanding and believes in their view so much is a liability imo (can't accept that they won't get everything they want in game or are too fixed on features - feature creep eg. the obsessive 'NEXT-GEN' crowd :( ).
I can honestly I was there too but my third eye has been washed and cleared, cheers bill...
I am sure others have dealt with this many times before?
I can honestly I was there too but my third eye has been washed and cleared, cheers bill...
I am sure others have dealt with this many times before?
About the author
Professional mouth!, getting projects complete is the only problem.
#2
Never too late to realise something. Even now despite my ignorance/arrogance.
03/20/2011 (12:17 pm)
Point taken, :)Never too late to realise something. Even now despite my ignorance/arrogance.
#3
03/20/2011 (6:51 pm)
My lack of in house experience shines through ;(
#4
03/24/2011 (9:05 am)
This is why producers get the big bucks, they can speak both languages and can do both jobs themselves.
#5
03/24/2011 (9:16 am)
I had better get some practice as a producer so... of course after improving my programming skills. Also after I get my head straight. Cheers.
#6
As a programmer, my biggest issue is in keeping artists focused and motivated as you often need to tread a line between artistic freedom and agreed specs/assets.
03/24/2011 (9:46 am)
I agree with all the points. Technical Artist is indeed becoming a very important role too (and well paid).As a programmer, my biggest issue is in keeping artists focused and motivated as you often need to tread a line between artistic freedom and agreed specs/assets.
#7
03/24/2011 (10:25 am)
Cheers for points of view, all of them are helping out no end.
#8
03/27/2011 (11:21 am)
Honestly Sean, I am neither an artist nor a programmer, but since I am managing our project, I deal with artists, programmers, writers, designers, etc. I find that almost everyone I bring into the project has a view of their 'dream game' and they want me to hear all about it. I spent two days 'arguing' or should I say discussing "why our designs won't work but his will" with a fellow I was considering bringing in to create some scripts for us. Needless to say, we both decided it wouldn't work. I have found that usually most people who come in with solid ideas do have something to offer and can actually make a game design better. But it can be difficult explain to them that you are looking for writers or programmers rather than more designers. :) I do think its a learning process and I hope I will learn how to identify a good fit earlier in the process. I have a great deal to learn!
#9
Always good to get info gathered through experience rather than an 'organisational behaviour/project management book', its seems the negotiation could be coined as the 'eternal struggle' but games have been created over the years so a compromise would have been reached eventually among their creators. The good fit is like a diamond in the rough nowadays (for my inexperienced perspective of course).
A good way to discover a diamond in the rough is to understand the future contributor's/employee's discipline. Even just the fundamentals. That way you will be able to know who is good and bad on a deeper more significant intrinsic level. Being able to better analyze and break down the work submitted to you for review, really separates the wolves from the sheep.
Regarding learning, take your time and enjoy it. I have been here for the past five years and only in the past couple of months, I have really started to enjoy it. Because not rushing. The documentation and info on the torque developer network is great to help out with getting started also. Definitely go through the documentation. It's a must....
03/27/2011 (12:15 pm)
@Teila - cheers for reference point. We are all still learning thankfully, otherwise the journey would not be as fun.Always good to get info gathered through experience rather than an 'organisational behaviour/project management book', its seems the negotiation could be coined as the 'eternal struggle' but games have been created over the years so a compromise would have been reached eventually among their creators. The good fit is like a diamond in the rough nowadays (for my inexperienced perspective of course).
A good way to discover a diamond in the rough is to understand the future contributor's/employee's discipline. Even just the fundamentals. That way you will be able to know who is good and bad on a deeper more significant intrinsic level. Being able to better analyze and break down the work submitted to you for review, really separates the wolves from the sheep.
Regarding learning, take your time and enjoy it. I have been here for the past five years and only in the past couple of months, I have really started to enjoy it. Because not rushing. The documentation and info on the torque developer network is great to help out with getting started also. Definitely go through the documentation. It's a must....
#10
03/27/2011 (3:57 pm)
Good advice, Sean. I have been doing this for 10 years but as a writer with a team of about 7-10 writers. It was challenging but definitely worthwhile. I learned not to dismiss someone who wasn't perfect but to work with them. Many of those individuals have become huge assets to our team. Uncovered talents, especially among younger folks but often among those of us who have had other careers as well, are often buried in those rough diamonds. :)
#11
I will have to work on that myself.... but the ego is dissipating gradually thank god.
It must be interesting discovering things about people as you go along in development. I suppose a group of imperfect entities make up a perfect one. All for the greater good.
03/27/2011 (4:05 pm)
10 years? that puts me in my spot apologies ;)Quote:I learned not to dismiss someone who wasn't perfect but to work with them.
I will have to work on that myself.... but the ego is dissipating gradually thank god.
It must be interesting discovering things about people as you go along in development. I suppose a group of imperfect entities make up a perfect one. All for the greater good.
#12
03/27/2011 (5:05 pm)
Apologies not necessary! I am new to the design side, other than a few scraps they used toss to me once in a while. :)
#13
03/29/2011 (6:05 pm)
It is fairly easy to create a demo or get something up and going as a programmer (being one I can understand your point of view to a degree), but when it comes down to getting more visual polish and building something that doesn't look like programmer art (there is a reason that word exists) then you probably will want to work with someone who uses that side of their brain a little bit more even if it is smaller project. It could just also be a case as Teila mentioned that you and that person wouldn't and shouldn't work together. It is important in a small group that everyone is comfortable working together and I would value that over someone that might be more experienced, but everyone hates and causes more problems then they are worth.
#14
Totally Agreed, luckily though I was trained in art and writing before got into programming so at least I have half a chance of avoiding it as an indie. But sound is another story ;) I'll get my keyboard out a make sound like the first king's quest.... Really cool and retro. Only joking, good sound is always needed. Sound effects, no problem but composing music is not my fortay. If that is the only thing I can't do then no bother. Plenty of freelancers around.
03/29/2011 (6:23 pm)
@JoshuaTotally Agreed, luckily though I was trained in art and writing before got into programming so at least I have half a chance of avoiding it as an indie. But sound is another story ;) I'll get my keyboard out a make sound like the first king's quest.... Really cool and retro. Only joking, good sound is always needed. Sound effects, no problem but composing music is not my fortay. If that is the only thing I can't do then no bother. Plenty of freelancers around.
#15
03/30/2011 (12:29 pm)
The value of a team is that someone will always ask you something that you realize you cannot answer. :) I don't think I would work without my team.
Employee Michael Perry
ZombieShortbus
1. Never treat your teammates like enemies or creators of problems. I've seen more programmers with antagonistic attitudes than I have artists or designers. Amazing art sells games and engines, so treat them well.
2. Respect is a two way street. There is no VS, there is only cooperation. Both parties should take the time to develop a solid information exchange process. If an artist has a demand of the engine, they need to clearly explain what they are trying to accomplish. If the engine cannot support a feature for the artist, the programmer needs to explain why, suggest alternatives or research ways to support it.
3. Technical artists are a programmer's best friend. They can help bridge the gap between programmers with no artistic understanding and artists with no technical knowledge.
4. For programmers: if you have the time, get some books on art tools like Max and Maya. Watch video tutorials Photoshop and 3D modeling. You do not have to become an artist, but knowing the language and processes of an artist is going to alleviate many potential headaches.
5. There is always a weakest link, but it is up to the lead to identify it and strengthen it. Work with the person who does not have a tech understanding before you write them off.
6. If you formed a team, it is because you have acknowledged a project is too much work for you alone. You are the head of the snake, so act like it. Lead them, but do not assume you know everything. Do not say you need help, then bully someone because they do not know something.
I can go on and on, but when a project fails or a team falls apart, you start by looking at the top for blame.