Announcement: Be excellent to each other.


Caravel Forum : Caravel Boards : Development : Multiuser DROD
New Topic New Poll Post Reply
Poster Message
trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged
icon Multiuser DROD (0)  
I'm fiddling around with DROD/Main.cpp at the moment, and came to thinking of what to do in a multi-user environment like linux. There's two options: Keep it like it is, putting the DROD data files and config in a public writable directory, or let each user keep his/her own set of data files and config in their home directories.

There's ups and downs to both. DROD handles multiple users in-game, right ? (i haven't looked at that too closely yet, and the beta doesn't run in Wine..). So, putting the writable data and such in a shared dir seems the best thing to do, although that is less secure (it would have to be world-writable for all users to have access, so one user could potentially screw up for everyone). The other option requires some extra coding, but then each user would have his/her own copy of the config, own holds etc. This would also enable multiple users to play DROD on the same computer at once (i'm guessing that's why the 'disallow multiple instances' rule is in, right ?), though that would probably only be possible when playing remotely.

I'm leaning towards the first option myself, but wanted to know what you think.

One other thing, what should i call the writable dir (shared or otherwise) ? caravel-drod, cdrod, just drod, or maybe caravel/drod ? (i don't want the writable files together with the read-only ones, that's bad style :P)

06-27-2003 at 04:33 PM
View Profile Send Private Message to User Send Email to User Show all user's posts Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Multiuser DROD (0)  
Hmm...you had the original Caravel version running in Wine before, right? I'm curious: why doesn't the beta run in Wine?

(Isn't the code almost completely ported to Linux? I'm thinking getting that to work at this point would require no more coding than what you're proposing.)

If we can get DROD:AE working under Wine or Linux, would there be any advantages to getting the original one working the way you suggest?

[Edited by mrimer on 06-27-2003 at 04:46 PM]

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
06-27-2003 at 04:44 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
ErikH2000
Level: Legendary Smitemaster
Avatar
Rank Points: 2794
Registered: 02-04-2003
IP: Logged
icon Re: Multiuser DROD (0)  
trick wrote:
I'm fiddling around with DROD/Main.cpp at the moment, and came to thinking of what to do in a multi-user environment like linux. There's two options: Keep it like it is, putting the DROD data files and config in a public writable directory, or let each user keep his/her own set of data files and config in their home directories.
Gerry!

We can handle multiple users, but not simultaneous users. Everybody's data is in the same three data files. I absolutely wouldn't recommend sharing these data files for simultaneous use. It's only a matter of time before they get corrupted. The database API has a single-writer limitation(a tradeoff for performance, according to the author). We've already had bug reports from people that accidentally ran two instances of DROD. So in theory and in practice, it causes data corruption.

What's wrong with requiring one complete installation with no shared files on each computer of a DROD user? This allows non-simultaneous use for however many users log in locally to a computer. We've got new features that allow the data to be manually moved between installations. What's missing?

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)
06-27-2003 at 05:10 PM
View Profile Send Email to User Show all user's posts This architect's holds Quote Reply
trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged
icon Re: Re: Multiuser DROD (0)  
I was talking about the native linux client, sorry if that was unclear. The only reason i mentioned Wine was to say i haven't played the beta yet, so i don't really know from first-hand experience what it's like.

The reason it doesn't work in wine is mostly because of bugs in wine itself. I can still get 1.5 to start, but once i press a key it auto-repeats with no way to stop it except dying. The beta simply doesn't find its data and die (i'm guessing wine doesn't like unicode filenames).

Anyway, the native linux version is right around the corner, so there's no use hunting down problems with Wine now.

I just need to know what to do about that multi-user thing. It's no rush, tho. I can just make it use a shared dir for now and change it later if that proves to be the best solution.

06-27-2003 at 05:21 PM
View Profile Send Private Message to User Send Email to User Show all user's posts Quote Reply
trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged
icon Re: Multiuser DROD (0)  
Erik, you posted while i was writing (and eating) :)

There's no problem making sure no more than one instance of DROD is running at a time. Again, there's two options: A lock-file, or reading the process list and figure out if one of them is DROD. The simplest is using a lock-file, but stupid users asking for trouble could delete that and run another instance of DROD while one already is running - i don't think that's likely to happen, but still. Reading the process list takes more code (still simple, tho), but would prevent that if the name of the executable is the same. Some other user could possibly rename it. This again could be solved by comparing the name of the current process with the ones in the process list, but that still wouldn't catch if someone tried running two differently-named executables. The lock-file i mentioned before wouldn't have that problem.

All in all, all of the above problems are highly unlikely and would only be caused by users asking for trouble, so any one of the solutions should do, or maybe even both, though that would be overkill.. but hey, why not :)

The simultaneous-users-scenario i talked about was if all users had their own copy of the three dat files, but there's not really any reason why they should since DROD handles multiple users itself.

- Gerry

06-27-2003 at 05:37 PM
View Profile Send Private Message to User Send Email to User Show all user's posts Quote Reply
ErikH2000
Level: Legendary Smitemaster
Avatar
Rank Points: 2794
Registered: 02-04-2003
IP: Logged
icon Re: Re: Multiuser DROD (0)  
trick posted:
Erik, you posted while i was writing (and eating) :)
You shouldn't write and eat simultaneously. It will cause problems when food gets into the keyboard.

I don't want anything to happen simultaneously. It's too dangerous!
There's no problem making sure no more than one instance of DROD is running at a time. Again, there's two options: A lock-file, or reading the process list and figure out if one of them is DROD. The simplest is using a lock-file, but stupid users asking for trouble could delete that and run another instance of DROD while one already is running - i don't think that's likely to happen, but still. Reading the process list takes more code (still simple, tho), but would prevent that *if* the name of the executable is the same. Some other user could possibly rename it. This again could be solved by comparing the name of the current process with the ones in the process list, but that still wouldn't catch if someone tried running two differently-named executables. The lock-file i mentioned before wouldn't have that problem.
I'm not worried about people trying to run two instances of DROD on the same computer except by accident. I agree it's unlikely.

The lock file idea is problematic because it is still possible for DROD to crash and not delete the lock file when it exits. (This used to happen to me all the time with Access and Paradox.) I'm sure you can figure a way to handle it, though.
All in all, all of the above problems are highly unlikely and would only be caused by users asking for trouble, so any one of the solutions should do, or maybe even both, though that would be overkill.. but hey, why not :)

The simultaneous-users-scenario i talked about was if all users had their own copy of the three dat files, but there's not really any reason why they should since DROD handles multiple users itself.
I thought maybe you were talking about networked use, i.e. sharing one copy of the dat files for users on different computers to access simultaneously. If you only have one DROD process accessing one set of dat files at any given time, there's nothing to worry about.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)
06-27-2003 at 07:06 PM
View Profile Send Email to User Show all user's posts This architect's holds Quote Reply
trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged
icon Re: Re: Re: Multiuser DROD (0)  
ErikH2000 wrote:
You shouldn't write and eat simultaneously. It will cause problems when food gets into the keyboard.
Oh, the keyboard's fine. I dropped some pasta sauce on my t-shirt, though, when saving it from dripping on the keyboard.

I don't want anything to happen simultaneously. It's too dangerous!
Hm, i wonder how DROD would be if the monsters didn't move simultaneously.. It's a dangerous game :glasses

The lock file idea is problematic because it is still possible for DROD to crash and not delete the lock file when it exits. (This used to happen to me all the time with Access and Paradox.) I'm sure you can figure a way to handle it, though.
I thought about that. Simply saving the name and process id of DROD in the lock-file should fix it. Then when DROD starts, check if that process id exists (with the right name, in case another process got the same id later). If it doesn't, it means DROD crashed, so it's safe to ignore the lock-file.

Hum, i just thought about another potential problem with the lock-file. If the user manages to launch two instances of DROD simultaneously, things could get dangerous, as you say. If one instance checked for the lockfile before the other could create it, both would go on. Hm.. Disk i/o never happen simultaneously (on the same disk), so checking when creating the lock should fix it. I have to experiment a bit with that.

- Gerry

06-27-2003 at 10:23 PM
View Profile Send Private Message to User Send Email to User Show all user's posts Quote Reply
mrimer
Level: Legendary Smitemaster
Avatar
Rank Points: 5056
Registered: 02-04-2003
IP: Logged
icon Re: Re: Re: Re: Multiuser DROD (0)  
trick wrote:
Hm, i wonder how DROD would be if the monsters didn't move simultaneously.. It's a dangerous game :glasses
Actually, they don't. From time to time you'll notice they move in sequence. That is, one tries to move first and bumps into the one in front of it, then the one in front moves forward. We decided to leave it that way.

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.
06-27-2003 at 10:45 PM
View Profile Send Private Message to User Send Email to User Show all user's posts High Scores This architect's holds Quote Reply
The_Lucky_Mutt
Level: Delver
Rank Points: 35
Registered: 05-27-2003
IP: Logged
icon Re: Re: Re: Re: Re: Multiuser DROD (0)  
mrimer wrote:
Actually, they don't. From time to time you'll notice they move in sequence. That is, one tries to move first and bumps into the one in front of it, then the one in front moves forward. We decided to leave it that way.

Why did you decide that? I've notice some really odd tendancies that can't be explained because of that. For example, if you have a horazontal line of mimics each right next to each other, when you move left they all move togather and when you move right they break off one by one (or vise-versa)... in fact I think there was one room that required this uneven moving (or was I just doing it oddly)... anyway, what was your reasoning behind leaving it that way? To hard to make them move together? not up to the challenge?

-TLM
08-12-2003 at 12:16 PM
View Profile Send Private Message to User Visit Homepage Show all user's posts Quote Reply
The_Lucky_Mutt
Level: Delver
Rank Points: 35
Registered: 05-27-2003
IP: Logged
icon Re: Multiuser DROD (0)  
Ok, Ok, so it is hasty of me to ask if you arn't up to such a big challenge without trying to tackle it myself, so here is my solution that makes it so that there are no tob to bottom or left to right prejudices.

(By the way, I understand that it is things like this that have to do with the basic movement or DROD that are close to imposible to implement because they would chage how every room works... but I offer the solution anyway.)

The Relitivity Solution:

1) Have every creature choose the spot where, if there were no other creatures, it would go.

2) Settle all the creatures whose intended position is both currently enpty and is not claimed as an intended position for any other

2a) Repeat step 2 with the information about which have moved for sure until repetition yeilds no change

3) Go through all of the cases where more than one bug claimed the same square and give the square to the winner based on the folowing fules

3a) The bug farther away from Bethro wins
3b) If tie (as in the case of two roaches a knight move away) Give the square to the bug that is closer to the closest border of the room that they are not equal disstance from (Just so that it isn't based on which is is closer to the upper left corner) If your playing some tripped out version of DROD that has rooms with an odd number of rows or columns, so there is still a tie, crash the program with a cryptic error message like 'relativity could not be upheld'.

4) For all the creatures that didn't get their desired spot, see if a secounady spot applies (as a roach moving diagnol will settle for horizontal). Have all the creatures that this applies to chose their desired secoundary spot. Settle all the creatures who a secoundary choice doesn't apply.

4a) When a diagonal primary is denied, the creature should choose the direction (horazontal/vertical) that the creature is farther from Bethro, is counting only that direction. In the case of a tie (ie, a bishops move away) then the creature should chose the direction that will further him from the closest edge of the room. If still a tie, move the creature in the direction that will put it closest to the border that Bethro is farthest from not counting the two checked earlier. If your playing some tripped out version of DROD that has square rooms, so there is still a tie, crash the program with a cryptic error message like 'relativity could not be upheld'.

5) Repeat Steps 2 & 3 with the creatures secoundary choice.

6) Have the still unmoved, unsettled creatures chose a trinary choice, or settle. Then repeat steps 2 & 3

*) When dealing with queens, simply reverse all of the arguments (ei, 'closer to' becomes 'farther from').

*) You might want some creature hiarchy, ie, snakes always beat roaches, but that is trivial.

I think that just about covers it... I think that I upheld some of the fundemental easily noticed roach tendancies when they move en masse, but I'm not sure how much I changed... I think large roach parties would be harder to string into lines, then again, the farther does move first, so maybe not.

-TLM

[Edited by The_Lucky_Mutt on 08-12-2003 at 01:21 PM GMT: reworking the theory]
08-12-2003 at 01:10 PM
View Profile Send Private Message to User Visit Homepage Show all user's posts Quote Reply
New Topic New Poll Post Reply
Caravel Forum : Caravel Boards : Development : Multiuser DROD
Surf To:


Forum Rules:
Can I post a new topic? No
Can I reply? No
Can I read? Yes
HTML Enabled? No
UBBC Enabled? Yes
Words Filter Enable? No

Contact Us | CaravelGames.com

Powered by: tForum tForumHacks Edition b0.98.8
Originally created by Toan Huynh (Copyright © 2000)
Enhanced by the tForumHacks team and the Caravel team.