Can art wait?

Can art elements wait until game mechanics and features are complete or nearly so? Textures, models, special effects, etc. Is there a downside to waiting to implement these?

I'm much more comfortable with coding and using Unity than I am with something as overwhelmingly complicated as Photoshop or Blender (to me Blender is super complicated), so I'd rather focus on developing my features and mechanics than get bogged down by trying to make my project look nice before it really matters.

Also, I'm developing on my own, so I need to spend my time and money as efficiently as possible. Thanks in advance for any comments, opinions, or suggestions.

Edit: I've tried looking for an answer to this online, but have had no luck.

 

You are good to build up reliable mechanics and game backbone, before any art, specially if you lonely dev.
Just use cubes / spheres / sprites as placeholders for future animations / models.

By the time you get to the reasonable stage, you may learn thing, or two, which will help with selecting art.
But you shouldn't rush to that point.

 

Once the prototype stage is over, it's almost irresponsible to not make art considerations, as they can dramatically affect the development process.

 

Hey thanks for the responses! Murgilod, I know the art direction I want to go when I'm ready for it. I can also use Unity's 3D/2D objects to make placeholders or use stuff from the asset store until I'm either ready to delve into the art myself or hire someone who knows what they're doing. I'd rather hire someone because it would reduce development time, but that will be expensive. At this point, I'm gonna go with Antypodish's advice and get everything else right and then worry about how I'll handle the art.

 

You may want a little art in as you go along prototyping. Adding in a placeholder sound or some temporary particle effects so you know where things should be and so you are starting to think about how you will "juice it up" for the final art.

I've played enough "pretty" games that just weren't fun that I firmly believe in the idea that if it's not fun to play with cubes and basic textures, it's probably not fun to play.

 

If you do the art at the end, you may have bad surprises with performance, here are some things that you may see a bit late:
- too much GPU memory consumed
- loading times too long
- too many vertices in a scene
- special effects too slow
- specific shader problems (especially if you have a lot of transparency)

If you cannot create the art too soon (which would also bring its own problems anyway...), I would advise you to use placeholders which at least are close to the final models you intend to use.
Avoid using cubes, use a mesh with about the same number of vertices you intend to use for the final model, and with a texture of the quality you intend to use at the end.

Also, try to have a total amount of textures placeholders which represent the approximate amount of texture you intend to have at the end.
That way you will have a more precise idea of the loading times and the GPU memory used.

 

I like to use free character and props models from the AssetStore until I get past the prototyping phase. Since they are only for prototyping, I just find models that look very loosely like what I want and not worry about it too much. I also like to remove the albedo maps on these, so that it's more obvious that they are just place-holders.

I've often heard that it's better to wait on the Art until later, because projects evolve over time and you can waste a lot of effort creating assets for features that get cut, or what not. I just like making art, though, so I can't resist.

 

When you start, greybox and work on pure mechanics, make them fun without the fancy looks.
when they take form start on doing basic graphics, a few basic particle effects, make the game feel alive, make you want to work on it more, and you can see the end product in your eyes even though you have only a few basic models, see if anything is too much, too little or what ever.

this video sums up my point perfectly.

the first guy here: (not the one doing the intro, about 5 minutes in)

also this two are a good look at:

 

Lonely dev sounds so sad, say solo dev haha.

 

Semantics. But you got valid point

 

depends on how high a priority it is for your project.

if you are particular about the artistic vision, it's going to require lots of iteration to nail down.

how much art is interconnected with the rest of your design process is dependent on the project and probably your personality. if there is high interdependence, then art should probably be part of the prototyping process.

if you are picky about art but you don't have a clear vision, you'll noodle forever. You got to know exactly where you are going. New artist waste vast amounts of time noodling -- always feeling dissatisfied because they don't know what the goal is. This is why you need concepts and a clear image of the final product.

Art is highly subjective, even within your own brain. Don't waste time pussyfooting around. Once you define a vision and commit to production, it's a fight to the end. No second guessing. Save all of that for dedicated review time. Very important to divide and define your time. Don't let emotions be in charge.

Reworking things many times to meet the goal is good. Reworking things many times without having a goal is useless and will break you down emotionally over time. So if the art is integral to the game, get the goal clearly defined as soon as possible.

Lastly, when it comes to art, shoot for the heart, not the head. What that means is, don't overestimate yourself. Plan for ignorance, failure and worst case scenarios -- not what you believe you can do.

 

I like to get the art in early so I can get the look and feel of the game as quickly as possible. Having the art in also makes for a better experience for any testers, otherwise their feedback will constantly be about the stand in art rather than issues you may actually care about.

There are also performance considerations as well, where you can get a good idea of how your game performs earlier in the process than if you were using stand in art.

The downside is the earlier you create the art, the more likely you may make changes to your game making already created art no longer needed. This can just become a waste of time, but if you outsource or license art like me it can result in wasted money. It also front loads your art costs in your project, which may not be helpful.

 

I got the art after the prototype phase in an art theme and I made a trailer.
I'd recommend getting prototype art and making a trailer you will use to sell and see how other people react to it. Sometimes, your taste in art themes and most other people differ.

 

I can support that first clip posted here.

From my point of view you should focus on the implementation of your art and fx, but not necessairly refine it. If you start to develop your game without these things in mind, basically focusing on the domain level then you might get real trouble once you start implementing the view part.

What I mean is you need to define the infrastructure of your content. Make your systems ready to play effects at any point. Stay flexible whether you want to play an animation, a tween effect or a particle.
You can extend this system once you start working on content and polishing but the fundament should already exist.

I guess it is quite common to start with GameObject.SetActive() and repalce that later with an animation. But things can change a lot then because suddenly the GameObject is always active or at least for the time the animation plays. It could change your logic completely if you have Update methods on it or check for GameObject.IsActive.


Well another aspect can be the scope of your project, you should know the amount of objects, textures and polycount as early as possible. If you make a game which works fine, then add art and you realize it only runs at 20fps that is bad. If you plan to have 500 skinned meshes at once then you should test it out now.

 

It depends on the game. If art is important then yeah, it ought to be trialled early and iterated on just like any other major part of your game.

 

@Rokkr_0 Alot of good advice above.

I will admit, that this is a really interesting question. And so much can be
said here.

When the crew at Platinum Games were creating Bayonetta 2, the programmer
who has worked in the game industry, for over 30 years, himself said in a vid,
"That without the artwork, the programmer has nothing to work with."
It's quite an interesting comment he made, because he even went into more detail.

It's like according to the game being made, and in some particular cases, the
artwork is literally necessary, to help give an idea to the programmer, of how
to program a monster or characters AI, and how they must move or behave,
when interacting with the main character, or supporting characters etc.
Or what events must play, when the monster, or character makes his entrance
in the game etc. If the monster has spikes on it's body, and those spikes are
supposed to fire out, to attack the main player, and other characters, then how
many times should it fire out, at a given time? Etc.

I can say alot more, but it is too much to write.

 

I agree this stuff is important. I don't think it's all one way, though.

In our pipeline here, since I'm a programmer/designer, I'll often start with simple shapes mashed together and then adding functionality to that. Then I'll get input from the rest of the team and, if we think it's worth going forward with, we'll get some simple art in there which reflects whatever interactions are going on. We'll iterate on that just enough that we feel it can be tested meaningfully by people outside of the team. For that to be worthwhile, I'm a strong believer that your presentation and your mechanics need to support each other - it's a two way thing!

Based on feedback we then iterate on both functionality and presentation as needed. We identify issues, and for each one we try to decide whether they should be solved via presentation (not just visuals, but also audio and anything else) or by functionality changes. Generally we do a bunch of both before we're happy with something and are getting consistently good player feedback.

As a concrete example, for one of the early puzzles we made for our current game we had a grey-box block in. The puzzle worked, the functionality worked, and we'd built a new level based on prior player feedback. We took the new level to playtesting events and quite a few players got stuck - a clear fail for what should be an introductory puzzle!

However, from observation it was pretty clear to us that it wasn't a problem with the rules or functionality. Players who found an interactive object seemed to reliably solve the puzzle from there. Players who got bored or frustrated before that point moved on to the next game. So, we changed some art to call attention to the things we wanted people to mess with. From there, the vast majority of players finished the level. We considered that a success, and we got there just by changing our placeholder art.

Later, when we added voice over - some new functionality - we put in one line of dialog which hinted players towards a first step. With both visual and audio cues I think we ended up with effectively 100% completion.

 

What I find interesting is the core challenge at play here. Which is how can you get a team of diverse people to all see and work on a vision of something without having to create concrete representations of everything.

You see this at play when contrasting people who have worked together a long time with those who haven't. The teams who know each other well and work well together spend less time explaining stuff, or having to create some extra representation of something to illustrate their ideas.

I think putting in certain art at strategic points can help a lot. It's a reference point that helps to ground you and others. And art and functionality can be related also.

For our game our maps are what we have that is close to final art style. Just the triangulation and shading makes them unique. It's a great reference point as it occupies so much space. Makes doing demo's easier. I can point out the terrain as being where the art is going, and all the stuff that's not there, is easier to understand and ignore.

That said I think a lot of people get into the habit of not being creative. You do at least have to work at thinking stuff forward, trying to visualize it. That's actually I think a key trait of successful people generally. So the person that is always saying it needs to be in game, is wrong. Maybe it does maybe it doesn't, but you didn't even try.

 

Yeah, you're right. That's why I wrote:
"and in some particular cases,"
Because, there is too much to write, and so much can be said,
on this topic.

But amazing thing is, the way the Japanese come up with their game ideas,
even down to the way they program something,....
eg. a simple object, character or monster, is sometimes based, or influenced
by art, or a drawing, and I find that so artistically and psychologically amazing.

Also, I read your whole comment above. It was really interesting.