So I'm continuing an older project I'd once put down for a bit and one of the things I'm going to do is use a client application to connect to the main server when you log in and click, "join game" or whatever it ends up being.
If you're a regular PC gamer and you play games that use clients, such as World of Warcraft or League of Legends, to interact with your account outside of the actual game, you'll know that one thing they do is make sure your game is up to date and if needed, download and install any updates to either the game client or the game files itself.
Is there a way to get this behavior? Such as check the current version of the game versus the version that's installed and then have it automatically download and update the game?
One of the easiest, if clumsy, ways I've thought about doing it was simply through the Windows system shell. If I'm not mistaken, everything you'd need to do could be done through there such as pinging the game server, downloading the files and installing them, ect.
That is possible, right? Or even if it is, is there maybe a more suitable way of handling this without having to make explicit calls to the system shell to get it done? Or worse yet, telling the playing that they have to go to the download page and reinstall everything again just for the one update.
ID:1926721
 Aug 28 2015, 8:12 pm
|
|
|
Aug 28 2015, 8:15 pm
|
|
Kaiochao
  |
Are you talking about in BYOND games?
|
I don't think it's something you have to worry about. The "client" for all BYOND games is Dream Seeker, and players aren't able to connect to servers that have a more up-to-date version.
| |
Wait, are you trying to do something like what Vengeance 56 does for multiplayer? Have a separate DME for the client and the server, and use world.Export() for all the networking? This is actually a pretty bad idea. Not only does world.Export() have a minimum ping of 100ms, but it requires port forwarding for clients as well as the server.
Either way, both the client and the server would be updated by the BYOND pager. | |
Not quite actually being a true game client, no. Exactly like you said, having a separate DME for a client and server, but the client application is for account management while the server's job is simply to host the players itself. That way, out-of-game uses doesn't take up more resources and require me to try to modularize more game states.
All the client would do is forward the player to the game server through the preinstalled game itself. Not actually trying to use world.Export() as a socket. Would that still require a port forward? The reason I ask is because the game is a round-based PvP game and I wanted to have a hub server that could manage the player queue and spawn additional servers for the individual games going on. I can already spawn additional servers, that's not difficult, but I'm just trying to think of a way to clean up the networking and player management. I think having players manage their game settings and account stuff off of that hub server would free up a lot of resources instead of having several idle clients using up server bandwidth and resources just so they can tinker with their stuff out-of-game. | |
The performance for world.Export() is minimal, there is no HTTPS and even the performance for world.Call() is minimal, so there would be no gain by doing this.
| |
ErikHanson wrote:
The performance for world.Export() is minimal, there is no HTTPS and even the performance for world.Call() is minimal, so there would be no gain by doing this. No one is talking about using world.Export() for client-server communication. Pretty much everyone understands why that's a bad idea. Also, what is world.Call()? | |
I've made an external Mysql controlled account login/registration with a login prompt for the game, but as far as game updates go and a client for account management. That seems a bit far-fetched. The Pager and DS already handle all of this.
I suppose it may be possible, though?? Not sure. | |