Sprites and tiles and UI bits, oh my!

[eliddell]

Here beginneth my posting of the laughable assets for my game project, in the hope of improving them a bit.

This is my goblin.  You can call him A, because his placeholder name in the unfinished game UI is "A. Goblin".  A is the protagonist of my roguelike game project, currently known as "Goblin Mage".  He's presented here against a background colour that matches the main colour of the most-common in-game floor tile (we'll get to the tiles later). I suspect his arms in the side views are too long, but I'm not sure by how much or whether there's a better way to position them (or is the perspective just playing tricks on me?). I'm also not sure about the shading around his ear in the bottommost, right-facing view.  Hopefully it's at least clear that the light source is above-left. I suck at drawing humanoids.   And I really need to do my best to fix this guy, because the player is going to be staring at him all the time.

A has a walk cycle.  The walk cycle is terrible.  This is partly on purpose (the idea is to use the smallest possible number of frames, because I have to do four-directional movement animations for ~30 different creatures, which will go much quicker if I use step-pause-step-pause 1-2-1-3 walk cycles out of the 8-bit era), but in this case, I know there should be some torso rotation on the two "step" frames but can't convey it without making things look worse, in addition to the problems from the static frames.


I've included the full game palette in the walk-frames pic.  The idea is to keep it under 64 colours.  Currently I believe it's at 51.  The game is grid-based, with a nominal grid-square size of 32px, but sprites can slop over a couple of additional pixels to the right and an indefinite distance upwards without causing significant breakage.  (The intention is to have some 64x64 boss monsters, but I haven't gotten to that part of the engine code yet.)

[SeinRuhe]

Placeholder for my response and possible edit from my part on Monday since I'm outside my place and I absolutely love doing characters

Here I am and what's promised is debt!

From what I see one of your main concerns is the sheer amount of work involved on animating 30~ sprites, I gotchu there brother, just place the lightsource directly above characters, this will allow you to flip one frame of the walking frame, reducing the amount needed from 3 to 2, what's even better in this case is that you can flip the two frames you need for a walking animation with this technique, making the walk cycle 4 frames instead of 3, which may be perceived as a more fluid animation with the same amount of work! (The idea here is to draw the passing and the contact frames of the walk cycles)

But what happens to the extra missing frame? Should all be savings in efforts? Well, no. A good idea is repurpose that frame to give a standing position to your goblin, you can convey a lot of personality in a single frame so the idea is to use it as best as possible to communicate who your character is.

I did a redraw to the character trying to give it a little more personality and also making it resemble more the idea I have of a goblin in mind, and of course, with the lightsource directly above for the reasons I previously mentioned. (The idea I had in mind is a goblin trying to escape from a dungeon, playing as the bad guy to justify attacking his monster friends, kinda dumb, I know)

Other small detail that really adds up is to avoid the outline where the character feet meet the floor, this makes it feel grounded, also add a shadow.

Hope this helps a bit!

There's a lot more to address but I think is better if we help you with this one step at a time.

[eliddell]

(Text now, art probably this evening/tomorrow.)

I should perhaps give a little more background, because this is a comparatively mild-mannered goblin.

He's from a village at the bottom of a cave, where his ancestors have lived for generations.  Problem is, there's now lava encroaching into their living quarters, so they have to Get Out Of There ASAP.

None of the goblins have gone more than a couple of levels upward from their village in generations.  The village has collectively decided that the most useless person who still has a chance of clearing out the monsters on the floors above is the apprentice of the shaman/village elder.  So he's been sent out to fight not entirely willingly, and will probably spend half his time on the first couple of floors wondering how he got into this and why he was dumb enough to help finish off the supplies of mushroom moonshine they can't carry with them last night.  So grumpy and hung over, but not really vicious.  I should have given more thought to the facial detail and posture, though—currently, my version has a lot less personality than yours.

I take your point about the feet.  I've been holding off on cast shadows until I decide whether to go with a translucent version of the near-black brown already in the palette, or something else.  (They are going to have to be translucent shadows, because of the possibility the sprite could be standing on top of an item on the floor, which needs to be reasonably visible if he is.)

Altering the direction of the light is going to require changes to thirty-odd existing tiles . . . but I'm looking at on the order of 300 sprite frames (4-dir movement + 4-dir attack + a death animation per sprite, plus casting or throwing animations for some, plus single static sprite frames of 20 other goblin villagers).  So yeah, changing the lighting direction will probably be an improvement in the long run.

(Want to know what the really scary part is?  Thirty monster types is a really small inventory for this type of game.  Big roguelikes may have hundreds of monster types.  For some reason, they don't animate their tiles, if they even bother having any.)

[SeinRuhe]

The story background of the character seems quite good to me, try to convey absolutely the most of that story on the sprite, way he stands, way he walks, even on the attacks! A good yet goofy exercise I do when making characters is acting them in front of my window at night so I can see the reflection (I really need a mirror or a camera xD), believe me, the difference on the results is quite big.

Don't hold on on the shadows, or anything really, it's better to do some stuff twice or trice and be happy with the results than doing it only once and have a suboptimal feeling about it. Shadow specific, code them on a layer below the character and items, transparent or not that's only a matter of changing the layer properties or having to recolor the sprite with some alpha.

If you want to let me see the tiles I'll give them a look, maybe the lighting on them can be fixed without much hussle?

Lastly, I've played some dungeon crawlers, the sheer amount of content of some of them is plain scaring from the dev point of view, what most (If not all) devs do is to have small milestones, this keeps the moral up. For what I see you should even start with a lower count of monsters, have a minimum viable product and after that continue adding up more and more! I'm willing to bet there's still a lot you are trying to figure out for this game, so is better to redo a tiny amount of units and tiles than having to redo everything because you figured out better ways.

Looking forward to see how this plays out!

[cels]

I'm not good at sprites or tiles but I will offer some opinions as an amateur:

What I like about SeinRuhe's edit is that the legs and feet look three-dimensional and placed within a 3D world. I love the use of markers on the ground to establish the position of the feet relative to the ground. I also love how this edit accentuates muscles and bones in order to show actual structure as opposed to having Simpson-esque blob limbs. Even the structure of his cranium and his pronounced brows.

What I like about the original is that it's seen from above. The industry standard seems to be to have a weird perspective that is a mix of front view and top view, or simply just show the front view of a character even though it is seen from above. Like early Zelda games, where we see a sideview of a character in a top-down world. In SeinRuhe's edit, i feel like the torso, arms and head are seen from the front (we can even see under his nose and the shadow of his crotch), whereas in the original we're seeing the character slightly from above. Hence, we see the top of his feet, the top of his shoulders and the top of his head. I prefer the original in this regard.

On the other hand, the side views do not appear to be seen from above. Rather, they seem very strictly sideways. When seen from above, it makes sense that the arms appear longer than the legs (foreshortening) but when seen from the side, it makes him look like an orangutan.

I won't attempt an edit. Not yet anyway, until I have a better feeling of what perspective you're going for and whether you're totally bending the laws of physics like Zelda.

[fskn]

Great tips from SeinRuhe (plenty of them!) and cels.
I do agree with the side animations not looking like they're being seen from above.

It looks like the main problem with the sprite in general is structure. And it's hard to give solid advice without knowing the actual perspective you're using. Buuut... I'd say you could try and make a sort of basic, super simple 3D-ish character model using balls (for the head and hands, don't be silly...) and boxes. Solids, if you will. Then adding the features needed. Thus you would have a more convincing interaction between the characters and the environment they're in.

Something like...


(hopefully that'll get the idea across.)

EDIT: Whoops, silly me, forgot to add depth to the side view of the torso:

[eliddell]

I think cels has nailed just what was wrong with the side frames—they're too side-on.  That's what I get for using other people's sprite work as reference without checking that they got it right. 

Fresh attempt at the front frame, redone mostly from scratch:



Not quite sure about the legs, shorts, ears, or perspective, but we've gone from robotic-expressionless to, "Hey, I'm having a bad day, and if you get in my way, you're going to have a worse one."  That's probably an improvement.  He's also acquired a shadow, and some muscle definition.  Looking back at the original sprite, I'm not quite sure what I was thinking in some regards.

About the tiles—I was mostly just kvetching, truth be told.  The only terrain tiles that would be affected are what would have been shadowed wall corners under the old lighting scheme.  The item tiles that will need to be reworked are mostly 1. mushrooms or 2. armour, and some of the armour tiles are pretty terrible anyway.

The perspective is intended to sort of match the cabinet perspective typical of SNES-era Squaresoft games like Final Fantasy VI, but the sprites in those are so small it's difficult to figure out whether they're perfectly side-on or matching the terrain.  I'm not doing the weird Zelda perspective where you can see all four walls at once or anything like that.

I do have this broken down into chunks/small milestones, although I sometimes get a bit ahead of myself.  Next set of art assets required:  the goblin and his move, attack, and die animations, and one monster (giant rat) and its move, attack, and die animations.  Next coding milestone:  hook up certain bits of the UI so that they're displaying real information and not placeholders, and debug the minimap that's supposed to be appearing on the bottom right.  At that point, I can either work on basic combat or sidestep into dungeon feature placement for a bit.

Existing terrain tiles (I'm not thrilled with the floor tiles, but they don't look quite as bad in context as they do here): 


Existing item tiles (the mushrooms will not be grey in-game): 


Terrain tiles in context (procedurally generated level with old goblin sprite and unfinished UI bits): 

[SeinRuhe]

Great work! Now that's a Goblin! I'll get on some specifics regarding execution this time, bear with me because it may get a little dense.

I think you are over rendering the character and this prompts some issues I'll try my best to explain them and how to fix them:

- There's a lot of banding on the character, this is when there are two sets (or more) of pixels that goes along the other like a staircase, since I suck explaining I'm also adding a visual explanation.

- There's also room for improvement on the light department, I'll explain this with the head only, basically, when an object is lit from above, the planes that face more towards the light will be the ones that receive most light, so they will have the brightest shade, so the top of the forehead should be brighter than the middle of the forehead, but more than that, the shading on the top of the head should touch the outline.

- I see that you are trying to describe the arms as round with the shading, for this is better to have the darkest shade in the middle of the form (Where the terminator is located) due reflective light, this does not need to be super accurate and reflect the correct hue, just a change of value is more than enough. Also keep in mind that limbs resemble a bit more a box than a cylinder, actually a mix of both  .

Tiles, sketch or not, look kinda good, my only advice would be to rely more on clusters of pixels to generate texture instead of noise/orphans.

Items suffer from something weird caused by how they are shaded, if you shade with the lightest shade on top, the mid shade on the middle and the darkest shade on the bottom stuff starts to look like a block (think of Mario question block from the NES) try to apply the thing I said earlier of the terminator, you may see an improvement, if not just apply what I said about the planes, and if not let me know to do some extra research  .

Lastly, I'm almost certain the screenshot you posted last has some kind of compression because it looks really antialiased.

If something I said makes no sense let me know and I'll try my best to explain it better.

[cels]

SeinRuhe beat me to the punch and did a better job but I will post this as a show of solidarity.



- Totally agree about too much banding.
- I also notice that your color ramps are a bit linear (all basically the same hue, rather than going from colder to warmer). Not a huge issue but may be worth thinking about.
- In regards to lighting, banding and clusters, I think it's potentially problematic that your sprite currently has so much detail packed into it and so few large clusters. It's going to be more labor-intensive if you're going to highlight every ab muscle and use five different shades on his arms. If you look at some of Wolfenoctis' sprites (here), he's very clever at conveying detail without using too many colors and too detailed shading. He also uses very large clusters sometimes, which is probably great for animation. So it's not that one is better than the other, but if you're doing a lot of animated sprites, it might be worth thinking about. Even if you keep the most important sprite (the goblin) more detailed.
- In regards to items, totally agree about clusters vs orphans / noise

[eliddell]

Okay, iteration the next: 


Reduced the banding, reshaded several areas.  I think that unless you guys can spot something grossly wrong, I'm going to leave it at that, and move on to the back and side views.

I'm aware that I tend to introduce way too much banding and grain into my work (and then have trouble spotting it myself).  Not doing much in the way of art for a couple of years probably made it worse.

Minor details:  the gradients are hue shifted, just not by very much—if you look at HSV samples, the lightest green has a hue of around 80, and the darkest is around 100.  Too conservative, probably.

The image host seems to have recompressed the big screenshot at the end of my earlier post  .  Good to know before I post about this project elsewhere, I suppose—I'll need to use smaller screenshots, find a higher-bandwidth image host, or dig out my login info for the webspace I've had for the past ten years but never used.  (Some of it would have shown anti-aliasing anyway, since the most of the UI is built out of primitives drawn by the game framework, but nothing like that.)