I'm not talking about the big studios now though because I'm sure they pay most of their team by the hour and no a share of the revenue.
I'm talking more along the lines of indy where it's very rare for people to be able to afford paying others by the hour... leaves only one option of paying for a share of the revenue.

And in the case of forming a team where everyone shares the revenue... isn't it a lot better to have as few team members as possible?
Like it would be a great waste of money to have more than 1 programmer? First of all it's usually not the case that production increases by 2 times just because you have 2 programmers.. And even if it did increase by twice the speed then I don't think it's worth it still... because..

Now you hve to share 50% of the revenue with the other guy.. but if you do it yourself it will take twice the time... but you get 100%.. So while it does take twice as long time if you're doing it alone.. you're also getting paid twice the revenue.

What do you think about this?

I'm just wondering because I'm thinking of joining a team for share of revenue but they always have so many team members already... 3 programmers and 5 artists etc.. on an indy game. That would leave such a small share of revenue for each member that it just don't feel worth joining them. If it was a world of warcraft millionaire studio team I could join and get 5% of the revenue I would sure as hell do it but not 5% of an indy game that might become a fail.

If I was an experienced programmer I wouldn't share the revenue with anyone.
I would outsource both the art and sound because that's something most people can afford if they don't spend all their salary on beer etc.
And as long as they have designed the game so it's not going to be too heavy and high quality 3d art.

Isn't it better to have as few people working on your game as possible?
... because I'm thinking of joining a team for share of revenue but they always have so many team members already... 3 programmers and 5 artists etc.. on an indy game.

Oh, I see where you're coming from now. At first I thought it was a Production & Management question, but you're asking from the other side of the fence. I'll move this after.

So you're saying you are in it for the money. You want to join an indy team to make money? That's very unlikely to work out well for you. Very few indy teams actually make money (especially enough money to significantly repay each of the team members). You should expect to be on several teams before one of them pays off for you. And I think you should further adjust your expectations -- rather than joining an indy team expecting a payoff, I think you should expect to build your learning, your portfolio, and your resume. Then with that under your belt, you could even look for a job in games.

Now to try to figure out which forum will get you the most useful feedback...

Now you hve to share 50% of the revenue with the other guy.. but if you do it yourself it will take twice the time... but you get 100%.. So while it does take twice as long time if you're doing it alone.. you're also getting paid twice the revenue. What do you think about this?

You would be still working for the same effective wage per hour, you are just taking more time (and therefore more risk) before seeing any of it.

You can have two people working for $5/hr for 3 months, or 1 person working for $5/hr for 6 months. Either way you are earning the same wage.

As Tom pointed out, the chances of making any substantial profit from a hobby project are very small.

Let's assume you did manage to do fairly well and make $5000 on one of the app stores or some other source, and you only spent 3 months of hard work on the project which equates to roughly 500 hours. That's a whopping $10/hr, about what you can make flipping burgers. If it took you six months you are earning below minimum wage. If it took a team of two people 3 months of hard work that is also below minimum wage.

To be financially successful you need very rapid, very inexpensive production, and you need a great product with a lot of sales. All of these are unlikely for a hobby project by inexperienced developers.

I don't agree with the comments about indy games not making enough revenue.
I think biggest reason a lot of indy games don't work out is because they don't have a good game design from the start.

When you are indy you are limited in practise, not theory in what kind of games you can make.
Not in theory because in theory you can make anything if you have enough time for doing it and learning.
But in practice you don't have all the time in the world because most people don't have motivation of not making money for too long time or can't stand a slow development progress and the light at end of tunnel is to ofar away etc.

So as long as you have a good design from the start that makes a great game that's doable for a team of 1-2 persons and some outsourcing then you can make a lot of money. Like a multiplayer f2p game with a cash shop.

I don't agree with the comments about indy games not making enough revenue.
I think biggest reason a lot of indy games don't work out is because they don't have a good game design from the start.

That's the reason why they don't earn enough revenue. Have in mind that the successful Indiegames out there are a vast minority.

When you are indy you are limited in practise, not theory in what kind of games you can make.
Not in theory because in theory you can make anything if you have enough time for doing it and learning.

There's not just the theory of what general things you can make, there's also a bunch of theory on what specifically you can make within those things. Not only that, but there's also the many factors of programming etiquette and routines, that can turn around and bite you later on. Things like sloppy commenting or using less effective programming objects/functions. There's also going to be a lot of problems if you don't know how to effectively collect garbage and manage the stack and heap of RAM. Just take Notch as an example, he's the brilliant guy who designed Minecraft but even he forgets himself some times and he had no idea that Minecraft would be that popular (which means that he's got limited understanding about the player community, especially considering the vast success of The Sims and Second Life).

Remember that theory is based on knowledge, and that's something you can either have or not have. My point is that you can know everything about the given programming language and still be a bad game designer.

So as long as you have a good design from the start that makes a great game that's doable for a team of 1-2 persons and some outsourcing then you can make a lot of money. Like a multiplayer f2p game with a cash shop.

Yes, but it's not enough to make a lot of money. Not only do you need to have an economy as your developing the game, but you also need the game to sell enough to pay that back and also back you for the next project. Cause it's rather risky to have to take up huge loans for every single project. Suddenly you make a flop and you're history.

[quote name='glhf' timestamp='1334701856' post='4932304']
I don't agree with the comments about indy games not making enough revenue.
I think biggest reason a lot of indy games don't work out is because they don't have a good game design from the start.

That's the reason why they don't earn enough revenue. Have in mind that the successful Indiegames out there are a vast minority.

When you are indy you are limited in practise, not theory in what kind of games you can make.
Not in theory because in theory you can make anything if you have enough time for doing it and learning.

There's not just the theory of what general things you can make, there's also a bunch of theory on what specifically you can make within those things. Not only that, but there's also the many factors of programming etiquette and routines, that can turn around and bite you later on. Things like sloppy commenting or using less effective programming objects/functions. There's also going to be a lot of problems if you don't know how to effectively collect garbage and manage the stack and heap of RAM. Just take Notch as an example, he's the brilliant guy who designed Minecraft but even he forgets himself some times and he had no idea that Minecraft would be that popular (which means that he's got limited understanding about the player community, especially considering the vast success of The Sims and Second Life).

Remember that theory is based on knowledge, and that's something you can either have or not have. My point is that you can know everything about the given programming language and still be a bad game designer.

So as long as you have a good design from the start that makes a great game that's doable for a team of 1-2 persons and some outsourcing then you can make a lot of money. Like a multiplayer f2p game with a cash shop.

Yes, but it's not enough to make a lot of money. Not only do you need to have an economy as your developing the game, but you also need the game to sell enough to pay that back and also back you for the next project. Cause it's rather risky to have to take up huge loans for every single project. Suddenly you make a flop and you're history.
[/quote]

So you're basically agreeing with me and adding a few points to it?

So conclusion is that you need to have a great game design before starting.. but you need a person who has vast gaming knowledge and great at theory to do the game design. I think I've made a thread months ago about that.. How can you know that YOU know better than others and how can you know who knows better than who.. basically who are you supposed to listen to/be the game designer? But that's a different subject really.

basically who are you supposed to listen to/be the game designer? But that's a different subject really.

It sure is. I may need to move this thread to the Lounge.