Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

emblem-controls v1 #1008

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Conversation

johnmorrownj
Copy link

Adds settings to culture that provide some control over the creation of emblems for that culture. This implementation includes variation in the default cultures but it could be configured to not change anything by default. I also cleaned up the culture editor grid a bit. The next step will likely involve seeing about adding an iconic charge (or two) and iconic tincture to religions and states to make that charge and color likely to appear in emblems for that religion or culture. Note that the version was updated to 1.94.00 because it adds not data to the culture structure.

Description

Motivation was to provide more culture-specific control over the look and feel of the emblems created for it. In particular, Christian iconography, some other charges, some of the line types, and so on create a very Christian Medieval Europe look that's appropriate for a general heraldry program like Armoria but is not necessarily appropriate for a fantasy map containing very different cultures. I sent a lengthy email to azgaar.fmg@yandex.by discussing this and decided to take a shot at implementing my ideas myself.

In particular, it in the Culture editor window, it allows Charges to be set to All, Limited (primarily removes crosses, some other charges with strong Christian iconography, the cannon, and the humans, which have a strong Medieval European look), Nature (animals and plants), Things (arms, tools, agriculture, seafaring, architecture, and miscellaneous), Nature & Things, Shapes (a subset of the conventional category), and None, which suppresses charges. Lines can be set to All, Limited (the less strange options), Straight, or None (which suppresses ordinaries completely and uses straight lines for divisions). Tincture can be set to All, NoPatterns (which turns off patterns), and NoStains, which excludes both patterns and stains from color selection. The method used to create those options could be used to create other options and my choices can be adjusted as needed. I think it's all configured and controlled fairly clearly but it could probably be refactored and improved.

Note that I reworked the culture editor grid as part of this, so even if you reject this change, you may want to look at the grid rework and see if you can get anything useful out of it. I also implemented a variation of rw (random weighted) called rwx (random weighted exclude) that lets you pass and exclusion list that will skip elements in the exclusion list when creating the weighted list, which makes it possible to skip just a few elements of a larger list without creating new lists. You may find other good uses for it.

I upped the version number to 1.94.00, because it has to update the culture structure with the new data when reading an existing map save. I think I managed to figure out and find all the version updating throughout and updated the auto-updater to update the culture data.

Type of change

  • New feature
  • Refactoring / style

Versioning

  • Version is updated
  • Changed files hash is updated

…l over the creation of emblems for that culture. This implementation includes variation in the default cultures but it could be configured to not change anything by default. I also cleaned up the culture editor grid a bit. The next step will likely involve seeing about adding an iconic charge (or two) and iconic tincture to religions and states to make that charge and color likely to appear in emblems for that religion or culture. Note that the version was updated to 1.94.00 because it adds not data to the culture structure.
Copy link

netlify bot commented Nov 1, 2023

Deploy Preview for afmg ready!

Name Link
🔨 Latest commit 1b86980
🔍 Latest deploy log https://app.netlify.com/sites/afmg/deploys/65421b7a79d2780008784967
😎 Deploy Preview https://deploy-preview-1008--afmg.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@Azgaar
Copy link
Owner

Azgaar commented Nov 1, 2023

Hello and thanks for the contribution! 🤗

It's a pretty big one, so unfortunately will require quite some time to review and work on. There are things that can be improved:

  • UI/UX: Culture Editor emblem settings takes to much space. I would suggest to colocate all settings into a separate dialog/menu (just like we have a menu for State name change)

  • Controls: Emblem generation control points are quite arbitrary. I would like users to control emblems, but in a more clear ways. Users don't know what 'Lines = Limited' means. These control points / types are a subject for a good lengthy discussion (Discord?)

  • Shared code: COA generator is a shared code between FMG and Armoria. So the difference in it should be minimized to allow changes from Armoria to be simply ported to FMG. All FMG-specific configs should be separated from Armoria config. Another option is to make the changes in Armoria (would need new UI in Armoria)

  • Code quality: I have recently reviewed my own COA generation code and found it very messy. So it would be nice to refactor and introduce some structure to it, define all chances/probabilities via config, and only then introduce new logic to it. There is a big intent to improve the code quality (see FMG 2.0: Codebase refactoring and modernization #842) and I would like all new big changes to work in that direction

@johnmorrownj
Copy link
Author

It's a pretty big one, so unfortunately will require quite some time to review and work on. There are things that can be improved:

That's not unexpected. Part of the goal of me implementing it was so you could see how settings be used to change the look and feel of the emblems created in practice and for me to see if they worked as expected. So even if you don't merge this in as is (I didn't really expect you to), I would like you to see how it works.

* **UI/UX**: Culture Editor emblem settings takes to much space. I would suggest to colocate all settings into a separate dialog/menu (just like we have a menu for State name change)

While I do JavaScript and "full stack" work, JavaScript is not my strongest language and I'm more of a back-end guy than a front-end UI guy. I surprised myself that I was able to figure this out enough to get it working cleanly as quickly as I did. Pointing me to an example is helpful and I'll take a look at how the State name change works. I agree that interface real estate is a concern. There is more that I would like to add and know I can't keep adding more the way I did for those options. A separate dialog/menu would work better in the long run.

* **Controls**: Emblem generation control points are quite arbitrary. I would like users to control emblems, but in a more clear ways. Users don't know what 'Lines = Limited' means. These control points / types are a subject for a good lengthy  discussion (Discord?)

Yup, those options are pretty arbitrary and the names aren't great, but I wanted to get it implemented to demo it in case you hated the idea. I didn't really expect them to go out as is, but these changes are not worth putting more work into if you aren't interested in them.

I'm willing to get on Discord to discuss this (I'm in Eastern time in the US) and, yes, I think it's something other people should discuss, not only in terms of labeling the options but also what kinds of options other people might want (what kinds of categories do they want to be able to include and exclude). I was mainly trying to hit some broad stroke filters that solve problems for my own map/setting and which could demo what I have in mind, so you can see how it changes the look of the emblems in practice. As I mentioned in the email I sent, my goal is to make a high percentage of the emblems usable as-is without having to manually fix or create them.

I think there could be room to adjust the categorization of the charges (the existing categories aren't bad, but you might want an ecclesiastical category for clear Christian iconography like the Agnes Dei, Mitre, Orb, Angel, etc.) and other elements like lines, ordinaries, and divisions. Category filtering could open up a way to introduce non-European (e.g., Asian, African, Native American, etc.) motif charges into the mix (though I know you are constrained by getting good svg files you can legally use for Armoria) by letting Armoria and FMG filter those out for traditional heraldry. One thing that could improve round Asian emblems (and maybe all round and square emblems) would be to allow the arrangement of charges radially around the center, either pointing inward, outward, or perpendicular left or right to a radial line (see the Mitsubishi logo or other Japanese mon for examples). Rounding out the geometric shapes (e.g., Delf Pierced) could also make shape-based output look better.

I would also like to see the ability to pass a different color set to Armoria via the COA API, so I do plan on looking at Armoria and the API there at some point. I've been playing with using light blue (mithril) and pink (sangril) as alternate metals, which works well from a visibility perspective and makes there results a bit more exotic looking ad there are some unconventional tinctures such as Beau Celeste (a light blue), Buff (the New Jersey state flag's field is Buff), Rose (light red), Brunatre (dark red), Eisenfarbe (gray), Copper (reddish orange), and Orange that might be nice to have. See:

https://upload.wikimedia.org/wikipedia/commons/c/c9/Heraldic_tinctures_diagram.svg

(Beau Celeste, Rose, and Buff could be used like metals because they are light.)

While you could keep hard-coding more tinctures into Armoria and FGM, it might be better to make the API able to deal with them so that other programs can manage the color palette as needed.

I do think the cross-integration between FGM and Armoria is great and know it has to be kept.

* **Shared code**: COA generator is a shared code between FMG and Armoria. So the difference in it should be minimized to allow changes from Armoria to be simply ported to FMG. All FMG-specific configs should be separated from Armoria config. Another option is to make the changes in Armoria (would need new UI in Armoria)

If you look at my changes, it's largely done via alternate category lists and filters. See the rwx function I added, because I think the filter approach could make a lot of things possible without bogging performance down too much. My configs largely don't touch the existing configs (which made it easier to resolve merge conflicts when you changed them around with a recent commit) and could be further separated without too much work.

The overall approach (filtering the charge categories and further filtering some charges that appear in other categories) might be useful in Armoria, too. Also hierarchically categorizing the divisions, lines, and ordinaries could make them easier to filter. It's easier to filter on entire categories than on individual elements. The line filter I apply to filter every line that's not straight is a worst case scenario in that regard, but it still works reasonably well. I'll take a look at Armoria when I have a chance.

* **Code quality**: I have recently reviewed my own COA generation code and found it very messy. So it would be nice to refactor and introduce some structure to it, define all chances/probabilities via config, and only then introduce new logic to it. There is a big intent to improve the code quality (see [FMG 2.0: Codebase refactoring and modernization #842](https://github.com/Azgaar/Fantasy-Map-Generator/pull/842)) and I would like all new big changes to work in that direction

I saw that you were going through a clean up and improvement pass in a recent commit (that created merge conflicts for me, but such is life) but your code was a lot less messy than it might have been and was easy enough for me to figure out how to get a prototype working of the kind of filtering I'm looking for so I could demo it and you can see it working. Code can always be improved but what you've got is pretty good and was easy enough for me to graft filtering into. If I waned to nitpick and gripe, I might complain about variable names (I'm not a huge fan of single-letter variable names -- I was traumatized by started out doing BASIC on Apple ][ computers, where only the first two letters of a variable name were significant). It looks like your latest change did some clean up there and that might be something to look at refactoring.

What I basically did was put another layer of abstraction that let me adjust the category lists for charges, created a reduced set of conventional charges for basic shapes (splitting the convention category into two could make that unnecessary but I was trying not to introduce any incompatibilities with Amoria), and then created a filter process which gives a flexible way to take selections out of a larger list. See the rwx function. I think a lot can be done with that approach in other contexts, as well. If you select the three "All", you'll basically get the Armoria defaults. I touched a lot but I don't think it's as intrusive as it might look at first.

I'll take a look at your suggestions and please let me know if you want to chat on Discord. I'll also take a look at Armoria to see if this should start out being implemented over there.

The one other thing I eventually want to take a look at is the random name generation system. While it's not bad, I use my own word lists as sources and I noticed that the existing system has a lot of positional effects coded into the name generation, which produces a bit of a mess if you change all of the languages or move them around a lot.

@Azgaar
Copy link
Owner

Azgaar commented Nov 1, 2023

I don't hate the idea, but it should be other well-thought implementation of it or nothing. I will open a conversation on Discord.

@Azgaar Azgaar marked this pull request as draft November 1, 2023 12:47
@Azgaar Azgaar added the POC Proof of Concept label Feb 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
POC Proof of Concept
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants