I'm an indie game designer and have been trouble finding a reliable programmer to create my game (it's a SP and MP final fantasy tactics like game). I want to program the game to be cross platform so I am considering Love2D, java, or C. I am considering hiring a programmer to work on it for me since I can only do basic stuff. However, I work a normal day job like most people and can't afford to pay a lot. Before I commit myself to this option what would be a reasonable amount to offer for a project like this? Also, what would be a typical way to measure work (pay by milestones or pay by month?).

1. Why do you want the game to be cross platform compatible? Which platforms specifically are you trying to target? Why? What's the business logic behind it? If you don't know the answers to any of these questions, you really need to sit down and figure out why this is a necessary requirement and what you're objectives are. If you're committed to cross platform support, it's going to take some factor of X time longer to complete and ship your game. You'll almost certainly want to use a game engine.
2. Now you want to specify a programming language requirement as well? Why?! That almost guarantees that you're not looking at a specific game engine and that means your multi-platform support is going to be excruciatingly difficult and cost a lot of time and testing. My recommendation is sit down with your programmer and pick a game engine he/she is very familiar with.
3. Since you're working a day job, that's going to make things a lot more difficult for you and your programmer to complete the game. What happens to their progress if they have a critical question for you? Can they interrupt you at work or do they have to wait? How do you keep the pace of work smooth and seamless? What happens if you get home at night and are burned out by work and can't muster the energy to work some more on a game project? What if you lose your motivation/commitment to the project? What if that happens to your programmer?

4. You want to pay your programmer well enough to keep them motivated to keep working on the project. The precise amount of money that comes out to varies by programmer based on their level of experience, motivation, alternative offers, economic circumstances, interest, etc. The only way to figure this out is to talk to your prospective programmers.

I didn't make two threads although the forum did time out on me and I refreshed my browser so it's quite possible two were made--if so it was quite unintentional.

Anyway--OK pay by milestones; what do you think is a fair wage? I guess it would depend on the milestones and the number of them.

Like for example, if it were broken into the following steps:

Milestone1 : Proto build with basic features: isometric drawing, unit animation, terrain height, field rotation, zooming in/out, unit customizations, class /experience /equipment tables, etc

Milestone2 : MP alpha with map editor

Milestone3 : MP alpha with map editor, with AI, with army editor

Milestone4 : MP alpha with map editor, with AI, with army editor, with replays

Milestone5 : MP alpha with map editor, with AI,with army editor, with replays, with saves

Milestone6 : MP beta with map editor, with AI,with army editor,, with replays, with saves

Milestone7 : MP final and SP alpha with campaign editor (story scripting, event scripting like chests with items)

Milestone8 : MP final and SP beta with campaign editor (monster units, monster AI, victory/loss conditions)

Milestone9 : MP final and SP final with campaign editor

I think that's too granular for milestones. Most projects pretty much say "We'll pay you after Kickstarter, and more after public launch."

As for wages, like I said before, it's mostly profit sharing. So, if say, you make 25k in your Kickstarter campaign, and you have 2 programmers, 1 artist, then you can give each 5k, and keep the remaining 10k yourself. It's really not something set in stone.

You can pay something i dont know 10$ for an hour, As the game creation takes usually quite long it becomes quite expensive thing;

Second problem it that there is quite high risk it would slow down infinitely before it would be finished.. (how to prevent it)

Third problem is to sell it and make more money than it cost..

I have no busines experience at all but those three problems are obvious ones

have no busines experience at all but those three problems are obvious ones

Compensation is ALL but obvious, even with straightforward wages.

The best plan is the one you mutually agree on, and the best starting plan is to discuss with your team individually and ask what they'd be comfortable with, being straightforward about your position as you've been in the OP.

Professionals will understand and value this rationale and may or may not agree with the circumstances (assuming the latter, they would never agree to any terms any way).

Once you know what they'd ideally like, you can see if that makes sense to you, and provide a formal offer to them.

There's no magic way of doing this.

Normal rates around here(western europe) for freelancing programmers are in the $50-$200 / hour range. I would expect US rates to be similar.

Freelancers have to pay for their own equipment, licenses, insurances, taxes, social security fees and put away money for downtime between projects, their retirement, vacations, etc (costs normally covered by an employer) and thus they will be significantly higher than a normal salary.

The success of any software project depends heavily on the quality of the staff involved, attempting to cut costs by going with cheap freelancers is very likely to backfire(inexperienced programmers will most likely require far more time even for simple tasks and are far more likely to deliver low quality code)

Throwing in revenue shares is an option if the OP is unable to afford paying market rates but he needs to consider the risk everyone takes when assigning shares. It is unfortunately quite common for "idea-guys"(not saying the OP is one of those, but they are unfortunatly quite common) to assign the majority of the shares to themselves while letting everyone else take all or most of the risk. (working for free or at a reduced rate is equivalent to investing money in a project).

a fairly decent way to assign revenue shares to a team of partially paid freelancers is to:

* give them 1 share * (TheRateTheyAreWorth - TheRateYouPayThem) for each hour they spend on the project.

* give yourself 1 share * TheRateYouPayThem for each hour they spend on the project

* give yourself 1 share * TheRateYouAreWorth for each hour you spend on the project.

* if you spend money on the project in other ways(servers, hosting, marketing, etc) give yourself 1 share per <insert_unit_of_currency> spent for that.

This gives everyone a share proportional to the risk they take and noone gets shafted, if you take a reasonable share of the risk(by paying a portion of everyones normal rate and/or by putting in solid, high quality work yourself) and keep the total risk other people take down you can attract and keep some decent talent even on a tight budget.

I prefer basing shares on results as opposed to time.

You can also agree on static shares plus a split of profit, that way, they get a static % of the game's funding (insures they get money), plus royalties on sales beyond a certain threshold (insures they are willing to work hard for a better product).

That being said, a share-only agreement would dictate that you know your team well enough. You should handpick motivated (and capable) individuals you've known. On the upside, most "sharks" won't joint if this is royalty only.

Handing out equity shares in exchange for units of work is usually an extremely horrible idea.

Having shares that are constantly diluted every time new work is added is an even more horrible idea.

There are proper ways to divide up ownership shares in a startup. Those are not the way, unless your goal is to sell your budding studio away. You may start up a brand new business, but if you follow that route the business will not be yours very long.

Who decides what makes a share? How do you track it? How do you turn it into value? Is the person who contributes 50,000 lines of horribly buggy code going to get a bunch of credit, and the person who rewrites all of it as a 5,000 line rewrite of the system going to only get a tiny credit? If a concept artist submits a bunch of concepts that are universally rejected, to they get zero credit? If somebody's contribution is eventually removed, does their credit also vanish?

Since credits get diluted as more people get free credits for submitting work, does that mean the people who started everything up, investing 2000 or 3000 hours during the most risky part of startup have their shares diluted to nothing as more people come on board? Their year of sacrifice becomes equal to a few weeks of team effort, is that what you wanted?


Pretend you are in business and go read some business books and business web sites about startups, company ownership, and funding.