About Massively Multiplayer Online Game Structure

[williamlai3a]

Hi~

I am planning to build a Multiplayer Online Game with the type like World of Warcraft, but surely a mini-size one (only have one server support and mush less maps, NPCs and players).

I would like to ask how should the code be structured? in order to handle the consistance problems and the network problems?

Thank you very much.

[dlangdev]

how can i join?

do u have something available for me to read?

just joking...

[keless]

Dear sir or madam, your question is way to vague to be answered.

To put things in perspective, let me give you an analogy: If I were to say "I would like to build a race car, only not as fast. How should I structure it?" That would be similar to your question. In order for these forums to be helpful to you, you will have to ask a question with a smaller scope.

[williamlai3a]

Dear sir or madam, your question is way to vague to be answered.

To put things in perspective, let me give you an analogy: If I were to say "I would like to build a race car, only not as fast. How should I structure it?" That would be similar to your question. In order for these forums to be helpful to you, you will have to ask a question with a smaller scope.

Hi keless, thanks for your reply.
Let me explain briefly.

I had troed to build a single play game which run with the below structure:

void GameObject::run()
{
while( device->run())
{
//main loop function
}
}

void GameObject::OnEvent(irr::SEvent event)
{
//event handler
}

So, I am thinking can this structure handle network in/output event?
And how can I solve the network delay problem?

Thx a lot

[rogerborg]

1) This isn't relevant to Irrlicht, and should be discussed in one of the Off Topic forums.

2) There is no single right answer to the questions that you asked. It's a good question, but you (and only you) can decide how much work and trust you want to offload to the clients. The more popular you expect your game to be, the more paranoid you must be about only accepting requests rather than state changes from clients. If you don't expect to complete it, or for anyone to play it, then it won't matter and you can have clients do all the work and send state changes to the server, on the assumption that you can fix it later should anyone every ZOMG HAXX your clients.

3) Writing even a "mini Massive" (JUMBO SHRIMP!) game is tens of man years of work for experienced developers.

The definitive articles on this subject are:

So you want to make your own MMORPG

Why your next 3D MMORPG will fail

4) Why not use/contribute to/ learn from Worldforge?

[keless]

William:

I am currently working on my own client-server application and based on your last post, I now understand the problem you are considering and can help.

The biggest thing to consider here is what networking solution you are going to use. You are also going to have to answer this structural question not only for the client, but also (possibly differently) for the server as well.

In my own app, I am using Raknet as my networking API. Raknet is a threaded API which allows me to create a connection and poll that connection for new incoming packets without blocking my main application thread. As such, my main loop for the client looks like:

Code: Select all

//update is called as long as g_Device->run() returns true
void Client::Update() {
	uint32 currTime = RakNet::GetTime(); 
	uint32 updateStart= currTime;
Packet* packet = m_RakClient->Receive();
	while( packet && (currTime - updateStart < CL_PACKET_HANDLING_TIME_PER_UPDATE)  )  {
		HandlePacket(packet);
		m_RakClient->DeallocatePacket(packet);
		packet = m_RakClient->Receive();
		currTime = GetTime();
	}

	m_LevelManager->Update(time);

	g_Device->yield(); //allow other applications to use the CPU
}

Meanwhile, my server side looks like this:

Code: Select all

	while( m_Device->run() && !g_Die ) {
		uint32 currTime = GetTime();
		uint32 updateStart = currTime;
		
		//TODO: fix this-- currently pulling a bunch of packets and then a bunch of world updates, needs to be more mixed?
		
		//handle in-comming packets (listen for new connections and user commands)
		Packet* packet = m_RakServer->Receive();
		//handle a burst of incomming packets for the next SV_PACKET_HANDLING_TIME_PER_UPDATE(ms)
		while( packet && (currTime - updateStart < SV_PACKET_HANDLING_TIME_PER_UPDATE)  )  {
			m_Server->HandlePacket(packet);
			m_RakServer->DeallocatePacket(packet);
			currTime = GetTime();
			packet = m_RakServer->Receive();
		}

		//handle server update (if its been at least SV_SERVER_WORLD_UPDATE_PERIOD(ms) since the last time)
		if( currTime - m_LastServerUpdate > SV_SERVER_WORLD_UPDATE_PERIOD ) {
			m_LastServerUpdate = currTime;
			//NOTE: currently does 1 world simulation step per 1 world update sent out to players (increase this?)
			m_Server->Update(currTime);
		}

		m_Device->yield();
	}

I am going to remove the yield() from the server when I have it running on its own machine (currently client and server are both running on the single development machine together).

How you chose to set up your own loop will be based on what network API you've chosen.

That should be enough to get you started, however you should look forward to the next step: Interpolation.

[Ico]

It's a little bit off topic but I'd use two threads for the server so one thread handles network traffic, the other one world updates. With your current design a flood of network packets would block your whole game world from updating.

-----

If you don't know on how/where to start or are unsure, try to start with something more simple/smaller. Even a simple tic-tac-toe game can help you figuring things out for later. It will be far more tolerant to design flaws regarding network handling, updates, etc. but you'll be able to update and improve it then.

[dlangdev]

do you really want to go down at that level of abstraction?

can u elaborate more about your plans, like are u you going to use a network lib or will u roll your own?

a network library will save u a lot of time, a huge time saver, unless of course you need to write your own, winsock is going to be your basecode.

[dlangdev]

It's a little bit off topic but I'd use two threads for the server so one thread handles network traffic, the other one world updates. With your current design a flood of network packets would block your whole game world from updating.

ummm, actually what you really want to design your server as a single instance similar to an http server, because u can scale it to a cluster later. think in terms of cells and aggregation of cells.

[williamlai3a]

Thanks all of you.

Let me explain my plan in more details.

I am still deciding whether to use the irr's own network engine or use another network engine like Raknet.

Do you have any suggestion to me?

Thx a lot

[Dorth]

There is no official Irrlicht network engine, only community made projects (at least 2) containing Irr in their name. And if you are serious about an mmo, you are either looking at a lot of study to make your own multiplayer lib or a commercial one, the lowest level you could get away with is something like RakNet (base price 100$). If that is not acceptable to you, then you are not realist on your project.

[rogerborg]

For me, Raknet is the clear winner.

It's a little bit off topic but I'd use two threads for the server so one thread handles network traffic, the other one world updates.

I'd disagree strongly. First, it raises the complexity by an order of magnitude. Second, mutexing will block your game world from updating anyway - and if you don't mutex properly you'll get into inconsistent states or race conditions. Third, in an OG, network traffic is the priority, not world updates. It doesn't matter if your world simulation is purring away smoothly if you can't get state change information to your clients, or accept requests from them.

[keless]

Roger, if you're using RakNet like I am, you ARE having two separate threads for the server: one for networking and one for game logic.

The network thread is hidden behind the RakNet API, which is why Connect() and Send() are non-blocking calls.

[rogerborg]

Aw, god dammit. Yup, that should have been obvious. So, I need a message queue on my logic thread, or just go back to Enet which does things much as the Pilgrims must have done. God dammit.

[Ico]

Don't think so as afaik RakNet should queue your messages anyway.

Assuming some kind of counter to be the data to be sent to all clients you don't want your clients to receive different values (some getting 50, some 51, another one 52, etc.). And that's something that won't happen:

Code: Select all

while()
{
  UpdateGameWorld();
  SendPackages();
}

It doesn't matter when the packets are finally sent as I'm sure they're sent FIFO. The server won't be able to change the data while you're creating the packages. And even updating the game values later on shouldn't change any packets not yet sent (I'm rather sure RakNet uses its own buffer for the data to be sent - would be pointless otherwise).