Pixel Art Tutorial Snippets

Discuss the development of other free/open-source games, as well as other games in general.

Moderators: Forum Moderators, Developers

User avatar
Jetrel
Art Director
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Pixel Art Tutorial Snippets

Post by Jetrel » August 26th, 2011, 8:27 am

Stilgar wrote:Regarding what you said about Allacrost, how has the experience with Wesnoth differed, in your opinion? Wesnoth's sprites/screen size are on the large side according to the measures you gave, too.

1] Wesnoth doesn't have terrain pixel-art. Wesnoth's terrain is "computer painting" for lack of a better term for: just drawing in photoshop/gimp, combined with usage of textures/photosampling to quickly provide textures, rather than having to artificially generate textures with brushstrokes. It's especially the use of textures like that that just collapses the time cost - if we had to actually generate some of the textures by hand (which we have in the past), it takes much much longer - whether pixel-art or painted. You look at the textures in any 3d game, and they're almost always retouched photo-samples - trying to draw them by hand takes a ton of effort. Pixel-art usually doesn't use sampled textures because the act of cleaning up said texture into "micro-patterns" that fit good pixel-art would take a very long time - almost as much as creating a texture from scratch.

By micro-patterns, I mean that not just any arrangement of pixels is 'legal' in good pixel art; there are a lot of arrangements you want to avoid because 1] they convey the wrong texture, 2] they cause banding, 3] they over-AA something into looking blurry when it should look sharp, etc. If you just downsampled a texture into pixel art, you'd want it dithered much more optimally than we currently have algorithms for. I think this could be algorithmicized ... some of photoshop's dithering actually seems fairly nice on gradual color curves, it just 1] kinda sucks at picking colors and 2] whilst it's good at dithering, it doesn't do so great at keeping sharp edges sharp, and such; it sometimes mangles detail.


2] The other big deal is that wesnoth's terrain doesn't "break repetition" on a screen. We've taken some great strides towards that - our mountains for example break what would be horrendous repetition up to an admirable degree, but it's not nearly enough to occasionally "fool the player" into feeling like everything drawn on the screen is fully unique art, without any repetition.

Obviously, you can get that ideal by just drawing full screenfuls of content and not re-using stuff (c.f. the king's quest series, monkey island, and other adventure games), but the problem there is exorbitant art costs (IIRC, KQ5 had something like 25 full-time artists, when I read the credits).

What you want is to strike an optimum where you do re-use stuff, but it's placed sparsely enough that you don't rub the player's nose in it. For example, you might have repeating castle-wall tiles, but you'll have enough "variations" of the brick texture that the user will only see 2-5 duplicates of a given tile image making up the wall - not a giant wall made out of 300 duplicates of just one texture image. If you have trees of a fairly "standard" size for 16-bit platformers, you want to lay out your levels so you only have a couple of those trees on-screen at once (even better, you want to arrange your levels so you never have more than one of the same variant onscreen at once). You don't want to have 20 duplicates of the same thing - it stops looking organic, and starts looking like copy+paste. If you're able to control placement of assets on levels to minimize the number of times anything is simultaneously being drawn more than once on a screen (camera/viewport size plays into this, since a bigger camera area explodes the cost in variations to do this), then you can make it feel like you have more assets than you actually do.

So wesnoth basically just gave up on that - in part due to the mutable viewport size. We've tried, but because people will have ever larger screens, and the map will be made larger to fill them, we can't create the above illusion. We've settled for feeling like a board game. (Realistically, we're kinda inbetween; there are views of the game that feel very board-gamish, and others that feel more like a bird's-eye view down into a miniature world. Obviously the mismatch between unit size and terrain size is also something that firmly pushes us toward board-game territory, as well.

Definitely, though, the big thing we've completely given up on is control over framing and cinematics. There are a number of scenes even in 16-bit games where, because they can strictly say what is and isn't in-camera, they can create the feeling of movie-style camera shots. Consider chrono trigger; and many of the special scenes in it such as the campfire scene, the courtroom scene, or even the entrance to magus' castle. Even on regular map-wandering, the restriction of the camera to a fixed size has a massive, massive effect on what the game "feels" like.

This sort of thing is really the bread and butter of the entire movie industry - it's a huge part of what makes movies emotionally effective. We just don't have that. Other, similar games also don't have that; civilization for example.


3] Wesnoth's sprites are similar in difficulty to allacrost. They're still not nicely animated, but because the game itself is functional without them (and isn't a one-shot story-based game, but is a recurring skirmish game you can play over and over against friends), it didn't kill us. This sort of thing DOES kill an rpg - or anything that's based on a one-time experience of content.

Stilgar wrote:Also, would you have any handy tips when it comes to breaking out of a "rigid" feel in sprites due to difficulties with the concept of a grid of squares getting in the way of planning out more free shapes?
Loosely, draw your art; or generally practice drawing your art, with no concept/concessions towards a grid. Then butcher your art to make it fit on a grid. I can and should speak at length about this, though, since trying to bust the grid was really the crux of one of my primary experiments at frogatto. Not quite now, though; this post is long enough.
Play Frogatto & Friends - a finished, open-source adventure game!

User avatar
Jetrel
Art Director
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Pixel Art Tutorial Snippets

Post by Jetrel » February 5th, 2012, 11:38 pm

Probably said this already, but perhaps the statement of it is better refined this time around:
Jetrel wrote:
puffinpunch wrote: Thanks Xamllew. I couldnt really think of a way to dither the sky apart from a pattern.


Try to avoid dithering as much as you can.

A common newbie mistake in pixel-art, is that people look at pixel art, and they form a sort of "checklist" of what you need to do to be pixelart. Many of these things that they recognize are correct - such as recognizing that pixelart typically has a low color count. The problem comes with dithering - they see that pixelart has dithering in it, so they think "oh, okay, I want to put dithering into my art if I want it to look like pixelart."

Dithering is actually not a good thing, because it adds texture and noise to otherwise smooth surfaces in a drawing. It gives everything this weird, grainy look. Dithering, instead, should be viewed as a necessary evil - you want the least possible amount of dithering that you can get away with. If you're really clever, when you absolutely have to dither, you can co-opt the texture it adds by dithering in a pattern that matches the intended texture of the material you're drawing. On your tree, for example, you could make your dithering resolve into little shapes that look like chunks of bark. Usually this means avoiding dithering that's single-dots, and grouping it into slightly larger chunks.

Pixelart is fundamentally an optimization problem, where you're trying to limit your work with a bunch of different factors that actively contradict each other. For example you want as low of a color count as you can get, but you also want as little dithering as you can get. The lower your color-count gets, the more you need dithering - if it was as easy as just saying "hey, don't do X" - you have to balance it. You have to juggle two contradictory things, and that's the art - defying the catch-22, and coming up with something that uses quite a low color-count, and yet manages to get away with very little dithering.
Play Frogatto & Friends - a finished, open-source adventure game!

User avatar
Jetrel
Art Director
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Pixel Art Tutorial Snippets

Post by Jetrel » July 4th, 2012, 7:51 am

Jetrel wrote:
Arc wrote:I absolutely love frogatto, and I am an aspiring spriter, game developer, and graphic designer. I was wondering, do you guys have any sort of specific palette you abide by? I love spriting by rules and the colors used in frogatto are excellent.
If you do, could you provide a source of the palette or any idea how to achieve it?

Thanks ahead of time,
-Arc

So, ... there are some schools of thought in pixel art where you come up with the palette to end all palettes before you do anything, and then magically do an entire game with that. I've never actually seen this pulled off - I've seen people do it with mockups, but I've never personally seen it done with an actual game. It's always something people "aspire to", but in practice they usually have to do some little tweaks here and there, because they usually find out there's some major thing or another that just really needs a few different (or additional) colors to make it look good.

The way I work is I start freely drawing stuff - I draw using pixel art techniques, using the pencil tool and all, but if I feel like I need new colors, I just make them up on the spot. Often, if I'm drawing something similar to an object I've already got - like if I've drawn a wooden bridge already, and now I want some wooden scaffolding, I'll sample colors from the existing stuff I've already drawn. Sometimes I end up needing a few more shades - usually the palette used on something small, if you're being reasonably economical with colors, just isn't wide enough to comfortably shade a larger object with more gradual curves. Usually it just takes one really big object to iron out almost all the colors I'll ever need for a material type.

Once I've gotten to that point, I usually find all the existing stuff that's of a similar material and make it all conform to a given palette. Sometimes I'll have independently drawn a bunch of things that kinda use similar materials in them (metal, wood, etc), and I'll go back and change my different attempts at e.g. metal or whatnot to use the same palette. It's pretty easy to do, if all of your stuff is in a few graphics files - at least, it's easy with photoshop's selection tools. It could be really tough in simpler programs like MSPaint.

Using the same palette -strictly- isn't important unless you're using actual color-shifting tools to change the palette on the fly. We didn't do this for quite a while, but since 1.1 or so, we do this to translate our colors within environments. So when you go through seaside, the rocks under you change from brown, to being a mossy green, halfways through. Using the same palette in a general, non-strict sense does generally make your game cohere better, visually, and look much more polished. The most important thing it does is makes tiles and props and such all flow together without visible seams - if the colors were different, you'd see a difference when they overlapped.


So in general, I suggest that you NOT try to build a palette before you draw your game's art. I suggest you just wing it, every single time you make pixel art - you'll build up a really good improvisational skill at color-choices. I suggest you only gradually "coalesce" into having a unified palette as your game progresses, and only really settle on one once you get to the point where you've created the "backbone" of the art for the game, and where the rest is just details.
Play Frogatto & Friends - a finished, open-source adventure game!

User avatar
A-Red
Art Contributor
Posts: 495
Joined: May 6th, 2009, 1:21 am

Re: Pixel Art Tutorial Snippets

Post by A-Red » July 28th, 2012, 3:21 am

Can someone please explain to me how to determine luminosity? I have never yet found a way to make any program cough up this one silly value for me. Is there a good rule of thumb for finding luminosity in HSB?

User avatar
Jetrel
Art Director
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Re: Pixel Art Tutorial Snippets

Post by Jetrel » January 9th, 2013, 12:33 am

A-Red wrote:Can someone please explain to me how to determine luminosity? I have never yet found a way to make any program cough up this one silly value for me. Is there a good rule of thumb for finding luminosity in HSB?
I'm sure there's an official conversion; but I don't have time to find it right now. Tbh, the "B" value is HSB is probably decent to go off of. It's not the same but you can probably treat it as a substitute. The key thing which both HSB and LAB do, similarly, is split "how light the color is" into one number, and "what coloration it has" into the other two.
Play Frogatto & Friends - a finished, open-source adventure game!

User avatar
em3
Posts: 342
Joined: April 1st, 2009, 8:59 pm
Location: Poland

Re: Pixel Art Tutorial Snippets

Post by em3 » January 17th, 2013, 4:49 pm

ride on shooting star

Post Reply