{"id":838,"date":"2014-02-21T11:26:20","date_gmt":"2014-02-21T11:26:20","guid":{"rendered":"http:\/\/www.qcfdesign.com\/?p=838"},"modified":"2014-02-21T11:26:20","modified_gmt":"2014-02-21T11:26:20","slug":"coders-5-things-your-indie-artist-would-like-you-to-know-about-graphics","status":"publish","type":"post","link":"http:\/\/www.qcfdesign.com\/?p=838","title":{"rendered":"Coders: 5 Things Your Indie Artist Would Like You To Know About Graphics"},"content":{"rendered":"

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

More importantly, unlike larger studios (where formalised roles of designers and project managers become more clear and compartmentalised), indie projects tend<\/i> to be dominated by a programmer, simply because there\u2019s 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\u2019s not the sort of environment that we have enough experience to comment on.<\/p>\n

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

(1) Respect and communication are vital<\/b><\/p>\n

\"MarkandPaddy3\"<\/p>\n

Image: sharpsuits.net<\/a><\/em><\/p>\n

This is a short point, but it\u2019s 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 \u2013 and explaining \u2013 the constraints of a project are your<\/i> responsibility. Artists aren\u2019t magical unicorns (unicorns can\u2019t draw for shit, anyway) and won\u2019t 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 \u201cspecial\u201d one, and while you shouldn\u2019t underestimate \u00a0the ability of the average colour crusader to innovate and work with difficult situations<\/a>, you really don\u2019t want to be one of those<\/i> clients.<\/p>\n

Everything you think about in code is already in your head. If you want to get those ideas and restrictions into another<\/em> person’s\u00a0head, learn to communicate properly.<\/p>\n

(2) Game art is more two-way than you think<\/b><\/p>\n

\"Sandwich\"<\/p>\n

Image:\u00a0sharpsuits.net<\/a><\/em><\/p>\n

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\u2019s actually the core experience (read: pages of moving and emotional if\/else<\/i> statements). As the engineer in your project, you\u2019re 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 \u2013 which often, though not always, further promotes coder-led indie projects.<\/p>\n

This bias can quietly smother plenty of interesting art ideas if you\u2019re not careful. Yes, it\u2019s 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 \u2013 small or not.<\/p>\n

In short: a good programmer can give artists a decent brief, but a great programmer can adjust the brief based on the artist\u2019s needs and suggestions. And if you can\u2019t carry out a particular vision, figure out if there\u2019s a more realistic change to be made and bounce that<\/i> off your colleague. Don\u2019t 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\u2019s practical.<\/p>\n

(3) You need some art literacy<\/b><\/p>\n

\"cartoon_72dpi\"<\/p>\n

Image:\u00a0sharpsuits.net<\/a><\/em><\/p>\n

During the conversations that you\u2019ll have as a result of point number 1, you\u2019ll 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.<\/p>\n

Although such knowledge may be seen as merely a convenience \u2013 after all, an artsy-type should be able to revise their own stuff well enough \u2013 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 \u201cgood taste\u201d can speed up integration considerably.<\/p>\n

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\u2019s really helpful to be able to say that out loud and understand exactly what it means.<\/p>\n

But more than anything, remember that you\u2019re the gatekeeper to all of the game\u2019s multimedia experiences. When you write a piece of code, you\u2019re 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).<\/p>\n

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\u2019re inserting components, you\u2019re the first person on the team who can spot any errors. You\u2019re also potentially the first person to create<\/i> those errors due to gaps in your knowledge.<\/p>\n

And if you\u2019re liable to flip out and panic when an artist presents you with anything other than a web-ready PNG, you\u2019re going to make their job of dealing with game asset constraints that much more \u2026 uh \u2026 \u201cconstraintful\u201d.<\/p>\n

(4) Build secondary tools for your artists<\/b><\/p>\n

\"Print\"<\/p>\n

Image:\u00a0sharpsuits.net<\/a><\/em><\/p>\n

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\u2019t have direct access to the coding and compilation process \u2013 some of them didn\u2019t even work in the same office. This meant that they had to do a lot of their work blindly, which just wouldn\u2019t 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.<\/p>\n

On the programming end, it was easy to receive and instantly preview art \u2013 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<\/i> 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.<\/p>\n

That’s not the perfect environment for the testing and refinement of dungeon look and feel.<\/p>\n

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.<\/p>\n

If you\u2019re 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<\/em> as possible. Heck, you can treat them as your first audience members \u2013 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\u2019ll be needing to do anyway.<\/p>\n

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\u2019t depend on you for feedback or maintenance \u2013 just a foundation for them to build on. Which leaves you to get other stuff done.<\/p>\n

(5) You\u2019ll need to do some show and tell<\/b><\/p>\n

\"JenniferFarley2\"<\/p>\n

Image:\u00a0sharpsuits.net<\/a><\/em><\/p>\n

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\u2019s career goals involve staying as far away from sprite generation as possible, when you\u2019re indie it\u2019s 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<\/i> work assuming that all mechanics are in place.<\/p>\n

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 \u2013 if you\u2019re on a squad with only one or two programmers, you\u2019ll 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.<\/p>\n

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\u2019t know the details about your combo system won\u2019t be able to suggest climax points to highlight with additional visuals. They won\u2019t be able to suggest a change in the colour of your weapon. They won\u2019t be able to discuss the merits of applying a 50% fade over the screen when you put your world into slow-mo. They won\u2019t be able to suggest a visual effect to coincide with that climax in the audio track. Et cetera et cetera.<\/p>\n

Sure, if you\u2019re 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.<\/p>\n

At the end of the day, an indie coder\u2019s job in dealing with artists should revolve around respect and accommodation. You\u2019re 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<\/i> them \u2026 not above them.<\/p>\n

And that’s about it for now.<\/p>\n","protected":false},"excerpt":{"rendered":"

In this post, we\u2019re dedicating some time to the flipside of last week\u2019s writeup for illustrators wanting to break into game art. For reasons explained last time, this isn\u2019t just gonna be a straight reversal of the previous advice \u2013 a few core asymmetries exist between the work that artists and programmers do, and it\u2019s […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[44,48,49,46,45],"_links":{"self":[{"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=\/wp\/v2\/posts\/838"}],"collection":[{"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=838"}],"version-history":[{"count":0,"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=\/wp\/v2\/posts\/838\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=838"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=838"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.qcfdesign.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=838"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}