Acharis has some very good suggestions.

Another reason democratic systems are bad for a dev team:

Person A cares 100% about the game - he puts TONS of time into it. Made team T-shirts. He gets 1 vote.

Person B just wants his name on a project. Doesn't do much work. Gets 1 Vote.

Person C only works when someone complains that he's not doing any work. Doesn't seem to care. Gets 1 vote.

Person D is enthusiastic, has great ideas, but isn't a very skilled worker. Gets 1 vote.

So the guy doing 70% of the work ends up with 25% of the input. Possibly less if he's quiet or not highly opinionated or bossy. With a small team, a dominant personality can easily bully his opinion onto others. Often this personality type is the one doing the least amount of work.

Since you're trying a "democratic" system, I'm guessing no-one is getting paid. So when people's ideas get ignored enough, they will quit. Or if they're bored of it, they'll quit. If they're being lazy and you call them on it, they'll quit.

It might be different if you're a tight knit group of friends that have been pals for years - but not many people are that lucky.

...Because you need one person to hold this all together...

I'm glad you have your creative juices flowing and are thinking about cool mechanics and different aspects of the game.

However, I agree with Acharis. Another way to stress that you need to start with a game designer first is to suggest that you need to look at the fundamental aesthetics for the game, which will hold it all together. What experience are you trying to create for the Player? What objective do you want the player(s) to achieve and what is their incentive to want to do this? What makes it fun?

If you answer these questions the core mechanics will become clear.

Brainstorm or find someone with a fun idea and concept that answers these questions, which everyone on your team would enjoy and start there; even if you're going to be building in RTS mechanics. The game designer needs to be there to answer these questions that will glue the project together before anything else.

Hope this helps .

You could introduce special connections between systems, like involving expensive combat units in resource acquisition (e.g. Necromancers collecting Corpses and Souls from battlefields where units die and bringing them back at their Necromancery to build bad things), or giving buildings combat uses (e.g. detonating a mill or a rocket factory, or rerouting water from a dam, water mill etc. to cause a flood). Units can be turned into resources (for example, a summoned Demon could pay generously in gold and more interesting things in exchange for being dismissed, filling the role of a resource transformer or producer) and resources could become units (for example, elemental spirits appearing at random in sufficiently stocked warehouses, consuming some material to form a body and joining the player's army out of sympathy).

Warcraft 3's undead race did this fantastically.

The basic resource drop off building for them was a graveyard, that generated bodies, which had almost no purpose at teir 1 upgrades. The undead siege unit had the ability to pick up/harvest bodies, but couldn't do anything with them.

One of their teir 2 magic units, however, could raise skeletons from bodies, whether they're in the open, or stored in a siege unit.

Their primary healer unit could also turn into a flying unit that can hit land/air, but loses it's ability to heal. In this form, it can absorb friendly units mana as well.

Could you please tell me why you think it's such a bad idea to vote? Our programmer has had concerns about the amount of work the as-of-yet unsigned team members will deliver.

Because you need one person to hold this all together (yes, I know Valve does it diffirently), you seem to be lacking the project leader.

Quick advices based on me managing these teams in the past:

- limit the number of team members to maximum 4-5 people, the overhead of additional people is killing

- give the "game designer" position to the programmer (it solves a lot of problems since the main task of a designer is to explain to the programmer how to make things, if that's the same person it speeds up things greatly)

- mercilessly get rid of people who are lazy or "have no time", it leads to nowhere

- it's nice to have one "support" or "marketing" person (to update website, wiki, twitter, facebook, contacting with press, etc), I would surely sacriface one team slot for such person (even at the expense on one artist where artists are quite valuable), note such person could also be the project manager (strangely the project manager does not need to have such great tech skills or even understaning of the game you are making)

Thank you for your feedback. I have linked this thread to our programmer. Our team is going to be 5 people tops (best case scenario) and I hadn't even thought of a "support" person before. I will re-read this many times, I am sure :)

It might be different if you're a tight knit group of friends that have been pals for years - but not many people are that lucky.

This is the case for us. We've been friends for years. It's just hard to try to get them into a working atmosphere from this background. But we'll get there. Eventually :).

Brainstorm or find someone with a fun idea and concept that answers these questions

This is why we did the voting thing initially. Because we want to see the best idea out there before spending our time developing it. We've got our very rudimentary basics down. Once september 1st comes around, I'll make a new thread to detail the creation process, hardships and whatnot.. I'm looking forward to the whole thing kicking off!

How do you connect the different systems for resources, buildings and combat? Do you have something better than making the player see production as an unpleasant and unavoidable cost and setup that the combat part requires, or seeing combat as a harsh necessity that makes compromises in construction necessary?

For example, a complex approach in which resources need to be transformed requires a lot of factories, warehouses and resource transportation: an obvious excuse for imposing large bases, separate outposts, many units assigned to escort and patrol duties, and raiding or disturbance attempts against opponents (e.g. make them run out of Steel so they don't build Catapults, because they would be a strategic threat).

You could introduce special connections between systems, like involving expensive combat units in resource acquisition (e.g. Necromancers collecting Corpses and Souls from battlefields where units die and bringing them back at their Necromancery to build bad things), or giving buildings combat uses (e.g. detonating a mill or a rocket factory, or rerouting water from a dam, water mill etc. to cause a flood). Units can be turned into resources (for example, a summoned Demon could pay generously in gold and more interesting things in exchange for being dismissed, filling the role of a resource transformer or producer) and resources could become units (for example, elemental spirits appearing at random in sufficiently stocked warehouses, consuming some material to form a body and joining the player's army out of sympathy).

In general, concentrating on interesting mechanics is going to be better than abstract goals like a certain game mode, and playtesting prototypes is going to be more productive than brainstorming and voting.

I like this a whole lot! I was thinking a Necromancy-based race anyways :) . And I absolutely LOVE the idea of using the environment/buildings outside their main function thing.

Thank you. As for the playtesting, we are going to make our first good build out of whatever comes out september 1st and then comes the playtesting. (Which I'm looking forward to. Our very first test build was just the camera, rudimentary movement, box selection, unit creation from buildings but nothing resource-y yet.

Alright, so I'm guessing I would go for the eco-simulator with a combat component here. But how do I make it so that it is this rather than two game?

I understand what you mean, but I do not see the means to achieve it.

It is important to pin down your core gameplay (eco-simulation) first. Don't stop tweaking it, until it feels right. It is always tempting to add new features, if the core-gameplay doesn't feel right at the beginning, but you need to understand, that a new feature will only draw your attention temporary off the issues with the core-gameplay.

Once you have the feeling, that the core-gameplay feels good (prototype+tests), you can add a more advanced combat system which suits into the gameplay and doesn't fight it.

Alright, so no skimping on the rudimentary core mechanics before adding more refined features. Got it!

Thank you for all the feedback, everybody. Feel free to add your thoughts, reply and whatnot. I'll be keeping an eye on this thread ;).