forum.webdiplomacy.net

webDip dev coordination forum / public access todo list
It is currently Tue Oct 17, 2017 4:10 am

All times are UTC




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Jun 28, 2008 7:11 am 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
The gamemaster should run right away when the last person in a game has finalized. At the moment there's a ~1-5 minute wait after everyone has finalized


Top
 Profile  
 
PostPosted: Wed Jul 02, 2008 9:28 pm 
Offline

Joined: Sat Jun 28, 2008 4:59 pm
Posts: 17
On some other servers there is a customizable wait period for the server after receiving final orders from all players, which defaults to 30 minutes. This is an appropriate interval for email as a medium. The user perceptions aren't colored as much by the wait as by the expectation of immediacy in a web-based game. It may be a good idea to retain the delay, but notify users of its purpose.

Chris


Top
 Profile  
 
PostPosted: Thu Jul 03, 2008 2:02 pm 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
Is there a purpose? :S The 5 minute delay here is just because the cron script runs the gamemaster script every 5 minutes, I think ideally it would run the second the time has expired, or the moment the last player has finalized.

It's not a big deal for 24 hour game periods, but others change phpDip to have customizable process times, which 5 minutes extra would be a bigger wait time.


Top
 Profile  
 
PostPosted: Thu Jul 03, 2008 7:14 pm 
Offline

Joined: Sat Jun 28, 2008 4:59 pm
Posts: 17
The purpose of the delay in email servers is to give the last person to enter orders a guaranteed period of time to change 'final' orders. This provides a comfort level with finalizing orders and, according to theory, makes games flow faster.

It looks like the phpDip engine polls each process every 5 minutes to see if any should be run. The good things about this are that it's simple, it works and it doesn't require permissions on the shell that might not be available.

The mechanism that controls this for nJudge is a flat file database that includes the timing and other control information for the games. When there is an event, whether triggered by orders received or by the timer (in this case, the at daemon), the program checks a master record first to see if it woke up on time. If it didn't, it runs a "bailout plan". Otherwise it runs the job it was woken up to perform, parses the database to find out the next time it should wake up (taking care of any other jobs that are due), puts the wake up time in the master record and creates a new at process to wake up at that time.

I know that paid hosting accounts probably won't have access to the at daemon, but there appears to be a cron equivalent in PHP. Is there an at equivalent too?


Top
 Profile  
 
PostPosted: Thu Jul 03, 2008 8:30 pm 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
Nope Dreamhost gives access to a shell so it does actually use cron. Before I came to dreamhost I had cron set up at home, so the gamemaster.php script was run every 5 minutes by requesting the page from home. This has obvious disadvantages of course.

Differences like the 5-minute/30-minute wait do make me wonder how compatible e-mail and web play are though (I'm not sure if your e-mail interface idea is just about providing an interface or if there should actually be a true e-mail interface to phpDip games)


Top
 Profile  
 
PostPosted: Thu Jul 03, 2008 10:05 pm 
Offline

Joined: Sat Jun 28, 2008 4:59 pm
Posts: 17
The at daemon runs once at time X as opposed to running whenever condition X is met, so it's a little different to implement than cron. For one thing, you need to schedule the next instance to run before the process closes. I agree that running a PHP script by loading the page is kludgey. It's not worth an engine rewrite to implement something like that. That's why I was wondering if PHP offered that kind of a function directly or whether it would need to be fudged with the cron-like utility.

Ten minutes is a perfectly reasonable delay for email games given today's Internet backbone and direct routing. The 30 minute delay is a legacy from slow 486s and bizarre email routes that might take 10 minutes or more to reach its destination. With the current infrastructure, judges with direct connections turn around an email query in under 20 seconds. It's not as fast as a page load, but it's fast enough to have email players and web players operating in the same time frame for games as fast as 24 hour deadlines. I don't expect people to use an email interface often for games with 12 hour deadlines, but the same parser is the base for some of the more esoteric interfaces in the back of my mind.

My email interface idea comes in stages. First is output - results, game listings and summaries to make the engine work with some of the tools players already know and one or two underdevelopment. Then would come the order entry commands. Full command compatibility is an eventual goal, but it is not in my agenda to have the web engine duplicate all the faults of the email interface, though hopefully the feature set can be expanded to be a superset of both with a reasonable set of defaults to prevent it from being needlessly complicated - or recognize and report that feature X is not available without undesirable or unexpected behaviors.

An example is the default game timing on a judge game:

Move clock 1410 min 12.00 next 71.00 grace 167.00 delay 0.50 days -MTWTF-
Retreat clock -1 min 0.00 next 23.00 grace 71.00 delay 0.50 days -MTWTF-
Adjust clock -1 min 0.00 next 23.00 grace 71.00 delay 0.50 days -MTWTF-

Clock is the time that deadlines are set in minutes after midnight - 1410 is 11:30 PM and -1 means that this setting has no effect on scheduling. Min is an obsolete parameter that's supposed to prevent a run away game with certain settings. Next is the time to deadline. The most popular timings are 3-days with press or 1 day without. Grace is the time after the deadline before you are considered abandoned and a replacement is allowed. Delay is the setting (in hours) that we were discussing. Days is the days of the week where deadlines are permitted. A lower case letter would mean that all deadlines would be in the afternoon. Some judges are modified with a default setting is -mTWTF- so that deadlines with a clock of -1 won't get set for 00:00 Monday morning.

If delay was customizable (assuming that deadlines were customizable too), I would default to 5 minutes and interpret delay as hours if it contained a decimal point, but in minutes if it was an integer.

Chris


Top
 Profile  
 
PostPosted: Fri Jul 04, 2008 12:02 am 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
Ah I see, I quite like that time management system but on the web where people aren't necessarily as familiar with the board game or as willing to put time into learning there's a thinner line between ease of use and richness of features. Depending on your audience that's a tricky line to navigate I've found

But yeah I think it'd be compatible at least

Code:
Move clock - min 0.00 next 24.00 grace 48.00 delay 0-5 mins SMTWTFS
Retreat clock  - min 0.00 next 24.00 grace 48.00 delay 0-5 mins SMTWTFS
Adjust clock  - min 0.00 next 24.00 grace 48.00 delay 0-5 mins SMTWTFS


Top
 Profile  
 
PostPosted: Fri Jul 04, 2008 5:30 pm 
Offline

Joined: Sat Jun 28, 2008 4:59 pm
Posts: 17
There's an on-line adjudicator that offers 7-day, 3-day, 2-day, 24-hour and 12-hour deadlines. The interface is terrible, but despite the implementation they don't seem to suffer from making the offerings available.

As a preliminary to working on an implementation for the phpDip trunk, I'm going to run some press games on the judge with settings:
Code:
Move clock -1 min 0.00 next 24.00 grace 48.00 delay 0.08 days SMTWTFS
Retreat  clock -1 min 0.00 next 24.00 grace 48.00 delay 0.08 days SMTWTFS
Adjust clock -1 min 0.00 next 24.00 grace 48.00 delay 0.08 days SMTWTFS


(Days is the parameter set "SMTWTFS", not the unit of time for the delay.)

Email games usually slow a bit over the summer, so if that format takes off before September then it's a clear hit. That will tell me whether the email interface or enhancing deadline options should be a priority for my end.

Chris


Top
 Profile  
 
PostPosted: Mon Jul 07, 2008 1:30 pm 
Offline

Joined: Tue Jul 01, 2008 2:42 pm
Posts: 11
Location: chicago
kestasjk wrote:
Code:
Move clock - min 0.00 next 24.00 grace 48.00 delay 0-5 mins SMTWTFS
Retreat clock  - min 0.00 next 24.00 grace 48.00 delay 0-5 mins SMTWTFS
Adjust clock  - min 0.00 next 24.00 grace 48.00 delay 0-5 mins SMTWTFS


Actually, I think it's not quite compatible, as phpDip doesn't hold the game while waiting for the grace period to expire.

It'd be more something like:
Code:
Move clock - min 0.00 next 24.00 grace 0.00 delay 0-5 mins SMTWTFS
Retreat clock - min 0.00 next 24.00 grace 0.00 delay 0-5 mins SMTWTFS
Adjust clock - min 0.00 next 24.00 grace 0.00 delay 0-5 mins SMTWTFS


with the caveat that ejections aren't actually processed unless a player doesn't submit orders for two consequtive turns they are eligible for giving orders. In the PBEM world they halt the game when no orders are given and when a player is in CD. This may not be universal, but it was present in all the games I saw/took part in.


Top
 Profile  
 
PostPosted: Tue Jul 08, 2008 5:06 am 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
Yeah, I dont think a grace period would work in a web setting :(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group