Managing the Development of Game Art

Hi everybody, our Lead Artist on Astrobase Command, Daniel Dahl, has been putting up some great thoughts on the creation of game art. I've collected several of his weekly updates here so that they can hopefully give you a hand in your own work.

------

Today we’re doing a Special Weekly Dev Update. This is a first for us so if there will be more in the future will depend on how you guys like it compared to the increased time investment to make them.

The goal of this is to (hopefully) give insight into how and why we do things, and perhaps help you better make your own games in the future.

Astrobase Command is not a prototype. But everything starts in the beginning, and for games the beginning is a prototype. Prototypes are relatively small things and can be more easily explained and summed up than an entire production cycle. This is why the Specials will focus on prototypes.

This first Special will be Daniel talking about the initial stages of how he finds a style for a game. This is in part Art Direction and in part Concept Design.
Prototype Art I:

Making a prototype is a lot of fun. It’s a limited period of time where you get to fill your mind with new cool and shiny things. It’s something I’ve done quite a bit and always enjoy getting another opportunity to do.

Starting out making art for a new prototype I usually start by taking a while to get a feel for how it will feel to play. If it has any particular story elements tied to them or if it belongs to an existing IP that of course has to be included in the consideration.

Depending on if the vision overlaps with already existing art, or if there is a need to be extra unique, or if I already have a good visual library in my mind; my course of action differs. If I have a good visual library to pull from I skip ahead to either concepting or production. If I am exploring new ground I start gathering references.

References are super powerful but can also be very dangerous. References are basically any images or videos of stuff that has some element you like for your own project in it.

Their power is that you get to very quickly get a great way to communicate to a Concept Artist (or really anyone) what style of technology, creatures, mood, colors, etc you are aiming at. This is one of the cases where an image says a thousand words.

The danger of using references is that for a less experienced artist (or other people without a lot of experience in how to art) it is easy to just pick up a specific reference, instead of using it as inspiration, and make a copy of it.
Making a copy of someone else’s work aside from moral, and potential legal issues generally has the piece end up being boring and uninspired. So much of creativity in design comes from the individuals mind.

Another potential pitfall with using references is that if you find something where one element of it is a great fit for you it’s pretty hard to not let the rest of it sway you from your vision. Of course sometimes those things swaying your vision are valid solutions to issues you haven’t yet realized you will encounter down the road you’re going. You need to weigh this carefully.

Concept Art is a tricky subject as the term has become a bit blurry. Much of Concept Art that the average person sees from companies is not made to communicate how something should look between people on the team. To show the production artist what it should look like all you really need is the designs for the specific object and some information (painted or written) of what types of materials and colors it should use.

What you see from most games getting called Concept Art is really highly rendered, detailed, and polished illustrations. Much of their purpose is to be Promotional Art.
Now, there’s nothing wrong with promo-art. It’s not only pretty pictures but it also helps to communicate the style to non-artists, externals, and players. It does however take a lot longer to make than just getting the design down.

When a concept reaches a 3d artist it helps to have a nice picture for them to pull from but it is not needed. Most of the work done aside from figuring out the design of the object will end up being discarded as you can’t use a concept as a texture (usually), and even if you could you wouldn’t want to since it’s not compatible with PBR shaders or procedural textures.

Another consideration you need to make is if it is worth it to make a single concept. Especially when working on a prototype. I’ll go into that in more depth along with actually how to actually make the art for the prototype in the next special.

---

Prototype Art II:

Concepts, are they worth it?
The short answer – No.
The long answer; Yes. No! Maybe? You see, it really depends on what the scope and deadline of the prototype is.

Sometimes the goal is to have a full pitch package, with a playable bit of game accompanied by concept art to show externals a wider view of the world along with the narrow bit of gameplay you present. If that’s the case, and assuming you also have enough time to actually accomplish it the answer is Yes. Without a doubt.

Sometimes your prototype has a deadline only allowing a scope containing nothing but a playable you really don’t have the time to put into making concepts, since they aren’t intended to be presented. So, no.

Of course there are any number of circumstances where it’s a maybe. Not only just the time and planning needs to be taken into consideration, but also things like the strengths and weaknesses of the involved artists as well as who the target audience is.

What tends to be the answer from my experience is that the deadlines are too short to do both. The reason is simple, it’s generally quite risky and the cost of having employees (or yourself) do this stacks up very quickly. Of course, sometimes it ends up being the playable bit that is dropped and concepts/pre-rendered images are favored.

Now, assuming you picked one path and you’re now ready to art it all up. So how do I do it?

Since making a prototype is generally a very time-boxed thing I usually start planning out what is needed by writing a list of everything I find is obviously needed to describe the game. I then sort the items on the list into different categories;
* Things that are essential.
* Things that should be in.
* Things that would be nice.
It’s not important to have everything listed from the start. I just list the things I can think of and then during the process I add things as I come to think of that are missing from the list, as well as remove ones that have become invalid. And of course, the categorization of any listed item is always up for re-evaluation.

With the list in hand I just start making the thing that I have the clearest mental image of and is most essential. There’s no real time to reflect too much, things need to get done so I just get at it. The biggest danger of making a prototype (assuming you have a deadline) is to not get it finished in time due to unexpected turns in making it. For example you might discover that the characters need to be a bigger focus, and therefore need a lot more work to hold up. Or maybe you realize that you might be able to squeeze in a second level set in a different location instead of just making the one.

In order to mitigate the risk from this unknown the safest approach is to have an iterative process. I make the essential items first, at the lowest acceptable quality level. I then evaluate depending on how much time I have left and how much is left to do.

If I’m already running out of time, I do what I can to polish up what I have.

If I’m good with time just go ahead and do a first pass on the next tier of items.

Once I’m at about halfway to the deadline (or when I cant think of what else to add) I generally want to start a quality pass. At this point I have a decent picture of what is done and what the target is, so it’s easier to know how much I can afford to bring up the overall quality and it’s easier to spot what is sticking out the most and potentially address it.

Sorry about the wall of text, this is a pretty theory heavy part of Game Art and it’s hard to illustrate something like this with graphics. I tried to be as brief as possible but I tend to go on quite a bit when discussing topics I’m interested in.

---

Game Art Balance I:

An easy mistake to make is to think that by balancing two things means there should be equal amounts of each. Nothing could be further from the truth, most of the time balancing things against each other means figuring out how much you can squeeze into the less important without messing up the more important one.

Today we’re going to be looking at three of the axes of game art; fidelity, stylization, and utility. But don’t fear, there are many more.

To begin lets look at what they are.

Fidelity.
This is what many think of as the amount of detail something has. For example a character made of 100,000 polygons and 5 * 8192×8192 textures has a higher fidelity than the same character made with 1,000 polygons and a single 256×256 texture. It’s however different from detail, lets say you have two Cubes that to your eye, even on close inspection, appear identical. And only when you look at how it was made can you tell that one has much higher polycount and texture size than the other by several orders of magnitude. In this case there is a difference in fidelity but since the extra fidelity is not used to add anything there is no difference in detail.

Stylization.
This is how the Art Direction deems the asset should look. For example if you’re making a mushroom for a realistic FPS game you probably wouldn’t want to make it look like it belongs in Mario Kart. This impacts everything from what shapes are used to what style the textures are painted in to the proportions of an object.

Utility.
The purpose of Game Art is ultimately to enable gameplay. An object needs to communicate what it needs to to the player and it needs to be as usable as it is expected to be by the player. If you are making an explosive barrel, the color that screams explosive barrel to the player (so that they can see which barrel to shoot) is red so it needs to be red. But it might also need to be big enough to be easy to shoot but not so big that any stray bullet will hit it.

Knowing this of course brings up several issues where the needs of the different axes conflict with each other, some more obvious than others.

Fidelity vs Stylization:
You are making a chair, the poly-budget is high enough for you to make two chairs in the target style, what do you do? Stop wasting time on making two chairs, just make one at the target style and be happy you could get in under budget.

Fidelity vs Utility:
You are making a pistol for the first person view, these are usually pretty high-poly. However the game needs to run at 60 fps and your pistol is eating up 10% out of the total frame time, double what is acceptable, now what? This one is a bit trickier, mainly because there are different solutions. You can optimize, reduce the fidelity until acceptable. You can start over with the ingame mesh and get it right. Which of these is faster really depends on the situation. Another option would be to, if you never see the pistol from the opposite angle (since this is the first person version), cut off the entire opposite side of the pistol.

Stylization vs Utility:
You’re making that lovely red barrel. The style has it looking awesome, fitting in perfectly in the world. But playtesting shows that the player can’t find it. To remedy this you could make them much more brightly colored and bigger. However this would make them not only look completely out of place, but also ugly. The solution is to figure out at what point of compromising between the two you achieve the optimal balance. Or, if possible, figure out a way to get both utility and stylization. This is of course much easier said than done.

These things might, especially the first two, sound super obvious but they are still common mistakes. Sometimes due to inability figure out the balance, sometimes because they ran into the deadline, and sometimes because of stubbornness, a refusal to admit the requirements of reality.
This is why many games run poorly, look like crap, and are unplayable.

Now, this is just scratching the surface when it comes to what you need to find the balance for when making every single piece of Game Art.