Game Client in Design Philosophy

ID:266056
 
Dec 23 2011, 7:36 am
This idea really came to me while I was responding to a post about the Dream Maker Software, and one of the drawbacks was the lack of Client-Side processing. This was something that could drastically increase the size and speed of games, so I thought of something. Instead of asking for Client-Side processing from Tom and Lummox, why not do it myself? This wouldn't be a terribly difficult task to be perfectly honest, and it works almost exactly like a client for other games.

The Game Client would be created, It would have everything to make the game work on its own. All of the processing, the calculations, and everything else would be done off of the players CPU, not the server's. The client would be set up to only allow the player access into the world if it could establish a connection with a central processing server. If a connection was made, it would periodically send signals to the processing server to send back to all game Clients connected to that server. These signals would only be sent when something is done that would effect other players, whether physically or visually. This means that signals will be sent whenever a player moves, attacks, speaks, ect. This will let the server know what the player is doing and will send appropriate responses to everyone else, showing the player moving from one spot to another. The player client calculates the amount of any damage or healing and simply relays that number to the server.

I'll bore you not with further details as I assume you get the point. Therefore I'll add this last bit.

TL:DR - The player client processing all math and whatnot, only sending signals to a main server whenever necessary. This would, in theory, relieve a lot of stress off of the main server.

The only thing that may make the entire system fail would be the amount of signals required to make this possible. It may just be that they might be in great enough amount that they would bog the server as much as, if not more than, a normal Server-Side game. This is my only predicament before pursuing a model of this system.

Any thoughts?
#1 Dec 23 2011, 9:30 am
Gakumerasara's done this already in his first-person shooter, Vengeance56 a while ago because first-person is really slow.

IainPeregrine also made use of inter-world communication with his Artemis project. Basically, it allowed you to chat with people between games. One person logs in to Game A, another person logs into Game B. Both games support Artemis. Anyone in Game A can chat with anyone in Game B over world chat as if it were one game. People in Game A and B can also chat with Ceres, which I think was some kind of hub.

So, it's definitely possible, but it's really complicated.
#2 Dec 23 2011, 9:51 am
In response to Kaiochao (#1)
Interesting. I assumed that others had the same idea's, I was simply unaware if they had a chance to attempt an implementation of it. The only thing I'm wondering now is exactly how fast the main server is to responding to these constant message relays. I knew that such a thing was indeed possible, however whether it was possible was never my question, speed and efficiency was. Do you know anything about the processing speeds of these libraries?
#3 Dec 26 2011, 9:43 am
In response to Solomn Architect (#2)
How *exactly* are you going to do this?
#4 Dec 26 2011, 10:32 am
In response to Magnum2k (#3)
I explained it above. The process itself is actually very simple. You would use the Topic function for the server-to-server communication and simply track everything on the server, packaging the information and sending it to the main server. The main server processes that information and sends it out to everyone else. The client server's would process the messages received and act accordingly. Client-Side processing isn't anything difficult, it just takes a little bit of knowledge and critical thinking.
#5 Dec 26 2011, 10:49 am
In response to Solomn Architect (#4)
That's okay. Write out a pseudo-code for it and I'll complete it - I'm too lazy at the moment to do any thing that actually requires thinking.
#6 Dec 26 2011, 11:04 am
In response to Magnum2k (#5)
I'm unsure how you attempting this has anything to do with answering my question. I'm curious how efficient this model is with resources and whatnot. I assume that this is actually an extremely efficient model for multiplayer games. I'll write something up myself and check it out. I do plan on reviewing the results and posting them for others to review my findings.
#7 Dec 26 2011, 11:09 am
In response to Solomn Architect (#6)
You can achieve this by simply using JavaScript but bleh whatever, go ahead.
#8 Dec 26 2011, 6:59 pm
That's the thing. You can't make a "One size fits all" Game Client. Each client has to be able to send specific messages to the server that can process them and, in turn, send back messages to the Client that it can understand and parse. The best one could muster is a Tutorial series on how to develop one for yourself.
#9 Dec 27 2011, 12:22 am
In response to Solomn Architect (#6)
Solomn Architect wrote:
I'm curious how efficient this model is with resources and whatnot. I assume that this is actually an extremely efficient model for multiplayer games. I'll write something up myself and check it out. I do plan on reviewing the results and posting them for others to review my findings.

It seemed to work pretty decently for Vengeance 56. But for an action game, I wouldn't expect it to support more than a handful of players on one server. If you make something turn-based, you could handle a much greater number without the increased latency damaging gameplay. Make sure to use the persist option of client/Export() (I think it was actually Gakumerasara who got the staff to implement that option...).
#10 Dec 27 2011, 6:16 am
The problem is that BYOND already handles a lot of things correctly. You *could* use world.Export() to send messages between servers so that each client can run their own server, but most of the messages would be used to just re-create what BYOND already does for you. BYOND does some processing on the client and it'd be nice to be able to do more, but to implement it like you described is a lot of work because you'd be throwing away the client-server architecture BYOND gives you. It'd be easier to just not use BYOND.

That's why this would be better as a built-in feature - you could still use BYOND's client-server model but extend it to include custom client-side processing that's relevant to your game. The feature is surprisingly simple to add because you can place lots of restrictions on it (and have it still be useful) and because Dream Seeker already has the ability to execute DM code.
#11 Dec 27 2011, 9:17 am
In response to Forum_account (#10)
If by that you mean that the messages already sent to the current model is Graphics, User Input, Server Output, ect, then yes, the current model holds very well and recreating that would be quite a waste. However, I mean calculation processing, loops, other high CPU functions to run off of the Client, freeing up the server quite a bit. If these things could be dumped to the Client, at least somewhat, it would really improve the playability of a lot of games. I just don't see the point in having all of these people connect with high quality computer's, ripe for CPU usage, without leeching from that at least a little. Of course this is more of a Developer's improvement as players would find it bothersome how more of their CPU is being run by a simple BYOND game.
#12 Dec 27 2011, 10:18 am
In response to Solomn Architect (#11)
The problem is that the high CPU functions tend to require knowledge of objects. You'd need to share and manage information about objects in the world - what mobs are standing where, what objects are dense, etc.

For example, path planning can be expensive but you'd need to make sure that both worlds are in sync. If you're using two servers and world.Export() to communicate, if one server believes a turf to be dense and the other thinks it's non-dense, a path planning routine could find an incorrect path. To be able to offload the path finding you need to make sure this information is in sync, which is a difficult problem that takes a significant amount of CPU time to manage.

With the problem you're trying to solve, bandwidth usage might be the bigger issue. Suppose you want to use 30 moving objects to create a detailed explosion. With BYOND's client-server model the server creates the objects, tells each nearby client about each object, and notifies each client of each object's position updates. It doesn't take a lot of CPU time to move each object but it takes a lot of bandwidth to notify every client of every position change. With client-side processing the server could tell the client "make an explosion at this location" and each client would create and manage the objects itself - just one message is required.
#13 Dec 27 2011, 11:57 am
In response to Forum_account (#12)
That is more of less the model I'm going for. Each Client-Server will be its own stand-alone version of the game. It will be the entire game in and of itself onto the player's computer. It manages itself to every extent. The only thing that the Main-server would be used for is receiving and resending those signals to each client to tell them what is going on. From there, the server inherently knows exactly what to do when certain signals are called.
#14 Dec 27 2011, 12:14 pm
In response to Solomn Architect (#13)
Solomn Architect wrote:
That is more of less the model I'm going for. Each Client-Server will be its own stand-alone version of the game. It will be the entire game in and of itself onto the player's computer. It manages itself to every extent. The only thing that the Main-server would be used for is receiving and resending those signals to each client to tell them what is going on. From there, the server inherently knows exactly what to do when certain signals are called.

If each client is a standalone version of the game that manages everything then you're not making client-side processing, you're making a single player game =)

You can use world.Export() to add some communication between servers. As the extent to which you have multiplayer interaction increases, the practicality decreases. You keep talking about "signals" in a very abstract sense, but what will they actually be used for? I'm not sure that client-side processing is the right term here.

I'm also not sure where the benefit is. Here's how it happens now:

1. A player hits the up arrow.
2. Their client determines that this key press matches a macro and sends a message to the server.
3. The server executes code associated with the macro. This code results in a position change.
4. The server sends a message to every client near the player that moved, informing them all of the player's updated position.

The benefit of shifting some responsibility to the client isn't in CPU savings - this task isn't taxing the server. Client-side processing can conserve bandwidth, but that's not the case here because these client-side updates need to be sent to other clients. You'd get better responsiveness for each player, but the responsiveness of updates from remote servers would suffer and you'd have concurrency issues - if you and I move to the same turf at the same time, both of our clients allow the moves because each move was performed before the client knew the other player had moved. You'd also have to code each client to be aware of what properties have changed and know to send messages to the server, and the server would have to do some processing to decide what updates need to be sent to each client.
#15 Dec 27 2011, 1:49 pm
In response to Forum_account (#14)
Forum_account wrote:
If each client is a standalone version of the game that manages everything then you're not making client-side processing, you're making a single player game =)

I guess I should have said this before. The Game Client will not allow the player to accent -ANY- content past the Login screen unless it can set and maintain a signal with the main server. This keeps players in the multiplayer environment without fear of Single Player boosting.

[...]if you and I move to the same turf at the same time, both of our clients allow the moves because each move was performed before the client knew the other player had moved. You'd also have to code each client to be aware of what properties have changed and know to send messages to the server, and the server would have to do some processing to decide what updates need to be sent to each client.

This is when things are handled by not having density in inter-player relations to begin with. Mobs would be allow other mobs to pass through each other, thus saving a lot of headache due to latency issues. Blizzard uses this model in World of Warcraft with much success. Of course they will collide normally with solid objects and whatnot.
#16 Dec 28 2011, 7:23 am
In response to Solomn Architect (#15)
Solomn Architect wrote:
This is when things are handled by not having density in inter-player relations to begin with. Mobs would be allow other mobs to pass through each other, thus saving a lot of headache due to latency issues.

That's only one example of an issue that can be caused by information being out of date. It's also not a good solution to say that you just can't do that. What if I'm able to attack you because my knowledge of your position is out of date? What if I'm able to run through a door because you locked the door before I passed through it, but my server wasn't aware of that?

The reason why you have these problems and the reason why it'd be difficult to handle them with this model is because this is something that just works better under BYOND's client-server model. The server manages everyone's position and all events so it always knows who is where and who tried to move first.

The BYOND server's current behavior is often ideal and when it's not ideal it's still beneficial (ex: it has higher latency but avoids concurrency issues). Some actions would be better handled by the client but I don't think you understand why that'd be better. You're suggesting that everything be handled on the client, but that's likely to be worse because some things are better handled by a central server. It would be beneficial to have client-side processing in a way that augments BYOND's existing model, not in a way that replaces it (because the existing model is good for many things). I don't think you understand that it's sometimes better to have a central server, so you don't understand how detrimental it would be to lose that (when you shift all responsibility to the clients).
#17 Dec 28 2011, 2:07 pm
In response to Forum_account (#16)
Forum_account wrote:
I don't think you understand that it's sometimes better to have a central server, so you don't understand how detrimental it would be to lose that (when you shift all responsibility to the clients).

But I understand quite clearly, sir. I was not suggesting exactly a "Better" way, but approximately a more efficient one. Client-side server models have their fair share of problems, just like the Central-server model BYOND currently uses. I don't want you to think that I was pressing for a change, because it's for those reasons why I am hesitant to develop something without heavy constraints to accompany the latency.

To solve this problem, you would have to stop all incoming signals and have them wait until the previous one has been sent to all other clients. This is fine on a slower action or a turn based model, however things can get extremely crowded when you're trying to handle player damage, health, enemy stats, death, magic, position changes, ect.(assuming that we're talking about an RPG of some sort). If the server experiences even a second of latency, it can cause the entire game to come crashing down due to an overload of processing, thus locking up the server and eventually shutting down.

I like BYOND's current model. I was only suggesting another way that things could be done.