I think it would make the most sense to have the option to download either the "legacy" universal spritesheet, a given animation, and perhaps a behemot file with all available animations in one file.
Personally I don't like adding stuff below the death animation, because it breaks the "every four rows is a new animation ordered NWSE" pattern. The death animation does that anyway, but it's the last one in the sheet, so it gets a pass. I also don't like working with "tall" sheets and prefer working with more square files. I guess because my display isn't tall.
All of that is of course neither here nor there, software can be made to handle anything...
For the tilesets, I think it's worth looking carefully at what is actually needed. Camps, kitchens, farms, taverns and breweries can, I think, be reasonably constructed from existing assets, with perhaps just a few flavour items to round things out. Think a stag head on the wall, stacked barrels of wine with a tap.
More weapon animations (or animation variations, think slash, backhand slash, thrust all with a sword) and tool animations (especially if they don't need new animation frams but can cleverly reuse existing animation frames) would be awesome.
As for what I'd like to see: more animals! Sure, we have farm animals, some birds, a rabbit, a boar and a wolf, but wouldn't it be awesome if we had things like deer? Bears? Monkeys? I appreciate that'd be a lot of work though - and that's before considering that death and attack animations for those would be awesome too.
Love the minotaur kid... calf? Really like the flexibility the modular heads provide.
Progress this week has been slower than anticipated. We were in quarantine, so I expected that to free up some time, but it seems to have done the opposite.
I've been thinking how to set up the build system. It's going to depend on lpc-tools, which only makes sense (reuse what you can), but beyond that I'm finding it tricky to make up my mind how to go about it. The thing is, something like Make expects to generate "filename.output" from some "filename.input", but the way files are organised now, it needs to build, say, "output/body/male/purple.png" from "source/body/male.png" and that's more tricky. You can write an explicit rule for it easily enough, but really I want something that requires a little bit less maintenance, so I can just tell it that "source/body/male.png" exists and it will figure out what outputs it can generate from that. I may end up wanting to overhaul the directory structure. So it is very sensible to think about a canonical organisation for the files.
I'll probably try to stay with plain Make. I did look at something like CMake, but that has more build-in assumptions about the relation between source (input) and output that make it less convenient.
Not sure this counts as constructive thoughts on organising the spritesheets. I suppose whatever we come up with can be changed later anyway. When in doubt, I am a proponent for picking something that is more convenient for humans to work with, since computers are supposed to work for us rather than the other way around.
Oh, final thoughts about the jump animation: I agree with nuking the special-case head if it's not crucial, it's not as if it breaks tons of existing assets and if it makes adapting other assets even marginally easier, that's a win. For my project, I extended the universal spritesheet to be 1152 pixels wide and stuck the jump animation next to the shoot animation. Not saying that's the best place for it to go, but I would argue against trying to stick it at the bottom of the existing universal spritesheet (say) and would prefer "loose" animations instead, but that's just me personally.
Ok, here's where I am and what I think I'm going to be doing in the next couple of weeks.
I found some well-defined and named colour ramps in an old post by Eliza. I'm going to check how those compare to other existing ramps and whether they're all still current.
I like the idea of splitting things up in a "source" and multiple "outputs", as bluecarrot16 suggested.
Not re-inventing the wheel, so I will reuse everything I can and am aware of.
I'm going to cut up the universal spritesheet and split it out again in individual animations. I love the convenience of a single big spritesheet to work with, but it engenders some stagnation as well, because...
... there are several animations out there that are not in the universal spritesheet, and I want to treat those as equal citizens. There's (Eliza's improved) jump animation, a running animation, the recent sitting frames, animations that are frankensteined from existing animations, the grab animation and a few I did myself (carry, push) based on other animations. Some of these have a (limited) selection of hair/clothing, some don't, but we'll get there when we get there.
Cut those down to single sets of colourramps for skin and eye colour.
Assemble things like eyes, noses, expressions and the like. Some of these are in the generator, some aren't, but they should all be constructable from a few source images, just as the hairpieces are.
Wrap that up in a nice build system where you run some configure/make and it all automagically works (on *nix systems anyway; no clue about Windows).
Once I have the recolouring and assembling of the character bases, facial features and hair in place, I'll worry about handling the clothing. Hopefully that will be relatively straightforward once these are done (and I can probably just re-use what's already in the generator anyway).
Forgot to mention: I haven't done hand-crafted Makefiles in ages, having switched to CMake some years ago, but I was fairly proficient with writing them at one point (arguably none of my project involved much more than %.o:%.c: $(CC) $< -o $@ though). If nothing else, I'd be happy to contribute what I can in that department.
Ok, so thinking about it, I think my intended use-case is fairly specific: I want to be able to procedurally generate characters in-game. Conceptually, that means porting the spritesheet generator, but ideally in such a way that I can put, say the source images for a haircut somewhere, and the code takes care of assembling the piece and colouring it the right way. Of course, the hair generator does that already, and doing hats/eyes/ears/noses the same way isn't the hardest thing in the world. Even whole heads are doable, with some caveats to be worked out.
Cut-outs for arms (and legs) are highly situational, but very useful precicely for figuring out when an arm blocks a part of the face, or a weapon (or any other type of object you may want to hold, think lanterns and hand baskets) and masking that part out automatically. Not having to draw weapons with clever cut-outs for the hands, and then doing that again for the skeleton/female/juvenile variations (just shift a few pixels where needed) is a win.
There is one other case where I've found these to be helpful, and that is for making variant animations, like a walk cycle with the arms in a different position, say if the character is holdingor pushing something.
For recolouring, obviously everyone can pick whatever colours they like, but having a well-defined ramp available for easy recolouring gives maximum flexibility for everyone, I think. I like the idea of having a well-defined "brown" variant listed for all clothing items, I'll definitely use that as a base for whatever I manage to come up with.
I guess the first step I'll do then is to figure out what named colour-ramps have been proposed in the past (for skin/clothing/materials) and collect the various masks that are scattered around. Would it make sense to post those in a separate submission here, or put them in a repository somewhere?
Holidays are over, so it'll be slow going over the next few weeks, but hopefully I can get some things done if I have a clear idea of what I'm going to do exactly.
So I was just brainstorming about having a character builder into my game (for customising the player character, as well as easily generating a procedural troup of marauding orc's), and now I'm wondering if anything new or additional has been done with these?
Basically, I was thinking about in-code recolours of the bases for different skin tones (I think there are palettes for that scattered around), having bluecarrot16's hair bases and palettes (no need to store a full sheet if we can build it from a handful of basic images with offsets per frame) and having cloting items in a few well-defined palettes that can be recoloured on the fly. I guess the latter isn't available in any form yet, and of course it won't be so easy for cloting that does something more interesting than sticking to a single 5 or 6 ramp colour range.
Is there a definitive set of masks (for body parts), offsets (for headgear) and palettes/colour ramps (for skin tones) somewhere in a form that's easily readable/documented?
I am wondering if we could make a headless version of each of the "primary" body types (adult male, adult female, teen, pregnant, muscular), then combine any of those body types with any of the heads (human male, human female, orc male, orc female, lizard, wolfman, boarman, minotaur, skeleton, etc.).
I wasn't planning to mirror the E/W heads, since you went to the trouble of fixing the reflections on the scalp :p Good point about the hurt animation.
Isn't that something that could be automated using the scripts (either by having the spot as a separate highlight, or by recording what parts of the image to slide up a step along whetever colour ramp is in use)? I know it's something I tend to mess up half the time because I forget to make the adjustment after mirroring an image. ;)
I like how the greens work together in that image (and I love the flowers), but it's one step brighter than what I have now, which I feel is too bright for me. I'm not entirely happy with how the tree comes out (the one in your screenshot looks fine, the one I'm using doesn't fare so well with the new colour ramp).
Recolouring the floor similar to how you did does solve the problems with it (even going down a step on the ramp I was using before helps), but it does come out "cooler" than it was before, which changes the feel. I can't quite get my walls to look "right" with respect to what I was going for there, may need more tweaking.
I guess I really like two of the colour ramps in the original LPC palette that you had to cut out. :) Perhaps it's just a case of it being different and needing some time to get used to it.
At the end of the day, I personally wouldn't mind using your palette with two extra colour ramps, although that does kind of defeat the purpose of the whole exercise...
Something I have not done but thought about many times is that some colours in the original LPC palette are similar enough that it seems you should be able to merge them to an in-between shade. Is that something you've tried at all?
In a different note: you have a LttP inspired cliff? Cool, I personally can't wait.
I think it would make the most sense to have the option to download either the "legacy" universal spritesheet, a given animation, and perhaps a behemot file with all available animations in one file.
Personally I don't like adding stuff below the death animation, because it breaks the "every four rows is a new animation ordered NWSE" pattern. The death animation does that anyway, but it's the last one in the sheet, so it gets a pass. I also don't like working with "tall" sheets and prefer working with more square files. I guess because my display isn't tall.
All of that is of course neither here nor there, software can be made to handle anything...
For the tilesets, I think it's worth looking carefully at what is actually needed. Camps, kitchens, farms, taverns and breweries can, I think, be reasonably constructed from existing assets, with perhaps just a few flavour items to round things out. Think a stag head on the wall, stacked barrels of wine with a tap.
More weapon animations (or animation variations, think slash, backhand slash, thrust all with a sword) and tool animations (especially if they don't need new animation frams but can cleverly reuse existing animation frames) would be awesome.
As for what I'd like to see: more animals! Sure, we have farm animals, some birds, a rabbit, a boar and a wolf, but wouldn't it be awesome if we had things like deer? Bears? Monkeys? I appreciate that'd be a lot of work though - and that's before considering that death and attack animations for those would be awesome too.
Love the minotaur kid... calf? Really like the flexibility the modular heads provide.
Progress this week has been slower than anticipated. We were in quarantine, so I expected that to free up some time, but it seems to have done the opposite.
I've been thinking how to set up the build system. It's going to depend on lpc-tools, which only makes sense (reuse what you can), but beyond that I'm finding it tricky to make up my mind how to go about it. The thing is, something like Make expects to generate "filename.output" from some "filename.input", but the way files are organised now, it needs to build, say, "output/body/male/purple.png" from "source/body/male.png" and that's more tricky. You can write an explicit rule for it easily enough, but really I want something that requires a little bit less maintenance, so I can just tell it that "source/body/male.png" exists and it will figure out what outputs it can generate from that. I may end up wanting to overhaul the directory structure. So it is very sensible to think about a canonical organisation for the files.
I'll probably try to stay with plain Make. I did look at something like CMake, but that has more build-in assumptions about the relation between source (input) and output that make it less convenient.
Not sure this counts as constructive thoughts on organising the spritesheets. I suppose whatever we come up with can be changed later anyway. When in doubt, I am a proponent for picking something that is more convenient for humans to work with, since computers are supposed to work for us rather than the other way around.
Oh, final thoughts about the jump animation: I agree with nuking the special-case head if it's not crucial, it's not as if it breaks tons of existing assets and if it makes adapting other assets even marginally easier, that's a win. For my project, I extended the universal spritesheet to be 1152 pixels wide and stuck the jump animation next to the shoot animation. Not saying that's the best place for it to go, but I would argue against trying to stick it at the bottom of the existing universal spritesheet (say) and would prefer "loose" animations instead, but that's just me personally.
Ok, here's where I am and what I think I'm going to be doing in the next couple of weeks.
Forgot to mention: I haven't done hand-crafted Makefiles in ages, having switched to CMake some years ago, but I was fairly proficient with writing them at one point (arguably none of my project involved much more than %.o:%.c: $(CC) $< -o $@ though). If nothing else, I'd be happy to contribute what I can in that department.
Ok, so thinking about it, I think my intended use-case is fairly specific: I want to be able to procedurally generate characters in-game. Conceptually, that means porting the spritesheet generator, but ideally in such a way that I can put, say the source images for a haircut somewhere, and the code takes care of assembling the piece and colouring it the right way. Of course, the hair generator does that already, and doing hats/eyes/ears/noses the same way isn't the hardest thing in the world. Even whole heads are doable, with some caveats to be worked out.
Cut-outs for arms (and legs) are highly situational, but very useful precicely for figuring out when an arm blocks a part of the face, or a weapon (or any other type of object you may want to hold, think lanterns and hand baskets) and masking that part out automatically. Not having to draw weapons with clever cut-outs for the hands, and then doing that again for the skeleton/female/juvenile variations (just shift a few pixels where needed) is a win.
There is one other case where I've found these to be helpful, and that is for making variant animations, like a walk cycle with the arms in a different position, say if the character is holdingor pushing something.
For recolouring, obviously everyone can pick whatever colours they like, but having a well-defined ramp available for easy recolouring gives maximum flexibility for everyone, I think. I like the idea of having a well-defined "brown" variant listed for all clothing items, I'll definitely use that as a base for whatever I manage to come up with.
I guess the first step I'll do then is to figure out what named colour-ramps have been proposed in the past (for skin/clothing/materials) and collect the various masks that are scattered around. Would it make sense to post those in a separate submission here, or put them in a repository somewhere?
Holidays are over, so it'll be slow going over the next few weeks, but hopefully I can get some things done if I have a clear idea of what I'm going to do exactly.
So I was just brainstorming about having a character builder into my game (for customising the player character, as well as easily generating a procedural troup of marauding orc's), and now I'm wondering if anything new or additional has been done with these?
Basically, I was thinking about in-code recolours of the bases for different skin tones (I think there are palettes for that scattered around), having bluecarrot16's hair bases and palettes (no need to store a full sheet if we can build it from a handful of basic images with offsets per frame) and having cloting items in a few well-defined palettes that can be recoloured on the fly. I guess the latter isn't available in any form yet, and of course it won't be so easy for cloting that does something more interesting than sticking to a single 5 or 6 ramp colour range.
Is there a definitive set of masks (for body parts), offsets (for headgear) and palettes/colour ramps (for skin tones) somewhere in a form that's easily readable/documented?
In case you're curious: the minotaur head (from https://opengameart.org/content/lpc-faun-and-minotaur) should work properly as a modular head as well.
Isn't that something that could be automated using the scripts (either by having the spot as a separate highlight, or by recording what parts of the image to slide up a step along whetever colour ramp is in use)? I know it's something I tend to mess up half the time because I forget to make the adjustment after mirroring an image. ;)
Oh, great, just what I needed: more stuff to include in my game. It's never getting done, I tell you!
:P
Those are some really awesome additions. I'll put them on my "wish-list" for when I get what I'm working on at the moment done.
I like how the greens work together in that image (and I love the flowers), but it's one step brighter than what I have now, which I feel is too bright for me. I'm not entirely happy with how the tree comes out (the one in your screenshot looks fine, the one I'm using doesn't fare so well with the new colour ramp).
Recolouring the floor similar to how you did does solve the problems with it (even going down a step on the ramp I was using before helps), but it does come out "cooler" than it was before, which changes the feel. I can't quite get my walls to look "right" with respect to what I was going for there, may need more tweaking.
I guess I really like two of the colour ramps in the original LPC palette that you had to cut out. :) Perhaps it's just a case of it being different and needing some time to get used to it.
At the end of the day, I personally wouldn't mind using your palette with two extra colour ramps, although that does kind of defeat the purpose of the whole exercise...
Something I have not done but thought about many times is that some colours in the original LPC palette are similar enough that it seems you should be able to merge them to an in-between shade. Is that something you've tried at all?
In a different note: you have a LttP inspired cliff? Cool, I personally can't wait.
Pages