You're missing the point of the discussion, single files or multiple files, how do I know if an enemy supports an animation? I'm going to have to end up storing that info for each enemy. Especially if it's multiple files, the file won't even exist.
Let's not get too caught up on the wolf example. I put "run" in the special attack slot to be able to test it and I figured it could be shown during a wolf's special attack if I called it "trample" or whatever.
What I'm trying to avoid is to have a separate file for each asset or stuff encoded in metadata or even a whole database in my code telling me which enemy has which animation and how many frames it has. That is a large burden.
I'm totally open to suggestions.
@BenCreating Not all image loading libraries tell you the width and the height of the image its loading. Some are more concerned with being "easy to use" rather than "full featured". This is especially true of ones that leverage graphics cards and Direct3D/OpenGL/WebGL.
I think you guys all know that splitting png files up into smaller pieces reduces the compression ratio and increases the error rate. I could put up with that if it made things easier to program, but it doesn't, you now have to handle the file not found error and you don't know if the file failed to load or it just doesn't exist because the animation isn't supported for that enemy/variant.
Whether we call it a standard or a convention, if a few enemies get made in a particular way, it is likely that enemies made to follow will use the same format. So I'm happy to call it a conventional format.
I think having both a "special attack" and auxiliary slot as MedicineStorm suggested is great way to ensure people can use a custom animation.
I propose that if an artist does not want to provide an animation, just fill in the slot with static frames.
I've named the file wolf_64_5.png to indicate that frames are 64x64 and animations are 5 frames. The convention could be that enemy_96_4 would have 96x96 frames and 4 frame cycles. If a particular animation does not use all frames, static frames should be added.This shuld be a good comporomise between the needs of flexibility and the needs of programmers to not have to keep a database of what images have what animations and where.
Animatino slots:
1. Walk - used complete 5 frame walk animation
2. Attack - used complet 5 frame bite animation
3. Idle - no animation here; filled with static frames
4. Taking damage - used 3 frame animation, then 2 static frames
5. Death - used 4 frame animation, preceded by 1 static frame
6. Special Attack - I put the running animation in this slot, complete 5 frames
7. Auxiliary - I put the howling animation here, preceded by 1 static frame
The reason I was suggesting more than was neccessary is because making animations simpler than the standards allow is much easier than making animations more complex than the standards allow later.
Yes and no. For example it was suggested by @BenCreating that movement animations should be only 4 frames. William's wolf for example, has 5 frames. It is very hard to make it 4 frames. It would also be very hard to make it 6 frames. If I want a bunch of enemies, for programming purposes, it's much easier if they all have the same number of frames but changing the number of frames is very difficult. The number of frames per animation could be different on a per animation basis, similar to the characters. But it would be easier for programming to make it more strict, to just say 4 frames for every animation. I'm tempted to make it 5 frames so I can use the wolf.
Hi, could you explain the Soundimage International Public License and how it differs from CC-BY and OGA-BY, which also are free to use and require attribution.
Talking to @JaidynReiman, he feels that making enemies might be more difficult than making regular characters becuase we are not building on a common base. Do artists here agree?
I was thinking at first we let some people submit some stuff and then deciding whether a "character generator" is even the right thing for enemies.
Right now, there aren't even standards for basic things like borders and padding, and which animations are placed where in the image or how many frames per animation. This makes it hard to use varied monsters in a game. We have to move things around in an image editor. We could add a whole database to tell us this stuff for each image, but that is a lot of work, and leads to inconsistent capabilities with each monster. So what the actual standards are is less important than that there are standards.
As far as dimension standards go, yes we don't want to be restricitve. But I'd really like to see some bigger enemies! William's wolf for example is what I'm currently planning to use for my LPC demo game. But I wish it was even larger.
Yes for movement we definitely want at least 4 directions. For battle, one or two directions might make sense. Front view, side view, or both? Or do we really want all 4 directions so that enemies can directly battle in any direction right on the map? The more directions, the more animations, the more work.
But I want to hear what the community thinks, especially the artists, not to impose anything.
This is really cool. i did not anticipate anything like this when a JSON import/export feature was requested for the LPC spriteheet generator. Thanks for showing me what could be done with it!
its plugins are native blobs, aren't multiplatform at all (they are actually Windows DLLs,
No actually they are browser JavaScript source code. In text files. They run in the browser on any platform. You are misinformed.
I don't want to be rude so I wont say "RTFM", but seriously, read the TirNanoG User's Manual that I've linked, you'll get answers to your questions there. I've thought all of these (and even more). These are ALREADY IMPLEMENTED.
Sorry, I assumed these were not possible when I read in your post that you had one layer, but I was wrong. Reading your manual, it appears you do have layers.
It is not clear to me from reading your manual how to put a tile on top of the player. Please explain, for example, how to make a bridge that the player could walk both on top of and underneath, in your manual. Or provide me with the link to the explanation.
An addition to the map section on how to do parallax mapping, animated tiles, and switching them during events would be nice.
I apologize for making you upset. My reaction to the use of C is based on my experience, but this is your project. I hope it proves to be great!
We now have a discussion for this idea.
See https://github.com/LiberatedPixelCup/Universal-LPC-Spritesheet-Character...
You're missing the point of the discussion, single files or multiple files, how do I know if an enemy supports an animation? I'm going to have to end up storing that info for each enemy. Especially if it's multiple files, the file won't even exist.
Let's not get too caught up on the wolf example. I put "run" in the special attack slot to be able to test it and I figured it could be shown during a wolf's special attack if I called it "trample" or whatever.
What I'm trying to avoid is to have a separate file for each asset or stuff encoded in metadata or even a whole database in my code telling me which enemy has which animation and how many frames it has. That is a large burden.
I'm totally open to suggestions.
@BenCreating Not all image loading libraries tell you the width and the height of the image its loading. Some are more concerned with being "easy to use" rather than "full featured". This is especially true of ones that leverage graphics cards and Direct3D/OpenGL/WebGL.
I think you guys all know that splitting png files up into smaller pieces reduces the compression ratio and increases the error rate. I could put up with that if it made things easier to program, but it doesn't, you now have to handle the file not found error and you don't know if the file failed to load or it just doesn't exist because the animation isn't supported for that enemy/variant.
Whether we call it a standard or a convention, if a few enemies get made in a particular way, it is likely that enemies made to follow will use the same format. So I'm happy to call it a conventional format.
I think having both a "special attack" and auxiliary slot as MedicineStorm suggested is great way to ensure people can use a custom animation.
I propose that if an artist does not want to provide an animation, just fill in the slot with static frames.
Here is what I've done for William's wolf :
I've named the file wolf_64_5.png to indicate that frames are 64x64 and animations are 5 frames. The convention could be that enemy_96_4 would have 96x96 frames and 4 frame cycles. If a particular animation does not use all frames, static frames should be added.This shuld be a good comporomise between the needs of flexibility and the needs of programmers to not have to keep a database of what images have what animations and where.
Animatino slots:
1. Walk - used complete 5 frame walk animation
2. Attack - used complet 5 frame bite animation
3. Idle - no animation here; filled with static frames
4. Taking damage - used 3 frame animation, then 2 static frames
5. Death - used 4 frame animation, preceded by 1 static frame
6. Special Attack - I put the running animation in this slot, complete 5 frames
7. Auxiliary - I put the howling animation here, preceded by 1 static frame
Yes and no. For example it was suggested by @BenCreating that movement animations should be only 4 frames. William's wolf for example, has 5 frames. It is very hard to make it 4 frames. It would also be very hard to make it 6 frames. If I want a bunch of enemies, for programming purposes, it's much easier if they all have the same number of frames but changing the number of frames is very difficult. The number of frames per animation could be different on a per animation basis, similar to the characters. But it would be easier for programming to make it more strict, to just say 4 frames for every animation. I'm tempted to make it 5 frames so I can use the wolf.
Hi, could you explain the Soundimage International Public License and how it differs from CC-BY and OGA-BY, which also are free to use and require attribution.
Talking to @JaidynReiman, he feels that making enemies might be more difficult than making regular characters becuase we are not building on a common base. Do artists here agree?
I was thinking at first we let some people submit some stuff and then deciding whether a "character generator" is even the right thing for enemies.
Right now, there aren't even standards for basic things like borders and padding, and which animations are placed where in the image or how many frames per animation. This makes it hard to use varied monsters in a game. We have to move things around in an image editor. We could add a whole database to tell us this stuff for each image, but that is a lot of work, and leads to inconsistent capabilities with each monster. So what the actual standards are is less important than that there are standards.
As far as dimension standards go, yes we don't want to be restricitve. But I'd really like to see some bigger enemies! William's wolf for example is what I'm currently planning to use for my LPC demo game. But I wish it was even larger.
Yes for movement we definitely want at least 4 directions. For battle, one or two directions might make sense. Front view, side view, or both? Or do we really want all 4 directions so that enemies can directly battle in any direction right on the map? The more directions, the more animations, the more work.
But I want to hear what the community thinks, especially the artists, not to impose anything.
This is really cool. i did not anticipate anything like this when a JSON import/export feature was requested for the LPC spriteheet generator. Thanks for showing me what could be done with it!
No actually they are browser JavaScript source code. In text files. They run in the browser on any platform. You are misinformed.
Sorry, I assumed these were not possible when I read in your post that you had one layer, but I was wrong. Reading your manual, it appears you do have layers.
It is not clear to me from reading your manual how to put a tile on top of the player. Please explain, for example, how to make a bridge that the player could walk both on top of and underneath, in your manual. Or provide me with the link to the explanation.
An addition to the map section on how to do parallax mapping, animated tiles, and switching them during events would be nice.
I apologize for making you upset. My reaction to the use of C is based on my experience, but this is your project. I hope it proves to be great!
Pages