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...
This exact thing (figure out how to put a character on a horse by using different parts of existing animations in code) has been on my TODO list for ages, but I've been putting it off because the work required seemed so tedious.
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 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...
Well done!
This exact thing (figure out how to put a character on a horse by using different parts of existing animations in code) has been on my TODO list for ages, but I've been putting it off because the work required seemed so tedious.
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.
3D Mario games have a similar problem. You can ameliorate it by using things like shadow underneath the platform.
That the LPC sprites lack a jump animation is just a reason for someone to add one (I'd find a use for such).
Pages