Non-host player syncronisation issue a show stopper |
Hi Everyone,
Before I use my first post here to report a, rather show stopping, bug for multiplayer, I'd like to say how much potential I see this game has and that if it wasn't for this bug I would happily be encouraging friends and people at work to play a massive PBEM/PBW game of SEV!
So, onto the bug.
Basically, in a TCP/IP game, any non-host player's orders/research/build/ship designs are oftem lost during the turn processing and replaced by what might as well be the choices of an AI player. It really makes the game unplayable and you might as well play against the AI.
Looking around the forums, this has been mentioned a couple of times in comments and I found the bug in the bugs/features list. However, the reason I am posting about it is because, whiles it has been reported for a while, it isn't listed as a priority fix. I can't see how this is the case, since it stops an reasonable multiplayer game from happening.
I've looked around for a fix for this, maybe a setting ingame or something similar, but have not had any luck. If someone knows how to get around this bug, please let me know. If not, and you experience the problem, please post here and let the developer know how much this needs fixing in the next update.
Thanks,
Paul.
Tried PBW?
You might consider giving PBW a try (Play By Web). Once the game is up and running (i.e. everyone has their empires submitted and the host uploads the game setup file), it's quite useable. It does a nice job of automating the process of gathering turn files, executing the turn, and distributing the next turn file to all the players; the game "owner" can sit back and just play, while the PBW server takes care of stuff.
Being an online MOO2 player for a number of years who is accumstomed to directly connecting with opponents in the game, I'd like to see TCP/IP functionality fixed, as well. However, since I've played a few games of SE5, I am not certain how much advantage it will provide. Once a game starts to get going, each turn starts to take long enough that direct connection doesn't provide much of an advantage. If everyone is online at the same time, I've found that you can crank out turns one after another. You still have to wait a little, of course, because progress is still limited by the slowest player on any given turn.
If you're interested, it's at http://www.pbw.cc
PBW
PBW is simultaneous turns only, I believe. Basically it just runs a PBEM game, with the .plr files being uploaded to and turn processing being done on the PBW server, rather than on one of the player's PCs. If something goes wrong with the turn processing (which I've seen, though not recently), the game's owner can just download the .plr files and run that particular turn manually.
The bug you mentioned is not present in PBW. (Someone once mentioned that the bug is basically just a matter of .plr files not being transferred correctly to the host PC in TCP/IP mode.)
PBW
Hmmm, interesting. I'll give it a look this week and see how it all works. Might make running a game much simpler!
Thanks for the info, I just need to go work out how to play properly now 
Re: Non-host player syncronisation issue a show stopper
2 things we did to get around the problem (both seemed to work):
1) Always have the host computer finish his turn first so it is back to the 'main MP screen' and waiting for the other player files. It seems if the host is still playing his turn when a remote computer tries to send it's turn file the host never properly receives it.
2) Run the game on a seperate PC. This way there is a dedicated host that is ALWAYS sitting at the main MP screen waiting for player files so it eliminates the need to finish turns in a particular order.
We are currently running with option 2 so we could alter the settings files to speed up the combat between turns. Hope that helps!
Update
We've now tried the play by email version of multiplayer, which seems to be working perfectly. Enjoying a bug free game so far!
It seems to be a problem with the simultaneous mode or with the TCP/IP network code itself.