Just to get back to @Borealys issue, despite a really interesting video, I feel like I still don’t quite understand the problem, and partly that might come down to terminology differences across domains.
For what it’s worth, it might make explanations easier if it were distinguished when using the terminology of Fibery (Apps, Types, Entities, Fields, etc.) and when using the terminology of gaming. I think it could be easy to misunderstand what an ‘attribute’ is for example.
To me, this seems to be the ‘meta-level’ I was referring to. If an example of a content element is ‘Goblin’ and it is stored as Fibery entity (of type Content element) then in principle, Fibery is the database that stores all content elements (and they can be visualised using tables, boards etc.)
Also, I’m not sure how to interpret this:
Does it mean that manually pre-defined Types are not viable, since the fields needed for each Entity would depend upon the other Entities it links to? Or does it mean that the Fields of a given Type depend upon the other Types that it has a relationship to?
Again, I wonder if terminology is a barrier here.
You’re right, I should only use Fibery terminology to make it clearer
I meant that I would want a Type that would group together all of our content elements. That Type would be named “Content element”.
What I mean is that if I create an Entity named “Goblin” in my Content element Type, I would then link it to the Type “Enemy”. But then, I would want the Goblin Entity page to show me the Fields (attributes) it has and let me play with the values there. But this problem comes when my Type “Content element” is linked to many Types (for each Content element): the Entities will have Fields that it doesn’t need and shouldn’t show, because for exemple I dont want armor pieces to show me an empty link to the Type “Enemy”, and I want that armor piece (in its Entity page) to only show me the attributes it has (with corresponding Fields)
In my previous example, I think I would need Polymorphic Relations to make it work. This way, I wouldn’t link the Type “Content element” to every Type of different “Content elements”. I would instead link the Entities of the Type “Content element” specifically to its corresponding enemy Entity (which is in another Type, called “Enemy”), and not it’s entire Type. This way, I wouldn’t have Entities with Fields it shouldn’t have in its Entity page.
I hope I made it a bit more clearer for you @Chr1sG
Sorry, maybe I’m thick, but I I still don’t get it :-/
I tend to use the terminology that Types have Relationships to other Types, and Entities can be Linked to other Entities according to these relationships.
So for example, Type A has a Relationship (which could be defined as one-to-one, one-to-many, many-to-many or many-to-one) to Type B, and Entity X (of Type A) may be Linked to (one or more) Entities of Type B.
I am struggling to understand a few of your comments:
Do you mean that the ‘Content element’ Type will have Relationships to other Types? If so, what are these other Types, and why are they related?
Would it be logical to use a Type for each category of element, e.g. an ‘Enemy’ Type, an ‘Armor piece’ Type, and so on? If not, why not? (this seems to be what Michael has suggested, and I still am not clear what the answer is).
Again, I’m not sure I get it.
For your example of a Goblin Entity, what does it mean to Link it to a corresponding ‘Enemy’ Entity?
Please forgive me if it sounds like I am being obstinate, it is not the case, i am genuinely just trying to get my head around it…
@B_Sp I didn’t forget about you! I will look more into this!
@Chr1sG It’s okay, I’m here to clarify things so we can find a way to do this together!
This is exactly what I would want. But the problem with this, is that we also want a Type to regroup all content pieces of the game. This is the problematic part.
Having this comes with this problem for the “Content element” Type: if I would open an Entity page, let’s say the Goblin Entity again, it would contain Fields to enter relations with Types it shouldn’t have connections with. It would have a Field to link it to the corresponding enemy from the “Enemy” Type (which is ok), but would also have Fields to link to the Type “Armor”, the Type “Wands”, etc., which we really don’t want, as it clutter the Entity page. What I want is that the Goblin Entity would show me the same Fields in the “Enemy” Type as in the “Content Element” Type: Fields for its attributes (so I can enter values here), and the Field to link it to the corresponding Entity from the “Content element” Type.
Also, by having Types for every “Content element”, means we have duplicates: one in the right Type (Enemy, etc.), and one in the Type “Content element”. This isn’t that big of a problem, but I think it should never happen. I kinda found a solution to mitigate the impact of duplates: I can automatically link together Entities by Names, and make the relation one-to-one, so I would have to just copy and paste all Entites of a Type into the “Content element” Type, and they would automatically link themselves together.
Why?
If an app contains all the Types defined as necessary, why do you need an additional Type for ‘regrouping’?
If you just want to be able to visualise multiple Entities of differing Types at the same time, then Boards or Views are good ways of doing that.
What purpose should/does the Content Element Type serve?
OK, so I watched (some of) the video again, and what I noticed was that Enemy was an Entity of the Type ‘System’, but there was an App called ‘Enemy System Entities’.
I’m becoming more and more convinced that the problem is one of a data-level and a meta-level. You have an App for the Enemy System, but the available characteristics (attributes, behaviors, behavior states) of an Enemy are defined in the ‘Systems’ App, using the ‘System’ Type.
Is it the case that you’re trying to use one App Type (System) to describe the data structure to be applicable within another App?
This is the doing of @Louis-Felix, I will look into this with him and come back to you! I am not sure that this is what we want, as this is another try at our problem that he did after the original post
Quick question (putting aside how it might be implemented in Fibery for the time being):
Is it the case that defining a game element as belonging to a particular category (e.g. a Goblin is in the ‘enemy’ category) means that the element needs to have all the attributes (with user-selectable values) that are defined as required for that category but ALSO needs to have attributes that are required for fulfilment of ‘behaviours’?
Are the specific ‘behaviours’ unique to the element, or are they the same for all instances of elements in the same category?
The attributes needed for fulfilment of “behaviors” ARE the attributes that are required. One can’t go without the other, or else the “behaviors” couldn’t work without them or would force us to “hard code” or manually link the attributes.
And no, the “behaviors” aren’t unique to the element. This is our “Systemic integrity”. The “behaviors” are always the same. They work differently on what they are attached, only due to the different values we choose for attributes. So this is why every enemy are REQUIRED to have the same attributes, so that we can re-use the behaviors and that they work with any element, if it has the required attributes also attached to it.
Do you need to be able to relate behaviours to attributes?
Sorry, my question could have been better phrased: “Is the selection of which behaviours are associated with an element determined by the category the element is in?”
(I think the answer is yes)
I haven’t read all the comments or watched everything, but in your video at 25:02 from what I gather your problem is as follows:
“Attribute” with several other sub-attributes/values that can be used other entities of different types.
→ Solution: Create entity that they all share.
The set value must be available in the entity that use it, to be used as default value.
→ Solution: Lookup the value of the entity they all share.
It must be possible personalize the value too, but doing so would change it for every other entity that use the shared entity.
→ Solution: Add override input field in the entity that use the shared attribute. The field you rely on to get the value form however is a formula that prioritize inherited value, but switch to override value if defined (or perform basic math on the default value + override, like multiplier).
If that is indeed the problem, it’s sort of of similar to one I had to solve with product prices:
I have a sub-product with default price, and lots of customers can use the product. This way I can create reports on how much customers have ordered for using the sub-product price.
I also have a quantity acting as multiplier, that is 1x by default, or however many I define if I do.
I also need to be able to override the derived price in case I want to apply a rebate to one or more of the items, or if I want to override the whole value altogether.
There’s also the issue of prices changing, but then invalidating old records. For that I have an “Saved price” field that completely override any other field, and old orders would use this field.
@Borealys I watched the video, thanks for the great explanation.
I should say the setup is pretty complex, but I hope I got the problem. Now I have one question. Let’s say, we have two enemies: Goblin and Jelly. Do they have the same set of attributes? I assume that is not always the case, since, for example, Jelly might not have Pursuit behavior, thus Jelly will not have fields for attributes that define Pursuit behavior.
If this is correct, here is the problem on a meta level. Type in Fibery is static. It means it will ALWAYS have pre-defined set of fields. Technically it is possible to generate fields when you attach some behavior or attribute to an entity, but these fields will be visible for ALL entities of this Type. Let’s say, if we will attach Pursuit behavior to any Enemy and generate fields, all enemies will have visible fields for Pursuit behavior (Goblin - correct, and Jelly - incorrect for our case).
It is not possible to have a Type with dynamic (changing) set of Fields for different entities based on attached behaviours.
To be honest, I can’t provide a good solution so far. Here are some weird possibilities:
Live with huge redundancy. Every Enemy entity will have fields for ALL possible attributes and behavior and you will have to not fill them if they are not required.
If you have sane amount of enemies (let’s say 100-200), maybe it will be fine to have a separate Type for EVERY enemy. Goblin and Jelly will be separate Types that will have connections to behavior and attributes, you will select required behaviors for Goblin and will be able to generate fields by pushing an Action Button. In this case you will have only relevant field for every enemy, but it might be a nightmare to build views. For example, to see all enemies you will have to create a Board with 100 types selected.
If you have Classes of Enemies that share EXACTLY the same behaviors, you might tweak solution #2 with Enemy Class Type and reduce amount of unique Types, like Jellies, Dragons, Goblins, etc.
Theoretically solution #1 can work fine if we will be able to hide irrelevant Fields for every Enemy based on attached Behavior. Fibery has hidden UI extensions mechanism, so maybe we can do it, but I am not sure so far.
NOTE: Fibery was designed to manage work, it seems you are trying to build the whole game domain inside Fibery. I wonder what is the value here? What you will do with this model later?
We are working all day long with your responses to find a solution to our problem.
@mdubakov With your answer about Static vs dynamic fields, we now have a better understanding of the boundary of Fibery, which helped us elaborate the best solution for us and within our constraint. We think we found a not perfect, but good solution. But first of all, there is 3 things we need to know that could be gamechangers for our problem.
Is it possible, with an action button, to generate a new Entity of a certain Type and insert some values in his fields? We would like to create a batch of Entities already linked to each other with this.
Is it possible to generate, with an action button, a table inside a rich text Field based on attributes Entities that are linked to another Entity?
If so, is it possible, with an action button, to “Push” rich text table cells to a google spreadsheet, and “Get” data from a google spreadsheet to generate a rich text table?
If it is possible or if you can make it happen, I think it would solve pretty much all of our problems. It could really help other businesses too. That would be kind of Fields linked to an Entity instead of being linked to a Type.
Their button is pretty powerful. It uses JavaScript (executes in NodeJS v12) that you code yourself.
Yes. You can also use any commands found in their API inside buttons via a method not documented there called executeSingleCommand. See an example usage here. They also have an easier to use API available that has a createEntity method. Not sure if the new entity is returned, as per their documentation it says it returns nothing—although not sure if that is correct anymore?Edit: Indeed it returns all the data of the new entity. To populate with values however you either need multiple calls, or you can use the API to create and set everything all at once.Edit: All fields of the entity can be set on creation too.
I am not sure, but likely. I have not used the API interaction with rich text fields yet. I would guess it is possible somehow? Pretty much anything can be searched for or written via the API. I do know that the rich text field itself is available as I have seen it, but under the name “Collaborative document” or something.
Most likely. The button API also has an external request function available inside the button API. I use this external call function on a webhook link to create a notification in our MS Teams channel when someone click the “Mark as complete” button (it also does other stuff at the same time!).
Thank you for asking! I gave the mandate to one of my programmer, he’s finishing a feature he was assigned to and will look at it after. It’s gonna be next week or the other.
What he’s gonna try is :
Create a button which will copy an Entity type with his relation to other Entities types to an other set of Entities types. Short, we’re gonna have a generic model to create instances of.
Based on relations to other Entities that we call “Attributes” he’s gonna try to generate a 2 columns Table in a Rich Text Field with the names of the “Attributes” in the first row and then add a “default” value which be a field of the “Attributes” type in the second columns. My designers will then be able to simulate Entity-field instead of the usual Type-field. Just with those two, it’s gonna be more than enough to justify that I transfer our pipeline on Fibery.
Later, if the 2 test above works, we’re gonna try to get the values entered in the table’s second column and sync them with a Google Spreadsheet and even Unity.
That’s pretty much the roadmap. The Fibery’s hype is still on!
