Interesting. I'm trying to get into Godot myself, so this was a good read. I enjoyed playing ogazuhl as well (oh, I get it: OGAzuhl). I'm a sucker for those classic 1st person orthogonal dungeon crawls, and ogazuhl already looks better than the ones I played in my infancy. Looking forward to DungeonMore. :)
"...and you set the license to CC(whatever), you already have trouble."
True, but not because you published your game with a pixabay asset. The trouble is from changing the license from pixabay's to CC(whatever). I was never recommending (and specificially expressed concern against) changing the license.
It's unfortunate pixabay staff and some contributors view the sale or hosting of CC0 assets on other sites as "abuse". I can understand some users not truly understanding the implications before submitting work under CC0 and feeling remorse over it, but the correct response should not be to attempt to force CC0 to be something it is not:
A: "You can have this candy bar. It's free. Do what you want with it. You can even share it."
Q: "Really? Cool. I think I'll share it with my friend."
A: "NO! you can't do that! We don't want you to share it with other people!"
Q: "...!? Then why did you explicitly state that I am allowed to share it?"
A: "It seemed easier to say it that way."
Q: "Are you going to stop telling people they can do things you don't even want them to do, then?"
A: "We never told people that in the first place."
Q: "You just told ME that!"
A: "Yeah, but it would be really rude of you to tell people we told you that. because we never really felt that way to begin with. We were just saying it, you know? We didn't mean it. Stop abusing us!"
Simon says they don't want to let people know which assets are CC0 because "abuses" were occurring. Anybody know what sort of abuses the Pixabay contributors were experiencing? I am having a hard time thinking of ways one could actually abuse CC0. User implying warranty or endorsement of author? Images of actual persons? Everything else is permitted.
P.S. If you do want to use pixabay's assets that are under the new license, you could do so safely in your project so long as:
you don't post them on a stock photo or wallpaper platform. (Pff! Unless your project is called "We're like Stockimage.com, but different", I doubt this is a concern)
you don't use assets with identifiable people, or portray people in a bad light or offensive nature (We don't really allow this on OGA either - see here - so not really a big change from anything you'd find here)
you don't assume or imply endorsement by author or source (already one of the very few requirements of CC0, so I doubt that would ever be an issue)
you don't use the asset unmodified. You must add value in some way. Kind of the opposite of the CC-BY-ND license; in this case, you MUST have a derivative in order to use it. :P
However, it is unclear if pixabay's ToS allows relicensing, and since OGA does not accept the Pixabay License as one of the available options, we may not be allowed to host any derivatives of assets under pixabay's new license, as that would require the license to change to a different license. I'll have to look into it more to see if their license must be inherited by all derivatives.
Unless this is some new new license change at pixabay, I've already taken a look at this. A similar concern was raised on the forum thread here a few months back. I think it's a pretty dirty move and I certainly won't be using pixabay moving forward, but the good news is they don't get to sneak into your project and change the license on assets already in use.
More directly addressing pixabay's change specifially, see the discussion on submissions derived from pixabay assets (before their license change) here and here.
TL;DR: Before 1-1-2019, pixabay used the CC0 license. pixabay's new stipulations do not apply to any OGA submission prior 2019. Any assets obtained from pixabay before their license change retain their CC0 status. CC0 cannot be revoked, so pixabay changing their license on CC0 assets is irrelevant. However, you should not download assets from pixabay today and treat them as if they are CC0, since they may not be the same assets as those that were available under the original CC0. Make sure the Published date on the pixabay page is before 1-1-2019.
hehehe! I think if OP is having trouble with tools like piskel for merging 2 sprites, coding something in magic-script may be a bit like using a steamroller to kill a spider. Still, imagemagic is a great tool.
It appears to me the animation is running slower than the movement speed. Try moving the character fewer pixels per move or cycle through more animation frames per move. I understand this may be difficult since you have a set number of animation frames as well as a set distance between tiles. Try working in multiples of your animation frames: if you have 6 frames in a walk cycle, try bumping your animation rate so it renders 12 frames per move (or 2 full walk cycles), if that still looks "slide-y" bump it up again to 3 walk cycles.
You may have to decouple your walking animation speed from movement distance. Make it so as long as the character is moving, the walk animation is running. Then, if the character stops, stop the animation as well and set the characcter back to the standing-still frame. That will allow you to set the animation speed independent of the distance traveled. Once the character stops at their destination, it may jump from a middle-of-a-step frame of animation to a standing-still frame, but it usually doesn't look as unnatural as you'd expect.
If that isn't making sense to you, let me know. Can you make the character spritesheet available here for me to use in demonstrations?
Yes, that method should work for other dimensions just as well. Simply change the values you're entering on step 7. :)
As for how to determine the frame size and offset... Rubberduck explicitly listed 16x16 in the tags for this one, but it's not always so easy.
Usually I'll pick a tile in the spritesheet with a clear border (for example, the trusses at 160,80)
Open the spritesheet in GIMP.
Menu bar > View > Show grid
Menu bar > Image > Configure Grid
Then I start adjusting the grid width and height until the grid lines seem to line up with the tiles, paying special attention to the tile I picked out earlier.
It involves some guesswork, but this method works pretty fast for me. Most spritesheets have dimensions in powers of 2, so 16x16, 32x32, 64x64 are pretty common. Often the width and height are mixed and matched, though: 16x32, 32x48. On the other hand, there's no rule that says sprites MUST be powers of two, so you'll sometimes encouter sprites with strange dimensions like 21x33. Other times, the graphics is set to conserve as much room as possible, so the sprites are not arranged in a grid (sprite-atlas) but in wherever they will fit.
For example, this pixel dungeon spritesheet (below) has sprites in multiple sizes (16x16, 14x20, 32x32, 35x35, etc) In these cases, no amount of grid tweaking will properly slice all the sprites. Some tools like Unity have texture atlas tools that help auto-slicing the atlas, but other than that, there isn't a good easy way to do it with atlases. Just open it in gimp and start manually cutting each sprite out.
Ah, looks like rubberduck set them up so the overflowing tiles are adjacent. I was wrong about the offsets. It's a 16x16 spritesheet with some tiles having overflow. So, here's how to split them out into individual tiles:
The sprite dimensions for this sheet are not grid-aligned. They appear to be 16x16, but separate sections have different offsets, which makes this more of a "sprite-atlas" rather than a spritesheet. Can you tell me where this came from?
Interesting. I'm trying to get into Godot myself, so this was a good read. I enjoyed playing ogazuhl as well (oh, I get it: OGAzuhl). I'm a sucker for those classic 1st person orthogonal dungeon crawls, and ogazuhl already looks better than the ones I played in my infancy. Looking forward to DungeonMore. :)
True, but not because you published your game with a pixabay asset. The trouble is from changing the license from pixabay's to CC(whatever). I was never recommending (and specificially expressed concern against) changing the license.
It's unfortunate pixabay staff and some contributors view the sale or hosting of CC0 assets on other sites as "abuse". I can understand some users not truly understanding the implications before submitting work under CC0 and feeling remorse over it, but the correct response should not be to attempt to force CC0 to be something it is not:
A: "You can have this candy bar. It's free. Do what you want with it. You can even share it."
Q: "Really? Cool. I think I'll share it with my friend."
A: "NO! you can't do that! We don't want you to share it with other people!"
Q: "...!? Then why did you explicitly state that I am allowed to share it?"
A: "It seemed easier to say it that way."
Q: "Are you going to stop telling people they can do things you don't even want them to do, then?"
A: "We never told people that in the first place."
Q: "You just told ME that!"
A: "Yeah, but it would be really rude of you to tell people we told you that. because we never really felt that way to begin with. We were just saying it, you know? We didn't mean it. Stop abusing us!"
Simon says they don't want to let people know which assets are CC0 because "abuses" were occurring. Anybody know what sort of abuses the Pixabay contributors were experiencing? I am having a hard time thinking of ways one could actually abuse CC0. User implying warranty or endorsement of author? Images of actual persons? Everything else is permitted.
P.S. If you do want to use pixabay's assets that are under the new license, you could do so safely in your project so long as:
However, it is unclear if pixabay's ToS allows relicensing, and since OGA does not accept the Pixabay License as one of the available options, we may not be allowed to host any derivatives of assets under pixabay's new license, as that would require the license to change to a different license. I'll have to look into it more to see if their license must be inherited by all derivatives.
???
Unless this is some new new license change at pixabay, I've already taken a look at this. A similar concern was raised on the forum thread here a few months back. I think it's a pretty dirty move and I certainly won't be using pixabay moving forward, but the good news is they don't get to sneak into your project and change the license on assets already in use.
More directly addressing pixabay's change specifially, see the discussion on submissions derived from pixabay assets (before their license change) here and here.
TL;DR: Before 1-1-2019, pixabay used the CC0 license. pixabay's new stipulations do not apply to any OGA submission prior 2019. Any assets obtained from pixabay before their license change retain their CC0 status. CC0 cannot be revoked, so pixabay changing their license on CC0 assets is irrelevant. However, you should not download assets from pixabay today and treat them as if they are CC0, since they may not be the same assets as those that were available under the original CC0. Make sure the Published date on the pixabay page is before 1-1-2019.
hehehe! I think if OP is having trouble with tools like piskel for merging 2 sprites, coding something in magic-script may be a bit like using a steamroller to kill a spider. Still, imagemagic is a great tool.
It appears to me the animation is running slower than the movement speed. Try moving the character fewer pixels per move or cycle through more animation frames per move. I understand this may be difficult since you have a set number of animation frames as well as a set distance between tiles. Try working in multiples of your animation frames: if you have 6 frames in a walk cycle, try bumping your animation rate so it renders 12 frames per move (or 2 full walk cycles), if that still looks "slide-y" bump it up again to 3 walk cycles.
You may have to decouple your walking animation speed from movement distance. Make it so as long as the character is moving, the walk animation is running. Then, if the character stops, stop the animation as well and set the characcter back to the standing-still frame. That will allow you to set the animation speed independent of the distance traveled. Once the character stops at their destination, it may jump from a middle-of-a-step frame of animation to a standing-still frame, but it usually doesn't look as unnatural as you'd expect.
If that isn't making sense to you, let me know. Can you make the character spritesheet available here for me to use in demonstrations?
Yes, that method should work for other dimensions just as well. Simply change the values you're entering on step 7. :)
As for how to determine the frame size and offset... Rubberduck explicitly listed 16x16 in the tags for this one, but it's not always so easy.
It involves some guesswork, but this method works pretty fast for me. Most spritesheets have dimensions in powers of 2, so 16x16, 32x32, 64x64 are pretty common. Often the width and height are mixed and matched, though: 16x32, 32x48. On the other hand, there's no rule that says sprites MUST be powers of two, so you'll sometimes encouter sprites with strange dimensions like 21x33. Other times, the graphics is set to conserve as much room as possible, so the sprites are not arranged in a grid (sprite-atlas) but in wherever they will fit.
For example, this pixel dungeon spritesheet (below) has sprites in multiple sizes (16x16, 14x20, 32x32, 35x35, etc) In these cases, no amount of grid tweaking will properly slice all the sprites. Some tools like Unity have texture atlas tools that help auto-slicing the atlas, but other than that, there isn't a good easy way to do it with atlases. Just open it in gimp and start manually cutting each sprite out.
Fortunately, in this example, Zombietom uploaded all of watabou's individual spritesheets in a zip file as well, so there is no need to slice this one image manually: https://opengameart.org/content/pixel-dungeon-graphics-by-watabou
Ah, looks like rubberduck set them up so the overflowing tiles are adjacent. I was wrong about the offsets. It's a 16x16 spritesheet with some tiles having overflow. So, here's how to split them out into individual tiles:
The sprite dimensions for this sheet are not grid-aligned. They appear to be 16x16, but separate sections have different offsets, which makes this more of a "sprite-atlas" rather than a spritesheet. Can you tell me where this came from?
Pages