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 ;).