Art in indie games
Author
Hello. Just a quick question. I'm thinking about starting on another (more ambitious) game project, but I was wondering whether it's best to have an artist beforehand. See, I have zero moddelling/texturing talent, so I usually use programmer art. Is it best to have some idea of how I'll get art beforehand, or just start working with programmer art and worry about that later?
Thanks,
best of wishes,
-xy
I always prefer to make my games without art first, as a prototype, to make sure it's fun before putting the time and effort into making it look good. Art made too early may have to be scrapped when you discover it no longer fits the game you are making.
On the other hand, if alot of art is necessary, getting started earlier might give your artist a head start. It depends on the type of game you are making, and the willingness of your artist to be flexible.
On the other hand, if alot of art is necessary, getting started earlier might give your artist a head start. It depends on the type of game you are making, and the willingness of your artist to be flexible.
As an artist, I'll usually espouse the use of good art, or else your game may fall into the "bad first impression" loop. Even so, I agree that if your game is no fun, or the programming is severely broken, it's not worth pumping lots of art time into it.
So, as a second voice (this one from from the art side), I figure that if you're still in the testing phase, it's probably best to focus on the programming and gameplay. Once you have an idea of what sort of art you want, then you can start some serious work on it.
Two other things to keep in mind, though, especially if you have a willing artist and are open to teamwork:
One, you may want to use an artist in the testing phase, so you can see what sort of things they come up with, so you know what you'll have to handle from the programming side. For example, an artist's approach to modeling and animation might need a different approach to programming (to use their work) than you might anticipate.
Two, if you have an artist working with you as early as concept designs, you will most likely have a stronger design overall.
These are facets of the overall design strategy that I try to abide by: use both the technical and the art as much and as synergistically as you can. They enhance each other, and you never know when a technical issue might be solved by an art tactic, or vice versa.
So, as a second voice (this one from from the art side), I figure that if you're still in the testing phase, it's probably best to focus on the programming and gameplay. Once you have an idea of what sort of art you want, then you can start some serious work on it.
Two other things to keep in mind, though, especially if you have a willing artist and are open to teamwork:
One, you may want to use an artist in the testing phase, so you can see what sort of things they come up with, so you know what you'll have to handle from the programming side. For example, an artist's approach to modeling and animation might need a different approach to programming (to use their work) than you might anticipate.
Two, if you have an artist working with you as early as concept designs, you will most likely have a stronger design overall.
These are facets of the overall design strategy that I try to abide by: use both the technical and the art as much and as synergistically as you can. They enhance each other, and you never know when a technical issue might be solved by an art tactic, or vice versa.
As someone working a project without any good art i would say go for it. My team and I can still work on the game just fine, we'll have to go over some code to make acomodations for the art, but it's not to big of a deal. Only problem about not having art...no screenshots. Although i highlt suggest that you get concept art. Not only will it help you get sprite/modeling artist, it'll liven up your design document, and aserve as something to show. Good luck.
As I believe most people like flashy looking graphics over game mechanics, and will more likely comment on it if it looks good (maybe this is a misconception of mine), it does a lot for your motivation to hear good feedback, even if it may only be at a superficial level. So by posting a screenshot with perhaps even preliminary artwork by an artist, may do alot to progress the project on further because you can see what the end product may look like, and you may be more inspired to push on. And everyone loves praise. :)
But I could be completely wrong, as I'm neither a good artist, nor a Sid Mier - but I dabble a bit with graphics, and find I'm more prone to continue when things look right. :) That all said though, I certainly see no problem starting with programmer art. It all depends what motivates you, or your group (if you work in a team).
And you could always program a roguelike game. (Adom rulez, btw :))
But I could be completely wrong, as I'm neither a good artist, nor a Sid Mier - but I dabble a bit with graphics, and find I'm more prone to continue when things look right. :) That all said though, I certainly see no problem starting with programmer art. It all depends what motivates you, or your group (if you work in a team).
And you could always program a roguelike game. (Adom rulez, btw :))
As art has a huge influence on how you percieve your game, it has a very important role. You might think that it would look cool if a monster died in a pool of green acid, and you start coding this using some kind of crappy monster and it looks kinda ok. Then comes the monster design along a the artwork, and suddently the green monster in a green acid pool isn't cool, it would have been a lot better having it blow up in a electronic discharge.
This scenario is bad in two ways, first you used a lot of time getting the acid death thing working, maybe even got the animators working on a acid death. Both the time and work is now wasted (Unless you find another monster and let him die in the acid). But you now have to start over and create the lightning explosion.
And vice versa, the game tends to change as the graphics envolves.
Get concept art as much and early as possible, don't start coding until you have the storyline ready, and try to get the storyboard ready before coding. Most of us need visuals to imagine it, how would you create the black moon?
This scenario is bad in two ways, first you used a lot of time getting the acid death thing working, maybe even got the animators working on a acid death. Both the time and work is now wasted (Unless you find another monster and let him die in the acid). But you now have to start over and create the lightning explosion.
Quote:
Art made too early may have to be scrapped when you discover it no longer fits the game you are making.
And vice versa, the game tends to change as the graphics envolves.
Get concept art as much and early as possible, don't start coding until you have the storyline ready, and try to get the storyboard ready before coding. Most of us need visuals to imagine it, how would you create the black moon?
Quote:Original post by Sturm
As art has a huge influence on how you percieve your game, it has a very important role. You might think that it would look cool if a monster died in a pool of green acid, and you start coding this using some kind of crappy monster and it looks kinda ok. Then comes the monster design along a the artwork, and suddently the green monster in a green acid pool isn't cool, it would have been a lot better having it blow up in a electronic discharge.
Agreed that art does have a huge influence, but if you start making a monster dissolve into an acid pool before you even have an artist, you are definitely jumping the gun. My suggestion wasn't "make the whole game before you have an artist". It was "prototype the game and make sure it's fun before you have an artist". Consider Half Life 2: they made every level using orange walls first, balancing them until they were fun without flashy graphics. Then they handed the levels off to the artists to make them look good, modifying the gameplay in the levels when needed. There was a back-and-forth, but gameplay was paramount (as it should be... we are creating games).
Quote:Quote:Art made too early may have to be scrapped when you discover it no longer fits the game you are making.
And vice versa, the game tends to change as the graphics envolves.
Get concept art as much and early as possible, don't start coding until you have the storyline ready, and try to get the storyboard ready before coding. Most of us need visuals to imagine it, how would you create the black moon?
It's a back-and-forth, but all the art in the world won't save a concept that isn't any fun. "Don't start coding until you have the storyline ready?" That recommendation makes my ass hurt, seriously. I don't mean to be rude, but a storyline doesn't mean dick if you don't have a game that's fun.
The game rules in your head are not fun, no matter who you are, I guarantee it: a designer has a "feel" that they want to get across, and they have to figure out the rules to get that "feel" Prototyping will solidify your ideas, skipping this important step and writing a story and creating art is, IMO, the absolute opposite path that any good game designer should take.
Once you know your game idea is solid, then you start making the monster that explodes or melts into green ooze or whatever, while coding up the main game.
Quote:Is it best to have some idea of how I'll get art beforehand, or just start working with programmer art and worry about that later?
A quote from the OP. Yes, you want to have some idea of how you'll get art. But I wouldn't kill myself over figuring out all of the art assets until you know what is necessary to make your game fun. No art is needed for a prototype, and only a small amount of art is needed for a first playable (however, that art should be indicative of what the final game will look like).
Of course, it sounds like I'm in the minority here.
Quote:Original post by JBourrie
My suggestion wasn't "make the whole game before you have an artist". It was "prototype the game and make sure it's fun before you have an artist".
I really don't think you can prototype a game. There are section you can prototype, effects, but not the full game (Unless you are creating tetris again).
Quote:Original post by JBourrie
Consider Half Life 2: they made every level using orange walls first, balancing them until they were fun without flashy graphics. Then they handed the levels off to the artists to make them look good, modifying the gameplay in the levels when needed. There was a back-and-forth, but gameplay was paramount (as it should be... we are creating games).
I do believe that HL2 was storylined before the first line of code was written. Though I can't say for sure as I wasn't part of the team. But I'm very sure that they knew where they wanted to take the game before they started to do it. Making games is similar to making movies. Before you start to shoot the film you need the story. But having the story isn't the same as having the storyboard.
Quote:Original post by JBourrie
"Don't start coding until you have the storyline ready?" That recommendation makes my ass hurt, seriously. I don't mean to be rude, but a storyline doesn't mean dick if you don't have a game that's fun.
...
Once you know your game idea is solid, then you start making the monster that explodes or melts into green ooze or whatever, while coding up the main game.
I think you are misunderstanding me here. You think of the storyline as the storyboard. But these are not the same. How do you know if you have a sound game idea if you do not have an idea of what you are going to create? You will need some kind of storyline in order to know where you are going with the game. You cannot just "take it as it comes", games, like movies, today have to be complete, they need the red line which makes sense to follow (It might be a insane red one, but it has to be there). I, and many I know, get fustrated over games/movies where the story doesn't make sense, where the ending was quick and dirty just because the time lacked to make the story right.
Quote:Original post by JBourrie
Yes, you want to have some idea of how you'll get art. But I wouldn't kill myself over figuring out all of the art assets until you know what is necessary to make your game fun. No art is needed for a prototype, and only a small amount of art is needed for a first playable (however, that art should be indicative of what the final game will look like).
At the time where you get the artists in your crew you should have a clear idea of where the game is going. I'm not saying that it needs to be a fixed paved road, but you need the direction.
Creating games is like creating movies (Many games are starting to look and feel like movies):
1) Get the right story (storyline)
2) Get a manuscript (storyboard)
3) Create concepts
4) Start shooting the movie (coding)
And just like movies there will be scenes you'll cut out, redo over and over until it's right, cut out because they didn't work, and add because it feels right.
The whole process, including content development, is iterative. I think it's best to start out with placeholder art, even if you just use simple geometry shapes (cubes, cones, spheres, and so on). This allows you to implement the core gameplay without being distracted by shininess. If you are going to contract an artist, it helps to have an early development version or prototype so that the artist can get an idea of how the game plays. This will aid in the creative process and put you both on the same page. You can continue iterating the gameplay until you've got it where you think it should be, then move on to the shininess. As the art content arrives, plug it in. It's fun to watch your world of spheres, pyramids and crappy textures gradually evolve into your final vision.
Quote:Original post by Aldacron
The whole process, including content development, is iterative. I think it's best to start out with placeholder art, even if you just use simple geometry shapes (cubes, cones, spheres, and so on). This allows you to implement the core gameplay without being distracted by shininess. If you are going to contract an artist, it helps to have an early development version or prototype so that the artist can get an idea of how the game plays. This will aid in the creative process and put you both on the same page. You can continue iterating the gameplay until you've got it where you think it should be, then move on to the shininess. As the art content arrives, plug it in. It's fun to watch your world of spheres, pyramids and crappy textures gradually evolve into your final vision.
I couldn't have said it better myself :)
And to Sturm: I think what you are calling Storyline, I would refer to as Game Design (possibly why theres a butting of heads here). In my experience, prototyping is the best way to get a solid game design.
Quote:Making games is similar to making movies. Before you start to shoot the film you need the story. But having the story isn't the same as having the storyboard.
Making games is nothing like making movies. The business of games is derived from the business of movies, as they are our closest media cousin. But making a "game" is not a story, it is (at it's essence) a collection of rules that creates a play experience. This can be seen in games like Tetris, Checkers, Poker, which are purely a set of rules with no extra strings attached.
This is what prototyping does for you: it allows you to create the set of rules free of all other distractions. Once you understand where the fun of your game comes from, you can then create the end-user experience through the use of graphics, sound, and story.
Quote:I, and many I know, get fustrated over games/movies where the story doesn't make sense, where the ending was quick and dirty just because the time lacked to make the story right.
Game design, in itself, is not to blame here. This is the result of a person adding a story and/or other media elements (i.e. not gameplay) that were poorly designed and detracted from the end-user experience instead of adding to it. No story is better than a bad one. Art is similar. When I was doing Rumble Box we had two options: stick with simple geometric shapes or have bad programmer-art models. We stuck with the shapes and have garnered alot of praise for the quality of our graphics (they're freakin cubes! :)
The point is that to focus on anything besides gameplay "first" is a dangerous move, and games that are gameplay-only can often be better then the story-driven hollywood epics that usually don't spend enough time in the game design phase (which, IMO, should include prototyping).
Quote:Creating games is like creating movies (Many games are starting to look and feel like movies):
1) Get the right story (storyline)
2) Get a manuscript (storyboard)
3) Create concepts
4) Start shooting the movie (coding)
1) Get a game concept
2) Prototype it to figure out if it's worth pursuing
3) Discover through the prototype what is fun about the idea and grow it into a full game design (usually a document)
4) Figure out the art assets needed to create the experience you have designed
5) Start making the real game (coding)
(Note: This is also why I feel that game designers should learn to code, at least a little. Prototypes can be as simple as little Java applets made in Processing, or flash projects, but if the designer himself is in there playing with the prototype it can make all the difference)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
