Post by: VBAM Charlie on February 11, 2008, 09:03:10 AM
Post by: Erik L on February 11, 2008, 09:33:11 AM
Post by: Brian Neumann on February 11, 2008, 04:32:48 PM
Brian
Post by: SteveAlt on February 12, 2008, 08:18:36 AM
Quote from: "Erik Luken"
Multiplayer would need to be hotseat. Or emailed databases. Though remember that when you advance time, it advances for everyone.
Hotseat would work well as you could handle events as they appeared. Emailing the Stevefire.mdb file is another option, although I would recommend compacting it before sending it. You would also have to agree between yourselves what events would require the database to go around everyone again.
Steve
Post by: Haegan2005 on March 03, 2008, 11:50:08 PM
. Ah well. I was thinking that Aurora has much potential for multi player carnage. I really enjoy my colo games, but I also enjoy watching my son come up with his own unique approach to problems. In some cases the problem is his dad and his father's mobs of tanks and calvary. While he by no means wins all of the time... It is enough to kep me on my toes.Basically, my question is thus. What would be needed to run Aurora as a true multiplayer game? And is it worth Steve doing it? I think that most of us play solo and the game does this very well. But multi brings forth its own issues with simultaneous movement, diplomacy sequencing, who gets what message and, I'm sure, lots more issues that I am too ignorant of in programming to identify.
Post by: SteveAlt on March 04, 2008, 03:42:46 AM
Quote from: "Haegan2005"
I have been thinking about multi for some time now. My son and I both ejoy hotseating for Civ 4 and Alpha Centauri. We will lose a whole day this way very easily
Basically, my question is thus. What would be needed to run Aurora as a true multiplayer game? And is it worth Steve doing it? I think that most of us play solo and the game does this very well. But multi brings forth its own issues with simultaneous movement, diplomacy sequencing, who gets what message and, I'm sure, lots more issues that I am too ignorant of in programming to identify.
If you hotseat Civ you should be able to do the same for Aurora. When you aren't in SM mode you can only view each race one at a time. If you want to keep your situation secret from an opponent, just close down windows and leave the main menu bar so he can change to a different race. One useful addition might be for me to add something so that when you are not in SM mode, you get a message to indicate that a different race has an event.
A multi-player game would be best with an SM though. He would advance time, get players to react to events and play the non-player races.
Steve
Post by: JSilvanus on July 16, 2012, 08:41:53 AM
Post by: fflaguna on July 16, 2012, 09:31:20 AM
The only other way that I can see doing a multiplayer game would be with everyone logged onto a host server, and only one person allowed to increment time. I actually did something like this with starfire, but that was quite different as the time ticks were for a fixed period of time, a turn based approach. I am not sure how this would work with aurora.
Brian
This works with Aurora, and I have done it with someone, using two separate clients accessing the *same* Stevefire.mdb simultaneously using two different player races. It worked acceptably, with one minor flaw that ONLY the person whose client clicks "advance time" has their sensor readings updated. That means each player needs to alternate clicking the "advance time" button and they will only get sensor updates when it's their turn to advance time.
This is due to the fact that sensor contacts are stored in the client's memory now, and NOT in the database. Other than this issue, we had multiplayer Aurora going and we were doing battle with our 10,000-ton destroyers built by each side in secret.
I won. :)
Post by: fflaguna on July 16, 2012, 09:36:05 AM
Can the database be simultaneously opened by multiple races? I mean, can it be multipated with a cloud file sync prpgram e. g. dropbox, so that we simply only need to coordinate when someone presses time forward, not take turns in opening the db?
Yes, the database can be opened simultaneously AND MODIFIED SIMULTANEOUSLY with seemingly no issues by separate player races.
However, I don't think Dropbox's sync mechanism works in the way Aurora needs it to. I don't know how Dropbox syncs files in practice.
A problem you will run into is that the Aurora.exe makes ten zillion SEPARATE calls to the database every nanosecond, which means it takes foreeeevvvvvveeeerrr to load a screen. We're talking 5-10 minutes just to open the ship design screen for a player across the internet. Our solution was for me to run a local virtual machine on my computer, that the other person connected to and took control of through a VNC. That way the opponent's Aurora.exe is still running on my computer, and all the database calls are instantaneous. His client through the VNC connection was a bit sluggish, but now we're only talking 1-3 seconds to load the ship design screen now.
Anyway, that was my romp through multiplayer Aurora.
Post by: Havear on July 16, 2012, 10:00:18 AM
Post by: jseah on July 16, 2012, 10:42:33 AM
Call it "difficulties in coordinating task forces of different races". =D
Post by: sublight on July 16, 2012, 12:09:31 PM
You need at least three people: two or more players plus one designated SM to advance time and watch for events that might require either immediate action or an early interrupt. I'm currently acting as the SM in one game with three player factions. We're posting a rough account in a game log here (http://aurora2.pentarch.org/index.php/topic,4595.0.html). For our game each faction has it's own password to help prevent accidental peaking, and the database is distributed through a shared dropbox folder. With .zip compression the database is 5-8 mb. Uploading a new database copy is fast (less than a minute) but doesn't allow people to simultaneously play off the same database at the same time.
Using relatively long time increments (3-12 game months) twice weekly has allowed us to play through 23 game years and counting so far.
A Co-Op game would be easier to run since you wouldn't need a designated SM, and as mentioned by jseah would allow better timing control.
Post by: Havear on July 23, 2012, 01:36:56 PM
Post by: Havear on July 24, 2012, 08:07:28 PM
Post by: Beersatron on July 24, 2012, 10:51:45 PM
Post by: Havear on July 25, 2012, 12:01:58 AM
Post by: fflaguna on July 25, 2012, 09:44:52 AM
I had multiplayer internet Aurora working successfully in my post above. We had two people both accessing the *same* Stevefire.mdb file at the same time from two separate clients, each designing a ship and SMing it into existence and then battling each other until one side won, with no database errors or corruption issues. See my post above for how we did it, involving setting up a VM with a VNC inside on the computer where the Aurora database file is stored. It's actually a very simple process.
Ask questions if you have any, as I'd love to help. :)
Post by: JSilvanus on July 25, 2012, 10:03:20 AM
Post by: Havear on July 25, 2012, 11:21:57 AM
Post by: sloanjh on July 25, 2012, 11:58:58 PM
I imagine the database doesn't employ locks, so if Player1 was designing some component that relies on a number of related entries at the same time as Player2 then the @@identity could be getting messed up.
It's probably even worse than that. A year or so ago I wrote a "SF Assistant Assistant" (not really what I called it) .NET app that allowed me to manipulate the SFA DB while running SFA (things like generating new officers through a GUI). I ended up with a corrupt DB even though I would only interact with the SFA or SFAA interfaces sequentially. Apparently manipulating an SFA DB that an instance of SFA is running on can corrupt the DB, even if nothing is happening in the SFA instance.
IIRC compacting the DB solved the corruption, but it kinda ruins the flow of the game :)
John
PS - It took a while for the corruption to happen - it wasn't a high probability event.
Post by: fflaguna on July 26, 2012, 12:33:07 AM
It was two VMs with clients open on my computer, while I had my client open natively. All three were using the same DB, albeit through shared folders through the VirtualBox VMs.
Weird, that sounds exactly like what we were doing. One client open natively, and one client open on the VM running on the same computer. We were two different races (in the same system), so none of the database read/writes overrode one another. The only issue we had was that sensor contacts would only update on the client who clicked the "progress time" button, since that was a function that only runs in the game client's RAM and is never saved as a database entry.
I don't know why it's not working for you. We were able to create ships and spawn them and fight to the death with no game corruption. :(
The method we were using was some sort of Windows home group file sharing thing using a network-mapped folder. Even though it's a rather simple thing to implement in theory, it was really awkward and it was difficult to set up in the first place.