well so now its a MMORPGRTS

so any idea ?

i mean possibility to make the game run well as in free roaming the players can see them selfs and interact to other peoples to talk

thats all and rest are mostly in instance i guess

You need to have an experienced network programmer working on this up-front (and ideally, also an experienced lead gameplay programmer), so they can design an architecture that's compatible with both your gameplay requirements and your wallet.

QFT.

possibility to make the game run well as in free roaming the players can see them selfs and interact to other peoples to talk

Totally possible.

What's your budget for development time/resources?
What's your budget for operating the game?
Does each player actually pay a subscription cost, or is this "free to play" in any sense?

a single big server

The problem is that you can't get a "big enough" server because of physics. The necessary interconnect within the CPU chips scales by N-squared (or sometimes, exponentially,) which means that there is an upper limit to how "big" a CPU can be made, how "big" a RAM bus can be made, how "big" an I/O subsystem can be made, etc. And, as it turns out, even within the realm of the physically possible, getting a twice-as-big server will cost you at least four-times-as-much. And, pretty quickly when scaling up, "bigness" will start coming as multi-CPU servers with NUMA memory, and at that point, you have to develop for them just like you would develop for a set of separate servers connected with a very fast network. So, economies of scale say that it's better to have lots of medium-size servers (where each is a single- or dual-CPU system with 8-16 cores each, 32-128 GB of RAM, 10 Gb network interface.)

That being said -- 2000 players that walk around and chat, not shooting at each other? Totally doable on a single server instance.
The big challenge there will be what your client software will do when it gets told that there are 2000 separate players all in the same city square. Can you graphics engine handle that? Is there enough bandwidth to download all the avatar customization for each user?

+1 to hplus..

Also, nobody knows what an MMORPGRTS is. It's mostly just a pipe dream or people misusing terms.

Also, nobody knows what an MMORPGRTS is

it's yesterday's news. The latest thing is MOBAMMORPGRTSFPS...

This is my own take on the situation as a relative newbie to physics but not to games servers;

Just as a sidenote, when it comes to physics remember there are two kinds of physics. There's the kind of physics that's important to emulate server side due to it being related to the gameplay and player state (e.g. trajectory and force of a bullet, fall rate of the player from a building), and then there is physics that bears no relevance to the game state but makes the game look nice. Think things like grass moving in the wind, leaves blowing through the sky, insects scattering from a dead body, or a particle effect. These do not need to be simulated server side. This does mean that different players will see very slightly different things, but they will be subtle enough to not desynchronise the gameplay.

Where possible, keep as much physics as you can client side, if the client can be trusted to calculate it, leaving only the essentials server side where they belong.

You can also take shortcuts. It might be tempting to use a big high end physics library to calculate the trajectory of an arrow from a bow, but let's be honest, if you used a simple interpolation of sine/cosine and some matrix maths to simulate gravity and inertia of the arrow, it would work, and the players would not notice. The server would be able to calculate each update much faster the more you do this kind of thing.

Similarly, collision detection can be offloaded a little. You can do a lot of collision maths client side, and perhaps do one percent, or 0.1% of the collisions server side also (but not tell the client which ones are also verified server side). This way, you cut down your server load by trusting the client to calculate the collisions, but by doing a few server side at random, the client can't cheat without being detected, because the client will never know which ones the server might verify, detect a desync, and boot the player off the server.

Again, leave heavyweight physics for the things that need it.

Good luck!

yes thats what im also thinking of

anyone heared of Forge networking ?

http://beardedmanstudios.com/ will it be useful for our project ?

It's been a while since I've mentioned it, but it's come a long ways and I just released a new version.

Game Machine.

Game machine is an open source server platform that excels at large virtual worlds with lots of players in the same area. It's focus is on solving a core set of hard problems not just networking. It has built in persistence that scales well. The best space optimization of any platform I'm aware of, and a well defined structure for writing game logic that runs concurrently. Plus a bunch of built in functionality such as multiple characters, groups/chat, area of interest, etc..

The default client is for Unity. Biggest market it's where I put my focus for all the client side implementation. But it's fairly simple to integrate with the server as the core protocol is protocol buffers, and I moved stuff like reliable messaging to a higher level of abstraction. So the networking layer is very dumb (as it should be IMO).

I wrote a completely functional open world mass pvp combat mmo in under 3 months using it, it was an eat your own dogfood project. And all of the server side code for that is also open source and comes with. So there are a ton of examples for how to solve most of the things you might tackle in an mmo.

na im not trying to change technology atm

na im not trying to change technology atm

The problem with the posts, and how it combines with this post, is that you give contrary information.

You started out asking for general and broad information without specifics.

Then you provide some specifics that let us start to draw out numbers, (number of concurrent users, update rates, and message sizes) so people were able to make more concrete calculations for estimates.

Then you come out in another discussion and say that your network infrastructure is already done; so whoever created it knows the answers and there is no need to ask on a public forum at all!

But then you ask about adding another technology (Forge) and ask if it would help your already-written-but-unknown existing implementation.

And now you mention that you aren't trying to change technology.

I would start with your statement that "The server side coding is mostly done as our networking programmer has his own networking framework which is able to do 2000+ CCU per server." That means you already have a concrete implementation, and you have someone who knows those answers. They know -- or should be able to calculate -- the bandwidth and latency requirements for both the client and server sides. They know -- or should be able to tell you -- what pieces you need to implement for the network communications.

Find that person and have a long and detailed discussion with them.

It seems also like you need some basic knowledge about networked games, as your questions jump around between asking vague generalities and specific nuance, then back to vague generalities.

Networking is the communications, how data moves between games. The implementation details about the client don't matter at all beyond the basic protocol when it comes to networking. It does not matter how you simulate your game, or what languages the game is written in, or if the game client is running a fully rendered graphical system or a blocky ugly preview system or even running headless with a computer driving the game and no visuals at all.

Think of other networking technologies you are familiar with. Web browsers, it does not matter if you've got a fancy graphical browser, a text only browser, or a computer pulling down the page from a script, all that matters is that the protocol is followed. It doesn't matter what email client you are using, if it is on a PC or a phone, graphical or text, human or spambot, as long as the protocols are followed the messages work.

All that matters for networking is that the communications protocol of messages and responses are handled within the times and values that the protocol requires. When discussing networking, it is the protocol and how the protocol will be used that matters. Figure out the protocol, who sends what, how much they need to send and how frequently they need to send it, and all the networking parts fall into place.

Add you on skype, we can talk about the networking solution on skype