LPC Enemies?
I noticed there is no concept of LPC enemy sprite sheets yet. Enemies are typically drawn as large or much larger than battler sprites in games. Smaller ones for when there are multiple enemies on the screen, and larger ones for bosses. Unfortunately, most (but certainly not all) of the pixel art enemies I see on OpenGameArt.org are much smaller than the LPC sprites, and the "bosses" look puny compared with them. We would need to somehow have standards for enemy sprites while not restricting their size too much. They need to be "in scale" with LPC sprites.
For example in RPG Maker MZ, battler sprites are typically 32x48 while enemies range from 64px to 384px in both width and height and are often of odd sizes.
Our enemies could be animated! But they typically require only one or two attack animations, and the types of attacks can be varied. A combat idle animation, a spellcast animation, taking damage animation, and death animations would also be nice. I'd also like to see a standard four direction walk animation for those who want to have their enemies wander around their maps.
Another open question is whether enemies should be front view or side view (facing right, typically). We could have both, but that is double the work for artists.
Enemies typically do not need clothes / equipment. Variations on an enemy, however are common. Usually recolors, higher strength versions, different sizes, etc.
While we could use the character generator, there are some downsides. First, most of the animations provided are unnecessary. Second, enemies often have special attacks. Third, enemies would be needlessly restricted to the same size as the battlers. Fourth, they would generally be humanoid in shape.
I think there is a concept for enemy sprite sheets, but it may not be a very robust concept. The LPC enemies generally do not need any equipment or clothes, as Guarav says, so they are generally simple animations + North,South,East,West facing frames. To illustrate Guarav's point: Non-humanoid LPC monsters
A few other enemy spritesets are more involved, such as William's wolf but, as Guarav says, most of the more complex enemies are humanoid, like a goblin or minotaur which are modifications of the LPC character base. Not a bad thing, but also not the kind of enemy that adds a lot of diversity to the foe list.
I don't have very good answers to these questions, but I am very interested in the discussion:
SpellcastingSpecial Attack,--Medicine StormI 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.
HTML5 Canvas Old School RPG
In terms of Animations:
- Moving
Obviously this is pretty standard.
- Idle
Not really necessary for the most part, but it could be a simple bob.
- Taking Damage
Hard to say. Taking damage might be useful, but it can be reflected with a red overlay or something like that as well. We don't necessarily need a "I took a hit" animation.
- Death/defeat
Similarly, not really necessary for enemies. Typically enemies just "fade away" when being defeated. This is not necessary and completedly optional.
- Basic Attack
- Spellcasting Special Attack
At least Basic Attack is obvious. A special attack isn't really all that necessary.
- Optional Auxiliry Action (just a slot for an additional attack or atypical feature. many monsters won't use this slot but it's available if needed)
I'd argue this would be the "Special Attack". Not sure what else would fit this category.
4-directional attacks would be nice, but isn't necessary.
I think overall, people just haven't been as interested in making enemies. Personally its the same for me. I haven't even theorized much on how much non-human enemies I would want anyway, but it is something I need to explore more.
Its kinda hard to set a standard with an open format. The best thing to do is to probably commission a few extra things. See if anyone is interested in taking commissions for LPC style enemies and making them larger.
~~~~~~
Follow Me:
https://www.twitch.tv/jaidynreiman
https://www.youtube.com/jaidynreiman
https://github.com/jrconway3
https://ko-fi.com/jaidynreiman
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?
HTML5 Canvas Old School RPG
Yeah that's basically my thought. And there's no realistic solution to that problem. Because there's no way to make a "base" you can build off of, you need to create a lot more stuff from scratch to create a variety of unique enemies.
Sure, you can create new Wolf variations, but its hard to make something brand new out of that. Maybe something like a Cerberus or Hellhound could be a wolf variant, though. So there are ways to make some potential varieties from existing assets, but you can't make a slime from a wolf. Or a proper minotaur. (Best bet for a Minotaur right now is using the Minotaur head on character sprites.)
Using character sprites for Goblins and Orcs helps to reduce the requirements a bit, but then they're a lot smaller than a common "enemy" sprite you might see in other games. Creating a larger one effectively requires you to, again, redraw it from scratch.
And that's not even delving into big ones like dragons or other such things.
~~~~~~
Follow Me:
https://www.twitch.tv/jaidynreiman
https://www.youtube.com/jaidynreiman
https://github.com/jrconway3
https://ko-fi.com/jaidynreiman
The character base conventions are useful because the assets are modular and can be combined in interesting ways. That’s not the case for the current enemies/monsters. You could establish some very simple conventions, like the order the animations and directions (N/E/S/W) should appear but beyond that…
I think the humanoid monsters are basically solved. You can draw new heads easily and place using lpctools (soon to all the new frames too once Jaidyn figures out the offsets). Tails, wings, etc. can be placed similarly. New body types that still have the same basic proportions (and thus can use the same weapons, accessories, etc.) are conceivable (e.g. leshen, rock elemental, etc.).
I could imagine making some modular monster assets! You could have body shapes (e.g. canine, dragon, equine, etc.), different types of heads, feet/hoofs, wings, etc. But it would probably require some thought and experimentation to figure out what could be readily combined. But might be neat to try.
Some other more complicated but not quite humanoid LPC-style enemies (in addition to the wolf):
https://opengameart.org/content/lpc-imp-2
https://opengameart.org/content/flying-dragon-rework
https://opengameart.org/content/lpc-golem
Adaptable to LPC style:
https://opengameart.org/content/plant-and-mushroom-enemies-charset-and-battlers
https://opengameart.org/content/slime-monster-pixel-art-for-top-down-rpg
https://opengameart.org/content/pixel-predator-plant-mob-character
Other than the direction order that bluecarrot mentioned, I'd add a couple of things to the list of conventions that improve the ease of using and editing spritesheets:
The animations required will depend heavily on the type of monster. My recommendation for the basics is: movement in all four directions, and at least one frame for dying/death.
It might be possible to create several enemies of similar size from the same base, provided they use the same type of movement. For example, with a head, tail, and color swap I think we could get an okay lion out of the wolf.
If anoyone does want to create completely new monsters, I suggest using as few frames as possible. A 4 frame walk cycle, 1 frame death, 2 frame attack, etc. Fewer frames means less effort to create a derivative, which leads to a much wider variety of creatures.
Well, yeah. Any action can be represented simpler than the standarts suggest they could be. The only thing neccessary for a monster "animation" is a single frame of the monster. Idle: that one frame. Taking damage: That same frame replicated, but flash it white on the second frame. Death: Same frame, but red, or with a code-side dissolve effect. Movement? Just use the one frame, but implement code that bounces the one frame along like a south-park character.
I don't think these standards are defining the minimum complexity that each monster should have, are they? Artists aren't required to do extra work to fill out every animation action slot for every monster just because the slot is there, are they? I assumed these standards would just be a common outline for how the monsters should be organized. On the other hand, anybody that wants more animations/actions than the standards account for would be breaking standards. Meaning, any developer wanting to use that non-standard monster would have to go rework their code because they coded their animation engine according to standards that don't account for anything but the bare minimum. For example: The original LPC guidelines don't account for climbing, archery, jumping, etc. I'm not suggesting we rework all LPC assets to include those neccessarily, but they have since been popular requested additions, and it has caused a lot of difficulty incorporating them retroactively (such as to ULPCG) because there's no standard place for such additions.
"Special attack" isn't going to be used by all monsters, but there will certainly be enough monsters that do have more than one attack. If a given monster doesn't use it, just replicate the "Basic Attack" frames in that slot. Similar situation for "Auxiliary Action". It could be a 3rd attack, or it could be a special mutation animation for Boss monsters: "this isn't even my final form!" It's just a catch-all slot for anything the monster concept needs but the standards don't otherwise have a place for it.
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.
--Medicine StormYes 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.
HTML5 Canvas Old School RPG
To be clear, I was not advocating that we make 4 frames the standard. I certainly do not think we should make every animation use the same number. There is absolutely no reason a basic idle needs as many frames as a walk cycle or an attack. The number of frames required will vary from creature to creature and animation to animation.
I think it might help to define a little terminology here. A standard is a requirement that must be met to be considered compatible with LPC. A convention is a common practice that most artists follow, but is not required.
The original LPC guidelines set standards for perspective, sprite size, and shading, but only set two standards for animations: the vertical layout of the spritesheet, and what order the directions should appear on the spritesheet. They provide example spritesheets that follow the standards, but the spritesheets themselves are not the standard.
The convention has been to use the Universal LPC spritesheet for humanoid animations, which has made it difficult for new animations to be adopted. As a convention, it has been a net good for the LPC community, but as a standard it is too restrictive.
I don't believe we should set standards for animation lists or frame counts. Those will vary based on the needs of each monster, and requirements of the artist (or the person commissioning the artist!) for their own game.
My suggestion of 4 frames was meant as a reminder that the first new monster in a category will set the convention for sprite size, frame count, and default list of animations for all derivatives. Just like making the wolf's walk cycle longer or shorter, it will require significant effort to change them later.
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
HTML5 Canvas Old School RPG
If your code plays all 5 frames (even for animations that weren't originally 5 frames long) you will have odd timing and hitches in your animations, especially animations that are meant to loop. For example, the walk animation is actually 4 frames long. The first frame is the stand/idle. Play it back with and without that frame. Which is a smoother cycle?
Putting the run in the "Special Attack" slot defeats the purpose of a standardized animation order. Your code would need a special case for it.
It seems you and I approach this problem very differently. I would use a separate image for each animation. They would be stored in a standard location. For the wolf, the file path would look something like this:
./resources/images/animations/wolf/walk.png
The only thing that ever changes in this file path is the name of the creature and the name of the animation.
My code needs to store what animations each creature has. Even if all the animations were in a single image, I would need to know that the spider has no auxiliary action, or that the wolf has a run in the special attack.
I don't have to store the number of frames in an animation. I can get that by dividing the width of the image by the frame size.
I would probably store the frame size as an integer. I'm already storing the available animations, so it's not much more effort to store that too. Though, as a side note, it would be possible to calculate it by dividing the height of the image by 4.
Yeah I don't like the format for the "special attack" being "run" either. It doesn't make any logical sense. Run should be a separate action. If you REALLY want consistency, what you should do is set run as a separate action, and for other assets you use, simply insert the walk animation for a missing run animation. Alternatively, if you keep them in separate files as BenCreating suggests, you can just check if a run file exists, and if it doesn't, only use walk.
I didn't catch it, but yeah, the walk animation is actually only 4 frames, not 5. Its 1 stand frame and 4 walk frames. 4 frames is actually pretty standard from what I have seen, I think classic RPG Maker uses 4 walk frames as well.
If anything, I think "howling" makes more sense as a "special attack". But that's up to you. I could see a magic wolf enemy use a howl for a spellcast of sorts (or for a special action; wolves in RPG's often use howling for a support buff), otherwise it could just be a taunt.
~~~~~~
Follow Me:
https://www.twitch.tv/jaidynreiman
https://www.youtube.com/jaidynreiman
https://github.com/jrconway3
https://ko-fi.com/jaidynreiman
I think I understand now. In which case, it seems like any animation that could possibly be optional should be a separate file. However, I can imagine monsters where even the "move" animations are optional: ie a poison spine shooting killer plant. Doesn't move, but has a ranged attack. This is a fringe example, admittedly, but it does make me wonder: what animations, if any, should be together in a single file, then?
--Medicine StormLet'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.
HTML5 Canvas Old School RPG
Here are the advantages I see for both multiple and single files. Am I missing anything?
Single file:
Multiple files:
My biggest concern with the single file approach is how to handle non-standard animations. Do they go in a slot meant for another animation? Are they added to the end after all the other animations? Do we put them in a separate file?
I believe non-standard animations will be the rule, more than the exception. An ostrich could have walk, run, and glide animations. A penguin could walk, swim, and belly slide. A dragon could have claw, bite, fire, and tail attacks. A bear can have two of every animation: once on all fours, and once standing upright. Will a single file have slots for all of these things, even though most creatures won't use them?
@Gaurav I'm happy to discuss implementation details, but I think I'd need to see your code to be of any help, and I don't want to derail the thread.
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.
HTML5 Canvas Old School RPG
True. That's a problem for all conventions we've discussed so far. What about a JSON file included with each monster's spritesheet(s)? The JSON file would indicate what animations are supported, regardless of composite- (single file) or separate- (multiple file) animation spritesheet conventions. If separate data files give you the ick, how else would a game engine dynamically recognize the presence or absence of an animation? And would that be less cumbersome?
--Medicine StormMy preference is a lazy artist is always to put everything into one file while working, since animation invariably involves copy-pasting between various frames (even between different animations). That said, it is trivial to split an image into multiple images at the end, and that seems like the most straightforward approach (combined with some documentation of the frame size/count) to make the images easily understandable. Again, I don't see how it is feasible to standardize the types of animation, number of frames, etc. at this stage. The monsters are just too diverse, like Ben said, and I don't think we have enough examples to make a useful prediction or declaration about what's needed. For the attacking missions that I drew, I used 6 to 7 frames depending on how the animation looked. The frame size for the monsters already varied from 32x32 to 128x128; I used the same frame size as the existing idle/move animation.
I recognize Gaurav's concerns regarding the complexity of storing/encoding asset metadata, optimizing file size, etc.; I'm not a game developer so I can't speak to that specifically, but I suspect it cannot be entirely solved or avoided simply by convention in a way which will be useful to everyone. I'm not persuaded that artists should change the way assets are drawn or formatted for the sake of compression ratios; that is a development concern which should be addressed using appropriate tooling (for instance using a texture atlas packer). For what it's worth, Pierre didn't seem to have any trouble using the monster animations, as I drew them, in Vagabond. I believe Pierre re-packs (using a simple script he wrote) the humanoid character LPC spritesheets to reduce empty space, and he might do something similar for the monsters. That works well with his engine and addresses his needs; others might not want/need to bother depending on their considerations. As an artist, I certainly would not want to work in this compressed format.
So to summarize, I would propose artists do the following:
1. Use a single frame size for all animations of a given monster, if possible
2. Arrange frames of a given animation left-to-right
3. For a given animation, stack different directions top-to-bottom in the following order: North, West, South, East
4. Provide one file per animation (preferred), or stack animations from top-to-bottom (rather than left-to-right)
5. Clearly document the frame size and intended animation sequence (if it is not obvious; for instance, if certain parts of the animation should loop). This can be done by means of a Tiled tsx file (my preference) and/or a description in plain text.
Oh, that's very interesting. No mention of number of frames, (intentionally, I assume) so the frame count can vary as required; the width of the image will simply be wider if more frames are needed. I can't speak to other dev's needs, but I am a Dev, not an Artist, and I can say for me personally those 5 convention rules would make it quite easy for me to dynamically load animations, without the need for custom sprite-specific code handling.
If frame[i].X + frame[i].width > spritesheet.width Or frame[i].isAllTransparentPixels {set LastFrame = i - 1}I also agree with size optimization needs being a developer task, not an artist task. sprite-packing is highly engine-specific, so trying to pre-empt that step is more likely to increase work for the developer.
--Medicine Storm