What about this:

Me = 20% equity, 12% profit sharing (with overall 100% control for business decisions)

Lead = 20% equity, 12% profit sharing

9 x Coder, Art, Level = 6.6% equity, 8.4% profit sharing

So I still have control, but you own more of the company?

I'd really start with a smaller team. Seems like already planning for you + 10 people is very... optimistic. Also, you dont know what recommendations your tech lead will make as far as how many coders you'll need. Personally I'd start with: you (business + design), 1 tech lead, 1 art lead. If you dont want to do design at all, then add 1 design lead. Start with that, make some progress, grow the team, repeat. You'd also want to decide how much equity you'll give initial recruits versus subsequent ones. Logically you want to give more equity to early hires than later ones. And of course some recruits should get more depending on their experience, how much time they can contribute, etc. It all gets fairly complicated very quickly, but you need a plan that all the initial founders have agreed to... because all that equity will come from everyone's share.

I would also really talk to a lawyer because there's probably all kinds of considerations like what happens if you give someone 10% initially and then they drop out after a month? You dont want to just give away equity unless someone has actually contributed, so you might want to make sure the equity vests over time.

What I bring to the table is industry and customer base knowledge

Okay, so how do you demonstrate that (or the value it brings) to a potential business partner? What games you have leveraged this knowledge to ship, and how can you show you did so? That's going to be one of the first questions anybody you approach is going to ask.

Before you say that's not worth much......WarZ Devs (failed)....DayZ Standalone Devs (failed)....H1Z1 Devs (failed). So you've got the gambit from CCC to AAA development companies, full of devs, full of marketing people, full of various other support people, that all failed. They didn't fail because they were bad coders, artists, and level design.

I'd be very curious to know what your definition for "failure" is, here. And why you think that (at least some of) those cited examples didn't have people with "industry and customer base knowledge."

What about this:

I haven't shipped any games yet. And I understand that might be a deterrent to some. But if they understand the vision, they'll get why what I'm saying is crucial to the development of the game.

Failure is a big initial sales release, only to have the game crater into the ground as a failure at the end. For me personally I will never buy another title from anyone ever associated with WarZ (Infestation), DayZ Standalone, or H1Z1. Those are customers they had, but won't ever give them another look because of the way the game cratered. So yes, they did win by getting a large amount of money up front. Congrats to them. But they lost their customer base for future titles. You don't build successful companies by making your customers so angry they won't come back for more.

I really don't know how many people I need. Truly ignorant there :) But talking to you guys is making me less ignorant :)

Again thanks for everyone's help on this!

p.s. OrOd that is one of the things I'm worried about. The team on Day 1 will probably not be the same as the team on Release Day. Figuring out how to compensate those who "helped" but didn't "stick with it" is going to be a huge part of how much or how little legal trouble we will have.....lol

I haven't shipped any games yet. And I understand that might be a deterrent to some. But if they understand the vision, they'll get why what I'm saying is crucial to the development of the game.

The thing is that there's a big difference between having a vision and executing that vision. Having previously shipped games, especially ones where you took your idea from start to finish, shows that you can execute over the development period and you understand all that's involved. This goes as well for finding your partners, like your tech lead for example. Someone who's an experienced engineer is nice, but someone who's shipped multiple titles or developed their own game is much better.

p.s. OrOd that is one of the things I'm worried about. The team on Day 1 will probably not be the same as the team on Release Day. Figuring out how to compensate those who "helped" but didn't "stick with it" is going to be a huge part of how much or how little legal trouble we will have.....lol

Yup, I would consider a vesting schedule that goes from 0 to whatever % that person gets over a reasonable time-frame, or perhaps based on milestones, or both.

If you were trying to design a game like DayZ, WarZ, Rust, or H1Z1 from scratch, which engine would you use?

I understand that it's suggested I put this in "for beginners" but I'm not looking for beginner advice. I'd like to know what the pros would use.

Well a student's opinion... Anything that can be quickly updated. Which... honestly doesn't change your options much... Most people would roll their own engines, and it's designed specifically to their specifications. It's possible to do this with any pre-made engine that works only as a framework. Because it's all about data handling and delegation.

I wouldn't use Unity for something like this, as adding content would be a severe hassle. Unreal, Cry, and Lumberyard would do just fine as the data can just be loaded from outside. But going on with others, I'd still make my own engine. The code base won't be nearly as massive, and the engine would be designed specifically for the game. Which means that the Client is just a viewer that sends command buffers. And the Server handles all the logic. The server handles all the logic and sanity checks, which means that updating the game and bug tracing won't be such a bastard. You can log everything that happens, restart the server to apply updates, or dynamically change the world at run time.

I haven't shipped any games yet. And I understand that might be a deterrent to some. But if they understand the vision, they'll get why what I'm saying is crucial to the development of the game.

[background=#fafbfc]I'd say this is a bad idea (rolling your own technology stack), especially initially when what one really needs to build is a prototype. Any of the major commercial, off-the-shelf engines will be more than capable of executing that and for a fraction of the cost of rolling one's own. They will probably be more than capable of executing the intended final game as well, perhaps with some custom modifications to support specific edge cases warranted by the design. Cost in this context is measured in time, since nobody's getting a salary: turnaround time to profit generation is important. The longer it takes to get there, the less your time is worth because there isn't a linear relationship between time (and effort!) put into the product from an engineering perspective and dollars you get back out.[/background]

[background=#fafbfc]?I also think this is an oversimplification of what actually needs to technically happen.[/background]

[background=#fafbfc]In any event this isn't the decision the OP should be making, since it's far outside of his wheelhouse. It's a decision the fellow he brings on as his technical lead should make.[/background]

Probably is a seriously terrible oversimplification. However, an arguable one as Dayz is designed to be hosted on user servers, not as one massive MMO. I will definitely agree now that I think about it, that I was in the wrong about saying roll your own engine. My general understanding of the technology behind a massive game like WARZ(even if it flopped badly) H1Z1 is that it's general implementation sever side is still engine independent. So you'll still need to role your own to some degree if one does not already exist. (Unless you guys in the professional world are snickering down at me because you know a secret that I do not.)

There won't be a single game engine (that I know of anyways) that will handle everything a server cluster needs to do.

Initial Packet Encryption as a small but effective defense against script kiddies/Trolls against DDOS.

Some way of tracking your client's state: Did your client suddenly loose connection? Is your client sending information?

Choosing a protocol that is effective for your use. UDP is probably the most common one used, but can be difficult to use correctly. Probably because it's like C, you can do anything with it, but only because it doesn't stand in your way.

Security measures to protect your user accounts, because you're held liable for their information.
User Delegation to other server clusters after initial login. Each server managing some portion of the world, with some form of set up specific to the game. Second Life for example has each region 256 meter squared landmass on each core of a processor. And a Grid is simply one computer of the server. But it's incredibly complicated still because it handles assets on a single universal data bank.

The list generally goes on...

1) If you're not a developer, and you don't have startup capital to pay any livable wage, what do you bring to the table? And not the BS about industry experience and customer base knowledge - I mean actual work that you can do.

2) If you're not paying, and you're not developing, and you're not a lawyer/accountant/etc who can manage some major aspect of the potential business by yourself, you're going to have to accept lower equity than any developer -- you're essentially getting equity for nothing, so it's still a good deal for you. Capitalists get away with making money from others' labor because they have the capital to pay wages while waiting on the returns from that labor. It's a matter of material convenience for the laborers - steady, consistent pay. That's the only way that arrangement works in practice.

3) You're asking people to spend considerable time (probably thousands of hours) on this idea of yours, for no pay, but you want 100% control? You're never going to get anyone talented to stick around with that policy.

4) About the 50hr guy and 5000hr guy - there's no accurate way to quantify time spent. If you ask the developers to log it; some will lie, otherwise will neglect to log time they spent just thinking about something. If you try to count lines; you lose time spent testing, chasing bugs, profiling for optimization, etc - all necessary, often difficult, sometimes requiring advanced knowledge - and all impossible to guess by anyone but the developer themselves. If you try to factor in communication by formal lines (IRC channel, meetings, we) you might miss a quiet, diligent worker and reward a gab.

5) If I take a day off from work to implement some feature in one sitting, I may only be investing 8 hours of work more than usual, but I'm also losing 8 hours of immediate pay to do this. How do you propose to handle this type of investment in the form of lost wages?

I did fail to mention what I'd be doing. It did sound like "hey, here's a good idea, go to work programmers, I'll be back at profit time". Definitely not the case though.

From day 1, I will be out there doing a few important things:

- Website / forum development. Maintaining, posting, moderating, everything.

- Business Transactions

- Marketing / Press Releases / Setting up for Funding Push

- Finance

This is the most important thing I will be doing though:

1. Going out to draw customers into the forum to start discussions about what the game should be like.

2. Polling those customers over, and over, and over until we've boiled down exactly what they're looking for.

3. Communicating this information to the team so they're ONLY programming what the customer would enjoy and find valuable (cutting as much programming waste as possible).

4. Marketing the game to the player base, issuing press releases, building the support for a successful kickstarter or other pre-release funding option. Making sure that our name and game are a constant presence in the genre all the way from initial development, to funding (kickstarter, etc), to launch.

5. Return to step 1, repeat infinitely until the game is ready for release.

Can programmers do that? Yes, some of them very well could. Can they do that job 100% and do programming 100% at the same exact time? No. Why waste valuable programming talent on all of that? Why not have someone with customer service and business experience do those functions?

And I didn't mention the most important thing of all. I have anti-cheat system in mind that will pair with any of the major AAA anti-cheat engines and AAA games. It will basically tie into the game, the anti-cheat, and a third party program to reduce cheating in enabled servers by 90% more than the AAA anti-cheat alone. If I can get the game going, the existing developers would get a profit share in the new business that would dwarf the initial game sales of the Survival game by several orders of magnitude. Example, in any FPS AAA game, the cheating is usually pretty rampant. Anywhere from 5-20% of the player base either has cheated, is cheating, or will cheat at some point. With this system I can get it down by ninety percent to 0.05% to 2% of the player base. The best part is, you can integrate it into any game that uses AAA anti-cheat. So this system could be in COD, BF, The Division, etc, etc, to provide customers an almost "cheat free" experience. It does require players to pay for the program and pay a monthly fee though.

I won't give away details, because that is the "real prize" for the devs at the end of the rainbow, and I don't want someone else to bring it to market. Once it is released, it's literally so simple of a concept, you'll slap your head and say "jeez why didn't I think of that". Because of this secondary business I'll be 100% committed to the first one succeeding because without a "proof of concept" of this anti-cheat working in OUR game, there's no way any other AAA development team would even consider it. But if we can prove it works in OUR game, the sky is the limit. Every AAA anti-cheat and AAA developer can use our new anti-cheat.