Video game studio hoping that Fibery is the solution!

Love your enthusiasm here! I used to work in the games industry myself, so I have a soft spot for it, and sympathy for your challenges with tool fragmentation/proliferation.

The Fibery team seems to be still working to find market fit. They have a general direction for now, but I think they may be open to the realization of new, unexpected markets like this. So I’m hopeful that @mdubakov or someone else on the team would take the time to talk directly with you. If you really can in part represent the broad interest of 14,000 potential users, that’s worth a conversation!

So welcome here, I hope Fibery can meet your needs, and I hope you get a chance to discuss it all with the team soon. I encourage you to reach out to them directly if you haven’t already!

1 Like

Reading over your list here, Fibery seems to already cover a lot, no? Give it a couple more years and I would think/hope it should be capable of all of that. Integrations are coming soon. Time tracking is already actually possible (rudimentary) with scripted buttons. Project and task management are good except for needing a better reminder/notification system and “activity stream”, I think. Project Management is good. Planning and feedback gathering are both pretty good, though the latter could benefit from forms integration. CRM is pretty close to “there” for me, just need polymorphic to avoid having a ton of visible relations fields as any contact can relate to many other Types. Chat is another big missing feature, but one I personally hope they do with a good integration rather than reinventing the wheel…

Anyway, I believe I will be able to do 90% of my work in this one tool within 1-2 years. :grin:

1 Like

Hey, good real time discussion!

Great expansion of my points. Indeed, my goal with that is that Fibery seems to be getting there based on stuff on that list - which wasn’t comprehensive but rather stream-of-consciousness :slight_smile:.

A couple of responses:

  • I would really like to see both Time Tracking and Recurring Entities developed to world-class levels. The Time Tracking you speak of I’ve looked at too, but there are issues, such as if you have a remote team or contractor developers, something that I’m sure is common in Product Teams (software), you can’t have one Type for the time entries as you’ll run into permission issues, unless you want your contractors seeing everything else you are tracking time on, and I don’t for sure!

  • We also need some basics like Activity Stream, ready-for-prime-time comments, More of content indexed in Search, etc. But we talk of these all the time and I have to believe they are coming soon, if not discussed by @mdubakov and co lately anywhere I’ve seen. Which is why I keep bringing them up and I am at this point pretty desperate for that stuff! I would much rather have any of these than other stuff that seems to be coming out lately like more App Templates, some odd additions to Whiteboard like Lock and “Rounded Edges to Boxes.”

I hope some of this comes sooner than 1-2 years as until we get stuff like Activity Stream, Proper Search, and possibly Native Apps as my team is begging for them, I for one can’t really be sure about committing to Fibery as much as I’d love to!

1 Like

Thank you. I will certainly not convert 14000 day one, but I’m sure gonna evangelize the hell of it! :grin:

I’m also teaching videogame project management in 2 universities and I will use Fibery to implement all the structure and processes that I’ve developed for the last 12 years.

There’s not a lot missing to Fibery and if it has polymorphism as you say, it would be a major plus that will turn me and my team into Fibery users right away even if it misses little things that would be nice like dependencies in a gantt style, mindmaps in the white board, forms like in Wrike for employees vacations, survey and other stuffs.

For the rest, I could already implement a great management pipeline right into Fibery for game development. @mdubakov tell me if you would be interested to talk, I don’t want to bother you if you have other plans.:sweat_smile:

1 Like

Big +1 on Activity Stream. I don’t need time tracking myself, but more importantly I still think it could be better handled by an integration, with less effort and more features. But that’s my perspective as someone who doesn’t need it. :wink:

1 Like

I am really counting on Fibery to do its own Time Tracking! If this was Notion, I’d probably have expectations lower and that an integration was all I could hope for. As somebody relying on Time Tracking and whose tried a ton, there is usually one big caveat and that’s that the integration requires you to upkeep in its tool separate projects, users, etc. - basically duplicating the work. Most good Productivity stuff I’ve used such as Wrike, Teamwork, ClickUp, Hive, Jira, etc. have solid, native Time Tracking that you can analyze within the app. A notable exception is Asana which has multiple integrations because it has no Time Tracking natively. All these integrations are subpar, mostly for the reason I stated of doing double work.

I still hold out hope that this declaration will not prove to be empty!:

Perhaps I don’t fully understand your problem @Borealys but it sounds as though you need to create a fibery Type for each content element, and define the Type Fields to correspond to the attributes required for that content element.
And then it sounds as though you want the list of Types and their Fields (elements and their attributes) to be recorded in a ‘meta-database’ somewhere.
Is it correctly understood that you want to be able to update the ‘meta-database’ and have the changes reflected in updates to the Types and their Fields?
If that’s a correct understanding, I think the best solution is to use the API to maintain integrity between the meta-database and the fibery Types.
Of course, the meta-database can itself be stored in fibery and you can use action buttons to trigger an integrity check/enforcement.

Am I close to helping? :slight_smile:

2 Likes

@Borealys @Louis-Felix Hi folks, I think you can solve the problem more easily. Few questions:

  1. How many different Types you will have? I can imagine 20-30 no more (like Enemy, Weapon, etc)
  2. Does every Type has static fields? I mean an Enemy ALWAYS will have hp, speed, etc.

If this is the case, I don’t think you need Attributes at all. You just add required fields for Enemy, Weapon, etc and they will always visible in right column to fill.

2 Likes

Yeah, I did wonder if it was as simple as that, but there were a couple of things that @Borealys said that made me think there was a meta level:

Also, the idea that the solution might be applicable for more than one game design studio made me think that the types shouldn’t be hard-coded.
Also I think that sometimes different people use different terminology, so it’s not always clear that what one person means by database, element, attribute, etc. is necessarily the same thing as everyone else!
I hope @Borealys might come back to us to see if any of us is getting close to understanding the problem he faces.

1 Like

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.

Cheers!

LF

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 : https://www.laguilde.quebec/en/members/

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!!

LF

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.