Advanced Payout Distribution

As a Roblox developer, it is currently too hard to properly distribute game revenue in a group with multiple projects.
Payout management in this scenario is too complicated, unless funds are distributed in separate groups - one for each project.

The solution?
It would be amazing to see a more advanced payout distribution system, in which developers can specify the amount members receive for each game the group owns.
I am in the process of creating a network that enables aspiring developers to work in full Roblox developer teams on defined projects that would eventually be published under the group, with funds ideally being distributed by the network to the developers of each project.

Here is a quick diagram explaining how it works now vs. my proposal:

Current situation: All funds go into the same collection which is then distributed, without differentiating the source of the funds.
Untitled%20Diagram%20(2)

Proposed change: Funds are differentiated by project (game). This way, multiple projects can have their payouts managed in the same group.
Untitled%20Diagram%20(3)

Iā€™d love to know what you guys think of this suggestion. Would you do it differently? Leave a reply!

Edit: It is important to note that the group Store is another source of funds. Perhaps this should also be a separate collection from games.

134 Likes

I definitely like this concept!
Honestly, I think that there should be a more convenient way of creating a group network or ā€˜branchā€™ in general.

Right now I add [UD] to every branch-groupā€™s name I make (initials of Universal Development, my group), for example. But it might be a whole lot easier if weā€™d be able to make a headquarters and then have the opportunity to connect them with all the branches. Not by ā€˜Alliesā€™ but preferably a (new) tab where says ā€œBranchesā€ where you can create and maintain branches.

To summarize what came to my mind related to that:

  • Allow financial monitoring for the headquarters & the branches that you own or gave somebody permission to;
    (Being able to view this should be a new permission!)
  • Create a tag with the initials of the headquarterā€™s name that displays on each related branch;
    (Maybe allow color customization and typo fixes to remove special characters, for example?)
  • Allow the changing of names for at least the headquarters;
    (This would affect the tags displayed on branches)
  • Ability to assign ā€˜Directorsā€™ who could take care of 1 or more branches that you own;

Itā€™s slightly off the specific topic, but I just thought it was worth pointing out in case it helps. :slight_smile:
Otherwise let me know, Iā€™ll make a new topic :stuck_out_tongue:

14 Likes

You have my support, this is something that weā€™ve definitely been needing for quite a while now.

11 Likes

@Iron_Legion please include this in the group revamp. It is needed so much, and this is 100% the best way to do it.

13 Likes

This is a much needed improvement and would really help studios manage multiple projects with ease.

9 Likes

I support this idea, however, for the time being I have developed a system to do this already and have posted about it. It requires a 3rd party spreadsheet.

6 Likes

I completely support this. It would make it so much easier to create projects within groups. Maybe this update would be introduced when they eventually get round to working on the groups tab itself?

2 Likes

This is absolutely crucial if we are to realistically see legit studios start taking off. Either that or a new sort of group structure itself completely geared toward game studios.

5 Likes

I would love to see it possible to have group funds not be distributed per item but per month.

Third party methods exist but more official methods would be better tbh

1 Like

Would there be a practical reason for the retention of funds pertaining to the developers in the group for a month?

1 Like

Mostly consistency. You donā€™t normally see game companies paying their employees a minuscule amount every time a copy of their game is bought.

1 Like

Although I do understand the desire to simulate a real company, I donā€™t see the point in retaining funds for an unnecessary amount of time (Roblox already does retain funds for a couple days, hence why there are ā€œpendingā€ revenues).
It should be fairly easy for Roblox to implement a solution that allows you to choose the frequency of automatic distribution, though right now developers can manually issue one-time payouts every month, which is what companies do anyway.

4 Likes

I hate to reply to a thread that stopped getting replies 2 months ago but Iā€™d love to know if anyone at Roblox has considered this idea or if an architecture similar to the one proposed is being evaluated for a future update.
This is the second major proposal of mine with a positive community response but no official replies. See my Disabled Scripts thread.

2 Likes

Sorry for the wait, Iā€™ve gone ahead and filed this and will post back here if I have any questions :slight_smile:

5 Likes

As a member of said network, I support this as itā€™ll just make it a little bit easier for payment to go smoothly! :smiley:

1 Like

simple yet needed idea

Iā€™ve been heavily considering creating a 2nd group just for the purpose of keeping group funds organized, with everyone getting different percentage of payouts for different projects itā€™s becoming overwhelming

2 Likes

Iā€™ve seen this listed in many different threads but I havenā€™t seen a detailed and specific explanation as to why itā€™s important or the specifics that might go behind a feature like this.

How It Might Work
Groups would be able to pay out developers individually for games. For example, if I am running a game studio working on 5 different projects with 2 developers on each project, it would be ideal to be able to set permissions and payouts for specific games. This would mean each of the 2 developers to would have access to the games that relate to them and have individual payouts on those games instead of having to have five different groups for each of the two developers.

The Problem With The Current Group Payout System
With Premium being more accessible to more users to create and be a part of 100 groups, itā€™s hard not to say ā€œWhy is this important?ā€. Brand and simplicity are the major issues that make this a reoccurring problem.

Brand
Many people already have established brands associated with their games and they want to keep their fans of their current group and games. The current method forces them to start over each time they want to add someone new on a payroll or give someone else access. We see this issue reoccurring with many groups as some developers attempt to make groups for new developers to work with without interfering with other projects.

Simplicity
When you release multiple games within your group, you have to get extremely make-shift with how you deal out percentages to other developers. If you have multiple people under payroll for different projects, you are forced to start calculating income of each game and account for taxes, percentages, commissions, etc. There isnā€™t a need for this level of complexity and it makes it much harder to utilize group tools.

Users also have issues finding projects from their favorite developers by group because they are forced to look through all of the groups that relate to their developer instead of having one centralized spot.

Conclusion
Overall, this is a feature that hundreds of developers have repeatedly asked for and pushed in one way or another. This feature would solve a huge amount of issues of brand and complexity that we have with the current system. I would also like to mention that groups are currently extremely outdated and desperately need a huge amount of renovations to make them easier to use for both developers and players alike.

23 Likes

Disclaimer: This is an issue that has been suggested before, and this is not a repeat of those. This is UI design mock up for the group admin page team to illustrate specifically how such a feature could be implemented

Unfortunately I only have the old version of the group admins tab to work off of, but since the admin page updates wonā€™t change the payouts section layout, this should still apply.

I propose adding in a very simple extra bit of UI to the Recurring Payout section, allowing players to select if a user should be paid of from a specific game, or the entire group, and if from a specific game, then selecting which game or games they get a set % from. The ā€œEntire Groupā€ setting would simply put that user into the payout of every single game in the group, at whatever the set % rate is for them.


I designed this keeping in mind the limited UI resources available to the admin page team, so only existing UI was used. The ā€œAdd Gameā€ plus sign is from the ā€œAdd Passā€ UI on each games page, and the scroll bar is from the group info section of the group admin page.

Downside: This layout is simplistic and would only allow players to set a single % rate for each user, not set it per game. This would be easily fixable, but it might be to complex for what Roblox prefers, and Iā€™d rather have this feature out sooner, rather then have it bogged down making it perfect.

Alternatively:
Ideally, the distribution should be set per game, with users then being added onto that games payouts, not per player with games listed for each player. However, this is not how the games page currently works, and weā€™d much rather have this feature out sooner then later over having it perfect.

Alternatively this could also be set inside the game itself in the configure game setting, however this pitch is designed for the group admin team, so that is not explored.

Thank you for your time!

37 Likes

Love this idea! Setting the distribution per-game or per-user is a simple switch that can be implemented if Roblox wants to (even a choice between the two as implementation wouldnā€™t change much).

6 Likes

This feature is long-over due and I would absolutely appreciate the ability to split percentage between game revenue for each of my games. This is an absolute must and something all developers would benefit from one way or another.

8 Likes