I think the solution to massive, repetitive open areas is just to not have any, and fill that space up with interesting stuff. So for that, the LPC base assets work fine (but more variation is great - also helps to make different areas in the game more distinct and memorable).
I have a few more tree variations to throw in, but I'm deliberately limiting it to three or so.
The major pain I have with the cliffs is that they're assymmetric: they extend two extra tiles southward cmpared to any other direction. Part of the issue, of course, is that I'm trying to do a Zelda-like perspective with art that has a more Final Fantasy perspective. Another part of the issue is that I don't have all my mountains pushed off to the northern edge of the map. Things get really complicated if the generator decides that terrain should drop down two levels. In theory the cliffs should tile properly. In practice, a procedural generator will find interesting corner cases that break things. I've been plugging those up, but new ones just take their place, so I'm trying to work out something that is more robust. I keep going back and forth on keeping the LPC base mountains or trying to find something else. I'd prefer to keep the LPC stuff.
The problem with the waterfalls is exactly that they end up being obscured by the ciffs: it's hard to tell that it's there and make it look good at the same time. Or I just suck at doing the pixel art for it, which is a distinct possibility. Games such as Zelda, Secret of Mana and Chrono Trigger avoid the issue by only putting waterfalls on south-facing cliffs.
Is this the final scale or you will generate larger worlds later?
Looks tiny, doesn't it? The feel for the game that I'm going for is Legend of Zelda: A Link to the Past. The overworld in A Link to the Past is 16x16 screens. The original Legend of Zelda was 16x8. Link's Awakening is also 16x16. None of those worlds feel very small, so beginning with something similar seemed like a reasonable thing to do. I believe Lenna's Inception also uses a 16x16 screen overworld, but I haven't checked in a while.
Of course, the thing with those Zelda games is that they have very intricately designed worlds with gated progression and winding paths that make the world feel larger than it is. For instance, to go from your house to Kakariko Village in A Link t the Past you have to take a detour to the south and walk around to approach the village from the south, or slip past Hyrule Castle and approach from the north. A Link between Worlds added a short-cut to the west of Hyrule Castle that takes you directly to the smithy, and it makes the world feel smaller as a result. I don't know if that level of crafted detail is something that can be accomplished with procedural generation (in principle, sure, but in practice it may be hard for a one-person dev team with a regular job). We'll see. At any rate, I do plan to enforce a rule that every screen has to have "something" of interest on it, so the world doesn't feel empty.
I got fed up with getting the cliffs to work correctly though, and gave it a bit of a rest last year. I've been tweaking the dungeon generation and combat system in the mean time, but both need work. I've been checking out Unexplored (information about the game anyway; the art style doesn't appeal to me, so I haven't played it), which has a very neat system for generating dungeons (using loops rather than the typical roguelike generators) that I want to do something with.
In the end of the day, this is a procedural world. Making it larger is trivial, and I might even make that an option so the player can decide if they want a fast game or a sprawling epic.
I've been working on something similar for a while too; I'm itching for summer holidays to start so I have time to go back to it.
For placing trees I tend to just scatter a bunch of trees around and give it a pass with cellular automata. Works well. Note though that I determine the biome type (based on a combination of elevation and, again, cellular automata) and then place trees, rather than placing trees and figuring out where the forests are later.
EDIT: forgot to say, working with cliffs is a right pain in the rear. The code keeps finding new and interesting ways to break by needing non-existent corner transitions. I still need waterfalls for east/west and north directions too.
I did simplify the algorithm considerably though. My initial setup had a hierarchical network of anchor points (joints) and offsets, but you can do all that implicitly and just store the coordinates directly.
The forward walkcycle works fine, most of the other animations are a good first attempt, but I'm sure it can do better by automating some more. Progress is a bit slower than I'd like, unfortunately.
Thanks! I certainly hope this will turn out to be useful.
I haven't done much to improve the output of the algorithm; I'm sure it's possible to eliminate the 1-pixel gap in the walk cycle with a bit more care (and more careful selection of the relevant body parts). I did have to tweak some of the offsets for the Warthotaur to get the limbs and head spaced correctly (the ruff throws off the placement of the arms and head), and I'm trying to automate that first. Shouldn't be too hard, but it's giving me issues...
I was also thinking about the ability to recolor the sheets in the generator. If we grayscale all sheets, and make some color picker in the generator, this might be doable. Maybe like how they do it in the online Lottiefiles editor, it should be doable and will deliver a lot of value.
Being able to recolour assets would definitely be useful, because it's such a tedious thing to do by hand. That said, it's tedious precicely because it's not as easy as convoluting a greyscale image with a colour.
A lot of (original) LPC artwork is based on 5-shade ramps and can be recoloured by swapping our colours for the corresponding colour in one of the other ramps from the LPC palette. To keep a consistent style, it would be best to pick colours already defined in the LPC palette rather than picking a new set from scratch, if possible (I'm not particularly fond of the LPC palette: it has a lot of green and brown shades that are sortof but not really interchangeable, and it's lacking in bright reds and yellows, so you need to add those if you want them).
Now, not all artwork that claims it's "LPC compatible" follows the LPC palette. That's ok, there can be good reasons for using colours not in the palette, but sometimes it doesn't use any of the "LPC palette" colours, and it looks off when used with other LPC artwork. At least it does to me.
Evert, I don't see what you mean about the cape. The cape cutout works perfectly with bracers, with everything else in the set.
You're missing the point. Cutouts work as long as the thing they cut around have the shape that you expect. The bracers extend outside the outline of the arm, so if your cut-out was made to reveal the arm, it will now incorrectly occlude part of the bracers. Even if it works fine with everything now, there's no guarantee it'll stay that way. Cutting out parts that should be hidden behind other parts of the sprite rather than working with layers is simply not scalable when you want to combine assets this way.
Two sheets will do nothing but take up space and slow down CPUs.
No it won't, unless you're compositing in real time, which is a waste regardless. If you composit the sprites off-line (GIMP, the generator) it's not an issue, and if you do it on-demand but cache the resulting spritesheet, it's also not an issue. Keeping all the LPC assets in memory is a waste of resources anyway.
It sounds like you think one cape can be made that fits both sexes, it won't.The body types are different and the cape will look goofy for one of them.
That's not what I'm saying. Perhaps I don't care that the cape doesn't look right, but I do want a quick idea of what the sprite looks like overall. If I want to actually use the sprite sheet, I'll need to fix up the cape afterwards, but that's probably still less work than if the program doesn't allow me to put the cape in at all.
Ah is there a newer version of the axe to use? Then I would like to update it.
I think so. The attack animation I grabbed from the spritesheet folder yesterday is the weird "wave axe in front of my face" rather than "swing axe at the enemy", which I think was fixed in the actual spritesheet.
I should point out that I don't actually use the generator itself, I just cloned the repository locally to have all the assets available in one location. Well, all the assets that are in the generator anyway; I think some of them may not be up to date though (the axe is what I noticed).
One thing I didn't like about the generator when I tried it (the original version a few years ago anyway): restricting what I can include in the sheet based on body type. I think the cape was female-only, but I wanted a cape on a male character. Couldn't be done. Sure, I if I want to actually use the sprite, it needs to be touched up, but if I just want to have a quick-and-dirty version to get an idea for how it looks, it's annoying that I'm arbitrarily limited because of body type.
Regarding the cape (and similar things): yes, in fact I do want two sheets to draw, one behind and one on top of the body. The reason is that depending on the frame, some parts of the cape should be behind the body, but other parts should be in front, and relying on cutouts is not good enough. Sure, you can make it work with the standard spritesheet easily enough, and it feels clever. Then you make a character that is wearing bracers, or spiky armour and oops, the cut-out no longer works! What if the character is wearing robes, or trousers? The same cut-out doesn't work for both combinations. Similar issues when trying to switch it from male to female sprites: having to fix the cut-out is more work than it would be if you simply had two layers.
The main issue, by the way, is in the side-facing frames. For the north and south facing frames you can simply change the drawing order, and it'll work correctly.
Having said all that, I should further point out that I do very little compositing within my game itself (just weapons, because those can be swapped; I haven't decided on what to do with armour yet, but that'd probably be switched as a set too, and only for the main character). Most of the compositing work is done in Gimp. If I were to do compositing in the game though, I would build the character spritesheet on the fly, similar to how the generator works, then draw from the generated spritesheet.
Sure, here's the head (the other half is just the standard Orc spritesheet). There's no problem with the back view, so it doesn't include the head for that one, and I haven't made Orc archers yet, so it's also missing the archery frames. And the death animation, it seems.
There are some other assets where making two separate "in front" and "behind" layers makes sense, like the cape (it's much easier to put the full cape behind the body than it is to make cut-outs). That's also useful for weapons.
I think the solution to massive, repetitive open areas is just to not have any, and fill that space up with interesting stuff. So for that, the LPC base assets work fine (but more variation is great - also helps to make different areas in the game more distinct and memorable).
I have a few more tree variations to throw in, but I'm deliberately limiting it to three or so.
The major pain I have with the cliffs is that they're assymmetric: they extend two extra tiles southward cmpared to any other direction. Part of the issue, of course, is that I'm trying to do a Zelda-like perspective with art that has a more Final Fantasy perspective. Another part of the issue is that I don't have all my mountains pushed off to the northern edge of the map. Things get really complicated if the generator decides that terrain should drop down two levels. In theory the cliffs should tile properly. In practice, a procedural generator will find interesting corner cases that break things. I've been plugging those up, but new ones just take their place, so I'm trying to work out something that is more robust. I keep going back and forth on keeping the LPC base mountains or trying to find something else. I'd prefer to keep the LPC stuff.
The problem with the waterfalls is exactly that they end up being obscured by the ciffs: it's hard to tell that it's there and make it look good at the same time. Or I just suck at doing the pixel art for it, which is a distinct possibility. Games such as Zelda, Secret of Mana and Chrono Trigger avoid the issue by only putting waterfalls on south-facing cliffs.
Looks tiny, doesn't it? The feel for the game that I'm going for is Legend of Zelda: A Link to the Past. The overworld in A Link to the Past is 16x16 screens. The original Legend of Zelda was 16x8. Link's Awakening is also 16x16. None of those worlds feel very small, so beginning with something similar seemed like a reasonable thing to do. I believe Lenna's Inception also uses a 16x16 screen overworld, but I haven't checked in a while.
Of course, the thing with those Zelda games is that they have very intricately designed worlds with gated progression and winding paths that make the world feel larger than it is. For instance, to go from your house to Kakariko Village in A Link t the Past you have to take a detour to the south and walk around to approach the village from the south, or slip past Hyrule Castle and approach from the north. A Link between Worlds added a short-cut to the west of Hyrule Castle that takes you directly to the smithy, and it makes the world feel smaller as a result. I don't know if that level of crafted detail is something that can be accomplished with procedural generation (in principle, sure, but in practice it may be hard for a one-person dev team with a regular job). We'll see. At any rate, I do plan to enforce a rule that every screen has to have "something" of interest on it, so the world doesn't feel empty.
I got fed up with getting the cliffs to work correctly though, and gave it a bit of a rest last year. I've been tweaking the dungeon generation and combat system in the mean time, but both need work. I've been checking out Unexplored (information about the game anyway; the art style doesn't appeal to me, so I haven't played it), which has a very neat system for generating dungeons (using loops rather than the typical roguelike generators) that I want to do something with.
In the end of the day, this is a procedural world. Making it larger is trivial, and I might even make that an option so the player can decide if they want a fast game or a sprawling epic.
I've been working on something similar for a while too; I'm itching for summer holidays to start so I have time to go back to it.
For placing trees I tend to just scatter a bunch of trees around and give it a pass with cellular automata. Works well. Note though that I determine the biome type (based on a combination of elevation and, again, cellular automata) and then place trees, rather than placing trees and figuring out where the forests are later.
EDIT: forgot to say, working with cliffs is a right pain in the rear. The code keeps finding new and interesting ways to break by needing non-existent corner transitions. I still need waterfalls for east/west and north directions too.
I might as well. No concrete plans though.
I did simplify the algorithm considerably though. My initial setup had a hierarchical network of anchor points (joints) and offsets, but you can do all that implicitly and just store the coordinates directly.
The forward walkcycle works fine, most of the other animations are a good first attempt, but I'm sure it can do better by automating some more. Progress is a bit slower than I'd like, unfortunately.
Thanks! I certainly hope this will turn out to be useful.
I haven't done much to improve the output of the algorithm; I'm sure it's possible to eliminate the 1-pixel gap in the walk cycle with a bit more care (and more careful selection of the relevant body parts). I did have to tweak some of the offsets for the Warthotaur to get the limbs and head spaced correctly (the ruff throws off the placement of the arms and head), and I'm trying to automate that first. Shouldn't be too hard, but it's giving me issues...
Being able to recolour assets would definitely be useful, because it's such a tedious thing to do by hand. That said, it's tedious precicely because it's not as easy as convoluting a greyscale image with a colour.
A lot of (original) LPC artwork is based on 5-shade ramps and can be recoloured by swapping our colours for the corresponding colour in one of the other ramps from the LPC palette. To keep a consistent style, it would be best to pick colours already defined in the LPC palette rather than picking a new set from scratch, if possible (I'm not particularly fond of the LPC palette: it has a lot of green and brown shades that are sortof but not really interchangeable, and it's lacking in bright reds and yellows, so you need to add those if you want them).
Now, not all artwork that claims it's "LPC compatible" follows the LPC palette. That's ok, there can be good reasons for using colours not in the palette, but sometimes it doesn't use any of the "LPC palette" colours, and it looks off when used with other LPC artwork. At least it does to me.
You're missing the point. Cutouts work as long as the thing they cut around have the shape that you expect. The bracers extend outside the outline of the arm, so if your cut-out was made to reveal the arm, it will now incorrectly occlude part of the bracers. Even if it works fine with everything now, there's no guarantee it'll stay that way. Cutting out parts that should be hidden behind other parts of the sprite rather than working with layers is simply not scalable when you want to combine assets this way.
No it won't, unless you're compositing in real time, which is a waste regardless. If you composit the sprites off-line (GIMP, the generator) it's not an issue, and if you do it on-demand but cache the resulting spritesheet, it's also not an issue. Keeping all the LPC assets in memory is a waste of resources anyway.
That's not what I'm saying. Perhaps I don't care that the cape doesn't look right, but I do want a quick idea of what the sprite looks like overall. If I want to actually use the sprite sheet, I'll need to fix up the cape afterwards, but that's probably still less work than if the program doesn't allow me to put the cape in at all.
I think so. The attack animation I grabbed from the spritesheet folder yesterday is the weird "wave axe in front of my face" rather than "swing axe at the enemy", which I think was fixed in the actual spritesheet.
I should point out that I don't actually use the generator itself, I just cloned the repository locally to have all the assets available in one location. Well, all the assets that are in the generator anyway; I think some of them may not be up to date though (the axe is what I noticed).
One thing I didn't like about the generator when I tried it (the original version a few years ago anyway): restricting what I can include in the sheet based on body type. I think the cape was female-only, but I wanted a cape on a male character. Couldn't be done. Sure, I if I want to actually use the sprite, it needs to be touched up, but if I just want to have a quick-and-dirty version to get an idea for how it looks, it's annoying that I'm arbitrarily limited because of body type.
Regarding the cape (and similar things): yes, in fact I do want two sheets to draw, one behind and one on top of the body. The reason is that depending on the frame, some parts of the cape should be behind the body, but other parts should be in front, and relying on cutouts is not good enough. Sure, you can make it work with the standard spritesheet easily enough, and it feels clever. Then you make a character that is wearing bracers, or spiky armour and oops, the cut-out no longer works! What if the character is wearing robes, or trousers? The same cut-out doesn't work for both combinations. Similar issues when trying to switch it from male to female sprites: having to fix the cut-out is more work than it would be if you simply had two layers.
The main issue, by the way, is in the side-facing frames. For the north and south facing frames you can simply change the drawing order, and it'll work correctly.
Having said all that, I should further point out that I do very little compositing within my game itself (just weapons, because those can be swapped; I haven't decided on what to do with armour yet, but that'd probably be switched as a set too, and only for the main character). Most of the compositing work is done in Gimp. If I were to do compositing in the game though, I would build the character spritesheet on the fly, similar to how the generator works, then draw from the generated spritesheet.
Sure, here's the head (the other half is just the standard Orc spritesheet). There's no problem with the back view, so it doesn't include the head for that one, and I haven't made Orc archers yet, so it's also missing the archery frames. And the death animation, it seems.
There are some other assets where making two separate "in front" and "behind" layers makes sense, like the cape (it's much easier to put the full cape behind the body than it is to make cut-outs). That's also useful for weapons.
Pages