![]() ![]() That's probably something the router could "discuss" with the servers kind of easily.īut I'm not sure you could even properly implement the servers based on Unity in such a setup. ![]() The router would only have to know which client IP needs to be mapped to which server. How would you implement the Router?ĪFAICS, the router couldn't be implemented with Unity (but that would probably also be "kind of overkill" -) ). Maybe there's some intersection of common issues we might run into (on the more abstract levels) -) I'm happy to share any experiences I'm having with this on the forums (see, for instance, Writing own network layer on top of Unity network layer). ) instead of a single call into the C++ stuff, but that shouldn't be too bad. I think that's another thing that is really missing in the current API, but I don't mind implementing that myself too much (guess it gives me a little performance hit doing a lot networkView.RPC(., player. So, what I'm basically doing in my project is moving the "All" and "Others" RPCModes into my own code so that I can distribute messages only to the people they are relevant to. basically, what I'm using are just RPCs -) ). I think except for this "small issue" with only allowing a single server (and a few minor issues), it's a very nicely designed API and implementation (I'm not using the buffered stuff, though, and neither am I using the Network.Instantiate-stuff because I feel I want and need more control on how things are handled. Well, what I've been doing recently is creating my own networking on top of the Unity networking. The difficult problems here are still with the many game clients accessing the game server (but I'm getting your point: it's significantly less clients per server and significantly less hassles on server transfers, so it may in the end be the best route to go in most cases) -) It's just a bunch of clients (at the same time acting as game servers) accessing a single database. Of course, you could put the messages to the database and then distribute from there to all the servers.ītw, I don't think that really would require a distributed database system. ![]() It also doesn't work when you want to have people communicating between those different areas. loading different terrains into one level probably won't work - but I haven't looked into this, yet also not everything has to be terrains, and with "just geometry", I don't see much of a problem with doing this completely dynamically). Obviously, the latter comes with quite a few other catches, too, and I'm not sure if all of them can be solved with Unity (e.g. It does not when you want to create one seamless world where people hardly notice they're switching from one area to the next. That works smoothly, when you have separate worlds. Doing such significant API-changes can become quite painful when there's already a lot of games using those APIs, so the earlier it is changed (if a change is needed), the better -) Maybe instead of using a lot of static stuff for networking, some factory pattern could be used? That'll work smoothly for the approach that most people will use (single server, few clients), but it can scale when things become more involved.Īs mentioned before: This is not something I need right now, but what I'm doing right now is aimed towards that, and I would like to not run into a dead end on the way. That could possibly be a dead-end in the long run. Would this be currently possible? Since most network related stuff having to do with connections is static, I would assume it's not. Finally, there's setups where the servers also need to be connected with each other. At least, that'll be needed if you try to achieve any kind of "smooth" transition.įurthermore, there's obviously things like "global chat" that would require being connected to a "chat server" as well as a game server. ![]() There's a couple of different approaches handling that, but my understanding is that in many of them, there's the need to be connected to multiple servers during the transfer. I'm not even sure if that should be called "massive", yet. Obviously, when you want to support larger amounts of players, you'll need to partition the game space so that different servers can handle different areas. However, I'm wondering how one could do a server transfer in an MMO-style game (I believe that "with a few hundreds" of players playing the same game, you'll already run into these kinds of things). The way I understand the current networking API of Unity, it's designed in a way that only supports a single server. This is obviously an MMO subject, but I thought I'd rather raise it sooner than later, even though it's not an issue for me right now because right now I'm putting everything into a single server. ![]()
0 Comments
Leave a Reply. |