Video game studio hoping that Fibery is the solution!

Thank you guys for trying to help us! :smiley:
I will put together a video and post it here in a new thread. I’ll start it right now so it won’t be long before I post it.



Okay, so here is the video at last! :slight_smile: I hope that you will be able to understand my French accent. :wink:. I’ve put a little sequence of a cutscene of our game at the end of the video just to share some of the real thing (still in development and gonna look prettier months after months). Tell me if I should make an other post with the video.

There’s one thing I think I wasn’t clear about after looking back at my video is that since you should always have the same behavior sequence child in the same behavior state entity if you reuse it with an other enemy, the same behavior sequence could be also used by an other behavior state. For example, the behavior sequence “pursuit” could be both used by the behavior state “Attack closeRange” and “Attack longRange” for example.

@mdubakov If you want to take a peek at all the videogame studios in Quebec (Canadian province which include the city of Montreal) here is a list of the studios members of the organization I’ve founded which include small studios of 4 people up to the largest studio in the world, Ubisoft Montreal with 3500 people :

I hope that the answer is easy and that this is just a paradigm that I don’t get. My programmers would be glad to create a tool with the Fibery API to generate new games entities directly in our game engine from Fibery and we could also use the powerful graphs to look at our attribute’s values and balance our game right from Fibery; letting the designers do their thing in one app and the programmers in the engine. :slight_smile:

Thank you very much for your time!!


Hi, thanks for your time and answer @mdubakov ! :slight_smile:

 1. It's hard to say right now, but easily between 30-50, probably even more!
 2. Yes, every Type will have static fields! We also want this to be easily scalable, if later we want to add new attributes to a Type, we want it to be easily done!

We did try that solution. As @Chr1sG suggested, we tried to have a Type for every content element, with each their own Fields to put the corresponding attributes and values for them (in the right column).

But our problem is that we want a database that would list all of our content elements. This meant that this database would be linked to way too many databases, so they would have Fields for every relation to another Type, and we didn’t want this :stuck_out_tongue_winking_eye:

** Maybe not every Type will have static fields. We might have a few Types that would have dynamic fields. We would then want the type to automatically create Fields for the attributes it needs, depending on the linked Types

But for now it’s uncertain that we would need dynamic (non static) Fields.

I read your post on Polymorphic relations. I think that might be the solution! I could have Types for every content element, and another Type regrouping all of my content elements. I would need to be able to link the corresponding content elements together, and not link the Types together. That is if I understood right how polymorphic relations would work.

1 Like

Hey thanks! Just for clarification to the community, I believe you’re referring to this post:

Wanted to clarify as there is a lot of discussion about this around here!

I would call that the “True North” post on the subject here in the community. Of relevance: @mdubakov edited the subject after I posted and added the “[Polymorphic Relations]” clarification in the title, and as you can see he also chimed in there. I continue to really hope for this, as an ongoing problem as you build out in Fibery - and Notion for that matter - is the increasing number of fields that you need due to every single relation requiring one. All the more if you want to use Lookups to add in information from “parent” relations, which I talked about here, as it’s becoming a big problem for me:

Finally, having you in here interested in features gives me even more reason to wish for some kind of voting here in the community.

I am starting to wonder a bit about what is the basis for prioritization within the team, as some features that we are getting lately don’t seem to be that high priority, while basics like Activity Stream, Date-driving notifications, and others, seem to have no discussion at all from the team and leave me to wonder how long I’ll be waiting on them. Without this stuff Fibery is not really suited for true Team Work Mgmt. Polymorphic is a great case in point: @Oshyan, @Chr1sG and I have had lively communication about this for weeks, but haven’t seen any discussion of it in from Fibery officially in Twitter, Blog, Reddit, and most importantly, actual responses here in the forum! Makes me wonder about Michael’s original declaration and whether Fibery still wants to do this. If not, I think they should at least spend 5 min and jump in here and tell us!

Thanks for the support!

1 Like

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.

1 Like

You’re right, I should only use Fibery terminology to make it clearer :slight_smile:

  1. I meant that I would want a Type that would group together all of our content elements. That Type would be named “Content element”.
  2. 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 :slight_smile:

1 Like

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… :slight_smile:

1 Like

@B_Sp I didn’t forget about you! :slight_smile: 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.

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?

1 Like

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?

1 Like

But wouldn’t these views be cluttered with informations (I could hide most, but still) that only specific Types had?

It would have other purposes, but I will have to wait before saying wrong information. I will look into this and come with another reply :slight_smile:

Thanks for your time by the way! Really appreciated :slight_smile:

1 Like

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 :slight_smile:

1 Like

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?

1 Like

This is exactly what we want yes ! :slight_smile:

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)


Not 100% sure, but yes we could want that!

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:

  1. “Attribute” with several other sub-attributes/values that can be used other entities of different types.
    Solution: Create entity that they all share.
  2. 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.
  3. 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.
1 Like