Beyond that, clarity. Some things are very simple, or well understood in the industry. You won't know which things. In that case let them get on with it. If you want something more custom, it gets tricky. Some programmers you'll tell to do something and they'll just start. Sometimes that's a danger sign that they're making lots of assumptions. Or you'll tell a programmer what you want. They'll ask you to explain in more detail. You will. They'll look puzzled and ask for more detail, etc etc. For example, if you say you want a character to act cute:
Artist: Make the character act cute. Programmer: What do you mean by cute? Big eyes and cute noises? Artist: No, ACT cute. Programmer: You have some animations you want me to play? Artist: Well yes... but no. Like very happy but easily scared. Programmer: Scared of which things? I can set up a system so you can tag which things it's scared of... Artist: That's going to take an awfully long time tagging things... any other ideas? Programmer: Er, scared of enemy characters and fast-moving objects? But we'd need to decide HOW FAST is FAST and if there are any exceptions. Also we'd need to add a sight system so it knows which enemies to be scared of... unless it's psychic? Psychic would be easier, just all enemies onscreen or within radius X. Hmm, but maybe disable this in cut scenes or things could get pretty trippy.
etc etc. Programmers have to (or at least should) consider all use cases, which is why the job can be difficult and pedantic. ;)
I think accuracy matters less than fun and utility. NPCs probably contribute the most in adulthood. Therefore (based on your suggested scale) I would suggest a short childhood (e.g. a week), a long adulthood (maybe months) and a short old age (a few weeks). If you want realism just find a function that squishes time the way that suits, possibly a piecewise function. By the way, you're aiming for seriously long life by game standards!
As PSVils said, you have some points that I agree with, but your overall argument is self-contradictory. You attribute opinions to others that can't be justified. For example "down to the refusal of their brain to play anything close to a shooter for more than 5 minutes or so because it’s boring". The AAA market for FPSes and it's "non risky profits" resoundingly disagrees with you there. If you were correct, there would be no market for such games. I'm sure there are people who feel that way, but you can't speak for everybody (or even close). I would also argue that it is almost impossible to "master" a multiplayer FPS because there will always be opponents upping the ante.
Your definition of gamer is fuzzy and exclusionary. You need to keep two things in mind: some gamers are casual due to time limitations (you can't get too hardcore in a 15 minute session), and some casual gamers have little experience with hardcore games so are sufficiently challenged by the controller itself before hitting the complexity of your game itself. I grew up playing games with joystick or cursor keys, then took a few years off gaming, so mastering two thumbsticks, two triggers plus at least 6 other buttons simultaneously was huge.
My main advice is unchanged, but if you want to squeeze a little extra out, remember that you're throwing away a lot of bits of precision by making everything size 1 or less. Try making the cube -10,000 to 10,000 and the sphere size 10,000. You might get a little extra precision at the low end.
Have you considered changing both the model size/co-ordinates and the zoom level when switching LOD levels? Essentially it would be the same as how many tile based systems occasionally re-centre the current tiles around 0,0 to maintain floating point precision. You want your model to have coordinates in a particular range, e.g. -1000 to 1000, so just renormalise them to suit.
I have to say that as a primarily C# developer I feel that we're getting a raw deal lately, e.g. XNA, Silverlight, WPF. I wonder whether it's better to focus on 3rd party game engines (e.g. Unity) rather than specific Windows .NET APIs because the people who produce those tools have the motivation to keep the transition smooth whereas Microsoft obviously does not.
1,800 players on one server! I don't know how on Earth they achieved that, it sounds too good to be true!
Ten years ago, Planetside had 500 players per server in an FPS. Planetside 2 is coming out soon, I hear. Five years ago, Sony/Zipper had MAG, with 256 players in a game (on a console.) If your goal is massive player counts, you simply design the gameplay, simulation, and networking to optimize for that goal. This means there are certain kinds of things you can't do in your game, because it would break the player count target.
That's my point, the gameplay etc was NOT designed for massively multiplayer, AFAIK multiplayer was just a mod applied to an existing single player game. So the odds against the existing design being compatible with what the mod achieved seem pretty staggering to me.
Out of interest, what kind of features are you thinking of that rule out a large player count?
I'm glad you found a working solution. If you want to use the Linq extension methods on collections you need to have the "using System.Linq;" line. It got me a bunch of times because it doesn't give you very useful compile errors. Personally I'm a fan of FirstOrDefault<T>, it allows a predicate and also works for empty collections.
On that last point, you could have Admiral and Generals. A general has control but at a lower level, and also participates in the action. If you request to be an Admiral and there are no free slots, you get made a General, but get put in a priority queue to become an Admiral.
Alternately, you could allow extra Admirals, but their forces are 100% NPCs. Therefore the fighting efficiency is low, but they still get their go at wearing the hat.
One simple way would be to create a texture that encodes which values to swap, e.g. use r and g as indices for the position.Then use the screen position as an index into that texture, and use the r and g as relative indices into the original screen image.You could get as fancy as you want creating your index texture because it wouldn't need to be calculated at runtime.
I was just pondering on what aspects of a humanoid NPC make them seem smart/dumb. Personally I find that the moment an NPC loses believeability I stop treating them like a character and start treating them like an obstacle, a puzzle or a resource to be mined. It also becomes frustrating because I tend to lose my suspension of disbelief. What aspects do you think make the most difference? I have a few examples below:
Lack obvious abilities, e.g. climbing stairs or fighting
"Forget" that they know you
Repeatedly fall for the same moves
Bad/no gaze tracking, including talking to where you were when you walk away
Lack of context, e.g. will talk to you about the weather when in danger
Keep to script even when it makes no sense, e.g. talking to a dead comrade