Does Rev Share Games Ever Make Money

Search Unity

Unity ID

A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate in the Unity community.

Forums
Menu

Hello,
I've been a hobbyist for a long time, but it's that time where I'd like to try collaborating again and making something cool with other people who are as enthusiastic as me.

While I can do everything related to game development, I'm not sure I can commit enough time to a project to warrant a paid position but I also want to make sure it's a project that people are motivated to finish so I ask...

Have any rev share projects from the collab forum been released? Most of the times I've tried collaborating (even on a paid project) it ends up getting cancelled. I don't even care if it sells well (though, it would be a bonus). I'd just like to help make something cool and maybe learn/teach a few things in the process.

Any examples would be very appreciated.

Kindest Regards,
If you want to make things that are cool and maybe learn a few things in the process, you're better off working on your own. Revenue share projects have about the same success rates as unpaid work does in general because, when you get right down to it, it still is unpaid work. You can't eat off the promise of maybe making some money in the future.
If you want a better success rate, you pay people. But even as you said, those projects can fall apart as well.
The only two successfully released games built on the "unpaid collaboration" ideas I know were Eternal Summer and Katawa Shoujo, both of them visual novels that took a lot of time to develop.
Revenue share project means unpaid volunteers, and those project appears to have something like 99% failure rate.

Because I haven't been watching the Collaboration forums, I don't know how many of those projects succeeded.
With all of the people who have posted this question here clearly there are many people interested in such a thing. What happens to these people? That is a good question.
Maybe try searching for their posts and comment on them to see if they are still interested. Because they would have been told the same as you... give it up basically.

Unfortunately, one of the big issues here is such posts often get moved to the collaboration forum where for some silly reason people are not supposed to comment (I *think*) and that probably kills 99% of such endeavors because there is no sense of community.

Maybe try to find a better site out there that is more supportive of such a thing. I remember seeing some like teamup or something. I don't remember now but there are sites very supportive of linking people up.

Last edited: Sep 18, 2017
I agree, I just wanted to make sure I wasn't crazy and it really was that bad. It almost begs the question on why have that subforum at all?
I've tried collaborating several times over the last few years and even amongst paid projects, the longest I've been on a project was 3 months. A lot of it, I feel, comes down to 2 things. Experience from the organizer (they are usually just "Idea People") and organization (No VCS, Documentation etc).

So if no one else has seen any, like GarBenjamin said I might as well see if there is another place for this. Any suggestions on a place like this?

Also, I think you're onto something about the lack of commenting in collaboration. It really kills the community feeling.
Many years ago I participated in several collaboration revenue share projects, some of them were quite lengthy (think half a year or more). All of them failed.
Based on my experience I see lack of funding as a big red warning flag indicating that the project is very likely to die unfinished.

Because of this, if you're looking to get some experience, it might be a good idea to still charge for your service, but charge a small amount.
I'd recommend checking 1GAM, GameJolt forums and considering participating in game jams.
In those places you will find very active communities of people actually making games and often just for fun. Also many Indie games and teams started out as much smaller simpler rough game jam projects.
I do participate in quite a few game jams, but I've never collaborated in any. Don't know why didn't start there. Thanks for that, hopefully, I can find a few that will be enjoyable.I've started doing this as well, I run into another issue there with people losing track of scope but so far it has been fairly successful. Thanks for that. I definitely recommend it for others. Just make sure to define a clear and exact scope. (You will do X but not X)
Hopefully someone else can stumble across this and learn from it.
I think you'll have much better luck if you try it in communities of active developers... maning people continually completing games and releasing them even if only on the 1GAM website, gamejolt or game jam entries list. Such people are doers actually completing games so that automatically weeds out the hurdle of coming across people talking about making games but never completing anything.
I participated in over a dozen rev share projects between 2003-2011 and the only one I know of that didnt fizzle out and die was FolkTale (on steam).
I stopped participating in late 2011 when I started a new job and had real life requirements so I dont know if the project eventually switched to paid participation or if it continued as rev share.
While I was on the team we had roughly 5-6 part (full) timers diligently working on the project not including the lead designer/developer.
Wow, I had a feeling rev share was rather poor, but I didn't think it was THAT bad.
Good thing I'm working solo, I guess. If I ever need any help, I think I will just hire people to do a specific job.
I think this is very good advice and it's how I started to (and sometimes still do) approach freelancing/collaborating on projects. I think perhaps that there is too much guilt around the idea of charging very low prices even as a relative beginner, but it's actually a very good way to get some experience and develop your skills. If someone is just starting modelling for example, and is not great but still does stuff that is way better than 'programmer art', I think that a lot of programmers would see that as a huge opportunity to get a small budget project finished. Think of it as a self-managed 'internship' - and relationships are always better when money or other investments are involved.
The thing to remember though is this: ALWAYS do the best job you can, regardless of the price you charge. If you think you deserve $100/hour, then charge exactly that, but one way or the other don't compromise your work ethic, reputation, and opportunity to get better by doing a half-assed job. It can be easy to think "well I'm just helping out, I'll just knock something together" but what you do is what you will be remembered for, $100/hour or $10/hour.

As for rev share in particular, I haven't done it yet but I think it's the same sort of thing (though on a much smaller scale) as a startup. Everybody has to be dead serious and very committed, there has to be teamwork, organisation, and a sense of purpose beyond simply "I wanna make a game and I will let some people join in". Lack of ability to explain the project in very clear detail, lack of documentation, lack of plan, lack of initial investment (website, prototypes, etc), and not having already signed up one or two quality people that they know personally or otherwise very well, are all good signs of someone who is going to let the horse wander into the ditch taking everybody's hard work with it.
I'm currently working on what amounts to a "revenue share project", we just don't call it that. There's two of us working on a commercial project that has yet to generate income, which sounds to me like the same thing. The main difference is that we don't consider it a "revenue share", we consider it a "startup game company" and are treating it as such. We didn't start it looking for a project to contribute to, we started it out of a shared desire to make games commercially, a mutual trust in each others' abilities, and a solid agreement and commitment on how to make it all work.
If you put it that way, then Vlambeer probably counts as "revenue share" business as well. Rami has said numerous times in talks that he and his business partner don't even like each other, and iirc they make revenue share contracts with all the freelancers they hire.
They're a well-known studio though, with a proven track record and a reputation on the line. I think that's proof enough at least that they will not be letting things just fizzle out. There's probably a queue of freelancers wanting to get on board with them.
I'd like to clarify that this advice only applies to side projects, "for fun" projects, etc.
If you're working as a freelancer fulltime and it is primary source of income, then you should pretty much never undercharge for your work, unless your financial situation is really stable. That's because working underpaid for just a few weeks can make you feel miserable.

However "charge a little" instead of "unpaid collaboration", can be used to weed out good portion of incompetent people and "idea people".
Even if you're a millionaire you shouldn't undercharge because it's bad for the market as a whole which still is full of other freelancers that need to make a living from their work. I see the point of weeding out some of the clients with low pay instead of free, but I think there's also a point to be made for either free or fully paid and nothing in between.
That's for sure, I'm only saying that if you're simply looking to expand your experience, develop your skills and work with other people, it can be a good way to do so. I think that a lot of us are pretty motivated and have interesting ideas as well as reasonable competency in a particular skillset, and given that games are difficult and time consuming, it makes sense to try to get together and get something done. If the person who owns a very interesting project can pay a quarter of a normal freelance wage as well as offer a rev share, I think it's an interesting opportunity, depending on the person.
I did this to get experience on a multiplayer game when I had none - so I just undercharged a lot, explained that I knew how to learn stuff fast but didn't know anything about multiplayer, and ended up integrating a lot of new assets into project without any trouble, and learning about how multiplayer worked.

Definitely though, if you're relying on it for livelihood, you'd probably best not do that (or games entirely for that matter);

As always, it's completely dependent on the kind of person you're dealing with. But I think there's a general tendency in the perception of what's a good project to work on, to skip directly from our own (some of us at least) situation of doing it on rags and dreams, directly to expecting someone to be able to pay $50/hour for a game's worth of content in some particular skillset. If you can find someone with the right character and slave away with them it might just turn into something really fruitful. But of course it's risky if you don't know them that well, and probably even so if you do.
The thing I wonder is, say you did pay someone $50 dollars an hour (or however much they asked for), how would you know how long it would take to get the job done? And how you would know they aren't lollygagging instead of working?
As an example, you mentioned multiplayer, how long would you expect to be able to add basic multiplayer to an existing single player game? Just keeping it simple, one vs one deathmatch. Is this something you could do in a few hours or would you expect a few weeks of work? That would make for a pretty huge difference in expected price to pay.

I've often thought about hiring people to speed things along, but I just never know how much it would actually cost.
Ask for flat fee quotes instead of hourly rates. The contractor will work out how much he needs to charge based on his hourly rate.
Hmm, perhaps I should look into this more. I still don't know if I even want to hire anyone, but at least I could get some quotes to get an idea of what to expect.
That said, by doing this you're pushing risk onto them, and they'll need to factor that into their pricing.
As any freelancer should. Risk is part of the price of admission. Flat fee quotes are more risky for contractors and less risky for clients.
I don't think anybody requesting services in exchange for payment should hold the risk, but a flat fee is fairest (imo) for both client and contractor.
If contractor gets done faster at the requested quality level, they earn more per hour and the client gets product faster. If the contractor is not able to complete the task as fast as expected they shoulder the risk and earn less per hour, but hopefully deliver the final product at the expected quality level.
If the exact work is known up front, I tend to agree. I don't think I've ever had a job where the client didn't ask for some kind of change along the way, though, and if you're going flat-fee that introduces overheads and/or inflexibilities.
It comes down to trust and working relationship. The funny thing is that I've found that where there's solid trust and a good working relationship it doesn't really matter which you go with. If those things are missing then either way there's going to be friction.
In case of a hourly contract, a good idea may be to establish a number of hours it is going to take max meaning there will be no extra money if the cost goes about that amount.You wouldn't. However, if their output does not match expectations and they fail to perform, they get fired and lose the money.Impossible to answer without seeing the codebase or at least playing the game.In which case contractor can simply charge you 5x of the maximum possible price you could've possibly paid on hourly in the worst case scenario. To factor in risks and all. That's the problem with flat fee payment. Someone is always being ripped off - either contract or the employer.
I agree with this, mainly because I think the contractor is in a better position to evaluate risk, as long as they have all the information they need to evaluate it. A client often has no idea what is going on technically and what might make the job more or less difficult, so I think it is much easier for them to be ripped off than it is for the contractor.
@neginfinity I would say that to prevent clients being ripped off by an oversized flat fee risk buffer, they can shop around and get a few quotes to compare. Of course that makes it easier for contractors willing to take more risks to compete but that's just the way things go - they're either shooting themselves in the foot and hurting their business, or doing a better job of tackling the risk - in which case they are simply a better choice.
Which may result in situation similar to $5 programmers, where an employer finds someone cheap, deposits a lot of money, they fail to deliver, and then the ex-Employer vows to spend the rest of their days telling on every forum how all freelancers are scum.
The problem here is that there are different kind of jobs.

There's stuff where risk is low and you're going through the motions. Making sites for someone probably fall into this category, especially if someone uses the same template every time. Those are suitable for flat fee.

Then there's stuff where nothing is certain, most of the project relies on technologies beyond your control, and everything can go to hell due to unforseen circumstances. This is majority of programming, and gamedev will fall into that category as well, unless all the games you create are clones of each other.

When you're making a game, you're not making a chair. Most of the software projects are one of the kind, and are not mass-produced. There are many things that can go wrong, and price estimation requires contractor to gamble and guess how long this is going to take.

This kinda reminds me of the situation in movie industry, especially FX studios.
https://gizmodo.com/life-of-pis-vfx-team-explains-whats-wrong-with-the-in-1531864103

So, I pretty much prefer hourly or daily pricing. Unless we're talking about something that can be cloned from existing code in a half of a hour, of course.
Either that, or they learn that good stuff doesn't come cheap.Don't get me wrong, I think that hourly pricing is much better from the point of view of a contractor. But from a neutral perspective I think that the issue comes down to the ability to price the project accurately, and contractors are at a huge, huge advantage here because they have some idea of what is involved.
The problem with hourly I think is that it makes it very easy for a contractor to make the work drag on, and doesn't enforce them to make a good appraisal of the project at the beginning. And then since the client doesn't really know what's going on, they have to make a gamble, which is never good in business even if you're not the party that's doing it.

Unless an hourly contract specifies clearly some kind of penalty or framework for overtime that makes it very difficult to rip a client off, then it's basically giving someone an open cheque. As a client I would be pretty uncomfortable with an hourly rate, especially if I didn't know enough about the work to decide if I was being ripped off or not.
I think that it comes down to getting the job done effectively and mutually beneficially. Pricing is just a thing that has to happen along the way.And unless a fixed price contract specifies how variations are to be handled you run into similar problems, too. The risk shouldn't be one sided in either approach.
Regardless of which approach is taken there must be systems in place to keep both effort and budgets on track. Neither contracting approach fully solves that, because that's only one aspect of the project's overall management. The focus on costing methodology seems to be detracting from reaching solutions and getting stuff done.

Either way, payment should be based on delivered work. If that delivered work is achieving the customer's goals and is in line with their budget then it doesn't matter which of the methods are being used. On the other hand, if they're asking for a big chunk of money and have nothing significant to show then there's alarm bells ringing no matter which method is being used. I can't think of any cases where a project I was involved in went well or went badly because of the choice of costing methodology.

The thing that's actually important is that both sides of the relationship stay in decent control of their side of the project. Either way, a client should not be handing over wads of cash without clear progress being demonstrated, and either way, a contractor should not be absorbing the cost of additional work. Both sides need the ability to assert relevant control in appropriate situations. That's not just about covering themselves, either, because that should also be in the project's best interest. (Clients don't get the best work out of contractors they're squeezing, and contractors don't generally keep clients they string along.)
Which is why I proposed "maximum hours" thing several posts ago.
From neutral perspective, a contractor will artificially prolong amount of time spent only if the contractor is an idiot. That's because the client will get fed up, leave, and never come back, plus they'll tell their friends about poor contractor they employed. Meaning loss of money.
Indeed, unfinished jobs and unhappy customers do not make for a compelling portfolio.
The problem is that the time taken to do something is very ambiguous, whereas the details about doing something can be as unambiguous as you like. This makes IMO an hourly contract much riskier.I agree, and I definitely think (and this has been my experience) that when there's trust and communication, contracts mainly serve as a precaution. I think that the problem with hourly is that not only it's quite easy to show progress while still not working efficiently, but also it makes it easy for the contractor to default to a work pace that is not obviously slow but nowhere near as fast as it could be.
Ideally though, the client would have a decent idea of the volume of work, in terms of hours, involved in a particular job, and would be comfortable with an hourly contract, but this isn't always the case. I think that as a freelancer a strong work ethic is perhaps the hardest thing to maintain, especially with the on/off of work availability and the lack of social infrastructure around you.

Anyway, I think both approaches can work, as long as they are handled properly. Personally I've found that the most important thing in any freelance job is to communicate a lot, because even if the client doesn't fully understand it, they have the information there and there are always means to utilise it (such as getting the progress evaluated by a third party).
I could do that by just inflating my estimated hours, too.I don't know about you, but I've never done my best work when I'm literally racing a clock for more than a short, controlled sprint. That can get short term benefits, but long term... not so much.
- - -

Something else to consider is that the value of my work is not the hours I spend on a thing. It's the problems I solve for you, or the things I help you achieve. If a potential client is arguing the details of how dollars are derived from hours then they clearly don't understand the value of what I do. And that goes for any good programmer.
I think you're overcomplicating it.
Is the employer happy? Is the contractor happy? Are the problems being solved? This is the important stuff.

It isn't that hard to write a report each week or even each day, but ultimately, if you're trying to ensure that contractor is working at maximum efficiency all the time, it'll only result in inflated prices and not higher efficiency.
Yup. I think my personal record for working in a rush mode was one month, but after that I was mentally exhausted.
The difference being that the client can see this before signing the contract, and can compare with other quotes.Not me either. But I think that it's not necessary to be racing against the clock on a fixed-fee contract. Those who price themselves according to the minimum humanly possible time to do something, will sooner or later either go bankrupt or start cutting corners. I have to say that this is a very good point. If you're highly skilled and established with a great reputation, and you're aiming at moneyed clients, then I'd say that you should be offering the 'premium service' on an hourly basis. I think there are certain transactions that work much better amongst experienced parties that probably don't work very well at the lower end (in terms of budget, job complexity and business acumen).
In the end, the only important thing is that everybody gets what they consider to be their money's worth from the bargain. I'm simply saying that from a neutral perspective, I think hourly rate transfers an outsized risk onto a client, especially when they aren't in a good position to evaluate whether the contractor is setting a good pace.

Overall I'll say again, I think communication is the easiest way to a good result for everybody, regardless of what kind of contract. I've saved a number of situations where things just weren't going smoothly, and I just write up a small 'essay' of what is going on with the job complete with technical details, that has really put things back into order in the relationship.
Unless you add some nice particle fx after the fact
This. If you are futzing too much over details, it's a waste of time and money on both sides. Time to find a more effective relationship.
When freelancing, I generally charge by the hour with an estimate of time. Changes of spec or challenges, I rework the estimate as soon as possible. It's really not that complicated.
Well I must admit that if someone isn't totally happy with the result, no matter how much I undercharged the reaction is the same. So there's a good case for arguing that in practice, the client should assume the most of the risk given that there's not even close to being a linear relationship with the quality of the result and their satisfaction.
Anyway, I have to say that @angrypenguin made a good point. In any kind of business transaction, if the focus is anywhere other than on the quality of the result it's off to a bad start. And in practice, I'm almost certain that hourly rates lead to a more positive outcome.
They should see your estimate before they sign a contract either way. An hourly contract doesn't mean that you don't provide estimates.I think it's more attitudes on both sides of the fence that lead to good or bad outcomes. If the attitudes are practical and the skill is there then I don't think that either method is significantly better than the other.
One significant benefit to fixed price contracts that I have to agree with - and the reason we mostly used them when I was doing contracting at my prior company - is that managers and finance people like them. It gives the impression that the commitment is fixed, even though in my experience that's not really the case because I don't remember a contract where the client didn't change their mind about something. The other important thing, which should go without saying, is that "fixed price" should also be "fixed deliverables". If the customer changes their mind about stuff it should be clear that the project plan, and remaining price, will also be updated accordingly. (And there's more of an overhead doing that on a fixed price basis than an ongoing hourly one.)

Last edited: Sep 21, 2017
Indeed, they are budgeting the project, and need to plan. Open ended hourly contracts without specifics are just a bad idea, unless they are long term (essentially an employment contract)
Agreed, although I think that in practice, like in any long-distance relationship, the limits of communication can easily cause problems when both people have otherwise quite a good attitude and approach - so that's what I think the most important thing is. Maybe communication can even save a relationship with poor attitudes ...Agreed, although I think that for a client who has a quite limited budget it's important to note that the risk is almost entirely theirs when changing specs on an hourly rate.
Ideally in a business transaction both parties have enough information to secure a good value for money or vice versa, but I think the reality in a lot of freelance projects is that access to information isn't balanced.

I'll say though that when lack of information in a transaction is the core problem, I don't think that a fixed price really does anything to fix that directly.

Last edited: Sep 21, 2017