Server Side Tennis

[HarryF]

Server Side Tennis Rules

What is it?
Server Side tennis is the game that's sweeping the globe! It's played either one on one between two coders, two vs. two in a doubles match or free for all in a "Sudden Death Match". The idea of the game is "serve" with a single script (in whatever language: ASP, PHP, JSP, Perl etc.) then "volley" with a revision of the "served" code, with some modifications. Server Side Tennis has it's roots in the ancient sport of Photoshop Tennis (remember - the graphic designers thought of it first!)

The first PHP trial match is here and the first in ASP ishere.

The Objective
The objective is to force the other player to either "fault" (post code with a fatal error in it), "out-of-bounds" violates the restrictions on the code - see below), or "time out" (the player misses the agreed deadline for volleying).

Lines
Refers to a line of code, terminated by a carriage return.

Comments
A comment do not count as a line - you should use them to explain your changes (to help in your defence in the case of "Calling for an Umpires Decision" - see below), but you should delete previous comments when you post a new volley.

Revisions
A revision is a posted change to the previous piece of code posted before it. Also referred to as a volley.

Bugs versus Errors
A bug is a design problem in the code - the code still executes but perhaps doesn't do what it was designed to do.
An error is a message from the languages interpreter (e.g. "Syntax error on line 14"). In Server Side Tennis code with bugs in it is acceptable. Code with errors in it may cause you to lose the match.

The Umpire
The Umpire is Exam Diff (a simple free Windows app for checking changes between two text files) found here: http://www.prestosoft.com/examdiff/examdiff.htm
Once ExamDif Diff is installed, save a copy of the last volley fired at you from your opponent (File 1). Then save your latest version that you're about to post with a different filename (File 2) and use ExamDiff to compare (default settings should be fine).
Count the number of lines marked in your new volley on the right - this is the number of diffs - see the Diff Rule below.

The Rules
These are the general rules for all server side languages. Special rules apply to each language - see below. If anything you post breaks one of the rules below, you lose the match.

The No Editing Rule
Once you post your "volley" in the forums, you may not edit it. Doing so loses you the match. Your first post is the only valid post.

The VI Rule
Each line can be no more that 80 characters in width. Make sure you use a text editor that shows you character columns.

The Terminator Rule
You may only execute one "statement" per line (a statement can be multiple functions though). Put another way, you can only use one "end of statement" character per line.
For example PHP that's a semi-colon

echo ( "Some Text" ); // End of statement 

The Diff Rule
You may only make a certain number of changes to the previous revision fired at you by your opponent, when you reply with your volley. Using the Umpire (ExamDiff above), the limit to the number of lines you may change is calculated with this formula;

Number of diffs <= (Total lines of code in original serve) * 0.3

So if the original code in the serve had 20 lines of code, you can have a total of up to 6 diffs in each volley. Fractions are rounded up. Going over the Diff limit means you lose.

The Red Line Rule
The total number of lines in any volley must not exceed or fall below specified upper and lower limits. The limits are calculated like this;

Margin = ( Total number of lines in serve ) * 0.25.
Upper limit = ( Total number of lines in serve ) + Margin
Lower limit = ( Total number of lines in serve ) - Margin

So for for a serve of 20 lines, the upper limit is 25 lines and the lower limit is 15 lines. This is the "Red Line Limit". Go above or below it and you're out!

The Time Out Rule
You must volley the last revision within 24 hours (or the agreed time limit). Failing to do so means you lose.

The Fatal Error Rule
If you post code with an error in it that prevents the code from executing or causes it to either run to infinity, time out or crashes the web server it's run on, you lose. Fatal errors are defined in more detail for each language, depending on error levels.

The External Source Rule
You may not "link" to other (imaginary) code (e.g. include ( "function_library.php" ) ), access code from a "database" or any other external source. The script must be self contained. You may "pretend" that you are accessing external sources for normal data (e.g. a database).

The Optimise by 1 Rule
Every volley you make must optimise the previous revision in some way. This is assessed in the following way;
- Makes the code more efficient (less lines of code, less functions)
- Fixes a bug
- Makes the code portable / reusable (e.g. declaring a function or a class)
Note that the sum total of your volley must optimise by at least "one". For example if you fix one bug but introduce another, your optimisation is nullified.
Failing to Optimise by 1 means you lose.

The Add Functionality Rule
Every volley you make must add some additional functionality to the previous revision. Assessed like this;
- Does the code accept addition input or provide additional output?
The additional functionality does not necessarily have to be useful. Examples might be to provide more error feedback or to give the "end user" an additional choice in how they use the code.
Failing to Add Functionality means you lose.

Calling for an Umpires Decision
For the "Optimise by 1" and the "Add Functionality" rules, any disagreements will be settled by peer review. You may "Call for a Umpires Decision" if you feel the previous revision violated either of these rules. You then need to get three posts in the thread stating "Yay" or "Nay" as to whether the rule was broken. The time it takes to do this comes out of your Time Out limit.

Serving
You serve by posting the first revision of the code. Ideally that code should have been written by someone else and be available for everyone on the Internet (e.g. Hotscripts). The code should be fairly short (e.g. under 50 lines), otherwise you'll be playing forever. Suggested sources for scripts are provided below for each language. Also, don't post proprietary code!

In additional to posting the code, you must state the following;
- What the "Diff limit" is (see the diff rule above); you might want to adjust this for short or longer matches.
- What the "Red Line Limit" is (upper and lower limits on number of lines in script - see above). Adjust for longer / shorter matches.
- What the "Time Out Limit" is.
- What version of the language you are using and any special options (e.g. PHP 4.2.1 with register globals off and magic quotes off).
- Any special rules (e.g. PHP with access to the Pear Library or ASP with such and COM object).

Matches
One on one - two coders battle each other to the death.
Doubles - find a partner and take on another pair - taking turns with your partner to post - don't write the code for them - if they don't turn up within the Time Limit - gameover.
Sudden Death Match - free for all! Last person to post a valid volley wins - the moment someone blows it (like they didn't test their code!) - the game is over. In sudden death, you must state which persons code you're working from - if someone gets there first - sorry - your's is old news (things moves fast on the net)

End of Match
If any of the above rules are broken or one player declares, the match is over and the winner is the last person to make a successful volley.

Bad Form
It's bad form to;
- post code in a match you're not playing in (unless it's a free for all match)
- get someone else to write the code for you, behind the scenes
- in doubles matches, having one partner write all the code (conferring is discouraged).

PHP Specifics
- No includes, requires or evals (on external data).
- A PHP fatal error breaks the "Fatal Error Rule".
- Recommend source of code is the Zend Code Gallery: http://www.zend.com/codex.php

[randem]

For what it's worth...

I've been using ExamDiff, and I like it a lot better than CS Diff.

ExamDiff allows you to drag-n-drop the two files you want into the app window, and it shows both files side by side with better display of the differences.

[HarryF]

Sounds good. Just checking it out now - will update the post above.

Quoting Samsm from the PHP trial game;

Good rules for a one-on-one match! However, I like the way it was initially evolving better... people jumping in left and right. I bet this would lead to faster gameplay and better code... especially if people are making an optimization each move.

While one-on-one matches are good I think it would be neat to promote multi-person matches as well. My reasoning: I have little interest in following along in others gameplay, getting a good idea then sitting on it... I want to hop in! From the looks of this match, other people would like the option to jump in too! Plus, with one- on-one there is an increased chance of stalemate or one player getting too busy to return.

As long as folks follow the rules regarding the amount of code to modify I don't see multi-player action becoming a problem. If you don't like the way someone implemented a feature then optimize it and make part of your move!

Just some thoughts!

Reckon that works - a Free for All Deathmatch - last person to post a valid volley wins - first person to blow ends the game. Update to the rules coming.

[HarryF]

OK - ExamDiff is looking good - it's a better tool. The only thing is I can see it confusing people. Basically we'd need to play it that the number of "diffs" in your new release must be less than some number.

So - the vote: CS Diff or Exam Diff as Umpire?

[sbdi]

Sorry to say but CFM will always win, I consider myself a weak / alright CF coder but i know I can do just about anything from CMS system's to shopping cart software

[samsm]

Originally posted by HarryF
first person to blow ends the game.

If it is done like this, one slip (possibly from someone who wasn't involved in much to that point) could blow what might have been an involved game. I think in a death match scenario the game should end once the public at large is tired of the thread (probably because the code has strayed into uselessness or is so mind-blowingly helpful that it cannot possibly be expanded).

[randem]

Okay, now for a slight change of pace, what say we try Server Script Hockey? :-)

This one's open to everyone.

[HarryF]

Like it. More mellow than this intense set of rules. Will keep rolling with this for interest if people want to use it - just update the rules to use EditDiff.

[dhtmlgod]

Hmmm... Harry, I think the hockey rules are going to be more fun...

[HarryF]

Could be right - may be overkill. I was pysched up yesterday It doesn't necessarily encourage good coding (while I think Hockey does) - you might use deliberately bad coding to force the other player(s) out of bounds. Was aiming for something where someone always wins - where there's clear end to the match.

Anyway, we got sudden death match at the moment so I guess we'll see how it goes.

[someonewhois]

We started a new topic on it in the PHP forum..



1 thing, about the rules:


You say no more than one semi collen per line, which is not true.

You can still have more than one semi collen in a FOR() statment. So you should add the exception of a for() loop is allowed more than one semi collen, however it is he only thing allowed on it's line, so there is no echo's on it etc.

Just wanted to get this updated.

Thanks,
~someonewhois