Coders: 5 Things Your Indie Artist Would Like You To Know About Graphics

In this post, we’re dedicating some time to the flipside of last week’s writeup for illustrators wanting to break into game art. For reasons explained last time, this isn’t just gonna be a straight reversal of the previous advice – a few core asymmetries exist between the work that artists and programmers do, and it’s not about the creative vs logical approach or however else the issue gets generalised. It’s about high-constraint versus low-constraint environments, and the reality that artists are often forced to adapt to a coder’s constraints rather than the other way around.

More importantly, unlike larger studios (where formalised roles of designers and project managers become more clear and compartmentalised), indie projects tend to be dominated by a programmer, simply because there’s no other way for that project to exist short of an artist engaging with some cross-discipline learning. Either way, an artist-driven project would have its own set of problems separate from the ones described here and it’s not the sort of environment that we have enough experience to comment on.

So, let’s assume you’re a coder-boss-type person on a project where you’re telling somebody who’s way better than you at visual design to draw things in exactly the way you want them to. Here’s a few ways to make the artists you work with a lot less miserable about that:

(1) Respect and communication are vital

Image: sharpsuits.net

This is a short point, but it’s the most important. The rest of the article will detail this further, but the gist of the situation is so: your artists are more than a plug-in device for your project. Outlining – and explaining – the constraints of a project are your responsibility. Artists aren’t magical unicorns (unicorns can’t draw for shit, anyway) and won’t figure out what you want from a highly specialised system (usually of your own construction) without an appropriate level of guidance. Every case you work through with a game artist is most likely going to be a “special” one, and while you shouldn’t underestimate  the ability of the average colour crusader to innovate and work with difficult situations, you really don’t want to be one of those clients.

Everything you think about in code is already in your head. If you want to get those ideas and restrictions into another person’s head, learn to communicate properly.

(2) Game art is more two-way than you think

Image: sharpsuits.net

A lot of indie programmers can be lured into a sense of complacency when dealing with other disciplines, to the extent where they may view assets such as graphics and music as mere accessories to what’s actually the core experience (read: pages of moving and emotional if/else statements). As the engineer in your project, you’re the person who physically slaps the bricks and mortar of the game together. This means you have implicit sign-off privileges that nobody else on the team can benefit from – which often, though not always, further promotes coder-led indie projects.

This bias can quietly smother plenty of interesting art ideas if you’re not careful. Yes, it’s often more practical to work out the constraints and then hand the brief to your resident scribblenaut for them to respond, but try including more phases of listening to their suggestions and figuring out whether your code can be more accommodating or flexible in key areas – small or not.

In short: a good programmer can give artists a decent brief, but a great programmer can adjust the brief based on the artist’s needs and suggestions. And if you can’t carry out a particular vision, figure out if there’s a more realistic change to be made and bounce that off your colleague. Don’t dictate to your artist, have a conversation with them. Go through multiple drafts. Prototype styles and approaches together. Let the visuals have an impact on code whenever it’s practical.

(3) You need some art literacy

Image: sharpsuits.net

During the conversations that you’ll have as a result of point number 1, you’ll often need to make suggestions or offer critiques of the art in a language that your artist understands. Alternatively, your artist will be trying to communicate important ideas using concepts and terminology that both parties are familiar with. The more vocabulary and understanding you have in both cases, the stronger and more nuanced your conversations can be.

Although such knowledge may be seen as merely a convenience – after all, an artsy-type should be able to revise their own stuff well enough – there will be times where your coding knowledge will come in and work closely with the rest of the art. In a lot of indie projects, this tends to be stuff like particles, sprite deformation and unconventional animation systems such as whatever take on inverse kinematics you deem appropriate. In these areas, your personal literacy and “good taste” can speed up integration considerably.

It will also allow you to describe constraints in ways that are more meaningful to your artist. If you want a non-baked, 1px guttered sprite sheet with a fixed alpha mask in PSD format, it’s really helpful to be able to say that out loud and understand exactly what it means.

But more than anything, remember that you’re the gatekeeper to all of the game’s multimedia experiences. When you write a piece of code, you’re putting it in yourself, compiling it and watching the results before your eyes. You can fire up and adjust a program of your creation several times a minute ( at least in more generous circumstances).

Everybody else in the studio has to hand their work over to you and trust that their contribution to the project will be handled properly. When you’re inserting components, you’re the first person on the team who can spot any errors. You’re also potentially the first person to create those errors due to gaps in your knowledge.

And if you’re liable to flip out and panic when an artist presents you with anything other than a web-ready PNG, you’re going to make their job of dealing with game asset constraints that much more … uh … “constraintful”.

(4) Build secondary tools for your artists

Image: sharpsuits.net

While working on Desktop Dungeons, some of our most massive behind-the-scenes devs tools were made with the sole intent of streamlining and previewing art. Our graphical wizards didn’t have direct access to the coding and compilation process – some of them didn’t even work in the same office. This meant that they had to do a lot of their work blindly, which just wouldn’t do in cases where we needed them to build lots of graphically tied-in elements: like tilesets that would add and remove layers depending on the surrounding terrain.

On the programming end, it was easy to receive and instantly preview art – we could copy the files into a ready-made directory, build our project and test dungeons easily. From the perspective of the people who had to make the art, they either needed to successfully predict what the game map would look like without accurate previews, or go through the labour-intensive task of mocking layouts manually in Photoshop every time they made a change.

That’s not the perfect environment for the testing and refinement of dungeon look and feel.

Parts of our code were eventually moved to editor programs and previewers which could treat our artists as end users and streamline their create->preview->revise experience. Soon, they could make rough tilesets and instantly check a sample dungeon’s appearance. This gave them the same information access and quick testing as the coders. Instead of relying on us as middlemen they reaped the benefits of a system that gave them more convenience and autonomy.

If you’re going to give artists constraints, awkward environments and weird styles to work with, the least you can do is meet them halfway and make your process as transparent and removed from yourself as possible. Heck, you can treat them as your first audience members – players who needs a friendly UI and some handy front-end features to engage and affect your creation. Think of it as a practice round for everything that you’ll be needing to do anyway.

And as a bonus: the more they can do things themselves, the more you take pressure off yourself to handle and test their revisions. They won’t depend on you for feedback or maintenance – just a foundation for them to build on. Which leaves you to get other stuff done.

(5) You’ll need to do some show and tell

Image: sharpsuits.net

This point comes last because it’s little bits and pieces of all the other points smooshed haphazardly together and put into tangible practice. Although the average, non-drawing coder’s career goals involve staying as far away from sprite generation as possible, when you’re indie it’s necessary to wear that hat from time to time. It can often be helpful to make mock-ups of game scenarios using temp art (no matter how ugly) and show your artist how something could work assuming that all mechanics are in place.

The goal is to draw your artist into more than one area of the project. As mentioned earlier, your position as coder tends to mean that you have a central role handed to you – if you’re on a squad with only one or two programmers, you’ll probably have to interact with the graphics, build the audio engine and insert other applicable media. All of your fingers are in all of the pies without even thinking about it.

An artist, on the other hand, can easily be excluded and compartmentalised if you treat them dismissively. The smallness of an indie team aside, an artist who doesn’t know the details about your combo system won’t be able to suggest climax points to highlight with additional visuals. They won’t be able to suggest a change in the colour of your weapon. They won’t be able to discuss the merits of applying a 50% fade over the screen when you put your world into slow-mo. They won’t be able to suggest a visual effect to coincide with that climax in the audio track. Et cetera et cetera.

Sure, if you’re smart enough then you could probably come up with a lot of cool ideas on your own. But therein lies the possibility for these ideas to be delayed, incomplete or simply inferior. And yes, while not all of the ideas suggested to you will be practical to implement (as tied to the core issue of coding constraints), having a more involved artist in the long term will give them a better sense of what ideas fit with you, and which areas may be more easily enhanced with a good visual idea.

At the end of the day, an indie coder’s job in dealing with artists should revolve around respect and accommodation. You’re working in an environment where you have first-hand access to all of the tools, limitations and raw elements of a project. The dedicated professional on your left has a broken telephone of requirements and assessments. Understand this, cut them some slack and find out what’s need to work with them … not above them.

And that’s about it for now.