• Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About Grofit

  • Rank
  1. MMO Server Layout Design

    Thats the way i was thinking about it originally but then i thought i would just get way too many hits on that one box, so i would offload it to a realm box which would do the same job as the guy mentions in there... The reason i started that way was because you wouldnt need to change connection at all, once you are connected thats it... if you change zones or whatever it just routes your data to the relevent zone and forwards you the response...
  2. MMO Server Layout Design

    I was under the impression WoW and the other larger ones used UDP, wow... Currently if someone drops some packets it should only affect their game, everyone else would just carry on. The game is point and click at the moment, so you click and move around that way, but again this is all just a learning exercise to see how well it all copes then maybe make something bigger out of it when i know what im doing... Currently the clients recieve a Movement X/Y event and run the pathfinding locally to move a character there. As long as the server validates the movement then the clients can do the leg work... attacks are all done via clicking a skill so its not eye bleeding action, but i *could* get by with UDP as if i miss movement packets it doesnt matter too much as the client will just keep moving on its current path, and if its staying still next update it gets will still take them to the same point, and there is sync frames sent out every now and again to make sure everyone is up to date. I also have server side trees so only the people who need to be updated get the updates rather than just spamming everyone, so ive tried to make it fairly efficient in how it sends/recieves the data and how it copes with it all, im just not that sure about how it should all have been put together... but i guess i was thinking everything would be alot slower than it may acctually be...
  3. MMO Server Layout Design

    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]
  4. MMO Server Layout Design

    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.
  5. MMO Server Layout Design

    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...
  6. MMO Server Layout Design

    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...
  7. MMO Server Layout Design

    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!
  8. MMO Server Layout Design

    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]
  9. 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...
  10. Hey, Ive got an area that is of finite size, lets say 50000x50000 which is loaded up and put into a quadtree and then displays what it needs to. The tiles may not always be placed in an equal stepping order like most tile based games, and can be put down absolutley into any position. The collision however is not done on a tile by tile bases and each area has a list of *shapes* (which expose a Contains(x,y) Intersects(Shape)). Although the collisions are generated on a tile by tile basis it may only take up 5x5 pixels of a 32x32 tile. Ive not done much with path finding before although i get the principle of A* and other common path finding algorithms. Its just im not sure how to create a grid to do the path finding off from the objects i have. Most tutorials ive looked at so far just use a simple NxN grid and each one is an incremental step along the given axis and that makes it really simple, however i cant make a grid 50000x50000 and do it pixel by pixel as that would take forever. So i was then thinking that i would have to do some sort of step system, so i would make a path finding node every N pixels, so lets say 5 or 10. This sounded great until i realised that if it is going to check pixels x5,y0 it may not find a collision then next path node x10,y0 may not find a collision, however one may be present at x8,y0 which would give a large penalty score or even block the path... and it would skip over it... Ive been trying to come up with some solid methods for it, like using a quad tree for top level path nodes, then if it collides break it down to see if it is something to worry about or not... but i was just wondering if there is any examples of this kinda stuff online or anyone has any advice on what to do for this kind of path finding.
  11. Thanks for the response, will check out that link and would be great to have polygon vs polygon collision, just didnt want to complicate things... for some reason the page wont load keeps timing out or something, but this net connection is balls... so hopefully i can try and drive round the neighbourhood trying to find a more solid connection to view it :D
  12. Hey, As i said above it implements an interface that just returns a bool for a contains check and an intersects check. Doesnt need to be fancy just needs to be handed a circle/rectangle/polygon and tell you if it intersects or not (well if using the intersect method) or if using contains method it just sees if the given point is within the objects area... Although its always going to be an ICollisionHandler internally it would check to see what type it is... so here would be a typical circle class: public class Circle : ICollisionHandler { // Private members private double m_X, m_Y, m_Radius; // Public properties for all members ... // The collision handler implemented methods public bool Contains(Point Position) { // See if the point is contained within the circle // then return true if it is or false if not } public bool Intersects(ICollisionHandler Entity) { if(Entity is Circle) { // Do circle vs circle intersection and return true if // they intersect or false if not } else if(Entity is Rectangle) { // Do circle vs rectangle intersection } else if(Entity is Polygon) { // Do circle vs polygon intersection } return false; // wasnt any of above so no collision } } Hope that clears things up, and thanks for the quick response. It doesnt need to be 100% accurate, although the more accurate the better :D
  13. Hey, Im having to write a lightweight and simple library in C# that handles collision detections for Circle/Rectangle/Polygon classes. Each one has to implement the following methods from the ICollisionHandler interface: - bool Contains(Point Position); - bool Intersects(ICollisionHandler CollisionHandler); As its for silverlight i cant rely upon alot of the stuff in the .net library so i just wanted to make my own quick implementations. Im pretty sure the circle collision detection for intersects was to add up the distance and the radiuses then /2 and compare it to the radius of one of the circles or something, but i cant remember off top of my head. Had a quick look but to be honest ive just moved house and im leeching off someone elses hub, and connection keeps dying. So if anyone can just reel off some code then thats brilliant! but im not expecting it, so any *specific* articles would be great. Contains should be fairly simple i would imagine, but i need to support the following Intersects: - Circle With Polygon - Circle With Rectangle - Circle With Circle - Rectangle With Polygon - Rectangle With Rectangle Dont need polygon with polygon... its currently holding me up on a project im working on while my net is off. Its kinda like a 2d map editor but the user can draw trigger areas (the above shapes) and then save them out to the file with some other data, then in the game it needs to check for collisions with them... Ive already done all the other work, like setting up the quadtree and seperating out all the triggers and things so its just adding these methods and im good to go! Any help would be great!
  14. Slerping from 2x Vertex3

    If it helps anyone else, i think ive answered my own question... When rotating a quaternion you would need to create a new quaternion with the new rotation then do the special Quaternion multiply between the new and the old, which gives you the new quaternion with the total rotations...
  15. Slerping from 2x Vertex3

    One other thing that may sound trivial to you guys but has me thinking... Would it be best off in the above example to store the direction the entities are facing as Quaternions or store them as Vector3s and just convert them to quaternions each time... The thing that puzzles me is that if im using Quaternions each time it makes sense to keep them as quaternions, but how do i rotate the quaternion? im sure its simple but quick searching yielded nothing worthwhile... As they will not always be looking towards entityB so if they want to look to the left or upwards im not sure how to do a rotation on the quaternion... or is it just like rotating a standard 3d vector? Everything i read just explains about how to create a quaternion from your RollPitchYaw or AxisAngles, so the Quaternion is the end point... never the starting point... if that makes sense... It sounds like it should be simple, and maybe it is and i will kick myself once someone posts... [Edited by - Grofit on April 29, 2009 3:54:39 PM]