1
General Discussion / Re: Pixel art and games
« on: February 07, 2015, 09:57:40 pm »
Both programmer and artist here, hopefully I can help.
This I would largely attribute to high-quality pixel art being very time-expensive. Even with highly skilled artists it's very detailed oriented thus taking a lot of time and fetching a higher price tag for a programmer hiring an artist for work. Most indies have little to no budget so for example if I wanted to hire an artist, I flat out couldn't pay them hourly during the project because I don't have that cash. It'd have to be a contract for royalty split or something after the game's released which requires a ton more trust between both parties and adds plenty more stress.
I think the so-so art is basically an outcome of the budget issues I described above.
There's often a major disconnect between people of different fields working together because one just doesn't understand what it takes to do some things. Relevant XKCD
For someone who is only a programmer they may tend to greatly underestimate the time it takes to create good art. For an artist they may do the same underestimating of time (lots of programming tasks like optimization, refactoring and testing are time-consuming and important tasks but result in little noticeable difference in the game) or be unfamiliar with whether something is possible or not or going to affect game performance too much.
Perhaps the biggest issue as some others have described is the game ideas themselves. I guess it really depends on the people and what their relationship is already for what is best - whether they are able to share "game design" responsibilities and take the other's ideas into consideration or if one person should be sole game designer. Really depends on personalities but for indie devs just starting out I'd argue that everyone having an open mind to other's ideas is probably the best way to go, as others here have said.
Pros of being two or more people:
- Plenty faster development time
- More ideas/outlooks (but depending on personalities could be a con as explained above)
Cons:
- More communication required to express what's needed. An experienced *game* artist here is much easier to work with than just a talented artist, because there are game-specific techniques needed like tiling, spritesheets, and texture maps that a traditional artist would need to learn.
- Financial stress
- Added layer of development to keep project up-to-date for both sides (like subversion).
From what i've seen, a lot of indie developments start by a programmer who at some point tries to hire or involve an artist into the project. That would, as i imagine it, result in the artist not feeling as involved in the project. It isn't his baby and he wouldn't pour as much work and refinement into it as much as he'd on one of his own works or practice pieces.
This I would largely attribute to high-quality pixel art being very time-expensive. Even with highly skilled artists it's very detailed oriented thus taking a lot of time and fetching a higher price tag for a programmer hiring an artist for work. Most indies have little to no budget so for example if I wanted to hire an artist, I flat out couldn't pay them hourly during the project because I don't have that cash. It'd have to be a contract for royalty split or something after the game's released which requires a ton more trust between both parties and adds plenty more stress.
Do indie devs feel they get away with so-so art because it's indie, and retro? Are we coders expecting too much, too little?
I think the so-so art is basically an outcome of the budget issues I described above.
When artists are trying to develop a game, i often hear that it is rare to find programmers skilled or reliable enough to accomplish their idea(l)s.
When i put that against a lot of debates (artists vs programmers, even if they're childish in nature) i wonder why there's such a distance between the two. I feel they should embrace and flourish together, but it seems it is hard to pair the two.
Is there a lack of mutual understanding between the two disciplins? Do you think coders should themselves get more involved with art? Should artists learn to understand programming? (here we go with the assumptions)
What are your experiences with game development, finding/joining teams, both for fun and professionally? Since i can only talk from a coders point of view, what is your take on this?
There's often a major disconnect between people of different fields working together because one just doesn't understand what it takes to do some things. Relevant XKCD
For someone who is only a programmer they may tend to greatly underestimate the time it takes to create good art. For an artist they may do the same underestimating of time (lots of programming tasks like optimization, refactoring and testing are time-consuming and important tasks but result in little noticeable difference in the game) or be unfamiliar with whether something is possible or not or going to affect game performance too much.
Perhaps the biggest issue as some others have described is the game ideas themselves. I guess it really depends on the people and what their relationship is already for what is best - whether they are able to share "game design" responsibilities and take the other's ideas into consideration or if one person should be sole game designer. Really depends on personalities but for indie devs just starting out I'd argue that everyone having an open mind to other's ideas is probably the best way to go, as others here have said.
Pros of being two or more people:
- Plenty faster development time
- More ideas/outlooks (but depending on personalities could be a con as explained above)
Cons:
- More communication required to express what's needed. An experienced *game* artist here is much easier to work with than just a talented artist, because there are game-specific techniques needed like tiling, spritesheets, and texture maps that a traditional artist would need to learn.
- Financial stress
- Added layer of development to keep project up-to-date for both sides (like subversion).