Only 2k?
A few questions:
1) American or Canadian dollars?
2) What kind of messages do you send? (how many - and how long)
3) How many people can this support?
4) Compared to something like Diablo 2 - How much bandwidth does your game take up?

1) 2000 USD. Which is the one time cost of 3 mid-range (1-1.4Ghz) computers and the equipment to assemble them on a network. Any more than that and you''re wasting money. Put the most money into your development PC(700-800), less into the secondary client(600-700) and the least into the server(600max). Tombstone can run just fine on a 200Mhz Pentium. Can''t handle more than a few hundred characters without severe lag but for testing purposes, it''s great.

2) Messages are sent on an as needed basis. The client indirectly calls local functions through the server. You wouldn''t call the server any more often then you would call the function directly in a single player game. The typical message is around 10bytes. Any more than that and you''re probably wasting bandwidth.

3) Tombstone is hardcoded at 12,220 max players (including NPCs) with 1024 connected over the net. As I said earlier, 1 character is as difficult to connect as 1 million. In otherwords, if I changed a single value I could have N connections. There is no limit. If your program has a limit set by anything more than a #DEFINE MAX_PLAYERS, you''ve done something horribly wrong.

4) 72 bytes per second per character per character (72*N^2). With a full load (12,220 characters running around) that comes to around 7Mbits per second. If this is your first on-line game don''t expect to pull off that kind of number. You''re bandwidth will probably be much higher.

Compared to other on-line games...I can''t compare. I don''t know what messages they''re sending or how often. In terms of Bytes per second I''m right on give or take a few Bytes. That doesn''t mean I''m as efficient though.

Ben


IcarusIndie.com

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

Oh, the main reason the server can run 480,000FPS (yes, really) on a 1000Mhz PC is because it doesn''t handle NPCs. They''re handled on a modified client. The server doesn''t know and doesn''t need to know the difference between an NPC and a PC which makes the code all the more efficient.

But wait, I only allow 1024 connections but I had 12,000+ NPCs running around. Planning ahead and sometimes just plain dumb luck often pays off. Without modifying the server code a single line I was able to log in N clients on 1 connection and control them all with a single client. One mid range PC can handle around 800 NPCs. The only later modification I made was keeping the server from sending the same message multiple times to the same connection (1 IF statement). The client handles the "multicasting" if that''s really what it is. It just acts as though the message was sent to all the NPCs it''s in control of.

There are a lot of things you can do to make a very large MMORPG without a lot of work or a big investment.

Ben

IcarusIndie.com

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

480,000FPS !? Oh you have the latest GeForce 975 GTS ?

Your server does not draw anything on the screen does it ? Don''t you mean 480000 UPDATES or GameLoops ?

I don''t think the term "frame" implies that you''re actually rendering anything, so using FPS in that sense seems perfectly valid to me. And no, there''s no reason whatsoever for a server to render anything. If you need somekind of omniscient monitor for debugging and/or editing the world, use a slightly modified client like Kalvin used for the handling of NPCs (using a client to control NPCs is a cool idea BTW ).

cu,
Prefect

It was probably meant as a more abstract concept ("Frame").

Sorry Kalvin

So you hosted 12,200 people on a 1.4gz P4?? How is that possible?

A few questions:
1) What language did you program it in?
2) What OS are you running?
3) How did you set up the multiple threads? Wouldnt 12,200 threads (by themselves) crash a mid-range computer?

Here's the news bit I posted on the test back in July last year.

--------------------------------------------------
Tested fully loaded server
It took over 20 minutes to load all 12000 NPCs into the game world. That means that I have a limit of 10 characters per second being loaded into the game. That's pretty good I think.

The server ran at just over 60,000fps steadily once everything was loaded.

The NPC bot took about 1 second per region or about 1.3msec per character to move them. It needs to be able to do 12 characters per msec before one bot can run the entire game world. I ran it on a 700 duron with WinMe the final NPC client computer will be the best AMD chip I can get. It may be enough but more than likelty multiple computers will be handling the NPCs. It may be the bandwidth (10Mbit lan) causing the slowdown and more processor won't help at a certain point.
--------------------------------------------

The 700 ran the NPC bot since I needed the speed. The NPC bot does alot more work than the server.

I thought it was the 1000Mhz Duron but actually it was probably the 333 K6-3 which was in the server before I upgraded it to 1000Mhz in Dec after the test. It would also make sense since the 333 with Win2K ran the server at 120,000FPS unloaded. Windows Millenium handled it okay but Win2K Pro was a significant improvement.

1) DirectPlay (DX7) with Visual C++
2) Windows 2000 Professional
3) There's only one thread. Why would you need 1 thread per character/connection/whatever? All the server does is process messages. There's nothing to divide up. Dividing up the processor really doesn't accomplish anything anyway. It may be handlingly twice as many messages but they take twice as long to process. The only time putting in more threads would help is in the client where you have more than messages going on but that runs at over 200,000 game loops per second (30 rendered FPS) on a 700 so it's not an issue. There's obviously plenty of free time to deal with messages without interupting the game play.

I'll do some more testing but for the most part you just need to stop listening to corporations with fat pocketbooks that don't code on P200s with crappy video cards, 24MB of ram and tiny harddrives. If you code for a 1000Mhz processor you'll never see these kinds of numbers.

Ben

IcarusIndie.com

[The Rabbit Hole | The Labyrinth | Programming | Gang Wars | The Wall]

[edited by - KalvinB on April 3, 2002 9:46:41 PM]

I never had the CPU be the bottle-neck sending data - pushing 80mbps (on an already over-loaded 100mpbs LAN) I had 30% utilization on a PII 700MHz, and I thought that was disgustingly high; I''m currently retooling it cutting-down on all the memory allocations. I''d suspect Movement/CD as the emp sink.

quote:

---

3) How did you set up the multiple threads? Wouldnt 12,200 threads (by themselves) crash a mid-range computer?

---

No one uses one thread per connection in a high-volume server.

IIRC, DirectPlay uses IO Completion Ports on 2k/XP, uses a single UDP port, and serves message request using a thread-pool. You don''t really need to create any additional threads if you''re using DP7 (it''ll make all the threads it needs), though having a control thread makes programming it easier.