$12256 / $11500
As a discussion with @bluecarrot16 went on here, I've realized I'm not the only one frustrated about the many incompatible LPC forks and unnecessary duplications, so I think this topic deserves more attention.
There I wrote
And maybe it's time to join efforts and create a standardized, LPC-NG specification and collection, and make the other forks read-only? (Or at least give a big red warning something like "For LPC assets submitted after 2022-XX-XX, please use these guides (link) as well as these collections (link) and the LPC-NG tag", something like that). I understand that converting everything to this new LPC-NG standard is a HUGE task, but I'm 100% certain it needs to be done, and sooner the better. Any delay will just make this harder and would allow even more new incompatible forks to be born.
I'm volunteering to collect the best aspects and practices from all existing forks and write a detailed, well-defined updated style guide for the benefit of designers as well as for game developers. (I've many years of IT management experience, so I'm perfectly capable to organize this, plus I think this is going to be fun and very beneficial for everyone). I personally think up to this date @ElisaWy's "LPC revisied" is the best, most well-thought revision of LPC, so I would like to use her guides and palettes as a base for the new style guide, but I would like to hear your opinions too what else should be considered.
To make it clear, I'm not talking about creating yet another LPC collection, I'm talking about creating a new, detailed LPC style guide (a HTML page), which hopefully could one day serve as the rules for the new, advanced and compatible LPC-NG collections.
I'm thinking about include things such as: expected perspective; angle of light and drop shadows; what animations are supported; if those are merged into a spritesheet then what layout should be used; standardize the pixel coordinates for the head, hands etc. so that the compatibility of assets is guaranteed etc. There's nothing new in these really, you can find this information spread wide in form posts (sometimes multiple times, in an incompatible way sadly), what is going to different that I want to collect all of these into a single, coherent, convenient and easy to use LPC specification.
What do you think?
Cheers,
bzt
PS: after voting, we've settled with the LPC-Refined tag.
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
This sounds like a good idea. I found while trying to build my centipede that there was not single guide on what exact prespective to use, as well as things such as lighting or pallete choices, so I had to resort to asking a bunch of questions here. It would be very usefull to have a universal guide, especcially for those trying to start making assets in that style for the first time.
Another suggestion is to compile together all the colors from LPC submissions and make a complete pallete, as well as a guide for the subpalletes used for different materials. Such as types of wood and stone.
I'd also love to see ElizaWy's LPC Revised be merged back into the main fork, maybe by mixing her expanded palletes into existing assets.
What do you mean by read-only? If you mean to take down these assets then I disagree, as different games may decide to go with different levels of consistency, and those assets could be useful.
Another thing that's been discussed before is also making a LPC specific license, which would possibly allow a user to just credit everyone who was submitted to LPC instead of having to figure out who made what. For instance, having a LPC Universal license, basically CC-by-SA, but allows you to just copy-paste a full list of LPC contributors. As well as having a LPC Individual license, which asks for individual credit if you use that asset, but reverts back to LPC-Universal once remixed.
Going off of the original LPC style guide, what sort of additions would be made? I realize expected perspective, angle of light, drop shadows, palette, and animations were mentioned, but those are already mentioned in the LPC style guide. I assume you're saying it is missing more specifics of those features, yes?
what does LPC-NG stand for? Liberated Pixel Cup N____? G____?
There cannot be restrictions imposed on what others are allowed to do with LPC assets under any fork. You may encourage buy-in and agreement to follow a stricter set of guidelines, though. You can create a ("yet another") curated collection of LPC assets and only admit the content that meets certain specifictaions as well, but you wouldn't be able to stop anyone from making derivatives that don't follow those specifications and you wouldn't be able to stop such derivatives from being widely adopted if the community happened to prefer them. This is a bit of the XKCD Standards conundrum:
I don't understand how a LPC-specific license would help the issues outlined. CC-BY-SA, OGA-BY, and GPL (the most common licenses for LPC content) already allow you to copy-paste a list of all-LPC-contributors-ever* for attribution. The Universal character generator already does this under the terms of these licenses; you can either attribute every contributor who has added to the generator's content, or just the specific contributors who made the components of the character you've made. How would a new license allow you to credit authors more easily?
*Such a list is always growing. There could not be a static place to copy the attribution from. It would have to be dynamic and curated to include new authors as they contribute content.
--Medicine Storm@FiveBrosStopMosYT: "What do you mean by read-only? If you mean to take down these assets"
Nope, read-only does not mean "take down these assets". It means they should be left still accessible (or with other words, "readable"), but further modifications using their incompatible guides is strongly discouraged and instead designers are advised to use the new updated guide and expand the new, compatible and standardized collections instead. Of course this is just a suggestion, they can still expand the old collections, just be aware that their work might be futile.
"I'd also love to see ElizaWy's LPC Revised be merged back into the main fork, maybe by mixing her expanded palletes into existing assets."
Merging back is not going to happen, and it is not even possible because Eliza's set is superset of the original. The one and only meaningful way is to merge the other sets into Eliza's set by providing the missing parts and animations for those older sets.
@MedicineStorm: "Going off of the original LPC style guide, what sort of additions would be made?"
The ones that I've mentioned. Most notably spritesheet layout guides, assets layering guides, positioning guides, modularity guides, expected animations guides etc., all the things that the current style guide lacks (and which are spread wide on these forums somewhere). ATM you simply can't create a compatible asset set relying on the LPC style guide alone, and that's the very reason why there are so many incompatible LPC forks.
"You may encourage buy-in and agreement to follow a stricter set of guidelines, though."
That's exactly what LPC needs, and that's exactly what I'm planning.
"You can create a ("yet another") curated collection of LPC assets and only admit the content that meets certain specifications as well, but you wouldn't be able to stop anyone from making derivatives that don't follow those specifications and you wouldn't be able to stop such derivatives from being widely adopted if the community happened to prefer them."
I've made it clear I'm not after a yet another collection. I'm after a new tag, to mark collections that fulfill the requirements of a more strict LPC specification, and hence guarantee interoperatibility and interchangeability. Right now there are a miriad of incompatible collections, all tagged with the same "LPC" tag, which is not good and extremely contra-productive.
"what does LPC-NG stand for? Liberated Pixel Cup N____? G____?"
It looks like you're not a sci-fi person, and you haven't heard of Star Trek :-) It's an acronym for "Next Generation". But that's just a suggestion, LPC-S (as in "Standardized") or LPC2.0 are just equally as good. The actual tag doesn't matter, what matters is the fact that you can filter standardized collections tagged with it.
"I don't understand how a LPC-specific license would help the issues outlined."
For example ElizaWy is only allowing OGA-BY licensed material in her LPC Revised collection. Limiting the license to one makes things easier sure, but I agree with you, I also think OGA's collection credits feature is good and more than sufficient. I wouldn't want to limit the licenses for LPC, other than the license must be FOSS.
Cheers,
bzt
Ok, I see want you mean, bzt, thanks. :)
@MedicineStorm
Ok, I didn't know you could do that with OGA-By and CC-by-SA, thanks.
The things it lacks include the complete works of Shakespear, the French Declaration of Independence, and my dog. For wanting to make the specification more specific, the end of this sentence is ironically vague. I want to know what else you feel the current guide lacks. However, I agree with all your suggestions preceeding it. :)
Oh, ok. That makes sense.
CHOLEGH! I know every episode by heart! but "NG" is not ubiquitously applied to situations like this to warrant recognition. For example, if I said FRoA #208, you wouldn't just know what that is without context, hahahah! Regardless, I'd recommend something that implies a different standard, not a new version of the old standard. LPC-S1 or something.
Thanks. That answers my questions. :)
--Medicine StormI agree MedicineStorm, we should put your dog in the guide.
@MedicineStorm: "The things it lacks include the complete works of Shakespear, the French Declaration of Independence, and my dog."
No, not at all. But I can only give you examples, because providing the full list would equal to providing the final specification, wouldn't it? ;P So here's a specific example: the style guide lacks spritesheet layout guide. If you're lucky, then you can find this image buried deep down in the forum, but even though that's the best I could find, sadly it is not up-to-date and does not match most of the submitted assets. Such a layout guide (describing the layout that submissions are actively use) should be on the LPC style guide without a doubt.
"Oh, ok. That makes sense."
Right? I think the best would be if only a moderator could add such a tag after a through validation process, but that would result in an extremely huge workload for the moderators. So instead I'm counting on the open source community's values and good-will, the designers doing self-validation by their best knowledge before adding the tag and listening to the comments and fixing the set if something doesn't comply. Yes, this means trust is required from the community, but based on my experience with this community that should be perfectly fine.
"CHOLEGH! I know every episode by heart!"
I had a feeling that you do, and sorry for the joke I did not want to offend you in any way.
"Regardless, I'd recommend something that implies a different standard, not a new version of the old standard. LPC-S1 or something."
Yeah, that's "LPC-S1" is good too. But I'd argue that this would be a new standard, because it's not, it would be based on the actual submissions. It's just a revision of the original with more specifics to provide more coherent assets, eliminating the chance of incompatibility.
Cheers,
bzt
Oh, pah! You can ignore my Klingon yelling. I assumed you meant that as a light-hearted joke and my response was intended in the same spirit. I wasn't offended at all, just joking back. :)
Surely not. If someone asks you what a book is about, you don't recite the entire book to them, do you? A full list of things you want included doesn't need to include the full details of each item on that list. That being said, your specific examples all make sense and are starting to form a more complete picture. Thanks.
That animation guide is indeed buried in the forum, but what does that guide show that the animation base character guide in the LPC style guide not show? I'm NOT saying "you don't need that other guide", I am trying to understand the gaps that need to be filled.
--Medicine StormP.S.
It's actually easier than you think. Any newly created tags (so created by simply adding them on a submission) are breifly reviewed. If they're effectively nonsense or don't contribute to helping people search for assets, they are deleted. Examples include "My cool game", "this sux but its free", "Art" (everything is art here), "Music" (we have searchable categories. no need to clutter it with category tags), "CC0" or "Public Domain" (again, we have license categories already) So long as I know why a new tag like "LPC-SX" or whatever is added, I make sure it isn't marked as pointless. If other people start adding random tags like "LPC-454885" with no real comformity, they'll get cleaned up.
--Medicine Storm@MedicineStorm: "what does that guide show that the animation base character guide in the LPC style guide not show?"
Again, it's easiest to explain through an example.
First, that style guide has multiple NAMED animations. Which is great, because is makes it clear that a melee attack animation should be called "slash" and the file "xxxx_slash.png" or something. But, it does not list all animations that are typically used (for example "thrust", which is another melee attack animation commonly used with LPC and "bowing" is missing. Or should that latter be called "archery"?)
Second, almost none of the LPC submissions use that one-animation-per-file scheme, you can't see any "xxxx_cast.png" in them for example. Instead, there's only one big image. Just take a look at Sara. How should we supposed to know which animation is which without a guide? Is the first one the "hurray" animation? The style guide does not help us here at all. (The LPC layout is already in your blood, but think about newcomers who have just read the style guide and see SaraFullSheet for the very first time.)
"It's actually easier than you think. Any newly created tags (so created by simply adding them on a submission) are breifly reviewed."
That's great news. But I think doing a through verification is still too much to ask from the moderators. A quick check is fine and appreciated, but the submitter should self-validate their submission in the first place, and commenters should point out if compatibility is failing somewhere.
BTW, after long consideration I ended up with the LPCERT or LPC-CERT tag (Liberated Pixel Cup Certified). This expresses that it's based on LPC, but also that the submission follows a stricter set or rules/guidelines which guarantees compatibility. What do you think?
Cheers,
bzt
Sorry if the following seems pedantic, but my impression is that you're unaware of some of the history and origin of the LPC collection assets, so I thought I'd clarify a few things.
The original LPC was an art and game development contest, for which some base assets were provided by OGA. The LPC style guide and descriptions refer to those original assets. As part of the composition, some additional animations were provided, the "thrust" and "shoot" animations were added later.
After the competition, the diverse set of character bases and assorted assets were combined in a "unified LPC spritesheet", which is a GIMP .xcf file with all/many available (at the time) assets in different layers. This inspired the online "universal spritesheet generator", of which various forks exist, with Castelonia's being the most complete, up-to-date and well-maintained one. Most assets created after the universal spritesheet was created are made to be compatible with it.
Some existing animations are not part of the universal spritesheet and as a result they lack assets. This includes a grab animation, the jump animation and the running animation that were contributed later. Eliza did include the latter two in her revision, but they exist based on the original bases.
I'm also experiencing a sense of deja-vu. You bring up some good points: yes, the LPC assets need to be more clearly specified, it's all scattered around at the moment and things like intended frame timings, windup/cooldown/repeat frames are burried deep. It's somewhat hard to find that the 9-frame walkcycle is actually a 1-frame idle and 8-frame walk cycle. Guides and references aren't easy to find in a single location and style. The thing is, this was all discussed on the forum here a while back, with bluecarrot16, Castelonia, ElizaWy and several others contributing their input. It feels like many of the points discussed there are going to come up again, and so it's probably a good idea to dig out that thread and use it as a starting point.
@Evert: "The original LPC was an art and game development contest, for which some base assets were provided by OGA."
That might be true, however I quote from the LPC style guide
ATM LPC falls short on that premise, and the clear indicator of that is the many incompatible submissions and forks (and you're right, this is mostly because lots of things were added later, therefore aren't defined in the style guide).
"It feels like many of the points discussed there are going to come up again, and so it's probably a good idea to dig out that thread and use it as a starting point."
Absolutely. I don't want to reinvent the wheel, far from it. I've already started to read through the forum, check existing LPC submissions and collect everything into one place, merged together into a single, coherent, easy-to-follow specification. I'm also planning to use ElizaWy's competition winner LPC Revised as base, because it has all the required animations and her guides provide exactly what's needed to maintain asset compatibility.
I'll present the first draft as soon as possible, and since I'm certain there will be things that escape my attention I'm counting on you (in plural, including bluecarrot16, Castelonia, ElizaWy etc.) to review it.
Cheers,
bzt
See also https://opengameart.org/forumtopic/curated-lpc-collection-project
--Medicine StormFirst draft awaiting your reviews!
https://bztsrc.gitlab.io/lpc-cert/
I've lifted everything from the original style guide, and added a great deal of descriptions about the characters.
What's missing:
@MedicineStorm: thanks, I know about that.
Cheers,
bzt
That looks amazing, Bzt! ... Honestly, I wish I had that compiled when I first started working with LPC. The original style guide wasn't nearly as thorough.
As soon as the animation standards are in, I'll be happy to link it in my LPC repository.
@ElizaWy: "That looks amazing, Bzt!"
Thank you very much, I'm really glad you liked it!
"As soon as the animation standards are in, I'll be happy to link it in my LPC repository."
That's very kind of you, but I'm afraid I have to ask you to wait a bit more. In order for this specification to be actually useful, I'll have to create the lpc-guides.zip as well. BTW you can help me with that if you're willing to upload your guides to your repo as soon as possible (in advance, before you're ready with the actual animations).
So, about the animations, here's my current proposal:
Mandatory animations, required from every submissions, because these are needed by all games anyway: "cast", "thrust", "walk", "slash", "bowing" (so far the same as the current), plus "sit", "run", "jump" (seems like these were already planned just not made it, but now we have these too thanks to Eliza).
About "hurt", I propose to expand it in all 4 directions, and rework just a little so that the first few frames could be used as "hit" (taking damage), otherwise the purpose would remain the same. This is the biggest change to the current LPC spritesheet, so I would really like to hear everyone's opinion about it. I think this is reasonable, but I'm a developer, not a designer.
Optional animations would be the ones that are nice to have, but not needed by all games made with LPC, therefore submissions without these could still get the LPC Certified tag: "idle" (with more than 1 frame), "block", "climb", "push", "grab", "lift", "carry".
The dilemma we're facing here is as follows: the less animations we make mandatory, the easier expandable LPC will be, however the less useful it becomes for actual games. On the other hand, the more animations are mandatory, the more useful and tempting to be used LPC becomes for games, but makes creating new assets (and porting the older ones to this new version) lot more difficult. As a reminder, ALL assets must have compatible sprites for every mandatory animations in every directions; if even a single sprite is missing, the entire asset set is totally unusable in a game. That's a considerable amount of work.
To solve this dilemma, we should find the balance and decide the right amount of animations. What you see above is my proposal, based on what we have now, but I would like to hear your opinion about it. For example, should "block" or "climb" be moved in the mandatory category? I have no right to make such decisions because I'm not the one drawing the LPC assets. I'll respect what you choose and I will update the spec accordingly of course.
Cheers,
bzt
Re: animations: I think it should specify humanoid character animations. Most of the monster animations don't apply, nor would animations like water or a door opening.
--Medicine Storm@MedicineStorm: "Re: animations: I think it should specify humanoid character animations."
Yeah, obviously.
"Most of the monster animations don't apply"
I've explicitly mentioned in the spec that NPCs aren't restricted. Meaning if they are modular and using the same guides that's the best, but if not, that does not influence LPC Certification.
"nor would animations like water or a door opening"
Which obviously doesn't belong under the "Characters" chapter. What do you think, should I put a section on animation under "Objects" too? I was thinking about that, but I don't see any compatibility issues with objects in the first place, since those aren't modular at all.
What do you think about expanding "hurt" in all 4 directions and using it as a combined "hit" + "die" animation?
Cheers,
bzt
I've played with a 4-direction hurt (I call it a death animation) before. There were some problems.
The biggest was that there just wasn't room to get knocked off your feet on the side views, if you're standing in the middle of a 64x64 square. You'd have to somehow fall in the middle of where you were just standing. Either you go to a crouch first, then go Splat!, or we'll have to require the user to move the figure left or right as they're falling a certain distance.
There is a precident for the latter-- the fighter game genre has plenty of these kinds of frames, and people figure it out. And it would read better using this method than a careful crouch-prone combo. It'd need to be carefully documented, though.
I'm not sure how you're going to set NPC character assets from PC assets, though. And I wonder if requiring all animations for all assets are really the way to go here.
@ElizaWy: "I've played with a 4-direction hurt (I call it a death animation) before. There were some problems."
I see. So separate "hit" (damage) animation it is then.
"I'm not sure how you're going to set NPC character assets from PC assets, though."
Isn't that obvious? How should i explain... Think about typical RPG game enemies: skeleton, orc, lizzardman, werewolf etc. (all of these supported by LPC). Which is simpler, drawing multiple variations for all of them (skeleton+sword, skeleton+axe, skeleton+bow, skeleton+mage hat, orc+sword, orc+axe, orc+bow etc. etc. etc.), or just using your guides for their base sprites once so that you can replace the weapons out-of-the-box in their hands? See what I mean?
"And I wonder if requiring all animations for all assets are really the way to go here."
Absolutely. Imagine for example the jump animation is missing for a trousers asset. How would that look like in-game? The player walks around with the character, everything is looking fine. Then they do a jump, at which point the character becomes naked, the trousers disappears. And then when the character hits the ground again, the trousers re-appears. This clearly won't work.
The problem is, if a game engine wishes to implement N actions, then it can only use assets that have animations for all those N actions. If even a single animation is missing, then that asset is completely unusable for that game engine.
That's why finding the balance and the right amount of mandatory animations is so important. Have too few: the game isn't enjoyable because actions are too limited (no jumping, no running); have too many: too much work for the designers therefore not enough asset exists to play with, and again, the game is going to be humdrum and not enjoyable.
This is the reason for creating "mandatory" and "optional" categories, to draw a line somewhere, which animations should exist for all assets. Currently we have cast, thrust, walk, slash, bow, hurt and this is clearly not enough actions, there's a need for hit, jump, run etc. but we can't expect that all assets will also have animations for climb, push, lift, carry whatever.
Cheers,
bzt
For the records, if we haven't had to think about already existing LPC asset spritesheets, and we were starting from the ground up, then I would start with the guides first (strictly specify layer joint points at first) and I would use this classification for the asset animations:
Tier 1: movement animations, both clothes and tools/weapons assets must implement all of these (walk, run, jump)
Tier 2: usage animations, clothes assets must implement all of these (cast, slash, thrust, block, hit), tools/weapons assets must implement at least one, depending on how that tool is used (magic wand = cast, sword = slash + block, spear = trust, shield = block etc.)
Tier 3: movement animations for which only clothes must be implemented, but it is okay if tools do not exists at all (die, climb, push, lift, carry etc.)
But we are not designing a new, we have a considerable LPC luggage, sort of technical debt because we must think about how to minimize the required modifications on the already existing assets to make them compatible.
Cheers,
bzt
Ok, I've created a sprite matrix for layers (asset's type) and animations to determine the minimum requirements. Please take a look.
https://bztsrc.gitlab.io/lpc-cert/#sprite_matrix
I've also rephrased some parts of the spec to make it clear that
-for NPCs not all animations are required,
-some of their layers might be merged, and that
-NPCs which aren't modular at all are not our concern (in lack of modularity there can be no compatibility issue).
TBH I don't think the sprite matrix makes any real difference: most of the layers requires all animations to be drawn: body, head, hair, cloth would all look strange with a missing animation. It is only the tools/weapons layer that can spare some sprites.
Cheers,
bzt
(This was written before you posted your draft; I will read it and comment on the substance of the discussion above later, but wanted to get these comments out before we get too much further along...)
I welcome the offer to build and document consensus and help guide our efforts. I'd like to make some suggestions about the purpose of this effort. Quoting from the original style guide https://lpc.opengameart.org/static/LPC-Style-Guide/build/styleguide.html: "The purpose of this style guide is to allow pixel artists to collaborate on a top-down set of artwork and produce content that is stylistically coherent ... we've intentionally built a style guide for artwork that should be easy to collaborate on for both intermediate and advanced pixel artists."
With that in mind, I would suggest a few overarching principles to guide this effort:
Should you embark on this, please be prepared for your draft to be modified or possibly abandoned, depending on how everyone responds. Plan for this to take a while and give occasional but substantial contributors some time to read and respond. Assume everyone is acting in good faith. Please approach this with some humility, understanding that there will be differences of opinion, mistakes, and genuine misunderstandings; also recognize that some of us have been working on this project for years, while others are just coming on the scene. As Evert says, many of the relevant issues have been discussed at length, so I would expect those participating in this discussion to at least try to familiarize yourself with that conversation. If someone says in response to your point, "that has been discussed before here: ____", please read the link before responding.
A few of these threads have been mentioned, but here is a more comprehensive "reading list" of threads where these issues have been discussed; these should absolutely be reviewed to understand how we got here:
Discussion of licensing that ultimately lead to the creation of the OGA-BY license:
Did you fork your guide on Git from the original? https://github.com/OpenGameArt/LPC-Style-Guide ; It would be helpful if we could see what has changed compared to the original. Is there a repository where we can eventually submit pull requests directly?
@bluecarrot16: thank you for your comments! I'm well aware of everything you've written. I think you've underestimated how prepared I am about this. I've offered my help only after I did my homework :-)
FYI, I think the original style guide is good on colors, lighting, tiles, projections and objects. I've haven't changed those in any way; I've added just one thing on objects, a section about layers, nothing else (I did not come up with that, this was already discussed in one of the forum topics, I just felt it worth mentioning). It is the characters section where the original falls really short, so my efforts are focused on that, how to create compatible character bases and assets.
My thoughts on your principles (TL;DR I agree with you on all of these):
"Coherence: the style guide should help create body of artwork that can be used together. This should be the primary and overriding goal."
100% agree, and this is what the original style guide fails to live up to. From the spec, Preface / Goal:
"Accessibility: the style guide should support ease and breadth of contribution to the body of artwork."
100% agree. I think the best way to do this, is having such guidelines that Eliza posted in her LPC Revised submission (animated contour, pantline, centerline etc.). Designers can load these as layers and turn them on/off to see if their work fits or not.
"Consensus: the style guide should reflect consensus among the community and not be dictatorial."
100% agree. That's exactly why I'm keep asking your opinion about things in this forum topic.
"As much as possible, it should reflect what people have already been doing, and if it makes prescriptive changes, it should do so for very clear and well-justified reasons that are broadly agreed upon."
100% agree. From the spec, Preface / Revisions:
"Flexibility: the style guide should only specify that which is necessary for coherence or interoperability."
100% agree, that's written in the spec's goal. And that's why I made it clear that for example NPCs which aren't modular, aren't the concern of this spec.
"Should you embark on this, please be prepared for your draft to be modified"
I'm not just prepared, I'm counting on this! I've kept modifying the draft and incorporated everything that come up in this topic so far.
"A few of these threads have been mentioned, but here is a more comprehensive "reading list" of threads where these issues have been discussed"
I've read all of these through, plus some others. I've already incorporated the conclusions from these topics into the spec. Let me know if I accidentally left out something.
"Discussion of licensing that ultimately lead to the creation of the OGA-BY license"
Yes, I'm aware and that is in the spec as well. It says if the LPC creators unsure which license to choose, they should pick "OGA-BY" (see Appendix / Licenses).
"Did you fork your guide on Git from the original?"
No. That's one unstructured page, my specification on the other hand is a readthedocs like, well structured, dependency-free html. (For the records, the spec's source is also in MarkDown files, but splited by chapters so people can more easily find things.)
Cheers,
bzt
Thanks bzt, glad we agree on most points. Again, I'll comment more on the substance a bit later. I take it this is the repo you are committing to? It's helpful to be able to track changes as they happen. https://gitlab.com/bztsrc/lpc-cert
@bluecarrot16: "Thanks bzt, glad we agree on most points."
Erhm, "most"? I think all... Did I miss something?
"I take it this is the repo you are committing to? It's helpful to be able to track changes as they happen. https://gitlab.com/bztsrc/lpc-cert"
Yes, that's the one.
src/ - directory where the MarkDown files reside.
src/zip/ - skeleton for the guides zip (WIP).
public/index.html - the generated specification, a no-server-component-parts single html file, which is accessible here (works as a local file too).
public/lpc-guides.zip - the downloadable, generated guides archive (WIP).
I'm planning to arrange ElizaWy's guidelines as seen on current LPC character sheets (same what ULPCCG creates plus the new animations), each guide on a separate layer. That, plus the palette guides will make the lpc-guide.zip. If there's anything else that could be helpful and worth adding, please let me know. (I'm deliberately not planning to add any actual base characters or LPC nudes, just the guides.)
Cheers,
bzt
I think the classic version of LPC characters and Eliza's have different vibes and one may be more suitable than the other depending on the game. Thus, I'm a bit uncomfortable with the terms "LPC Certified" or even "LPC Revised" for naming a fork which implicitly mean that the classic version is inferior. I would prefer a more neutral name like "Eliza's LPC".
Personally, I plan to continue using classic LPC assets in my game as I find them more suitable and there are more assets available. And if I need to commission new assets it would be for this base. I think you are underestimating the artist time that would be required to reach the number of assets currently available for the classic base for Eliza's. There are a very small number of skilled pixel artists active in the LPC community and I think this time would be better spent working on new assets than adapting assets for a new base.
So as far as I'm concerned, it's +1 for an updated style guide that takes into account all the evolutions and new practices in the community but -1 for using Eliza's base as a reference.
Finally, I briefly looked at your draft and I have a maybe controversial suggestion: artists should submit spritesheets with only 3 directions (north, west and south) and the sprites for the east direction should either be automatically generated by a script from the sprites of the west direction or generated directly in games. There is a large number of little inconsistencies between west and east directions in the assets and it would be good to have a workflow that prevent them in the future.
@pvigier: "I think the classic version of LPC characters and Eliza's have different vibes"
Sorry to say, you are confused and mistaken. Eliza's set doesn't have most of the animations (yet) or it has animations not in the original, so there's literally nothing to really compare (yet).
The few animations that you can actually compare, for example the "walk" animation, it only differs in a +/- 1 pixel offset shift, which does not give any "vibes" at all. I can hardly believe that you can actually see that 1 pixel shift.
"Personally, I plan to continue using classic LPC assets in my game as I find them more suitable"
Good luck adding "jump" or "run" into your game.
"but -1 for using Eliza's base as a reference."
That cannot be helped, that's the only one submission that actually has compatible heads and facial expressions, not to mention guides for future assets. All the former submissions are useless and incompatible in a real game, just try to use them if you don't believe me.
" I think you are underestimating the artist time that would be required to reach the number of assets currently available for the classic base for Eliza's."
And I think you're underestimating the usability of the current, incomplete and incompatible LPC set, and how much work it takes from the designers as well as from the game developers that ALL assets must be doubled (a male version and a female version of everything, just because one of the frame is 1 pixel bigger, smaller or just 1 pixel off...).
"Finally, I briefly looked at your draft and I have a maybe controversial suggestion: artists should submit spritesheets with only 3 directions (north, west and south)"
That's a TERRIBLE idea. It's not going to work, because left and right isn't mirrored sprites, and what's more it's not compatible with any of the existing assets either, not with the original LPC base, and not with Eliza's.
BTW, I've uploaded the first version of the lpc-guides.zip. Now you can see what LPC is really missing. If LPC ever wants to have compatible assets, the Guides.xcf in the ZIP has to be filled in entirely first (also available in the "Guides" directory, each layer as a separate PNG, should you not have GIMP installed).
EDIT: I've added Guides.psd in the zip as well for Photoshop people.
Cheers,
bzt
Here's a perfect example for you about the LPC asset compatibility problem I'm constantly talking about. Look how the helmet doesn't fit to the male base on the left. This, and the missing animations for certain assets makes the original LPC asset unusable in a real game.
This has to be fixed one way or another, without a doubt. And so far Eliza's set did the most to standardize these incompatible assets, that's why I have chosen that as a reference.
This is exactly what I like so much about Eliza's set (plus the additional animations). No different "vibes" or whatsoever, just correct positioning, standardized sizes, interchangeable parts and guides to help fixing the old assets and creating new compatible ones.
No different look, just compatible assets. And that's exactly what my LPC Specification is about, to mark submissions that follow the same guides and therefore are guaranteed to be compatible with each other.
Cheers,
bzt
@bzt: "Sorry to say, you are confused and mistaken."
Except, not really. There are differences in the male body, the colour palette and the animation. Note I don't say better or worse, just different - which makes it a matter of opinion which one is preferred.
"Good luck adding "jump" or "run" into your game."
Oh, that's fairly straightforward: you add in the existing animations, then adapt the clothing items you want for them and share those back to the community (when you're satisfied with them) so others can benefit, or you pay bluecarrot16 a commission to do it for you. Hell, for the jump you could just use Eliza's as is, since it's the same animation except cleaned up and with some assets to get you started.
"that's the only one submission that actually has compatible heads and facial expressions,"
Except, not really.
"not to mention guides for future assets."
Yeah, that's missing at the moment. Working on it.
"All the former submissions are useless and incompatible in a real game, just try to use them if you don't believe me."
That is uncalled for. You know, people have actually made games using LPC assets and characters. You might want to do some research there before proclaiming something that ends up just looking stupid.
Seriously, get someone to proof-read your posts before submitting them, because you're coming across as rude and condescending as all hell.
"That's a TERRIBLE idea. It's not going to work, because left and right isn't mirrored sprites, and what's more it's not compatible with any of the existing assets either, not with the original LPC base, and not with Eliza's."
Of course it's going to work, as long as you have left facing sprites, you have right facing sprites by flipping them. It's been done that way since the '80s. Sure, it doesn't work as well if the sprite isn't left/right symmetric, but many sprites are and even when they're not games have not worried about this for ages. Sure, having 4 directions (or heck, having 8 directions) is better, but in terms of priorities, there are definitely more important things to worry about.
You say the existing assets aren't mirrored sprites, so then explain why the character goes from right-handed in left-facing frames to left-handed in right-facing frames (also when going from up to downward facing sprites for... some reason). The only thing I can think of that supposedly differentiates the left and right facing frames is the glare spot on the head (it's supposed to be on the left side of the sprite) and even that flips position on some frames (it's wrong on the left-facing thrust animation for the male base).
"Here's a perfect example for you about the LPC asset compatibility problem I'm constantly talking about. Look how the helmet doesn't fit to the male base on the left. This, and the missing animations for certain assets makes the original LPC asset unusable in a real game."
Care to elaborate? What "missing animations" are you referring to? Older submissions have things like "no cast/slash" or "walk only", but the vast majority of those have been filled in ages ago, but you have to know where to get the most recent version (which is typically from the Universal LPC spritesheet character generator). Where did you pick the helmet and base from? I'm asking, because the version I have (see it at https://sanderfrenken.github.io/Universal-LPC-Spritesheet-Character-Generator/#?body=Humanlike_white&hat=Barbarian_silver&sex=male&weapon=Slash_dagger) appears to be fine?
You complain that things are "broken", "missing" or "incompatible", but appear to be unaware of effort that has gone into fixing the things you're complaining about and you're dismissive and rude towards the people who have put in that work.
Now, finding the correct place to look is tricky because newer and older submissions are lumped together in the site search. The same thing is going to happen to Eliza's recent submission once it falls off the front page. That should be improved, somehow. If there are issues or misisng things, do point them out - mistakes can't be fixed if no-one points them out, and someone may just be willing to help out if you ask nicely.
@Evert: "Except, not really. There are differences in the male body, the colour palette and the animation. Note I don't say better or worse, just different - which makes it a matter of opinion which one is preferred."
Except this isn't a matter of opinion. Assets are either compatible or not with the base body. That's empirically and objectively provable. And changing the palette is literally a single-click these days.
"Oh, that's fairly straightforward: you add in the existing animations, then adapt the clothing items you want for them and share those back to the community"
How is this any different than doing exactly the same for Eliza's set? (Except there you only have to create half of the sprites and you also have guides.)
"Yeah, that's missing at the moment. Working on it."
That is just not possible, you cannot create such guides for the current LPC set, simply because (again) there the base characters are incompatible, so ALL assets must be duplicated. No common guide possible.
"Of course it's going to work, as long as you have left facing sprites, you have right facing sprites by flipping them."
Just to be clear, are you volunteering to refactor ALL the existing submissions from 4 directions to 3 directions?
I find it pretty funny that
a) you (plural) are complaining that we shouldn't standardize because that would mean designers will have to make modifications to the existing sets
b) and then you (plural) suggesting that designers should make modifications to the existing sets...
"Where did you pick the helmet and base from?"
From the Universal LPC spritesheet character generator of course.
"I'm asking, because the version I have..."
...is DUPLICATED, as I've already pointed out multiple times, here and here. And not just for this helmet, you have duplications of every single asset, hair, tools, weapons etc! And yes, even your own example, the dagger is duplicated, here and here. It only makes sense to duplicate the clothes, but not the rest!
"You complain that things are "broken", "missing" or "incompatible", but appear to be unaware of effort that has gone into fixing the things you're complaining about"
Quite the contrary! I'm perfectly aware that despite of many many years of effort this issue still hasn't been resolved yet, that's why I've volunteered to put an end to this mess by merging all the info into a single documentation and guide sheet.
Have no doubt, here you're the one complaining, and I'm the one putting the effort and offering my free time to actually find a solution.
Cheers,
bzt
I can see the importance of the implications there. I think "Cert" or "Certified" implies endorsement by the original LPC contest organizers. It makes sense to certify any additions to this fork against the set of rules being outlined, but you don't want to imply that something isn't truly LPC without following these guidelines. It would be correct to say something isn't truly belonging to this fork of the LPC if it doesn't follow the rules of this guide, but otherwise it would appear as if we're saying there is only one set of LPC assets, and (currently) most of the LPC content doesn't even satisfy the conditions of its "own" certification, not even the original base assets.
How do you feel about using the tag "LPC-Revised" since much of the certification rules are to be influenced by ElizaWy's titular submssion "[LPC Revised] Character Basics!"? ... Or even "LPC-RCert" or some derivation thereof to indicate this is certification for the "R" or "Revised" fork, specifically?
Looking good! For the https://bztsrc.gitlab.io/lpc-cert/#licensing section, I recommend adding some (further) clarification about when licenses are requried when content is not made from scratch. The licensing page says there is no mandatory license, which is true, but that is only the case when the asset is not being derived from some other LPC asset. Since a vast majority of new LPC assets are derived from former LPC assets, I worry this could confuse people into thinking they need not use CC-BY (SA) for their derivatives when basing them off of CC-BY (SA) content. This is actually one of the more common licensing issues I see. The warning at the bottom addresses exactly this, and it's good; I am recommending further clarifying what constitutes a derivative of other work.
--Medicine StormThe focus of this discussion has largely been about the characters, but I think there's room to improve other sections of the guide as well.
Miscellaneous Suggestions:
Tiles:
Objects:
Characters:
I'd suggest having multiple certifications for different sets of animation. I propose we start with two:
The remaining animations can be added to future certifications as it makes sense. A certification should have somewhere between 3 and 5 required animations.
Examples of possible future certifications (some animations don't exist yet, or have not been widely accepted):
The advantages of this system are:
@MedicineStorm: "I can see the importance of the implications there. I think "Cert" or "Certified" implies endorsement by the original LPC contest organizers."
Actually no, that wasn't the intent. By "Certified" I wanted to express they follow the same guidelines, hence compatible with each other. And "LPC", because it's based on LPC. But I can see what you mean. Having endorsement from the original contest organizers would be most certainly highly appreciated! But since bart isn't around any more I'm not sure if that's even possible. So if the most currently active LPC contributors were to endorse it, I would called that a complete success.
"you don't want to imply that something isn't truly LPC without following these guidelines."
All I want to imply is if they don't follow the same guidelines then there's no guarantee that they can be used together with other LPC assets.
"I recommend adding some (further) clarification about when licenses are requried when content is not made from scratch. The licensing page says there is no mandatory license, which is true, but that is only the case when the asset is not being derived from some other LPC asset."
Ok!
@BenCreating: "The copyright at the bottom of the page should be altered"
Oh, that's just left to the default. I'm looking forward to replace it with "OpenGameArt.org Contributors". Thanks for the heads up!
"A page with a quick-reference bullet point list of the requirements to be certified for each type of resource (tile, object, character), with links back to the relevant sections of the guide"
Ok, let me see what I can do!
"A page for common errors and how to correct them"
A FAQ is a good idea I agree, but I don't think we should put this into the spec, that's not where it belongs. But maybe a link to the FAQ? I can see more sense in that.
"Guide for what makes a complete tile set, specifically for a building set. What is needed for a complete set of wall or roof pieces?"
In contrast to characters, which are animated dynamically according to the implemented actions in the game and therefore can be complete / incomplete, I don't think such a thing exists for tiles. There's no mandatory blob or Wang tileset requirement in LPC, so it is very difficult to interpret "complete" for tiles. (FYI, there's a section on tile authoring, same as the original.)
"Color palettes for common materials: wood, stone, grass, snow, water, sand, glass, etc."
We only have the common palette (as a helper, not mandatory) and a palette guide for metals so far. But if there's a commonly used palette submission with these, I'd be more than happy to add them to the lpc-guides.zip!
"A recommendation (maybe a requirement for the certification?) to draw objects from all 4 directions"
That's a no. You simply can't well-define when that would be required. Plus isn't necessary either by game engines (not dynamically controlled by user interaction / path finding algorithm).
"I'd suggest having multiple certifications for different sets of animation."
I'd really love to, but we're not creating a new definition here. We have to cook with what we've already got.
"The advantages of this system are"
Trust me, I know! But this spec MUST be backward compatible with the current LPC assets (animations type and number of animation frames wide).
See here. This LPC spec's grid is 100% sprite-position compatible with the current sheets. This is very important, because designers must be able to use the guidelines with current spritesheets, so that they can easily check (and fix) compatibility. Most current assets would only require moving some sprites 1 pixel to make them compatible with the guidelines, which is a huge advantage that we don't want to loose.
I've only added "sit", "jump", and "run" (because there's a demand for these, plus guides already exists). I'm sure "run" is very much needed, reading through the forum it seems lots of people wanting "jump" too. I really would like to have "sit", but that could be moved from "mandatory" to "optional" category I guess.
"An artist working on a sci-fi game does not need to create medieval specific animations"
Yes, the animation's names are indeed confusing. But they aren't for medieval only, and changing the names at this point would cause lots of confusion (again, the top left part of the sheet grid must be 100% compatible with current assets).
Cheers,
bzt
I was thinking of this as less of an FAQ, and more of a page for common pitfalls that would prevent you from getting the certification. Many new LPC artists don't realize these issues even exist. The guide is meant to increase compatability, and pointing out common errors does that.
I'll see if I can put together an illustration later that might make what I am thinking clearer.
I'm not saying we break backwards compatibility. It is very common for new assets to be released with only a subset of the existing animations. Typically, these are either split into their own individual sprite sheets (my preferred submission style), or layed out on the Universal Sheet with gaps left for the missing animations.
I am suggesting that we allow, and even encourage, this practice.
If my game only needs a walk and an idle animation, but I see that I can get the certification by drawing 1 additional animation, I am more likely to do it than if I have to draw 5.
If I draw that 1 additional animation, another artist is more likely to create the 4 missing animations later.
My point was not that we should change the names of the animations, but that if I am making a sci-fi game then an archery animation is a waste of time for me.
Smaller certification groups increase the possibiilty that new art will get released instead of sitting on my computer until I finally get around to finishing that archery animation, and also make it easier to search for assets that will work with my specific genre of game.
Spec updated. Added more details on derivative works, and added checklist too.
@BenCreating: "Many new LPC artists don't realize these issues even exist."
Present! I'm not sure what you mean and how that differs from a FAQ. But if you create a "Common pitfalls" list, I'll gladly add that to the spec!
"I'll see if I can put together an illustration later that might make what I am thinking clearer."
I know what you mean, but unlike the characters (which are dynamically animated in-game hence required to be complete), maps with tiles and objects are typically created using Tiled, which imposes no restrictions, so I'm not sure we should either.
"It is very common for new assets to be released with only a subset of the existing animations. [...] I am suggesting that we allow, and even encourage, this practice."
I'm strictly against encouraging this. This bad practice is one of the main reasons why LPC assets are incomplete, as designers are often "forget" to fill up those holes.
New submissions can be made and released with less animations, so far ok.
But the problem OGA currently facing is, these new submissions already get the "LPC" tag, so there's no way to filter them out in the search. The point of "LPC-CERT" tag is that it cannot be added to such half-ready submissions, it requires that all the mandatory animations must be finished, but no sooner.
"If my game only needs a walk and an idle animation, but I see that I can get the certification by drawing 1 additional animation, I am more likely to do it than if I have to draw 5."
Agreed, but LPC already established the list of animations as "cast", "thrust", "walk", "slash", "bowing", "hurt". Making any change to that list would break backward compatibility. This spec has only added the very much needed "jump", "run" to that list, and "sit" (but I guess that could be made optional).
"My point was not that we should change the names of the animations, but that if I am making a sci-fi game then an archery animation is a waste of time for me."
Yes, but the LPC asset creators cannot know in what kind of game their assets are going to be used, so they're not allowed to make such assumptions.
The asset's creator must create the bowing animation, even if your game doesn't need it. (Full disclosure, if I were designing LPC from scratch, I wouldn't want bowing to be mandatory either, but it is already on the sheets and in the Ultimate LPC Character Sheet Generator, so we cannot remove that animation at this point.)
"Smaller certification groups increase the possibiilty that new art will get released instead of sitting on my computer"
Hold on for sec right there! This specification does not stop you from releasing your art! It only demands that the "LPC-CERT" tag can be added to your submission when it's ready to be used in games, and not sooner. See the difference?
Cheers,
bzt
Not every game uses hand-crafted maps. What about games with procedural generation, or a building mechanic?
Whether it is a requirement or just a suggestion, I think it would be valuable to have some of that information added to the guide. That said, the expert on LPC tiles and objects is really @bluecarrot16, so I would defer to them on what should be included here.
Correct me if I'm wrong, but the LPC-CERT tag is intended to do two things:
In order to do either of those things, it has to set a standard for what is considered complete. No one likes to release unfinished art. If there is a standard for completeness, artists will wait to publish their work until they meet it, even if that means it sits on their computer forever.
You've listed 9 animations as mandatory. If an artist only needs 2 of those for their game, they will either never release their art, or never bother to meet the certification requirements. No one wins in this situation.
If we have several smaller certifications the artist will only need to create 1 or 2 additional animations to meet one, and they are much more likely to actually do it. Those are animations that would never have been created if the certification required all 9 animations.
If these small certifications have overlapping requirements (for example if LPC-MELEE-CERT requires a couple of animations that are also required for LPC-MEDIEVAL-CERT) then another artist is more likely to finish those last few animations needed for the next certification.
The disadvantage is that there is no single tag to find all LPC art that has a complete set of animations. However, there would still be many tags for smaller sets of animation which would make it easier to find art that can be used for a specific game.
I realize that for your own project, TirNanoG, that this is not the ideal situation, but I believe that many smaller certifications will lead to more assets being compatible with more animations than a single mega-certification ever will.
For reference, the standard 6 animations (cast, thrust, walk, slash, shoot, and hurt) have around 100 frames of animation after you remove all the frames that are mirrorred and duplicated. My LPC Wolfman took an average of 2.5 minutes per frame. That's 4 hours of work for a head swap and palette change. That is the simplest project you can ask for. A moderately complex project (like a new shirt, pants, or weapon) can take 2 to 3 times longer, and something more complex than that would take even longer still.
If my count is correct, the 3 new animations add 46 non-duplicated frames. That is an additional 2 hours of work. The simplest possible asset requires 6 hours to support all animations currently listed as required for the certification.
Compare that to a list of smaller certifications:
If an artist has already created an asset with just 1 of these sets of animations, they are much more likely to create additional animations they did not need for their own project if the time commitment is small.
@BenCreating: "Not every game uses hand-crafted maps. What about games with procedural generation, or a building mechanic?"
Very few LPC assets using game have procedural maps, while ALL of them require dynamic character animations. They exists, sure, but are a minority.
"Whether it is a requirement or just a suggestion, I think it would be valuable to have some of that information added to the guide. That said, the expert on LPC tiles and objects is really @bluecarrot16, so I would defer to them on what should be included here."
Make it a suggestion and it would be great! I agree if @bluecarrot16 writes about requirements for procedurally generated maps, I'd gladly add that to the spec! I just don't see any reason in enforcing those requirements to games using static maps, which are the majority. Hope this makes sense to you.
"In order to do either of those things, it has to set a standard for what is considered complete."
Yes, precisely! But being complete just one part, the other part being compatible with each other, that's just as equally important.
"If there is a standard for completeness, artists will wait to publish their work until they meet it, even if that means it sits on their computer forever."
They might prefer to do that, that's out of the scope. The point is, releasing full submissions isn't mandatory. The only mandatory thing is, the LPC-CERT tag has some criteria to be fulfilled in order to be given to a submission. If its given at the time of upload or later, that's irrelevant.
"You've listed 9 animations as mandatory."
That's not up to me, I've listed what's already in LPC plus the ones people on the forum would really like to have. (Personally I would want "sit" and "push" too, yet I haven't added the latter because not many forum members want it.)
"If we have several smaller certifications"
Then there's a chance people will be lost with the certs. Maybe later, but at first let's try to have one based on what we already got. Small steps! Small steps!
"I realize that for your own project, TirNanoG, that this is not the ideal situation"
You're totally wrong about that. For my TirNanoG engine only the walking animation is needed, everything else like "slash", "thrust" etc. is optional and user-configurable. As I've said before, I added these animations to the spec only because LPC sheets already have them.
"If my count is correct"
Nope, it is off.
And please forget that palette-stuff. Neither the original LPC Style Guide, nor this specification has a mandatory palette. Plus you can swap palettes with a single-click.
Cheers,
bzt
Update: made "sit" optional. Now there's 6 animation (which LPC already had), plus 2 ("run", "jump"). I think nobody can say that's not reasonable.
Cheers,
bzt
Small steps is the point of smaller certifications. I listed 4 that cover everything that exists. In small steps, the artists here would meet those certifications. With a single large certification, we are asking the artists to make big steps.
The majority of people on the forum are artists. We would really like to have more of the animations become standard and we have the skills to do it, but the lack of a certification is not what is stopping us. The time investment is.
The head swap is a simpler change than most clothing assets. The times I gave are lower than they would be for clothing.
I'm fully aware. My LPC Weapons took closer to 10-15 minutes per frame. A single weapon is still probably a 3 to 5 hour project.
The palette swap was by far the easiest part of the project. It does not significantly affect the times I gave, but I don't have data about how long I spent on palettes versus other parts of the project.
Fair enough. I will note: the run animation is not ready to be standard. There are 6 primary character bases (Child, Female, Pregnant, Male, Muscular, and Teen) and most of them do not support the run yet.
This is probably my last post specifically about certification. I've given my opinion, and don't think there is much more I could add.
@BenCreating: "Small steps is the point of smaller certifications."
Nope. Small steps in required modifications I mean. There small step is: take what we've got (6 anims) add the 2 most wanted. Creating many little certifications is NOT a small step, that would be a huge amount of rework. (You would have to split current sheets into one sheet for each small certs)
"A single weapon is still probably a 3 to 5 hour project."
You made a typo here. Repositioning a single weapon would take 3 or 5 minutes tops. (Draw something new doesn't matter because it takes exactly the same time for the old and for the new sheet, as they only differ in position)
"I will note: the run animation is not ready to be standard. There are 6 primary character bases (Child, Female, Pregnant, Male, Muscular, and Teen) and most of them do not support the run yet."
Wrong about that. It is done for the Male and Female base by Eliza (as well as jump and sit). To make it a standard, it is enough to support that two (most games will NEVER ever need pregnant women or teens for example.). FYI, the Ultimate LPC Character Generator does not support those either, for example check the slash animation, or the arms or gloves assets, only Male and Female variations exists.
Cheers,
bzt
I'm not very familiar with this whole LPC art style, and I'm having a hard time grasping what the problem is. Is bzt trying to make a variant of this style? Or is he saying new animations should be added to the standard LPC art?
Or is he trying to do something else entirely?
___________________________________________________________________
No mind to think;
No will to break;
No voice to cry suffering.
@Umplix: "I'm not very familiar with this whole LPC art style, and I'm having a hard time grasping what the problem is. Is bzt trying to make a variant of this style? Or is he saying new animations should be added to the standard LPC art?"
Thanks for your comment! My answers:
No, I definitely don't want a new variant of the style. The current issue is, that LPC assets aren't compatible with every body bases (+/- 1 pixel off and things like that). @ElizaWy did a great job fixing that with her LPC Revised character basics submissions. I'm planning to formalize what she did into a specification, so that future assets can be compatible (Eliza also did incredible guideline "wireframes" for the animation frames which makes porting old assets and creating new ones extremely easy). This is what it looks like in use:
She has also added 4 new animations to the set: "sit", "idle", "jump" and "run". It is a long time wish of the community to have "jump" and "run", and Eliza also did the body bases for that (for the female and male bases at least), so I think it's a very good opportunity to finally expand the LPC's base animation set with these. (Previously there were attempts to add "jump" and "run", but those never made it. Eliza's set on the other hand is ready and consistent with the other animations.)
So no I don't want to add new animations, it just happens that what the community lacks already made in Eliza's set, and if so, I think why shouldn't we use those?
In a nutshell that's it. There are other advantages of the LPC Revised submission, like interchangeable heads with emotions and facial expressions, compatible and animated hair, etc. but the main point is, thanks to the guides we can finally standardize the LPC set.
Cheers,
bzt
So make some LPC models compatible with non-compatible LPC clothes, equipment, etc.?
___________________________________________________________________
No mind to think;
No will to break;
No voice to cry suffering.
@Umplix: "So make some LPC models compatible with non-compatible LPC clothes, equipment, etc.?"
Almost. It is the other way around, the LPC models are ready, we need a clear set of rules and the guidelines so that artist can fix the now non-compatible LPC clothes, equipment, etc. compatible. (Slight difference, but very important, because there are 2 models, female and male, but probably nearly a hundred assets.)
Clothes has to be redrawn to some extent, but for equipment (hats, helmets, tools, weapons etc.) it is just a simple matter of repositioning a few frames. Using the guides that latter should be a piece of cake, even non-artist can do it, that's why I'm proposing to use LPC Revised as a base for the standard (that, plus it has canonized body bases, eg. no need for separate female dagger and male dagger any more, one can work for both. Also it should work for future additions too, should anyone create a masculine or pregnant woman base model for example).
Cheers,
bzt
OK, makes sense. Thanks for clarifying.
___________________________________________________________________
No mind to think;
No will to break;
No voice to cry suffering.
Any more questions about the spec?
From me: were the modifications satisfactory?
@MedicineStorm: is the new licensing page look ok to you? I don't want to put too much legal stuff there, I'd rather focus on advice and some pointers. IMHO it has the right balance now.
@BenCreating: do you like the checklist? Is there anything that you think I should add?
@bluecarrot16: what do you say to @BenCreating's suggestion? Would you be interested in writing down a few words about how to create compatible tiles?
Cheers,
bzt
I don't have any more suggestions at the moment.
I've been in communication with bluecarrot16, but they're pretty busy with a large project right now, so I wouldn't expect them to write something about tiles any time soon.
Thanks, but even though it was your suggestion, I'm afraid this question is not yours to answer. It was directly addressed to bluecarrot16, so only he can answer.
(Actually you trying to speak for him sounds pretty bad, it just makes us wonder if you have locked up bluecarrot16 in your basement like MedicineStrom did with bart :-D :-D :-D)
Cheers,
bzt
Pages