Aside from the forum faq, the earliest book is "Developing..." with a copyright of 2003. So 5 years ago, you were right and there were no books about MMOs! Hot field, baby, hot!

Here is my definition of MMP, given so that the rest makes sense:

A MMP game is a Virtual World whose purpose is interactive entertainment and intraplayer socialization. It will have an asynchronous populaton (aka: total subscriptions or accounts) in the 1000'S and a synchronous population (ie: players that play with each other) in the 100's.


Not "strictly" true and depends on what you mean by "one server".



THE SOFTWARE MODEL:
The canonical multi-tier software model involves Logic, Presentation, and Data. In a SP game, this is all handled on the same computer. In a MMP game, the Presentation is the client computer; Logic and Data are handled serverside.

In a MMP, the data is a MySql DataBase server (or your DB engine of choice) populated with your games tables and stats. Normally this will run on a unique computer separate from Logic. The Logic is the games dynamics. It can be physics, combat, chat, trade, etc... it is the rules that govern the game... the DataBase server just provides the numbers for these rules. Both are networked serverside so their connection is in the gigabit range.



THE "MASSIVE" SINGLE COMPUTER SERVERSIDE:
If one server means one physical computer, then you would have to run Logic and DB on that single computer. With this deployment -- and with programming taking into account this one server deployment -- my guess (please note: just an educated guess) is that you would be able to get about 100 players (not subscriptions) per computer. This fulfills MY definition of massively multiplayer but just barely.



THE MASSIVE MULTI-COMPUTER SERVERSIDE:
However, if you put the Logic components onto one physical computer and the DataBase onto another physical computer, then you can optimize each computer accordingly: CPU is a priority for the Logic server; HDD is the priority for the DB server. In this case it is my guess (again: educated guess) that you will be able to serve on the order of 1000 players this way. This is not only due to the optimized computer hardware, but moreso on the optimized programmed software that only takes it's specific role (presentation, data, or logic) into account. Note that these same two computers could have served only 100's under the single server model.



THE (not so) MASSIVE CONCLUSION:
Thus in this "back of the envelope" arguement both deployments fulfill the criteria for being MMP per zone, but separating Logic from DB means that you can really guarantee that this will be so since each "zone" has the capacity for thousands of accounts and hundreds of players at the same time.

Well my objectives are these:

A Massive game, with 3000 players, with pay subscription so i can hire servers, and free updates to the game. All the game packet will include models, textures, sounds, and everything that can be used to avoid band consuming.

The server will just take care of , Player names ( created when player registered online), last position, skills, movement information, character extras.., assets, chat.

Its a space game, i don't know what the 1 per zone meant. Since there are alot of solar systems, there is just one server, i think there is no need for more.
Everything will be loaded when you enter a different solar system.

Right now everything is goin okay.

I kid you not: those objectives are meaningless until you've read the books above and done more research. For example:

1) Let's assume you can get 3000 on two servers. Let's further assume that you have an independent DB backend. That's 3 servers. If renting, that's roughly 500 USD per month per computer or 1500 USD/mo. Now add bandwidth. To support 3000, I would go no less than with a 3 Mbs line, or roughly another 1500 USD/mo. That's 3000 per month just in hardware and bandwidth. Now what about customer service? You have to hire them (another 2000 USD/mo) and train them so that you have to hire a few months prior. In short, you are looking at around 10,000 USD/mo to run your game: where is this money coming from BEFORE the subscriptions? What happens if you don't hit your 3000 target? And where is any development budget?

2) The server better take care of EVERYTHING. Fundamental MMOG mantra: C/S is the only way. The Serve is god; the client it's servents. Put EVERYTHING you can on the server to make the client as "thin" as possible.

3) You better know inimitely what you "space" is and how it breaks down. Stripped of the game, an MMOG is a virtual world that a person navigates through. This means that you may have no choice but to put each solar system on a separate server... especially if you intend to have 1000's of ppl per system. What every your design, the way you break up your Virtual World among your Physical Computers is a huge decision.


Have you thought of the above?
Are your thoughts formalized into a Game Design Document?
Do you understand the networking and programming enough to create a Technical Design Document?

If not, then you are aiming too high by planning the game at this stage. It would be best to keep the concept alive ("a space game") but read through the above and do your research so that this concept is solidified in current MMOG industry reality.

well, not 1000 per solar system, For example, EVE-ONLINE, has millins of sollar systems. And just one server.
it has a maximum of 34000 aprox. clients.

The thing is how the game is working, there is no need to load solar system, just need to know coordinates of players, further data, don't need to be real time, and just download when players clicks some here.

Though i will of course take attention to everything.
Anyway first i need to tests the script, and do code and code, then i can carry out multiplayer tests a bit better.

You could use one of the many open source php/mysql based multiplayer gameengines. And insted of using a browser/html or flash/shockwave display the game, you use gamestudio as client.

It would be a rather slow (roundbased or round-time limited) game, but you can support a lot of users.

Its a more realistic approach for a hobby developer.

I hope you take my advice and try to walk before you run. I cannot emphasize enough that based on my personal experience and others, if you jump straight into coding without a firm understanding of the MMOG space, you will be wasting tons of time and incurring needless frustration. If you want to jump into the code, go ahead and jump. But don't complain when realize you didn't check if there was water in the pool.

As an example of what I mean:


One server CLUSTER... cluster. Not one physical server.

http://www.manifestogames.com/eveonline



There is no telling how many servers are back there but with 100,000 players, I suspect it's on the order of or close to 100 physical machines. Unless you are ready to handle networking among 100 physical machines, I urge you to step back and do more homework before you start coding for after all, you may find that you don't NEED to do any coding depending on your requirements and the ability of Multiverse, Second Life, or other Virtual World Platforms!

"Dream Big; start small"; that's my motto.

And what if..

I use for example, direct ip,
Like for a test, 100 players connect to my ip,
and just some information is sent and recieved... it would slow down, if i just tranfered for example, a

var player_id_x[1000]
var player_id_y[1000]
var player_id_z[1000]

Just that type of information, it would be slow?

This is not enought, because you have to send at least one angle. And now think about sending four arrays with indexes ot 1000 every frame. If I callculated it correct, you will have a transfare rate of 250 mb/s ^^
And you also have to send the animation states and much more...

Even if you use death reckoning it will be much data. Because of that you have to split your whole gameworld into small parts so that you only get the data of the players which are in your part.

I don't think that coding something is impossible even for a small team, but your whole game should be made well because a MMO game with only 3 players isn't that cool
-> I don't think that the technical thing is the difficult part, but getting a lot of people who plays your game

Dark_Samurai

As I keep saying, these questions are irrelevant at this stage in your development. Once you understand ALL the actions that your players can take in your and then you understand ALL the bandwidth EACH action.... once you understand TCP vs UDP, the different bandwidth between home and office, the way that GS does networking... only THEN should you even think of coding, not before.

For the third time this thread I urge you, turn back. I've been down the road you have, tried to start with the code and that was the only way we COULD do it 5 years ago. But today there is a ton of knowledge in books and on the net on this subject which has taken all of my errors, our errors, the industrys errors, and tried to make them better.

Don't reinvent the error wheel. Take a "time out" to do some more basic research. These questions you are having will answer themselves as you do.

Put another way, you can go ahead and think about coding right now and spend the next 2 years learning, building, and coding up to a point where you will have to scrap everything you did in the last two because now "you get it".... or you can take a few months picking up what others have done, taking notes, thinking, "get it", so that once you DO get to coding, in one year you have what you want!



That's the business side of things. Most people don't give this one thought when they start down the MMOG path. There is a perverse "if I build it they will come" attitude that is correct. What? Huh? What's the problem then? The problem is that acquisition is the easy part of a MMOG... if you build it they WILL come... to test it... and then leave. So RETENTION, the second part of the MMOG business model, is way more important.

Have you thought about that my new MMOG friends, have you thought about how you are going to ACQUIRE accounts and then RETAIN them? All part of the game, brother, all part of the game...