It could be interesting to minimize the differences between males and females, but that could break compatibility.
big Makefile (or similar)
I would advise against make, I can't say anything about other build systems, since I'm not familiar with them.
The best thing about make is that it only builds what changed.
I started with a makefile in modular bodies.
There were two things, I perceived as big downsides:
You have to know what you can build, there is no way for listing all options, as it chooses the rules based on the path you give it
It only allows the placeholder % once, which means if you allow costum item names, you have to manually add a rule for each animation, each recolor and actually each possible combination of both
That's why I started to switch to simple build script for my portaits remix.
I used --usage to tell people the naming scheme it expects.
--list semi-dynamically lists all posibillities by directly getting file names from folders.
I reused parts of --list for a --random paramater, that just randomly picks a possible combination. I used that for generating previews, but that is more relevant when you can select a lot of variations.
- coerce: takes an RGBA image and a palette (in .gpl, JSON, or PNG format), and produces an indexed PNG image which only uses colors from the palette (optionally, could force "nearby" but non-matching colors to use those from the palette)
I did not start to implement such a thing, but I thought about it a bit. I think you'd want it to warn you if there are colors in the image, which are not part in the palette. Ideally it should also be possible to produce an image with all colors, who are off.
There is one big downside of indexed PNGs: it does not allow semi-transparency. So shadows have to be either be in a different image or you need a script that can convert those to RGBA PNGs again and make all #322125 60% opaque.
The shadows shouldn't be of interest for the spritesheets, since I don't think it's used there. But it is significant if you try to use it with tilesets.
- recolor: takes an indexed image and applies a palette (or set of palettes)
My tool does currently not support multiple palettes, but it should work if multiple palettes get concatenated with cat beforehands. It also currently discards information about what index is transparent.
- collapse_recolors: takes a set of images (that are recolors of one another) and produces a list of palettes, such that each recolor can be generated from the base image with `recolor`
Extracting the color index from an image and dumping it into .gpl shouldn't be much work. Doing this with RGBA images or images with differently ordered indices would be a lot harder to (near) impossible. Especially images who effectively use multiple palettes and share colors between those will be a problem, since you don't know what color you should map it to.
The base assets are actually an example for that, since they have skin and eye colors. I did not split them in my submissions yet.
- collapse: opposite of `distribute`: takes a full animation and collapses it into a minimal number of images, as well as a map of offsets.
Yep, it might be handy to detect duplicates, mirrors and shifted versions of them. Not a hard problem, since you will mostly just trim transparent pixels and maintain a dictionary, but neither that trivial.
- offset: offsets each frame in an animation by specified amount(s) (for fixing bugs)
As far as I know, no assets have been released for TheraHedwig's run or jump yet
Only the original ones + wulax's have a bigger pool of assets
I HEAVILY advise you to preview animations
Yes, that's in general a good idea, I guess. I haven't really looked at all available one yet.
Or even clear what it was supposed to be. In the end, I've found it would have been better looking and easier to draw things from scratch.
Most people don't seem to realize that the 'walk' rows are actually a standing frame and then an eight-frame walk, and what you get is a nine-frame animation where the legs stutter and splay out every cycle.
That's true, but all original animations start with a standing frame. Walking isn't the only one. Thrusting, bow shooting and jumping start with a modified version of it.
Are there any substantive differences other than the breast sheet between "male" and "female" bases?
The jaw lines of heads are difinitely different, so are the brow line related shadows. Ear angle is different.
Male sholders are broader, which results in completely different arm angles.
Male legs are farther apart, which again results in completely different angles.
Female torse has a more accentuated waist than the male one, which is combined with thicker looking thighs. To make the thighs thicker, the lower parts of the legs are thinner. Males appear to be positioned one pixel higher, probably to make them look taller.
The only thing, which is the same, is the upper half of the head.
This is a fine idea. Ideally we can make tools to do this
General image manipulation tools like Image Magick can easily do that already. But you can also do it with mappings, for splitting you just have two maps and one source image, but that's a bit misappropriation.
off-site version control system
It's a bit tricky to decide on what to use, since git won't work well and svn being very centralized, which can be very impractical if the repo gets deserted and dies. Images are binary data, which works badly with diff-based tools like git. But when git or such is used, it would be a lot more handy for version control to have an image per frame. It's easier to sew which frames were changed in commits, it's easier to merge commits and image diffs are harder to see in bigger images. This is a lot harder to work with drawing-wise, though.
a head / hair accessory placement script would be an absolute godsend
My scripts should be able to that, they come with head position mappings for the original and wulax's animations. It would just have to have the same layout as my heads, which covers all 15 unique heads. The four directions + special angles for "hurt" + closing eyes from casting. I positioned male and female heads so, that the upper half of the head is at exactly the same position, so hats should work for both. But it does not include anything to handle hands/arms which overlap the head.
a standard single-file assembly order as well
I think so, too. The order matters, we should place the most important animations at first. If somebody starts to draw and loses mativation/interest, only the first animations will be covered. The die/hurt animation is usually packed at the end, because it only colors one direction, but I would put that at top to increase compatibility.
I would give higher priority to animations which are needed for NPCs like idle, walking, running and maybe jumping. And lower proriety to those who are era/theme dependant like bow shooting, gun shooting and spell casting. Slash and thrust should work in any era ... clubs, swords, spears, iron pipes, laser swords and practically any longer blunt object.
Ideally the icons (the flag as well) should have a similar style to the gargoyles. It's not important that UI and the game world match in style, but all UI elements should be in a similar style, I think.
I know what you mean about the moon, I'm aiming for a big dramatic one, like it's almost a character you know?
Then remove the clouds behind it. You do not have to put clouds in front of it, but clouds behind it is what is looking weird.
I would also remove the sun. The sun's position and the moons shading do not match up.
The first 6 rows (Die, Jump, Run) are about tilted heads. Jumping and running use tilts which are already included in "hurt", the each second row is the streamlined one.
I added the new eyes to "hurt" but kept it's shape because of compatiblity. They look more alive this way, so that should be useful for kneeling and other animations who reuse frames from this. The eyes who lose their shine are interesting for dying, though. Both versions should be usable alongside, since they only differ in the eye pixels, that should affect no current assets.
The next two rows (Run) are about how running works. It's not in sync with walking, which I dislike aside from the new head tilts. Just doing a more extreme motion like it's done it jumping should work, I don't think we need to tilt the torso that much. I don't even think you'd tilt that much while running, but it is certainly tilted a bit.
For Thrust and Bow I composed a new second frame, which is nearly a copy of a frame from spellcast, just the hand in the background and the eyes are different. This would certainly be incompatible with all old assets, but for clothings you just need to merge it with the frame from spellcast and the weapons would need a bit different cutout. But this would save us one unique arm angle for clothings.
Last is my first try of rebuilding the gun animation with arms from walking and two frames from bow shooting, yet again to get to less different arm poses, that have to be drawn. Well, the original back arm doesn't look good at all.
But I haven't tested any of those with weapons, yet.
Edit: My changes for thrust and bow shooting seem to work with weapons, I just had to duplicate a few pixels. But the gun shooting pose needs more work.
Edit2: I played around with the guns and attached the second draft. I'm not content, though. The stretched out arm and/or the guns have to definitely change more.
This is my first proposal for fixing thrust and bow shooting.
Everything with an E in the top right corner was edited compared to wulax's version.
Second row of thrust and bow shooting just have the light reflections fixed.
The edit in the first row of bow shooting just changes one pixel to make two tiles full duplicates.
For the first row of thrust I changed more, the second and third frame are now full duplicates of the ones from bow shooting, even though moved by one pixel. For that I had to also change the feet of all following frames, but I think that looks better than before and matches the downward direction. And there are not many changes needed for currently existing assets, foot wear can just copy the already drawn foot from the third frame, it's the same shape. The changes in the third frame will impact weapons, since the arm moved down by one pixel.
I always worry that I'm going to run into some limitation on texture size
I'm currently at 2368px hight and since modern systems should be fine handling HD textures, I don't think we'll hit limitations there. But I never worked with textures or games on modern hardware.
May platform of choice is only capable of fitting 32 64x64 tiles into sprite VRAM without further packing and deduplication. You wouldn't use LPC there, since it's in general way too big. But 32 tiles is already the full thrust animation
I guess in the end you have to see what your target engine/platform can handle.
If you really have to crunch down on size, just write a tool for packing it. On gameboy games don't store duplicate 8x8 tiles and for sprites they even remove mirrored duplicates (original gameboy can only mirror sprites, but not background tiles). That also reduces the overall size of a game, which is pretty irrelevant these days.
I attached a manually packed spritesheet. But you can certainly do that easier automated, just split your original image into a packed image and a 2D array representing the original image (aka LookUp Table), where each value is an index of the packed image (counted left to right, top to bottom). You can throw out full duplicates and empty tiles like I did in the manually packed one, you just use the same index at multiple positions within the array. And you just tell your packer to make width and height as close to each other as possible.
The lawnmower animation also has diagonal heads, but only top-left and top-right are new heads. And the heads have in general different lighting. https://opengameart.org/content/lpc-caeles-art
Okay, I don't think the layering doesn't make that much sense in general, I don't see a general way of doing it, body parts behave differently in different animations.
I definitely want to split all as many heads as possible, so that I can easily use them with different heads.
For some animations we would benefit from splitting things. Splitting arms and torso/legs in walkcycle would make sense, sine that's reused quite a bit. The current gun shooting animation and Evert's push only change the arms. So for the creation of new assets it's helpful to have a base that only has to be modified a little here and there. And animations like bow shooting, where torso and legs are often unchanged. And maybe body parts which are reused a lot.
I attached a spritesheet with all animations, I currently downloaded...
Are those all animations which are currently released?
I automatically fixed the color accidents of wulax's animations.
For Skoprio's and the original animations I changed the transparent pixels only.
Fixed a few black pixels in grab.
Where are the animation fixes located? And what exactly did they fix.
I want to do update all to their newest versions and then make first sure colors are right everywhere and remove differences between frames and body parts who should be the same.
I added an overlay with notes for myself what are [D]uplicated and [M]irrored tiles (ignoring head reflection). [R]eused is for tiles which only differ in a few pixels, I just used it once and have no clear definition for it yet.
On a related topic, I'd like to see the tools have more support for exporting separate animations, instead of having everything in a single image.
I always create separate images per animation, all my mapping rules are targeting that.
The big image I posted a few posts above is for getting an good overview and make it easier for me to find.
Aside from that I only concatenate images when I upload them to reduce the amount of images, they are always combined with "magick montage -mode concatenate -tile 1x -background none " or something similar.
My character generator also uses a canvas per animation in contrast to sanderfrenken's. In my eyes those character generators are only previews and combining and palette swapping should be done by the engine, there is no reason to have more than one color of everything. Modular bodies does create one big sheet in the last step, but sheets per animation in the second last one.
That's also why I wouldn't attribute any submission, which just replaces the palette with another already existing one or who concatenate or reorder other submissions. That edit does not get past the threshold of originality needed by copyright law, I can easily recreate that in a minute or so.
Color palettes themself are also not copyrightable, but I credit them out of respect (not the considerate one, but the one with high esteem).
but it discourages adding new animations because modifying the sheet breaks compatibility with existing assets.
There are some defacto standards of arranging the animations. I put the die/hurt animation first, since it's usually added as last, which is bad compatibility wise.
Okay, I added the running animation und updated the post above. (I will keep it updated, I don't see a reason to post it multiple times)
Also, the left-facing bow and thrust animations have the wrong head.
I only converted all animations to the attached palette and fixed issues arising from doing that. I kept the heads as wrong as wulax created them. I will create a new sheet for the edited versions, with markings on [E]dited frames.
Are you saying the layering is a bad idea?
At least the layering, how I did it, wasn't a good idea.
I made those layers foremost for reassembling the bodies correctly, that alone makes it more complicated. I tried to reuse parts for several frames, which also required to draw some pixels which aren't visible. I had a layer for front/back arms/legs, but the left/right arm/leg was always completely on one layer. It does not work that way.
What might work is: (I see sholders as part of the arm)
arm parts below torso
torso with legs
arm parts below head
head
arm parts above head
This does not allow to use left and right hand separately, well neither was it really possible before. But that could also be interesting. Like a walking animation where one arm has less motion because it's carrying a spear/bow. It could make it easier to draw weapons, but it's only worth it if there is not many clothing pixels that have to be redrawn, or even better if none have to.
that will make attribution/record-keeping much easier.
I agree in pvigier's case, but at least for the characters bases we should aim for one submission with multiple authors/maintainers. We can still specify per animation attribution in a markdown or text file and from this threads history we should know who did what. I'd expect that to make it a lot easier for those want to create new clothings.
Command-line "build" tools, which take a partial spritesheet and construct a full spritesheet (possibly with multiple layers) with all animations, duplicated/mirrored images, etc.
But I agree with BenCreating there, those who upload submissions have to use them, that includes being able/feeling comfortable to do so.
Basto's code for the heads
I used it only for heads, but it was never limited to them.
So it might be helpful if it could also generate GIF previews.
If this is relating the the build/shell tools, that can easily be done with short makefile:
It might be helpful if there was a command-line version of these as well, which could be incorporated into a build process.
Well, for that you can backport my cli-version of the character creator, which runs with nodejs.
Regarding the animations: I used a looking up head in my lying down sketch, but in general I don't think they are a good idea. People who can't really draw won't be able to port old assets to new animations, if they use new perspectives resulting from tilting/rotating. The sideways heads are already a pain, the original "hurt" animation as well. I would actually prefere to have a running animation based on the jumping (third and fourth frame) animation, which does not tilt heads. That's why I tend to forget that there is already a running animation.
And please write me basxto in ASCII. If I'd rename myself, links to my account would break.
It could be interesting to minimize the differences between males and females, but that could break compatibility.
I would advise against make, I can't say anything about other build systems, since I'm not familiar with them.
The best thing about make is that it only builds what changed.
I started with a makefile in modular bodies.
There were two things, I perceived as big downsides:
That's why I started to switch to simple build script for my portaits remix.
I used --usage to tell people the naming scheme it expects.
--list semi-dynamically lists all posibillities by directly getting file names from folders.
I reused parts of --list for a --random paramater, that just randomly picks a possible combination. I used that for generating previews, but that is more relevant when you can select a lot of variations.
I did not start to implement such a thing, but I thought about it a bit. I think you'd want it to warn you if there are colors in the image, which are not part in the palette. Ideally it should also be possible to produce an image with all colors, who are off.
There is one big downside of indexed PNGs: it does not allow semi-transparency. So shadows have to be either be in a different image or you need a script that can convert those to RGBA PNGs again and make all #322125 60% opaque.
The shadows shouldn't be of interest for the spritesheets, since I don't think it's used there. But it is significant if you try to use it with tilesets.
My tool does currently not support multiple palettes, but it should work if multiple palettes get concatenated with cat beforehands. It also currently discards information about what index is transparent.
Extracting the color index from an image and dumping it into .gpl shouldn't be much work. Doing this with RGBA images or images with differently ordered indices would be a lot harder to (near) impossible. Especially images who effectively use multiple palettes and share colors between those will be a problem, since you don't know what color you should map it to.
The base assets are actually an example for that, since they have skin and eye colors. I did not split them in my submissions yet.
Yep, it might be handy to detect duplicates, mirrors and shifted versions of them. Not a hard problem, since you will mostly just trim transparent pixels and maintain a dictionary, but neither that trivial.
You could just autogenerate a mapping for that.
Only the original ones + wulax's have a bigger pool of assets
Yes, that's in general a good idea, I guess. I haven't really looked at all available one yet.
That's true, but all original animations start with a standing frame. Walking isn't the only one. Thrusting, bow shooting and jumping start with a modified version of it.
The jaw lines of heads are difinitely different, so are the brow line related shadows. Ear angle is different.
Male sholders are broader, which results in completely different arm angles.
Male legs are farther apart, which again results in completely different angles.
Female torse has a more accentuated waist than the male one, which is combined with thicker looking thighs. To make the thighs thicker, the lower parts of the legs are thinner. Males appear to be positioned one pixel higher, probably to make them look taller.
The only thing, which is the same, is the upper half of the head.
General image manipulation tools like Image Magick can easily do that already. But you can also do it with mappings, for splitting you just have two maps and one source image, but that's a bit misappropriation.
It's a bit tricky to decide on what to use, since git won't work well and svn being very centralized, which can be very impractical if the repo gets deserted and dies. Images are binary data, which works badly with diff-based tools like git. But when git or such is used, it would be a lot more handy for version control to have an image per frame. It's easier to sew which frames were changed in commits, it's easier to merge commits and image diffs are harder to see in bigger images. This is a lot harder to work with drawing-wise, though.
My scripts should be able to that, they come with head position mappings for the original and wulax's animations. It would just have to have the same layout as my heads, which covers all 15 unique heads. The four directions + special angles for "hurt" + closing eyes from casting. I positioned male and female heads so, that the upper half of the head is at exactly the same position, so hats should work for both. But it does not include anything to handle hands/arms which overlap the head.
I think so, too. The order matters, we should place the most important animations at first. If somebody starts to draw and loses mativation/interest, only the first animations will be covered. The die/hurt animation is usually packed at the end, because it only colors one direction, but I would put that at top to increase compatibility.
I would give higher priority to animations which are needed for NPCs like idle, walking, running and maybe jumping. And lower proriety to those who are era/theme dependant like bow shooting, gun shooting and spell casting. Slash and thrust should work in any era ... clubs, swords, spears, iron pipes, laser swords and practically any longer blunt object.
Ideally the icons (the flag as well) should have a similar style to the gargoyles. It's not important that UI and the game world match in style, but all UI elements should be in a similar style, I think.
Then remove the clouds behind it. You do not have to put clouds in front of it, but clouds behind it is what is looking weird.
I would also remove the sun. The sun's position and the moons shading do not match up.
A little bit sketching around.
The first 6 rows (Die, Jump, Run) are about tilted heads. Jumping and running use tilts which are already included in "hurt", the each second row is the streamlined one.
I added the new eyes to "hurt" but kept it's shape because of compatiblity. They look more alive this way, so that should be useful for kneeling and other animations who reuse frames from this. The eyes who lose their shine are interesting for dying, though. Both versions should be usable alongside, since they only differ in the eye pixels, that should affect no current assets.
The next two rows (Run) are about how running works. It's not in sync with walking, which I dislike aside from the new head tilts. Just doing a more extreme motion like it's done it jumping should work, I don't think we need to tilt the torso that much. I don't even think you'd tilt that much while running, but it is certainly tilted a bit.
For Thrust and Bow I composed a new second frame, which is nearly a copy of a frame from spellcast, just the hand in the background and the eyes are different. This would certainly be incompatible with all old assets, but for clothings you just need to merge it with the frame from spellcast and the weapons would need a bit different cutout. But this would save us one unique arm angle for clothings.
Last is my first try of rebuilding the gun animation with arms from walking and two frames from bow shooting, yet again to get to less different arm poses, that have to be drawn. Well, the original back arm doesn't look good at all.
But I haven't tested any of those with weapons, yet.
Edit: My changes for thrust and bow shooting seem to work with weapons, I just had to duplicate a few pixels. But the gun shooting pose needs more work.
Edit2: I played around with the guns and attached the second draft. I'm not content, though. The stretched out arm and/or the guns have to definitely change more.
This is my first proposal for fixing thrust and bow shooting.
Everything with an E in the top right corner was edited compared to wulax's version.
Second row of thrust and bow shooting just have the light reflections fixed.
The edit in the first row of bow shooting just changes one pixel to make two tiles full duplicates.
For the first row of thrust I changed more, the second and third frame are now full duplicates of the ones from bow shooting, even though moved by one pixel. For that I had to also change the feet of all following frames, but I think that looks better than before and matches the downward direction. And there are not many changes needed for currently existing assets, foot wear can just copy the already drawn foot from the third frame, it's the same shape. The changes in the third frame will impact weapons, since the arm moved down by one pixel.
I'm currently at 2368px hight and since modern systems should be fine handling HD textures, I don't think we'll hit limitations there. But I never worked with textures or games on modern hardware.
May platform of choice is only capable of fitting 32 64x64 tiles into sprite VRAM without further packing and deduplication. You wouldn't use LPC there, since it's in general way too big. But 32 tiles is already the full thrust animation
I guess in the end you have to see what your target engine/platform can handle.
If you really have to crunch down on size, just write a tool for packing it. On gameboy games don't store duplicate 8x8 tiles and for sprites they even remove mirrored duplicates (original gameboy can only mirror sprites, but not background tiles). That also reduces the overall size of a game, which is pretty irrelevant these days.
I attached a manually packed spritesheet. But you can certainly do that easier automated, just split your original image into a packed image and a 2D array representing the original image (aka LookUp Table), where each value is an index of the packed image (counted left to right, top to bottom). You can throw out full duplicates and empty tiles like I did in the manually packed one, you just use the same index at multiple positions within the array. And you just tell your packer to make width and height as close to each other as possible.
The lawnmower animation also has diagonal heads, but only top-left and top-right are new heads. And the heads have in general different lighting. https://opengameart.org/content/lpc-caeles-art
Okay, I don't think the layering doesn't make that much sense in general, I don't see a general way of doing it, body parts behave differently in different animations.
I definitely want to split all as many heads as possible, so that I can easily use them with different heads.
For some animations we would benefit from splitting things. Splitting arms and torso/legs in walkcycle would make sense, sine that's reused quite a bit. The current gun shooting animation and Evert's push only change the arms. So for the creation of new assets it's helpful to have a base that only has to be modified a little here and there. And animations like bow shooting, where torso and legs are often unchanged. And maybe body parts which are reused a lot.
I attached a spritesheet with all animations, I currently downloaded...
Are those all animations which are currently released?
I automatically fixed the color accidents of wulax's animations.
For Skoprio's and the original animations I changed the transparent pixels only.
Fixed a few black pixels in grab.
Where are the animation fixes located? And what exactly did they fix.
I want to do update all to their newest versions and then make first sure colors are right everywhere and remove differences between frames and body parts who should be the same.
I added an overlay with notes for myself what are [D]uplicated and [M]irrored tiles (ignoring head reflection). [R]eused is for tiles which only differ in a few pixels, I just used it once and have no clear definition for it yet.
I always create separate images per animation, all my mapping rules are targeting that.
The big image I posted a few posts above is for getting an good overview and make it easier for me to find.
Aside from that I only concatenate images when I upload them to reduce the amount of images, they are always combined with "magick montage -mode concatenate -tile 1x -background none " or something similar.
My character generator also uses a canvas per animation in contrast to sanderfrenken's. In my eyes those character generators are only previews and combining and palette swapping should be done by the engine, there is no reason to have more than one color of everything. Modular bodies does create one big sheet in the last step, but sheets per animation in the second last one.
That's also why I wouldn't attribute any submission, which just replaces the palette with another already existing one or who concatenate or reorder other submissions. That edit does not get past the threshold of originality needed by copyright law, I can easily recreate that in a minute or so.
Color palettes themself are also not copyrightable, but I credit them out of respect (not the considerate one, but the one with high esteem).
There are some defacto standards of arranging the animations. I put the die/hurt animation first, since it's usually added as last, which is bad compatibility wise.
Okay, I added the running animation und updated the post above. (I will keep it updated, I don't see a reason to post it multiple times)
I only converted all animations to the attached palette and fixed issues arising from doing that. I kept the heads as wrong as wulax created them. I will create a new sheet for the edited versions, with markings on [E]dited frames.
At least the layering, how I did it, wasn't a good idea.
I made those layers foremost for reassembling the bodies correctly, that alone makes it more complicated. I tried to reuse parts for several frames, which also required to draw some pixels which aren't visible. I had a layer for front/back arms/legs, but the left/right arm/leg was always completely on one layer. It does not work that way.
What might work is: (I see sholders as part of the arm)
This does not allow to use left and right hand separately, well neither was it really possible before. But that could also be interesting. Like a walking animation where one arm has less motion because it's carrying a spear/bow. It could make it easier to draw weapons, but it's only worth it if there is not many clothing pixels that have to be redrawn, or even better if none have to.
I agree in pvigier's case, but at least for the characters bases we should aim for one submission with multiple authors/maintainers. We can still specify per animation attribution in a markdown or text file and from this threads history we should know who did what. I'd expect that to make it a lot easier for those want to create new clothings.
But I agree with BenCreating there, those who upload submissions have to use them, that includes being able/feeling comfortable to do so.
I used it only for heads, but it was never limited to them.
If this is relating the the build/shell tools, that can easily be done with short makefile:
%.gif: %.png
magick convert -background none -delay 16 $< -crop 64x +repage -set dispose background -loop 0 -layers optimize -compress LZW $@
Well, for that you can backport my cli-version of the character creator, which runs with nodejs.
Regarding the animations: I used a looking up head in my lying down sketch, but in general I don't think they are a good idea. People who can't really draw won't be able to port old assets to new animations, if they use new perspectives resulting from tilting/rotating. The sideways heads are already a pain, the original "hurt" animation as well. I would actually prefere to have a running animation based on the jumping (third and fourth frame) animation, which does not tilt heads. That's why I tend to forget that there is already a running animation.
And please write me basxto in ASCII. If I'd rename myself, links to my account would break.
The spear should probably overlap the hand a bit and make it look like it's being hold, similar to how it's done in the thrust animation
Pages