Elysian Shadows

Hi Artists,

I'm curious about how pixel artists and programmers collaborate to put sprites in 2D tile games like ES. What is the workflow?

Like this?...

1. Sprite artists create sprites with their choice of tool, say photoshop with some plugin to help with animation (e.g. onionskinning).
2. The artist then manually composes the multiple images (which were probably stored in layers) into a "sprite sheet" which is a single image. The grid used is some kind of convention that is local to the project, or it is arbitrary. The positions in the grid of the sprites are layed out so that it is obvious which frames belong in which sequence and belong to which animation cycle (e.g. these ones for walking left are grouped in a linear sequence, those for jumping are grouped in another line).
3. The programmer takes the sprite sheets and works out the cycles of animation to use, a jump sequence, a walk left sequence, a run left sequence, a run left with gun drawn sequence etc. and then notes down the pixel offsets inside the sprite sheet for each of these. The programmer might have a tool to help do this which allows them to draw boxes around the sprites to get offset pairs (i.e. the position relative to the sheet of a particular frame's top left pixel.
4. The programmer then puts the offsets into some file (perhaps source code) and defines this animated sprite so that the engine can load it and sequence the animation.

Perhaps that's how it works, I don't know. I'm asking.

If this is how it works, how are the following things determined?

1. The registration point for the animation. The sprites that are walking move at a certain number of pixels per frame. The foot that comes down should not slide across the floor while the sprite is moving, so the steps must match this pixel speed. Is this agreed upon up-front, worked out by trial and error or is it specified by the artist and followed by the programmer?
2. How do character variations work - e.g. carrying a sword or wearing a hat? Are these all just new sprites that have to be handled as separate graphics or does the engine compose this stuff using some kind of sprite layer composition (like with maps). Or does it happen at map build time?
3. Are there any engines that do some of the sprite work? Like you could imagine using a flipped left sprite as a right sprite. This might not be optimal but it would be less work. Is this crazy?

Every artist might have a different way of working. For example, some artists like to just throw their stuff at the developer and let them sort it out, while some artists are happy to use bespoke animation setup software, that sort of thing. The one common thing with all artists is that they always appreciate guidelines. If you send your artist some stick drawings, laid out on a sprite sheet, then that gives them something to work from, and it helps them work efficiently. They do not appreciate working on artwork that is not used, that shit will make your artist quit the team. I've worked with a few artists over the years...

The previous artist I worked with is a French guy, and he really appreciated the layout software I made, so he could position and adjust the GUI to suit his graphics - it was a suduko game with different selectable themes. Artists like to have things just perfect, if they take the time to make something perfect, like 3 parts of a scroll bar that all fit together, then they have to be perfectly implimented. I put that responsibility in his hands, and he got some great work done. By providing easy to use tools, I could hand over the responsibility and control, he would be in charge of the whole look and that let me spend more time on code. That allowed for a really smooth development, because I could just slot those visuals in, we ended up doing 5 different themes and I am very happy with them all. Sometimes it's worth spending some time on your toolset, make it easy, document it, and you might be surprised at how positively artists react. The artistic style ended up quite oriental, like a really technical and intricate painting, or Japanese print.

The artist on my current project is Brazillian, and his stuff is a lot more organic, which suits my project perfectly. He's working on some character animations - I initially made some sprite sheets (even though the characters are huge) - and this served as a guide, which was mostly ignored. Then he sent me a SWF of the animations and individual images. But! - the actual work itself is amazing, a really nice animation that is like nothing I've put in any of my games before. Now I have to go through hell to impliment those, but it's worth it - just like it was worth making the gui theme editor. The visuals are still work in progress, but what I'm going for is a painted backdrop look, with cell style animation - like a classic Disney cartoon.

I bring these 2 up, because I think it was a little bit different from how you might work with a sprite artist. 2 totally different styles and ways of working, but both with good results and no delays. For sprites, well personally I would make an animation system with editor that allows the artist to test their work and save it in a format best suited to the engine. Might just be XY offsets, but it could also mean hotspots, animation time delays, collision boxes, adding items etc etc. It depends on the game, but it's always important to identify the best work method for artwork early on. There are so many factors, and if the artist doesn't have experience with game art then someone else has to define the workflow.
The ES team all have experience, and when considering tile sheets, character sheets etc, they most likely already know what they need, or how it should be handled - moreover, they can probably produce coder art, so the artist might have some decent reference material to start from. It's not like making tile sheets is pure art, there is a lot of planning needed as well. Transition tiles for instance, how do the tiles blend between each other, how many transition tiles are needed, how can they be organised and sensible. Experience is key, no matter where it comes from. As I said, if you've had to tear apart Megaman sprites for a game, or have made your own game sprites before, then the artist can rely on you to keep them right. The more thought the developer puts in, the less likely the artist is to waste time on un-usable artwork. Even if it boils down to making a custom sprite editor, it might be the best way to save time in the long run. This is especially true if you need to attach weapons and stuff - that can get really intricate, and would require some planning.
I guess the safest bet is to opt for the artist that has the most experience - someone might be really good at drawing map tiles, but are clueless about animation, or someone might be really good with sprites, but can't organise them. Any situation can be made to work, just so long as someone has the experience to pull it all together. Programmers are lucky, if we have to re-code, it's usually to improve it - if an artist has to redo something, then it's usually because the developer fkd up, didn't communicate enough, didn't give enough information, didn't consider other factors... And that's why artists drop out of projects IMO.

1) Yes, we don't care if they use Photoshop, GIMP, or even Paint, as long as it looks good...

2) Depends. Most projects, yes, but our Toolkit goes above and beyond most. It essentially gives the artist an empty "sheet" that he can dag and drop each frame into (then it generates the static image dynamically for the engine).

3)Most simple 2D engines have preset locations for each frame of a specific animation (separated by different lines as you said). But yes, what you said was correct in our case, except for one thing: the programmer doesn't do it. Our Toolkit (semi complete) does all of this through a GUI. The artist defines a new "sequence" and gives it a name ("WALK_UP", "WALK_DOWN", "ATTACK1", etc). Many of these sequences names are already utilized within the engine (an entity with a "character" component is assumed to have walking animations). The ARTIST strings together a series of "frames" to create this sequence. Each frame has its own delay, sprite offset (imagine for a bouncy character), collision offset, etc. Providing this level of control really prevents our artists from being restricted. They aren't required to tediously group any individual images in specific locations on the sheet and are able to create completely unsupported sequences like "LAUGH", "VICTORY", etc that can be invoked through the animation component's Play(const char *sequence) function in Lua.

In the future, you'll be able to playback the animation in the actual toolkit with a playback button and timeline to tweak before you use it in the engine.

4) The toolkit does this all behind the scenes. And since the Toolkit is utilizing the Engine's asset code, they're both using the same object(s) to serialize and deserialize entities/components which means that it's represented the same way in both the Toolkit and Engine.

Now for the questions:

1) I'm not so sure that I can visualize this. We definitely do a lot of visual tweaking, but the feet aren't even technically moving in the animation (if the sprite itself isn't moving, it looks like they're running in place). You kind of have some wiggle room for speed before it looks strange. As long as your actual frame-by-frame deltas are scaled down (so that the animation itself goes faster) when the characters move faster, it looks great. The engine handles this scaling.

2) It really all depends. Most engines use multiple graphics, which is why this is such a pain in the asshole for artists. You see FAR less 2D games where every weapon or piece of equippable armor is visible. You see more WEAPONs than armor changes in 2D RPGs, because weapons can be drawn as separate sprites, so that is far easier to do.

3) That's not crazy AT ALL if your engine is hardware accelerated. Ours does that for the terrain (and will do that for animation of symmetric sprites as well). We have simple flags for our rendering functions that allow you to specify vertical flip, horizontal flip, and 90 degree rotations. (by screwing with texture UV coords or rotating the polygon). If your engine is 3D accelerated, your GPU is doing all of this shit in hardware, so it's essentially free.

Doing this kind of stuff in a software rendered environment (SDL, Allegro) is painfully slow as shit and isn't recommended, though.

You guys use photoshop and gimp? What is wrong with just paint?

bnpph wrote:You guys use photoshop and gimp? What is wrong with just paint?

That's not what Falco said. He said we don't care what program they use, as long as quality art comes of it.

dandymcgee wrote:

bnpph wrote:You guys use photoshop and gimp? What is wrong with just paint?

That's not what Falco said. He said we don't care what program they use, as long as quality art comes of it.

That's not what I said, but we do use both over paint... for every reason ever...

GyroVorbis,

Sounds like this toolkit is another essential element to the process. Level Editor, "Toolkit", Engine. Then there's the tools that the artist use. Are there any other significant components for ES?

christo wrote:GyroVorbis,

Sounds like this toolkit is another essential element to the process. Level Editor, "Toolkit", Engine. Then there's the tools that the artist use. Are there any other significant components for ES?

I will point out that level editor and toolkit are two members of the same creature. The toolkit is the all encompassing content creation tool for the team. A few of its functions are editing levels and entities.

Yeah, the Level Editor evolved into the Toolkit.

LibGyro is the third huge component. The engine completely sits ontop of it and couldn't do a single thing without it. Even the Toolkit includes a bit of code from it.

My artist and I are using a tool called Sprite Buddy. Essentially this tool allows the artist to import a spritesheet and map out the different animations. He specifies the frames, X/Y offset, and duration, then everything gets exported to an XML file. The engine then imports the spritesheet and parses the XML, looking for specific animation names. (idle, run, shoot, etc..)

It gives the artist 100% control over the sprites and animation and saves me a from doing a shitload of tideous rework.

Sprite Buddy download:
http://www.colourclash.com/sprite_buddy ... buddy.html

trufun202 wrote:My artist and I are using a tool called Sprite Buddy. Essentially this tool allows the artist to import a spritesheet and map out the different animations. He specifies the frames, X/Y offset, and duration, then everything gets exported to an XML file. The engine then imports the spritesheet and parses the XML, looking for specific animation names. (idle, run, shoot, etc..)

It gives the artist 100% control over the sprites and animation and saves me a from doing a shitload of tideous rework.

Sprite Buddy download:
http://www.colourclash.com/sprite_buddy ... buddy.html

Goddamnit. Now we have to outdo sprite buddy...