How does your art affect your design phase?

Hey All,

A friend and I have been working furiously on a new project. (~Platformer)

Something that has been beating us over the head a bit was how the art and or lack thereof affects the design process.
As the developer this bugs me less. I set up test scenes and create new functionality in a "clean room" of sorts. My mate is the level designer and uses whiteboxing to create the levels.

I'm using spritesheets from old games to frame the animation controllers and get a better feel for the movement. Now this is where it get's wonky. We have a strong vision and story board for our game, with designs on paper and white board to map everything out. A major goal is fluid, tight movement and actions. With limited artwork during the design phase how do you fill that gap in your perspective to make sure that your whiteboxing and prototyping lines up with the final vision and is not negatively influenced by the prototype assets?

I understand the "find the fun first" methodology but imagine playing Ori or Super Meat Boy using only whiteboxed assets. How do you handle the disconnect when designing and prototyping? Do you throw a whitebox alpha at some people and get feedback based on that? Will their experience and thus feedback be skewed by the lack of fluid animations and blocky levels?

Comments

  • I am in a similar situation to you. I was actually given a "what for" on these same forums for focusing on getting my art in the game first and then doing play tests and finalising the game mechanics.

    But the problem I had was that I had already decided the type of game and then I got the basic art and assets in place, and then started focusing on the game play. Now I have to worry more about the game mechanics and game play and less of having to fiddle with the art.

    I guess the bottom line is to use whatever method suits you best. By having the art in first, the sound designer was able to add the humorous elements in the music and tailor the music to match the style of the game while I churned away at the mechanics. My VFX and Artist were able to add the effects and extra models and used the current art and style as their guide while I was churning away at the mechanics.

    This setup worked well for us and we are still making tweaks and changes to the game mechanics, but now when we play test we have the sounds and art to go with.

    I personally don't like asking for feedback on mechanics from the general public while the game is still whiteboxed. I use my internal team to give me feedback on the whiteboxed version and then try to get something non-whiteboxed out to the general public. This may be wrong, but it works for me and I will probably continue to take this approach.
    Thanked by 1GlacieredPyro
  • quintond said:
    I am in a similar situation to you. I was actually given a "what for" on these same forums for focusing on getting my art in the game first and then doing play tests and finalising the game mechanics.
    I went into this post fully expecting at least some backlash. But in the end the girls and guys here are the ones with finished products out there and ignoring any feedback is like throwing away knowledge.
    quintond said:

    But the problem I had was that I had already decided the type of game and then I got the basic art and assets in place, and then started focusing on the game play. Now I have to worry more about the game mechanics and game play and less of having to fiddle with the art.

    I guess the bottom line is to use whatever method suits you best. By having the art in first, the sound designer was able to add the humorous elements in the music and tailor the music to match the style of the game while I churned away at the mechanics. My VFX and Artist were able to add the effects and extra models and used the current art and style as their guide while I was churning away at the mechanics.

    This setup worked well for us and we are still making tweaks and changes to the game mechanics, but now when we play test we have the sounds and art to go with.

    I personally don't like asking for feedback on mechanics from the general public while the game is still whiteboxed. I use my internal team to give me feedback on the whiteboxed version and then try to get something non-whiteboxed out to the general public. This may be wrong, but it works for me and I will probably continue to take this approach.
    Good to see what root you took. I have almost no artistic skill beyond spriting so I won't waste time that I could dev with, making art at first. So I've resigned myself to the fact that we will be designing without. The challenge is just the mental approach to keeping your design in line with your vision with little to no artistic influence.
  • edited
    I went into this post fully expecting at least some backlash. But in the end the girls and guys here are the ones with finished products out there and ignoring any feedback is like throwing away knowledge.
    I agree with you 100% and I respect the ones with finished projects, but there is a right way and a wrong way to provide feedback. Anyway.
    Good to see what root you took. I have almost no artistic skill beyond spriting so I won't waste time that I could dev with, making art at first. So I've resigned myself to the fact that we will be designing without. The challenge is just the mental approach to keeping your design in line with your vision with little to no artistic influence.
    Yeah, that is definitely the challenge and something I struggle with when testing a whiteboxed game. I find myself always wanting to include a crate model for the crate or a proper barrel for the exploding barrel. What I do sometimes however do is build the map using generic walls and mock-up textures and not worrying about those elements ... and I will sometimes only bring the player model and weapons in at a later iteration.

    Good luck with your project. 8-}
  • edited
    quintond said:

    Yeah, that is definitely the challenge and something I struggle with when testing a whiteboxed game. I find myself always wanting to include a crate model for the crate or a proper barrel for the exploding barrel. What I do sometimes however do is build the map using generic walls and mock-up textures and not worrying about those elements ... and I will sometimes only bring the player model and weapons in at a later iteration.

    Good luck with your project. 8-}
    Thanks for the feedback. We greatly appreciate it.
  • edited
    Not having art assets definitely can hinder getting the feel of the game right. Part of designing movement is designing how the visuals telegraph certain information to the player so that the player can understand and master the system.

    I don't think "find the fun first" is a truism. Games aren't even always intended to be fun (and shouldn't have to be).

    Maybe it'd be more true to say, find the core of your game design first. Find what the game can be about first.

    Working with spotty assets that don't cover all the player feedback you need and/or don't cover them well is a problem. I don't really know your circumstances or goals, but what I'd suggest is create some new art assets that allow you to solve your design problems, but create them at a very very low fidelity.

    What I mean is, if you're not prototyping the art style, but are trying to get the gameplay right, then you don't need the game to look like the final game. But you do need it to convey the information that the gameplay requires, so work with the simplest possible art that can convey that information.

    For instance, the art in N++ is super simple, but still conveys an adequate amount of information (for the game that it is):

    To some extent this is a two way street. Complicated art (like Ori and the Blind Forest) can feel very uncanny when the game behavior doesn't follow the art. Starting with the art often constrains the game design in this way. Sometimes there's a particular look that the game needs, and the objective is to bring that look to life. Sometimes the goal is to achieve a certain kind of movement/behavior, in which case the art needs to support that (and obviously there's always a bit of give and take between visuals and behavior, few games are going to be all about the art or all about the behavior).

    It sounds like you primarily want a certain kind of behavior, and you want the art to support that behavior. In that case I'd suggest producing some super fucking simple art that supports your behavior. That way you can iterate really fast on the art and the behavior. And then, when you have things behaving like you desire, you can start suping the art up.

    Even when the art is super simple, you can still start testing things like colour, to capture the right mood. Then, once you have the game behaving like you want, you'll have a LOT more information to inform the visuals of the game.

    Regarding Ori: I'd guess that Ori and the Blind Forest was about the art. They started with a great art idea and then went about bringing that to life. Obviously they were working within constraints and a lot of conventions (it is a 2D platformer). But nevertheless, that sounds like a different approach to what you desire. Their approach is totally valid, but they started with an awesome art team, for them it made total sense. You'll have to figure out where your strengths as a team lie.
  • Not having art assets definitely can hinder getting the feel of the game right. Part of designing movement is designing how the visuals telegraph certain information to the player so that the player can understand and master the system.

    I don't think "find the fun first" is a truism. Games aren't even always intended to be fun (and shouldn't have to be).

    Maybe it'd be more true to say, find the core of your game design first. Find what the game can be about first.

    Working with spotty assets that don't cover all the player feedback you need and/or don't cover them well is a problem. I don't really know your circumstances or goals, but what I'd suggest is create some new art assets that allow you to solve your design problems, but create them at a very very low fidelity.

    What I mean is, if you're not prototyping the art style, but are trying to get the gameplay right, then you don't need the game to look like the final game. But you do need it to convey the information that the gameplay requires, so work with the simplest possible art that can convey that information.
    I think this hits the nail on the head about where our feeling of furstration/confusion arose.
    Conveyance!

    There is a certain feel to movement action we wish to convey and I think that is where the disconnect occurs.

    For instance, the art in N++ is super simple, but still conveys an adequate amount of information (for the game that it is): [SNIP VIDEO]

    To some extent this is a two way street. Complicated art (like Ori and the Blind Forest) can feel very uncanny when the game behavior doesn't follow the art. Starting with the art often constrains the game design in this way. Sometimes there's a particular look that the game needs, and the objective is to bring that look to life. Sometimes the goal is to achieve a certain kind of movement/behavior, in which case the art needs to support that (and obviously there's always a bit of give and take between visuals and behavior, few games are going to be all about the art or all about the behavior).

    It sounds like you primarily want a certain kind of behavior, and you want the art to support that behavior. In that case I'd suggest producing some super fucking simple art that supports your behavior. That way you can iterate really fast on the art and the behavior. And then, when you have things behaving like you desire, you can start suping the art up.

    Even when the art is super simple, you can still start testing things like colour, to capture the right mood. Then, once you have the game behaving like you want, you'll have a LOT more information to inform the visuals of the game.

    Regarding Ori: I'd guess that Ori and the Blind Forest was about the art. They started with a great art idea and then went about bringing that to life. Obviously they were working within constraints and a lot of conventions (it is a 2D platformer). But nevertheless, that sounds like a different approach to what you desire. Their approach is totally valid, but they started with an awesome art team, for them it made total sense. You'll have to figure out where your strengths as a team lie.
    I like your suggestion.
    So for example if we really needed to get the feeling of, let's say blending into shadows. We could use a simple dark gray silhouette on black prop to understand if the feeling would carry over to the player. That is a great oversimplification but it's the gist of it.

    Your suggestion of prototyping according to what you need conveyed to the player only, as apposed to a more polished art asset overall makes a lot of sense to me and seems obvious looking at it now. Line art can even fit the bill as long as we stick to WHY we need the line-art as apposed to a square. In our case to emphasize certain subtle transitions in state and movement.

    Effectively TL;DR;

    It sounds like you primarily want a certain kind of behavior, and you want the art to support that behavior. In that case I'd suggest producing some super fucking simple art that supports your behavior.
    Thank you for this awesome write-up and sharing your thoughts and understanding of the process.
  • Like it's been said, a lot of this comes down to your goals. There are certainly pros and cons to prototyping with and without assets, but being able to convey the core concept is important.

    As someone with little art skills, I usually rely on simple polygons for almost all my prototypes until the project is quite far along. You can certainly get better at looking past a lack of nice assets and filling in the blanks. If a game is fun with just rectangles, then adding in pretty assets seems like it will only make things better. However, I do wonder if I sometimes abandon prototypes that would be great if they just got a little art update, and it certainly makes it hard to show "normal" people. "No, those squares are bad, and those ones are good..."

    Most of the criticism for making art for prototypes comes from the major time investment in generating them, but something that is often overlooked is the time and emotional cost in replacing them if need be. There is almost zero emotional hurdle you have to overcome to replace a rectangle with a pretty avatar (even if the avatar is low fidelity), but trying to basically throw out a complete character design because it just doesn't quite work with the game anymore can be tough. And the thing is: the chance that you'll need to replace the art assets you used in your prototype are pretty high.

    So depending on what your goals are, and your team makeup, you might find that generating low fidelity assets really helps, or you may find that, like me and many other developers, it's usually better to stick with the ol' circles and squares until you're much further along. I like @BlackShipsFilltheSky's suggestion of using low fidelity assets, if you do this well it can be a really great approach.

    TLDR: there is no one-size-fits-all approach, and YMMV :)
    Thanked by 2GlacieredPyro Tuism
  • edited
    In terms of laying out all the pros and cons. One of the cons of avoiding art entirely, and using blocks and shapes, is that you're learning to design around not having art.

    This is great so long as the games you're making are abstract, or you are just prototyping one aspect of the game that can be abstracted out (like how some of the early prototypes of Journey's gameplay where just circles navigating rectangles).

    But working with art, and marrying the behavior to the art is non trivial. If the first time you're trying to solve it is when you come to the final production of the game then you're in a far worse position than a developer who has been practicing it as they go. And working with abstract shapes will often lead you to practice different solutions than had you had art. Possibly avoid whole types of games. If you want to make games where the visuals play an integral role you've got to learn to make them come alive.

    And artists want to be involved in projects from the beginning. Working with abstract shapes robs them of that and relegates them to a role of prettifying a game that didn't need art to work.

    Totally agreeing though that no one size fits all. And it's fastest to implement a game in the way that involves the least amount of content to arrive at that particular game design (and some games require little or even zero art to work).
    Thanked by 1francoisvn
  • ...Snip...
    TLDR: there is no one-size-fits-all approach, and YMMV :)
    In terms of laying out all the pros and cons. ...SNIP... And it's fastest to implement a game in the way that involves the least amount of content to arrive at that particular game design (and some games require little or even zero art to work).
    Agreed, a middle ground is needed that suites ones situation to avoid a miscommunication between design and art direction. One of the pros of using at least something is that it quickly helped me spot bugs. My PC thought it was grounded while wall grabbing etc.

    Pro against the artwork is that level design is truly about the experience of the mechanics.

    I've now taken it upon myself to quickly map what will need to be acted out in some form. Now I am going to make an effort to within an hour or two at most, get the required "artwork" (@see run mspaint) to represent that.
    Anything more than that will be relegated to an artist or my hands when we are feature complete (well... the old last 10% adage)
  • Hi. I've published a couple of games now and to be honest with you, getting decent assets early on is so easy now that I don't make prototypes without it. I find it hard to be optimistic about my work during the design/prototype phase if everything is ugly. I also find it hard to envision mechanics without proper visuals.

    So what I started doing a looong time ago is to assemble a gigantic database of art that I either bought for really cheap (or free) from asset stores or I simply take art from somewhere I'm not supposed to. I build prototypes using those. It extends development time by about 2 minutes if you have some art, or 10 minutes if you need to browse asset stores. And it's generally cheap.

    Another thing that made me do things this way is the influence it has on playtesting. Graphics sell ideas. It's unfortunate but it's true. When I used to show my white box prototypes to other people, the majority of feedback would consist of comments like "Cool but why did you choose white boxes" or "this graphics is bad" etc. Instead of actually getting gameplay feedback. Because ugly (and pretty) graphics are distracting.

    For platforming you can head over to Kenney.nl end get all the stuff you need. Or the Glitch pack from opengameart.org. Those 2 alone are enough for sexy prototyping.

    TLDR
    If you can get graphics cheap and easy then use them. But don't develop around the setup of that art (armature structure, available anims, etc).
  • Eric said:
    Another thing that made me do things this way is the influence it has on playtesting. Graphics sell ideas. It's unfortunate but it's true. When I used to show my white box prototypes to other people, the majority of feedback would consist of comments like "Cool but why did you choose white boxes" or "this graphics is bad" etc. Instead of actually getting gameplay feedback. Because ugly (and pretty) graphics are distracting.
    This is one of my main concerns to be honest. We are planning our first build for Friday to some feedback on one full level and I hope people wont be stuck on the dodge gfx and rather give useful feedback. I will try drive the point though.

    What you say makes sense. spriters-resource has been invaluable in finding what I need.

    Re: animations makes sense also. Luckily Unity is very useful here with mechanim disconnecting it nicely.
    I'm going to throw the Glitch pack at the designer and leave it to him, thanks for reminding me about that.
    Also keeping a repository of generally useful art assets is a good idea. We do it with code snippets so why not this?
Sign In or Register to comment.