Looking ahead at the future of the generator, what do we envision? Would we consider rewriting the current one using a modern framework; or continue as is. #53
Replies: 2 comments 10 replies
-
|
"It will require us to learn vue" Oh that's easy. I work with vue every day at work, our dashboard is built in Nuxt/Vuetify. That being said, I do agree. I think its better to work with this one and make a few improvements here and there than to completely switch over to something else entirely. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to add the recoloring feature and reduced color versions of spritesheets to the current generator. How we go about doing that is something we can discuss. I would prefer to evolve the generator to more modern syntax and maybe introduce a more modern framework as necessary. I do not think a modern framework is necessary at this time. jQuery 3 is just fine. I'm not a "rewrite it because it is old and not the latest and greatest" kind of person. I think making our UI interface better is also something we can discuss. |
Beta Was this translation helpful? Give feedback.
-
|
Not being an artist, the idea of choosing palettes isn't something I really understand. But I'm imagining we'd choose a set of colors to use generally, and then when we'd pick an asset, we'd only show the asset in the colors from the set? How many colors in the palette? This is starting to sound like writing a custom palette picker followed by an asset picker, then followed by a specific color picker. |
Beta Was this translation helpful? Give feedback.
-
|
There's already a set of common palettes being used. I just like the idea that, if we have an easy way to drop in palettes, we give the option to provide LPCR palettes instead. That's basically it. IDK how we would implement it, but I don't think just dropping all palettes at once is a good idea because that'd add a ridiculously high number to pick from. LPCR support could easily be added later and we only focus on the standard ULPC palettes we already have. Those palettes can be found here: These are primarily based on my observation of assets of what is most commonly used. We have body colors, "cloth" colors (I commonly use these for generic asset colors that don't fit other categories), eye colors (not a large selection, I'd like to see more), hair colors, and "metal" colors (mostly for weapons and armor). The subdirectories here include "custom" palettes (assets where I kept the default palette and added new recolors) as well as the LPC "revised" palettes I grabbed from Eliza's assets here: (She has a _Palette subdirectory, but I didn't use that. I just grabbed the palettes straight off the assets instead.) |
Beta Was this translation helpful? Give feedback.
-
Maybe we can start without a custom palette picker? Instead, we can add to the json per asset which palette is supported. For instance, eye assets will support the eye-palettes, and weapons and armor (I assume) the metal-palettes. That way, we just keep the same palettes and options as we currently have. We can then later add the LPC-Revised palettes as well to choose from. Once an asset is selected, we show the palette options that belong to that asset's supported palette in a list for example. So when you select an armor, you will see a dropdown next to it with the options: ceramic, brass, copper, etc etc. On select of the list, we recolor the asset and the generated sheet. You could also redraw the preview indeed, on the other hand, the user will see the result of the recolor also directly in the generated sheet. A question: Are all assets already compatible with recoloring? Or are there any assets that don't adhere to a palette yet? And another one. How does the palette/ recoloring work? I if look at the metal palette, each entry holds 7 colors. So I assume any asset using that palette contains 7 different colors. I also see a source entry, which indeed holds 7 colors as well. So I imagine we take the image that corresponds with the source palette colors. And then for each pixel we get the color, look up the index of that color in the source palette, and then define the new color for that pixel by looking up the same index in the chosen material? |
Beta Was this translation helpful? Give feedback.
-
|
This is basically exactly what I had envisioned. On the json files, we list the palette that the sheet uses. If we eventually want to support multiple palettes, we can make it an array that allows the user to switch the palette on the fly to another variant option. "A question: Are all assets already compatible with recoloring? Or are there any assets that don't adhere to a palette yet?" I did add support for a few, but plenty still need it. I believe we were going to look into Vitruvian Studios spritesheets list to pick out the assets we're missing that haven't had color reduction done on them yet. I think all hairstyles are fine. Almost all head assets are fine now, though one of the bandanas I have noticed is still messed up and needs fixing. In addition, the Mail should be replaced by the one Napsio did. We just need to confirm with Napsio that we can update the licenses for assets that got their licenses updated since Napsio posted the list. |
Beta Was this translation helpful? Give feedback.
-
|
For the record: I'm not against the idea of having a global palette option either. Just in a by-default closed option towards the top of the list (the "Animations" filter is also closed by default), we have an option to toggle between our standard palettes and LPC Revised (with our standard palettes by default). LPC Revised is an option they can choose, but we don't force anyone to make a decision; they'd have to go out of their way to enable it. The color picker will then be based exclusively on that global option enabled, with each asset deciding which series of palettes to use. It shouldn't be hard to enable a toggle like this. By far the hardest part of course is switching our selection of a series of preset colors based on images over to toggling the palettes on the fly and having a color picker. |
Beta Was this translation helpful? Give feedback.
-
As discussed in this issue (#48) as well, there are alternatives from this generator that are a bit more sophisticated in functionality and technology.
A good example is LPC Studio here:
https://vitruvianstudio.github.io
The LPC Studio by Vitruvian is really nice. It's not up-to-date with the current assets, but that might be easy to fix. It supports recoloring, which is awesome. Didn't use it extensively yet, but overall it seems quite sophisticated already.
It would require us to learn Vue and I think overall the setup is a bit more complex compared to this generator (which is understandable as this generator is very simplistic). As with any modern frameworks, I do expect also it needs more LCM than the current generator.
I have to say that I do like the simplicity of this generator a lot, as it's easy to maintain and extend once you understand the inside. At the same time, the simplicity is also limiting.
Concluding, I think there are valid reasons to move to the more modern approach as the LPC Studio offers. But it will cost time to
The current generator is more or less feature complete, and what is missing we can add. I have always seen it as a plain tool for developers, and I never wanted it to have a shiny or polished UI with all sorts of nifty features. So from that perspective, it has always served me well.
But I also understand that there are users that would like to see a more modernized implementation, and that I think is what LPC Studio does very well already.
For the sake of time, personally I would stick with the current generator (I try to focus as much as possible now on my new game release) for now. I don't have the time and focus now to properly dive into LPC Studios. But if I would have the time to spare, I do think it's worth looking into it and try to estimate how much is missing, and what it would take to make it complete.
Beta Was this translation helpful? Give feedback.
All reactions