🔒 Locked

MMO Server Layout Design

Started by Grofit Oct 4, 2009 at 5:30 AM 23 replies 8k views

Original Post

Oct 4, 2009 at 5:30 AM

Hey, Im just currently doing a learning excercise into MMO servers and im currently coming up against a few problems, which i could easily solve, but it would feel like ive solved them in a cheap and not so extendible way... so i just wanted anyones opinions... Currently i have the following nodes: - Gateway node This is an externally facing node which connects up with X amount of login nodes to verify the connected users then once they login the gateway should pass them over to a realm node. - Login node This is a simple node that hooks up to the DB directly and validates any username/password requests. - Realm node This is basically a node per game world, so it would store all the current connections to a given world and deal with updating players and passing on updates to the world, its effectivly a per realm gateway. - World node These are created dynamically by the Realm node to process requests etc, this way if a character requests a movement thought the realm node, it would pass it on to an available World node that would validate its movement then send back the movement to take to the realm to forward on, they would also do any other in-game calculations such as damage etc. - Memcached Although not a node as such there are a few layers of caching, such as a global cache that any world node can access, so this would pull back items/areas that have already been loaded. Then there would be per realm caches to store the current players to save constantly hitting the DB, although snapshots are frequently taken of players to update the DB. Now thats just the basic outline im going with at the moment, and all the problems really stem from it being distributed and dynamic, so new nodes can be created as and when they are needed, here are the current problems ive got... - X amount of Gateway nodes The client has to know about the gateway nodes, as these are the first things they will hit to start accessing the world. Although going forward if you had 100,000 people wanting to connect 1 gateway wouldnt cut it, so i would need to deploy more. However how would the client know about them unless there was some kind of hardcoded configuration file with the client saying there are X gateway servers at XXX.XXX.XXX.XXXX. Only way round this i could think of would be to have a single gateway manager, that would take a connection then pass it on to sub gateway nodes, this way it would not hold the connection and would just pass it straight through, whereas the current gateway nodes hold the connections until either the client times out or logs in. - Having internal nodes knowing about other internal nodes Similar to the problem above, when a user logs in they are then asked which realm they wish to play on (akin to WoW realm choice), then once they click it the gateway node needs to find out: A) The specific realm nodes address B) If it is online C) If it is accepting new players Now currently if you have 10 realms you would expect 10 active realm nodes, but unless the gateway has a config file telling him where they are it wouldnt know how to tick the A requirement. I thought of maybe having a tiny DB that could be checked for online realm nodes, but it feels like a cheap hack, but it would allow for quick changeover if a realm node went down and a new one needed to be put up. As i dont really want to hardcode IP addresses within other nodes as the whole point of it being dynamic and distributed is that it should be able to expand and contract as and when is needed. Once it has an IP it can easily tick B/C requirements by just talking to the server. This issue also comes up when looking at how dynamic world nodes would be created, as its easy enough for me to get the Realm node to spawn some new world threads, but this would mean its always going to be on the same box... so its not going to offload any of the calculations, so the other boxes would need to have an app listening for spawning requests or something, again needing a config file or DB or something... As im sure you can see im still trying to get my head around the best sort of way to distribute the system as they would be on seperate boxes and even possibly seperate networks. So its not like i could do an IPX style network spam to see if there are any listening nodes as it wouldnt work with remote nodes, the DB idea sounds the best to me so far but it feels like a way round the problem opposed to acctually solving it, its a case of how should dynamically created nodes know where they are supposed to be feeding their information to. Unless you just pre create them and give them all configs, but then they are no longer dynamic... If anyone has any advice on the subject it would be great as ive been trying to find some decent articles online but not found much yet...

Antheus

Oct 4, 2009 at 5:45 AM

Quote:
Original post by Grofit

- Memcached

Memcached is used by web applications who do not need consistent or correct view of the state. There is no problem if web app shows 5-30 minutes stale data, or even if the data is incorrect. For anything real-time, stale state of several seconds might be unsuitable, and incorrect state can either break something, or require excessive validation.

Another problem with memcached is that it is not content-aware, nor are queries made against it atomic. This can cause inconsistencies with certain types of data when shared across multiple nodes.

Quote:
The client has to know about the gateway nodes, as these are the first things they will hit to start accessing the world. Although going forward if you had 100,000 people wanting to connect 1 gateway wouldnt cut it,

Sure it would. It would take several seconds for all 100,000 to go through, but other than that, it's not really a problem. On 100 Mbit network, the maximum realistic throughput is in the range of 20,000 packets per second. If authentication takes 4-6 packets and hand-off another two (let's say 10 packets per client), that means 2000 clients per second. MySQL should be able to handle up to 2000 queries per second as well. So it would take in the range of one minute to handle 100k clients.

What you call gateway node is typically called login server. Gateway nodes typically sit in front of world nodes, each routing several hundred connections, and login node hands off users to one of available gateway nodes.

Grofit

Oct 4, 2009 at 6:13 AM

Hey,

Yeah ive used it briefly before which is why i turned to it. It seemed pretty sturdy to me when sharing objects to remote servers, and we found the amount of hits we had at the time on the DB it helpped us out immensley pushing alot of the *alive* objects into the cache with using NHibernate.

Im more than happy to try use another caching solution if it is free and there is documentation out there about it, i just went with what i know. Originally i used to have the realm nodes just internally storing all characters within the area and npcs etc, the problem i found with this was that every time i wanted to do something on the world node they would be ignorant and would need to either be sent all the characters it is doing stuff with or request them from the realm node, meaning it would keep talking back and forth... which thinking about it is no different than calling the cache...

The thing that worries me is that currently the gateway node... or the login manager node, whatever you want to call it. Keeps the connections until they are timed out or logged on, so it could only at best store like 63000 clients right?

On a side note can you recommend any books on the subject? i could only find a few multiplayer based books for typical fps games...

I mean the odds of having that many people connected at once is a bit silly so i guess one login node being exposed directly would do the job, but im still a bit puzzled as to how everything inside the server domain links up without either having X amount of static server with config files, or having a DB or some way for them to all search for available world/realm nodes.

[Edited by - Grofit on October 4, 2009 6:13:08 AM]

Katie

Oct 4, 2009 at 8:11 AM

"having a DB or some way for them to all search for available world/realm nodes."

That's how large network systems work. Directory systems.

We had a solution whereby user-facing machines report back loadings to a central server. Lack of reporting means the machine is down or overloaded. From that, and a knowledge of network geometry, we send user requests to appropriate servers.

The balancing happens centrally, and updates are sent out to directory servers who can then tell machines how to find each other -- both users and also internal systems.

This also allows us to do things like introduce new machines to the network, take machines out so they can have maintenance done, balance network loads to use cheaper bandwidth where possible and so on by directing traffic around the network. The directory servers are peer-to-peer redundant.

Grofit

Oct 4, 2009 at 8:49 AM

Hey,

So is picking a DB as a central server looking a good idea? as it would solve all my problems as each node could just update the central DB and the nodes that want to process actions can just look up nodes on there, but as im doing this as a learning exercise primarily if it wasnt the *best* solution i would like to look into how larger systems do it...

Im still not sure using this approach how i could create new nodes on other machines, unless i add another layer that would be installed on every box, like a node manager, and you could fire messages over it to spawn new nodes on its machine, and work out how many nodes are currently running on it....

Thanks for your responses so far!

hplus0603

Oct 4, 2009 at 3:17 PM

I'm going to take you at your word, and assume that you really mean "M"MO, and not just a regular 100-player online game.

Your approach is way too complicated. You don't need all those node kinds. You need one node kind for real-time game rules (movement, combat, etc), and one node kind for login and database access, plus the actual database server. That's it!

You could probably even make the login and database access node kind a "singleton" node -- it doesn't necessarily have to scale horizontally; especially if you keep your game sharded with no more than, say, 10,000 players per shard.

In general, on the back-end, it's much more important to reduce CPU usage, to remove all crashing bugs, and to put in enough instrumentation that you can get good reports on how the system is performing, than it is to design a multi-tier service oriented architecture with redundancy fail-over. Once you remove the crashing bugs, the fail-over will become redundant. Once you optimize the CPU on your real-time node to deal with whatever your real-time rules are, you don't need service discovery at all -- everything knows where it goes. Once you have a good application-level design to access the database only where necessary (using a "check-out/check-in" data ownership model, say), multi-tier isn't very useful.

Also, for every byte you can shave off each packet each player sends, and for every packet send you can eliminate entirely, the lower your bandwidth cost will be, and generally, the lower your CPU requirements will be (because you get fewer packets to process).

Finally, if your game is big enough that you need multiple shards (with 1,000-10,000 players per shard), then you need a second database tier, dealing with "customers" as opposed to "players." A "customer" is someone who logs on to your overall company infrastructure; a "player" is someone who has avatars/characters on a given shard (world instance). Even if you have 1,000,000 customers online at the same time, the "customer" layer can be thin enough that it's not a major bottleneck; it generally just needs to verify that an account is in good standing and issue a login ticket when you first connect, and then let the player get a list of available shard instances ("realms" or "servers" or whatever).

Grofit

Oct 4, 2009 at 4:01 PM

Hey,

Yeah i would be aiming for > 1000 players at once... not that it would ever happen but thats the hypothetical scenario...

The thing that im a bit confused about is that you are mentioning that there should just be a multi tier system, do you mean it should all just reside on one machine? as ive been going on the assumptions that you would have lots of cheap servers to farm out to rather than one more powerful server... this way you can easily add new nodes when needed.

I may just be miss-wording my nodes. The login node is purely for logging in, the world nodes would be the ones that does all the real work. The other ones are just externally facing wrappers really.

Also i would be wanting to have multiple *realms* so one customer can access many realms of which each can have many characters... so each realm would have its own node assigned to it...

Also one thing i want to try and clear up so everyones on the same page... when i say *node* i mean a piece of software running in its own process. So one server may have many nodes running on it. So theoretically you could have 1 server box with 100s of nodes running on it, or have several server boxes with 10 running on each...

Again im not sure if it is the best way to go, but after talking to a friend who knows alot more about this sort of stuff than i currently do, he recommended going to with a distributed software solution so you can add new nodes without having to take the game offline...

Also going onto your point about keeping packet sizes down, currently all packets are based on a model of:

4 bytes - Content Size
1 byte - Message Type
XX bytes - Content

Im currently toying with ideas of how to keep it secure, so i think that when logged in the first 12 bytes of the content will be a unique identiier that is linked to the currently logged in users, as although i *could* use the IP address as a way to bind you get the problem that more than one person could be on the same IP...

I may be talking utter balls as i have very little experience on TCP/IP networks...

swiftcoder

Oct 4, 2009 at 4:53 PM

Quote:
Original post by Grofit
Im currently toying with ideas of how to keep it secure, so i think that when logged in the first 12 bytes of the content will be a unique identiier that is linked to the currently logged in users, as although i *could* use the IP address as a way to bind you get the problem that more than one person could be on the same IP...

Each user will always have a unique IP address/port combination.

As for packet overhead, don't forget that TCP has significant packet overhead of its own, before you even start to add your own headers. UDP of course has less overhead, but you have to roll your on reliable message infrastructure.

hplus0603

Oct 4, 2009 at 7:57 PM

The wrappers add complexity for little to no gain, IMO.

When you say "realms," that's what I mean by "shards."

When I say "tier," that's an architectural concept. For example, in a web app, the UI tier may be implemented in the browser, talking to an app server tier, which talks to a database tier (this is the classic 3-tier design). Think of them as layers of communication -- the UI never talks to the database.

When I say "horizontal scaling," that means adding multiple nodes in the same tier to share the load.

You will never send a packet bigger than 65000 bytes, so 2 bytes for length seems sufficient. However, how you frame your packets is a question at a very different level from how you slice your nodes into tiers.

Perhaps you should study systems architecture a bit before you actually try to architect a MMO system, though ;-)

Grofit

Oct 5, 2009 at 1:20 AM

Hey,

Yeah i know what you mean, in web development Ntier is typically used to describe systems that you mention with business logic in etc...

The thing that worries me about that though is that from past experience those sorts of systems are basically just libraries built at each layer, so your end user facing UI app just tends to include these libraries and although it is ignorant of what the libraries do other than the parts they hook into it is still ultimatly running within the same app.

So is what your suggesting simply speaking, seperating them out into seperate apps still but just keeping them on the same box and talking to each other that way, as it would still need some way to know how many apps are running on each tier to connect to them...

I agree that these overlay nodes dont seem to add much to it, the thing i was originally trying to get away from was the idea that the users would directly connect to a node that did something, so the current node i call the *gateway* which would be the first point of call, connected to multiple login servers (not that you would need multiple by the sounds of it), and the realm/shard ones will still be needed i think to control the multiple world nodes that do the work.

Dont get me wrong it would be a hell of alot easier to just make 1 server app and keep it in tiers and just pass the objects around in there, which is pretty much what i was originally doing just with a WCF service, which talked to the client, but it was quite slow and is balls at scaling, which is the same problem i would get with a single app... although i very much doubt you mean i should just have 1 app for it...

So i think the problem at the moment is when your talking about these approaches im not quite sure where the app boundries lie, be it on the same machine, remote machines, same app etc.

If you dont have time to explain no worries, sometimes talking to people on forums can be like trying to teach a carrot to play a piano...

Codeka

Oct 5, 2009 at 2:04 AM

Quote:
Original post by Grofit
4 bytes - Content Size
1 byte - Message Type
XX bytes - Content

I'd use a multi-byte approach for your integers (for example, look at how UTF-8 works). It's highly unlikely that you'll ever need packets that are more than 65,000 bytes (meaning 2 bytes is the maximum) and the majority of your packets will probably be less than 128 bytes (meaning 1 byte is all that's required). You could just stick to 2 bytes for "content-length" to save on the decoding step, but that depends on how many packets you expect to be over 128 bytes really.

Oh, and a "content-lenth" field is only required if you're going to be using TCP. I didn't read everything so I'm not sure if you've already chosen TCP or UDP, but I would suggest UDP is probably the best choice. In which case, a "content-length" parameter is not needed. A library such as ENet adds reliable delivery on top of UDP for very little effort on your part.

Quote:
Original post by Grofit
Im currently toying with ideas of how to keep it secure, so i think that when logged in the first 12 bytes of the content will be a unique identiier that is linked to the currently logged in users, as although i *could* use the IP address as a way to bind you get the problem that more than one person could be on the same IP...

You can typically identify a user by their IP address and port number. You could also include a short "session-id" parameter (maybe 4 bytes) but in general I'd say that it's too hard to usefully spoof another connected user's IP/port.

Katie

Oct 5, 2009 at 2:36 AM

"Once you remove the crashing bugs, the fail-over will become redundant."

Except that you'll need to be able to take the backend down to do code upgrades on it.

There's also the machine to worry about -- disks fail, CPUs fail. RAM fails. We used to have a lot of aggro with the switches connecting our racks out to the connectivity provider's network; and one of those going squiffy takes out a whole rack of kit in one go, and swapping them out is time-consuming.

And you would be *astounded* how often our backend network would fall apart -- the europe half suddenly would be unable to route to the US half for minutes at a time. We used to have aggro with the database servers both being unable to see the other ones and then deciding that they therefore are the "master" from now on.

Some of the underlying networks are amazing unreliable. The web works because it's cached all over the place and there's a lot of fancy juggling goes on to hang everything together... Whole countries just used to fall off the world -- usually because weird routes got advertised somewhere.

Software reliability is only the start of making a system robust.

Even if your software never crashes under normal use, what happens when you get DOSed? Some part of your network will get attacked by something and you don't want the rest to come to a shuddering halt. And this doesn't even have to be deliberate -- the internet's got to the point where things *just happen*. Machines will spew out random packets in random ways... and some of them will end up at your servers. People dig up cables. Someone turned off the power to our science park the other day by accident; because of the way the connectivity works, the other side of the city, IT companies fell off the internet. And then one day, you'll need to move racks of stuff between hosting centres without stopping everything...

Xest

Oct 5, 2009 at 3:29 AM

I'd tend to agree with hplus0603, your architecture is needlessly over-complicated.

A 4-tier approach should indeed be fine for your needs, here's an example-

Client tier- The client, obviously.

Authentication/Routing tier- Handles authentication, routes packets to the correct game server

Game server tier- This may contain multiple servers with different servers handling different tasks, or different areas of the game world, you'll really want it to be scalable in some way. The login/routing tier should route a users requests to whichever game server is handling that client, or if you make it scalable in some other way then you need to setup your passing between servers using the routing setion and your servers

Storage tier- Should handle persistent storage, usually to a database.

There are other servers you could add that are shared across all your game worlds if the above setup serves just one gameworld. You'll probably want a web server for your game to handle account management, game news etc., you'll probably want a server list server which lists the IPs of all the gateways to the game world, this will probably be your clients initial port of call to see which addresses to connect to to actually access a particular game world. You may want a patch server, that the client will connect to to check versioning etc. before connecting to the server list server. You may want a management system on the server side which can gather data on server health etc. The difference you'll note with every single one of these servers, is that their role is shared across all game worlds, so can be treated separately from your game world architecture.

Things can get more complex, if you need more than one system in the storage tier for example, but the above setup should be scalable enough for thousands of players.

Codeka

Oct 5, 2009 at 4:19 AM

Quote:
Original post by Katie
"Once you remove the crashing bugs, the fail-over will become redundant."

Except that you'll need to be able to take the backend down to do code upgrades on it.

Taking the whole server down at a regular interval (once every two weeks, once a month, etc) is usually acceptable and people do expect it (we're talking about games, after all not stock trading servers). Writing a server that can properly handle hot updates without disconnecting users is very hard, and it probably won't even work most of the time (i.e. when an update to the client is synched with an update to the server - they're going to have to disconnect and update the client anyway).

Quote:
Original post by Katie
And you would be *astounded* how often our backend network would fall apart -- the europe half suddenly would be unable to route to the US half for minutes at a time. We used to have aggro with the database servers both being unable to see the other ones and then deciding that they therefore are the "master" from now on.

I think most of your other issues are also overkill for a game. Many of them can only be solved with geographical isolation (i.e. data centres in multiple countries - or at least different data centres in the same country), which is probably far out of scope for most people.

In addition, people accept that servers can crash and as long as your world is backed up, good P.R. can smooth over hardware failures. Gibbs' rule #18: "It's better to seek forgiveness than ask permission." In this case, it's better to apologize for hardware failures than to spend 6-12 months of your development cycle writing code that will handle them gracefully (besides, if you did spend that time, what'll end up happening is the failure will be a corner case that you never anticipated and it goes down anyway [wink])

Antheus

Oct 5, 2009 at 6:01 AM

Here is a nice read about hosting problem, and cloud computing. Seems that some very basic attacks can take down some very big hosting names. Apparently, simple UDP and SYN flood are enough to take down the clouds.

Grofit

Oct 5, 2009 at 11:04 AM

Hey,

To answer a few of the issues raised here, im currently working with TCP/IP, which i know is the wrong choice because of its bloated nature and multiple handshakes and all that jazz, but the current platform being targetted doesnt support UDP (it barely supports TCP/IP tbh)... thats not to say it has all been designed purely to only work with TCP/IP, the sockets are wrapped up via interfaces that can be swapped for UDP based implementations... As im sure i would support no where near > 1000 people if i were to stick with TCP/IP in the long run, but as its a code implementation detail for the moment, i will stick to worrying about the topology for now.

@Xest

Thats pretty much what i have at the moment, it is slightly different but not too far off as nodes can be merged, but so far the part you describe as the routing/login is my gateway node. It is the first external facing app the client should hit. This then links to a login node, which for all purposes may as well be part of the gateway node.

My Game Server tier is my Realm node, with its children area nodes for offloading the work onto. Such as validating movements and carrying out logic on NPC related entities. As you are mentioning in this scenario every seperate realm/shard would have its own realm node, which also acts as a sort of caching area for game entities too.

Then i have a seperate database... well 3 of them acctually, 1 for static game entities such as items, monsters, skills, areas etc, 1 for realm specific entities such as characters, settings, inventories etc, then finally an account db which stores user details and account settings. There would only really be 1 account DB in existance (maybe a fallover one), probably one static entity db as i was planning on using memcached for caching things from here as well to keep the load down and share the cache between all nodes that need it). Then finally the only DBs that would have multiple instances would be the realm specific ones.

In a one server box scenario here is how i imagined it all being setup before i made this post:

Server 1
{
1x Gateway/Routing node (app)
1x Login node (app)
1x Realm node (app)
4x Game nodes (app)
1x AccountDB (db)
1x GameDB (db)
1x RealmDB (db)
}

in a multiple server box scenario here is how i imagined it all hooking up:

Server 1
{
1x Gateway node (app)
1x Login node (app)
1x AccountDB (db)
1x GameDB (db)
}

Server 2
{
1x Realm node (app)
4x Game nodes (app) - the number 4 is just an example they can be added/removed at runtime, like a software version of a rack farm
1x RealmDB (db)
}

Now after this post i could easily merge the gateway and login node together, i originally split it due to me thinking maybe there would be a scenario where lots of people are logging in and it wouldnt hurt to add another node to offload some of the work to. Although these are only used as a validation system before the connection is passed over to the relevent Realm node...

Im also leaving out any fallover/failsafe servers, as they would basically be identical as the main ones, just ready to take over any work if anything goes wrong...

The realm node and the game nodes i cant see any harm in keeping them seperate, purely because if you have 1000 people all hitting 1 realm node, and it has to manage all the incoming requests, process them, update server side entities, send updates to DB etc it all just seems like it would bog it all down, i may be wrong and it may all be super fast, but i cant see any harm at this point having a set of distributed child nodes that do the work, this way more can be added at runtime, or taken away if needed. Whereas if its all built into the realm app then it would require taking it offline to beef it up or trim it down.

Although if i were to stay using a distributed method so everything is being farmed out i would need to add another small DB for centralizing the node statuses etc.

Anyway going off the feedback i have so far, most of you think it should be like this right?

Server 1
{
1x Routing / Login node (app)
1x Realm node (app)
1x AccountDB (db)
1x GameDB (db)
1x RealmDB (db)
}

Im ignoring the client as you could have many different client implementations, all they care about is always connecting to the routing/login appliction running on whatever server.

Antheus

Oct 5, 2009 at 11:54 AM

Quote:
Original post by Grofit
To answer a few of the issues raised here, im currently working with TCP/IP, which i know is the wrong choice because of its bloated nature and multiple handshakes and all that jazz,

Nope. TCP is problematic because of its stream orientation. In case of packet loss, peers must wait for lost or corrupt to be resent.

In case of noisy connections with constant packet loss (5% or so), these delays will cause huge problems that you will not able to do anything about.

hplus0603

Oct 5, 2009 at 12:34 PM

While there may be a service that does authentication, and forwards the client to the right realm/shard/zone server, I don't think that should be a separate tier. When things are running right, the client talks to a zone server, and that's it. This reduces the needed connections and hardware by a large amount!

Login for a traditional sharded (realmed) MMO goes something like:

1) Client finds "login.yourgame.com" and connects with a username and password.
2) The login service sends back a list of currently active realms/shards, as well as an identity/auth cookie.
3) Client picks which shard it wants to connect to (typically, a UI function), and connects directly to the character server for that shard, sending its auth. It disconnects from the login server.
4) Character server sends list of available characters.
5) Client selects a character (or builds a new one).
6) Character server instantiates character into the right zone, and sends the client the address of the appropriate zone.
7) Client connects to zone server and disconnects from login server.
8) Zone server and client exchange gameplay data as appropriate.
9) When time comes to change zones, the zone server tells the client what the new zone server is, and the client re-connects to the new zone server.

The zone servers typically keep persistent connections to the character server for their realm. This allows them to do things like cross-zone whispers, guild chat, etc.

The character servers may keep a persistent connection to the auth server, or not -- exactly how the auth server knows which realms/shards are available to select may vary.

The tiers look like:

One per game:Auth DB ------ Auth Server ---------+                |                   |One per shard:  |                   |Shard DB ----- Character Server ----+                |                   |                +- Zone Server -----+- Firewall ----------- Client                +- Zone Server -----+                +- Zone Server -----+

Note that only one of the client connections is active at a time.

This looks pretty much like a 3-tier system, with three kinds of services (kinds of nodes?). Also, for operational purposes, you may end up treating the "inside" connections as private (say, in a 10.x subnet), so you can allow certain kinds of requests only from "internal" addresses, for an additional level of security against external hacking.

Now, if your game will not scale past, say, 10,000 simultaneous active players, you can simplify a little bit. You may use the same physical server for Auth and Shard DB, for example. You only need one shard, which means you can use the same physical machine for character and auth services. And, finally, if you have a studly machine and a lightweight game implementation, you might get away with a single Zone server for all 10,000 players. The architecture then looks like:

Database ----- Auth and Character -+                |                  |                +- World ----------+- Firewall --------- Client

Grofit

Oct 5, 2009 at 1:04 PM

OH! im with you, the game nodes are based on areas of the world, but my original idea was to start off with no game nodes. Then as characters entered zones/areas it would create a game node for that area to control the NPCs/Entities, then it could be subdivided into 2 area nodes of smaller sizes if it got too big... but i think that may be over complicating it a bit then...

The way the toolkit builds areas at the moment is based on a finite 2d area (its a 2d client) and it has an id, so you could have a large area that is 1000x1000 with areaid 132 and a really small one of 25x25 with an id of 24. So as there could be hundereds of areas i didnt want to just create 100s of instances of area nodes, but maybe i should group nearby areas under a zone id or something then i could have like 10 zones or something and just group everything under them or something... acctually saying that i have region subdivisions too... the way the world is divided up in game is:

Worlds
|
|--- Regions
#####|
#####|--- Areas

So i could group the zones per region as there is about 10 of them at the moment... then connect directly to them as you say...

Gives me something to think about!

(edit due to the spaces making the world region bit look incorrect)

[Edited by - Grofit on October 5, 2009 2:04:37 PM]

Rycross

Oct 5, 2009 at 2:11 PM

Quote:
Original post by Grofit
To answer a few of the issues raised here, im currently working with TCP/IP, which i know is the wrong choice because of its bloated nature and multiple handshakes and all that jazz,

The problem with TCP/IP is really due to the fact that it's a reliable, in-order stream-based transfer. This means that dropped packets can cause delays in your data stream while the underlying protocol re-transmits those packets. There are other concerns, such as Nagle's algorithm, which basically caches your data and trying to re-package it to get an optimal packet size, causing a bit of extra latency. Whether these are detrimental or not depends on your game and the types of communication you are doing. An FPS really does need UDP, while an RPG or RTS will usually run fine with TCP/IP.

At this point I'd like to note that one of the largest MMO's in the world, World of Warcraft, uses TCP/IP. So to say that TCP/IP is the wrong choice is, at best, oversimplifying the matter, and at worst is just plain wrong.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.