- Joined
- Jun 16, 2004
- Messages
- 108
My latest project is joining a game hosted by a bot after the game has already started. This requires special logic on the server side (host bot) as well as the client side (a custom GProxy++) to work. Since these are rather big hurdles I imagine this feature is unlikely to gain traction, but nonetheless it was fun to work on.
Since I heard this functionality was already implemented elsewhere (NetEase?), I figured it would be fun to take a shot at it. This is basically just a proof of concept. Also, a low effort post.
Here is a video showcasing an old prototype of it running:
(This video showcases an outdated version, the current version simulates the game much faster)
The basic idea behind this process working is very simple. Host bots receive and then distribute player actions. If we recreate the setting of the game and then dish out these actions in the same way as they were sent out in the past, we should be able to get a client to simulate the game as it was before. Then, if the client is able to catch up to the present time in the game, that client can be "injected" back into the original game with the other players.
As far as I am aware, there are a few things that need to be done to allow this behavior:
1) the client must join a game that recreates the original environment properly (must see all players as they were at the start of the game, the same PIDs must be allocated to the same players, the random seed needs to be the same, etc)
2) players that disconnect must not actually notify other players that they are gone from the game; instead, the bot will sit on the fact that the player is gone
3) clients must be patched. In order to recreate the game state, the client needs to be able to receive packets for itself. Normally, a client keeps track of what actions it sent to the host, then clears out those actions when they bounce back. If a packet comes unexpectedly, the client disconnects itself. The patch would alter this behavior such that the client would accept these unexpected packets and act on them properly.
The basic join in progress flow works something like this:
1) a player disconnects from a join in progress enabled game
2) the bot turns that player into a placeholder so someone else can join the game
3) an admin tells the bot to host a "rejoin" game (via command !hostrejoin [game index] [game name])
4) some player running the custom grproxy joins this rejoin game and spoofchecks
a) if the joining player was not originally in the game, s/he will have to use the !rjjoinas command to pick the spot to fill in as, then leave and rejoin the rejoin game (!rjgetgames will show the valid game indices and player indices the player can join as)
5) the bot starts the rejoin game and the player starts simulating the game as it was until s/he catches up and gets injected into the real game
Rejoin relevant commands (only available while in a rejoin lobby): !rjwait, !rjstart, !rjjoinas, !rjgetgames
This sort of functionality could allow for a number of interesting features. If it were tweaked a little, action history could be saved to a file and then players could all join a game together and simulate it together, kind of like watching a replay together. They would also be able to restart the game at any point while watching. It also allows for an unrelated player (who has never been in the game) to join and fill in the spot of a disconnecting player. It could probably be adapted to allow any number of players to simply observe the running game using their game client. Maybe replays themselves could be loaded up by the bot for players to simulate and potentially rejoin.
I attached to the post builds of a ghost bot and gproxy for windows which implement the described functionality. I also attached the source separately for each of those tools, in case anyone wants to try porting over the functionality to their own code.
The attached grproxy (modified GProxy++) patches client memory in three spots, which means you should not connect to online services (like Battle.net) with your game client while using it, otherwise you might get banned.
You probably should not bother downloading any of this stuff unless you are someone who is familiar with working with GHost++ (development and/or usage). The join in progress feature only works when these programs work as a pair. This means that, because none of the bots online right now are setup to use this feature, it is only relevant to you if you are able to host a modified bot yourself.
Downloading the grproxy tool in this post will not allow you to join games in progress on any existing bots.
The grproxy tool included here is very simple and I have noticed some simple problems with it:
There are probably also problems introduced in the host bot too that need to get fixed. I do not recommend actually trying to use the bot code for general purpose hosting in its current state.
Also I attached another tool I developed while developing this join in progress thing, tftlaunch2:
tftlaunch2 and grproxy are only designed to work with game version 1.28.5.
All the stuff here can be built with Visual Studio 2017 Community Edition (latest update required for c++17 fixes). The bot also builds on linux.
edit 1: uploaded minor update to grhost and source, in which a rejoining player that was ahead of the other players would not leave the rejoin state
edit 2: uploaded minor update to grproxy and source, prevent a crash after leaving a game when grpconnect is turned off in the configuration file
Since I heard this functionality was already implemented elsewhere (NetEase?), I figured it would be fun to take a shot at it. This is basically just a proof of concept. Also, a low effort post.
Here is a video showcasing an old prototype of it running:
The basic idea behind this process working is very simple. Host bots receive and then distribute player actions. If we recreate the setting of the game and then dish out these actions in the same way as they were sent out in the past, we should be able to get a client to simulate the game as it was before. Then, if the client is able to catch up to the present time in the game, that client can be "injected" back into the original game with the other players.
As far as I am aware, there are a few things that need to be done to allow this behavior:
1) the client must join a game that recreates the original environment properly (must see all players as they were at the start of the game, the same PIDs must be allocated to the same players, the random seed needs to be the same, etc)
2) players that disconnect must not actually notify other players that they are gone from the game; instead, the bot will sit on the fact that the player is gone
3) clients must be patched. In order to recreate the game state, the client needs to be able to receive packets for itself. Normally, a client keeps track of what actions it sent to the host, then clears out those actions when they bounce back. If a packet comes unexpectedly, the client disconnects itself. The patch would alter this behavior such that the client would accept these unexpected packets and act on them properly.
The basic join in progress flow works something like this:
1) a player disconnects from a join in progress enabled game
2) the bot turns that player into a placeholder so someone else can join the game
3) an admin tells the bot to host a "rejoin" game (via command !hostrejoin [game index] [game name])
4) some player running the custom grproxy joins this rejoin game and spoofchecks
a) if the joining player was not originally in the game, s/he will have to use the !rjjoinas command to pick the spot to fill in as, then leave and rejoin the rejoin game (!rjgetgames will show the valid game indices and player indices the player can join as)
5) the bot starts the rejoin game and the player starts simulating the game as it was until s/he catches up and gets injected into the real game
Rejoin relevant commands (only available while in a rejoin lobby): !rjwait, !rjstart, !rjjoinas, !rjgetgames
This sort of functionality could allow for a number of interesting features. If it were tweaked a little, action history could be saved to a file and then players could all join a game together and simulate it together, kind of like watching a replay together. They would also be able to restart the game at any point while watching. It also allows for an unrelated player (who has never been in the game) to join and fill in the spot of a disconnecting player. It could probably be adapted to allow any number of players to simply observe the running game using their game client. Maybe replays themselves could be loaded up by the bot for players to simulate and potentially rejoin.
I attached to the post builds of a ghost bot and gproxy for windows which implement the described functionality. I also attached the source separately for each of those tools, in case anyone wants to try porting over the functionality to their own code.
The attached grproxy (modified GProxy++) patches client memory in three spots, which means you should not connect to online services (like Battle.net) with your game client while using it, otherwise you might get banned.
You probably should not bother downloading any of this stuff unless you are someone who is familiar with working with GHost++ (development and/or usage). The join in progress feature only works when these programs work as a pair. This means that, because none of the bots online right now are setup to use this feature, it is only relevant to you if you are able to host a modified bot yourself.
Downloading the grproxy tool in this post will not allow you to join games in progress on any existing bots.
The grproxy tool included here is very simple and I have noticed some simple problems with it:
1) unit selections can become visually unsynchronized as a result of joining a game in progress; easy way to fix is to change your selection twice, or select and unselect a unit
2) dialog boxes can pop up while simulating a game, these should probably not be allowed to pop up since clicking them after the join completes would probably cause bugs in the map
3) ... there are probably a lot of things I did not notice yet
2) dialog boxes can pop up while simulating a game, these should probably not be allowed to pop up since clicking them after the join completes would probably cause bugs in the map
3) ... there are probably a lot of things I did not notice yet
Also I attached another tool I developed while developing this join in progress thing, tftlaunch2:
tftlaunch2 allows you to run multiple clients and have them all join the same LAN game. This tool also patches memory, which means you should only ever use it for the purpose of having all your clients join the same LAN game. Check the instructions.txt file for how to use it.
tftlaunch2 and grproxy are only designed to work with game version 1.28.5.
All the stuff here can be built with Visual Studio 2017 Community Edition (latest update required for c++17 fixes). The bot also builds on linux.
edit 1: uploaded minor update to grhost and source, in which a rejoining player that was ahead of the other players would not leave the rejoin state
edit 2: uploaded minor update to grproxy and source, prevent a crash after leaving a game when grpconnect is turned off in the configuration file
Last edited:
