3.0 and 4.0 were won by AdamBliss
5.0 is live at: http://perlnomic.org/
Perlnomic 3.0 is live: http://perlnomic.idohost.com
. Come join the fun.
Perlnomic 2.1 was eaten by Spaceports. The codebase is still in AdamBliss
's posession, and he'd love to set it up and play again someday if anyone is interested.
1.1 ended at 20:49, 2001.12.30. The winner was AdamBliss
2.1 is now live at
. You need to disable your HTTP-Referer field to get there (or else copy-and-paste the URL into your browser's address bar, rather than clicking through).
is an experimental perl-based Nomic-like-game. You
can play by visiting http://www3.hmc.edu/~abliss/nomic/
This is intended to be a passive message board for the game.
Well, my remove01 proposal was not the version I thought it was, so it broke the remove.cgi script. I'll post a fix tomorrow. --AdamBliss
- Fix posted; sorry for the trouble. Incidentally, I already have a script running to check my voting page for changes and email me; if you are interested in receiving an email every time something happens, let me know and I'll add you to the notification list. --AdamBliss
The winning condition is passed. Let the games begin. --AdamBliss
Well, I am relieved that my activity patch didn't break activate.
I mean, I had tested it, but I was still a little nervous.
Um, it seems to me that things just suddenly came to a halt.
- yep, it's dead. we need to get some sort of game (points, etc.) going to encourage stuff to happen. Plus get the comment system running (Wiki sucks for this sort of thing .. the only way to keep track of when stuff is added is to read the diffs) perhaps with the option to have comments sent to you via email (so you don't have to remember to go check a web site every day) --TimBuchheim
I noticed that I could rescind my remaining active proposal without reactivating myself, so I did. That should finish cleaning up the mess I left behind. --RobAdams
Random observation -- propose.pl lacks something in its newlines,
so that unlike the other .pl files, it's difficult to read above
and beyond the fact that my Perl is rusty. --AndrewSchoonmaker
- The newlines are fine for me. Try asking your browser to view source. --AdamBliss
As much as I'd love to have Cora and/or Roy in the game, I don't feel it's appropriate to
add them without their consent. I sent them an email when adduser was fixed; if they still
want to play then let them come and repropose. --AdamBliss
- I'll hold off accepting the proposal for now, even if it gets sufficient votes. If you have contacted them, we could just let themselves add again. Alternatively, we could resurrect their "adduser" proposals for them, but still require them to do the final proposal activation. --MichaelVrable
I've added a PerlNomicPatches guide. It tells you how to use diff to create patches and how to use Perl and patch to apply them. --TimBuchheim
Commentary by a random non-player: some of the proposals (as discussed on this message board) are things that seemed to emerge very quickly in FunNomic?
, as well (rules to deal with inactive players, restructuring the initial rules to make them work better, streamlining the voting and proposal processes). I think it has something to do with the web-based format, which makes the game rather different than a game in-person, so that, e.g., the rules in GEB: EGB don't work very well. It might be an interesting exercise to try to write a set of starting rules to begin with, after one of these games is over, to provide a starting basis for future games. I like the idea of using a computer language to run the rule system because it means that, in theory at least, there is an unambiguous interpretation of all the rules: whatever the perl script does when you run it. I guess that might take some of the fun out of the game for people like AndrewSchoonmaker
, who said that he liked games where arguing over the
wording of the rules was expected, but it seems to me that if players take it to extremes, rules-lawyering will quickly reach the point where you are trying to define 'is' and nothing can happen because there is no consensual definition of the rules. The computer language bit eliminates that problem.--CurtisVinson
On the contrary, having clearly-defined rules is the sort of thing that I like -- the reason to argue over wording is so that loopholes cannot be exploited later by other people. With exactly-defined rules, one can go about the business of adding one's own loopholes by subtly constructing proposals (though I've never played in a game that reached this stage, and nor do I think it is how everyone plays the game...) I just don't particularly like the "we all mostly agree about what this rule says, so don't argue about the fact that the rule makes lots of assumptions" style of game... --AndrewSchoonmaker
- Then get your butt in the game, SchoonMaXor?! --AdamBliss
It has been so proposed. No promises as to activity, though. :-) Now that I recall more of some of the previous Nomics that I've played in, I can maybe clarify my position on the above a little bit -- I don't remember whether it's in the Suber set or not, but I recall a rule stating that "anything not explicitly allowed by the rules is forbidden", which to my mind seems necessary in the standard game. Others hold the view that the rule should be "anything not explicitly forbidden by the rules is allowable" (I just tend to think of it as the default state...) and the rest of the rules should cover the slack so that people can't just declare themselves to have won. PerlNomic doesn't seem to require the one or the other, although you are still operating under the presumption that Adam will not just modify the directory/gamestate at his whim. --AndrewSchoonmaker (considered proposing as user "andrews_butt" but decided against it for reasons of ephemerality)
- Yes, you're all trusting me not to "play god" except when absolutely necessary (I had to fix a small bug when the game died as the second user joined). The alternatives to this are pretty silly. For example, we could buy some webhosting, upload the script, then randomize the password so that nobody knows it. Or we could put it on a webserver whose root password we don't know, and encase the box with concrete. Incidentally, is there a reason you didn't put a valid email address in? I strongly desire to keep close tabs on the new users and only allow trusted players to join, since after all these proposals are being run with my userid. --AdamBliss
- Yeah, sleep dep. Sorry about that. It's your choice whether to just vote the current version down and I'll resubmit, or I'll propose something to fix it once I'm in. (BTW, I'm not saying that I don't trust you to exercise the appropriate amount of restraint when playing god; just mentioning it.) --AndrewSchoonmaker
At some point, probably after Tim's proposal passes, we should create, as Adam put it, a dead man's switch. If nothing happens for X amount of time, the system will assume that we fubared something and thus can't get anything to work. It would then return the system to a known good previous state. It could preserve the changes, so if for some reason we all just forgot about PerlNomic for a while, we could reimplement the stuff we wanted.
There are many interesting details in such a proposal. I would suggest that the timer be reset any time someone votes. If things break, we'll probably stop voting. I would suggest setting the limit at 10 days. I know its kinda long for a recovery, but we can still write code in the mean time, and we should probably plan never to have to fall back on it. If someone starts drafting it, let us know here so that we don't
double draft. --CubeSchnaider
- Here's another potential idea for recovery. Every time a proposal is passed, the current nomic tree is copied, entire, into a subdirectory (last iteration's subdirectory excepted, of course). Then if the action of the proposal screws up the nomic, we can simply shift to the sub-nomic, and use it to fix the super-nomic. If somehow we botch the recovery so badly that the sub-nomic stops working, remeber that we will in doing so create a sub-sub-nomic, etc... --AdamBliss
Since I created a proposal to remove myself from players.txt, but for some reason you people have decided not to vote for it, I hereby wash my hands of the issue. You guys can just get rid of me yourselves. So there. But I will note that, in my infinite generosity, I have provided for you all a way of proposing a patch to any and all game files. This script has actually been tested on a real computer on real files. You can verify for yourselves that the patch listed there will result from a diff of players.txt with a version of players.txt with the line for my player removed. Enjoy your game. I'll be busy not having my life sucked away, thank you.
First, please vote me (RoyShea) in as an active user / player!
I would rather work on getting this game working from the
inside, as opposed to putting comments up on wiki. I would guess
that Cora feel the same.
Onto the technical stuff. I am not completely sure what the
ideal is behind the voting structure. However, it seems a
little off to me. Looking at the activate script, a proposal
can only be activated if it has yes votes from half of the
players. The script to remove a vote requires that at least
three quarters of the players vote no for that proposal. This
system leaves a large area where a vote can neither pass or be
removed from play. Are you trying to encorage users to change
votes over time? Can players even change votes?
What is more, I can not find any references to the use of abstains in calculating votes. Why have abstain in the options
if an abstain is calculated exactly the same as not voting?
Perhaps you are trying to implement a rule in which all players
must vote. But I do not see that being implementd nor would I
recomend it as such rules can greatly hinder game play.
Food for thought. What to do with inactive players?
- Welcome to the game, Roy! I'm sure it'll only be a short while before you and Cora are players, and I think we're all glad for that. Regarding the excellent points you raise, some of them are better understood from a historical perspective: The game began with only the simple-majority-to-pass. I added the possibility of removal later, when it became apparent that to avoid clutter we'd have to destroy some proposals. But I didn't want this to be done lightly, so I picked 3/4 arbitrarily. I now see just how hard it is to get a 3/4 majority out of a dozen people, especially when some are not very active. However, rather than lowering the 3/4 majority rule, I'm working on a solution to the inactive player problem (look for the proposals this evening...). Another good idea, I think, would be to allow the maker of a proposal to recind it at any time. However, this disallows a potentially fun scenario: though currently a proposal may only be activated by its owner, perhaps in the future it will be activatable by any player. Then a player might submit a proposal and see it spiralling out of their control, with no way to stop it! This would encourage more careful proposal writing. I agree with you that the abstain is not very functional. I added it at first because I didn't know how to make a checkbox group without a default value, and I didn't want the voting script to bias either way. Now it's useless, but it doesn't make for much clutter, and could easily be useful in the future, so I (for one) don't mind it. And yes, you can change your votes at any time. --AdamBliss
You know what? Something really weird just occurred to me. In the game, we cannot do anything without voting on it, but here we can do everything without voting on it. Anyway, I found it interesting that the game has generated so much here in the free-for-all domain. --CubeSchnaider
I've updated my front end to better handle hex encoded special characters like the ones in Adam's "special" proposals. Again, feedback would be nice.
Another exploit fixed (I hope!). But I had to mess some stuff up to fix it. Specifically, I exploit-passed my votefix00 amendment which altered vote.cgi, so that vote.cgi and vote.pl are now badly out of synch! So I'm afraid cube's going to have to re-propose his votesuccess-layout measure, because the change he wants exists only in vote.pl, which still contains the security flaw. I don't want to go too deep into the details of the exploit right now, because I'm not certain that it's totally fixed. But please vote against cube's layout01 proposal, since it will restore the hole by moving vote.pl onto vote.cgi. (And besides, shouldn't layout01 have
contained a chmod +x anyway?) --AdamBliss
- Okay, it wasn't totally fixed, but after messing things up even more, I think it might be now. I used the remaining exploit to run cube's exploit_fix00 proposal, which is now obsolete (and potentially harmful). --AdamBliss
- I really hope you didn't run exploit_fix00. It had the same bug that got vote.pl and vote.cgi out of sync. Since I can't see an ls -la, I can't currently tell if propose.* are out of sync. --CubeSchnaider
- No, they're fine. I didn't actually _run_ your proposal; it was simpler to make the substitution by hand.
I'm pretty sure it's all fixed now, so here are the details. There were two tricky
ways to get special characters into the system() calls in the scripts. Both of these
flaws had been noticed, and proposals to fix them were on the board. The first was because
I forgot to put a 'g' on the end of my 's///' in propose.cgi (Cube found this), and the
second was because vote.cgi didn't check that the proposal actually existed before allowing
you to vote on it (Vrable found this). Both were considered low-importance. But today
I realized that if you put backticks into the system calls, bash would evaluate the command
in the backticks. So by doing either of these two things, you could get an arbitrary
command run. I used Vrable's exploit to give myself enough votes to pass my vote.cgi fix.
Then I realized that Cube's exploit had the same problem, and used it to simulate passing
I left a bit of a mess behind, but I'll put a proposal through to clean that up later.
Well folks, it looks like our first major exploit has come and gone.
Here's the skinny. The vote.cgi script accepts HTML-POST data
from the form it generates. In the form, you specify whether you
want to vote "abstain", "yes", or "no" on each proposal. Vote.cgi
would then take whichever you selected, and write "userid:thing" into
the appropriate votes file, where "thing" is usually one of ("abstain",
"yes", "no"). But, I forgot to make it actually check that "thing"
is one of those three. So if Joe Player makes his own form
that dumps POST data to vote.cgi--say, exactly the way I'm making pretty-vote.cgi--he
might conceivably choose a "thing" that's not one of those three. Since HTML
can pass arbitrary ascii characters using &#NNN;, that "thing" might contain
newlines. If so, when perl writes "thing" to the votes file, it will spill over
several lines, and therefore be counted as several votes by the activate.cgi script.
The upshot is that any player savvy enough to write their own HTML form to give data
to vote.cgi can register as many votes as he wants on a given proposal.
The fix is simple; I just made a proposal that adds a little check for invalid
"thing"s into vote.cgi. Then I used the exploit to vote for my proposal eleven times,
and activated it. After all, I couldn't advertise the existence of the exploit
and then trust you other players to vote in my fix rather than use it to your own
nefarious ends, now could I?
The proposal I used is in activated-proposals; it's called exploit_fix01 or something.
And the old (vulnerable) version of vote.cgi is in vote.cgi.bk. If you have any
questions, ask me here or by email. --AdamBliss
[I]s anyone (else) interested in being [able] to anonymously submit proposals?
I'm working on a prettier voting script. Please try it out:
Let me know what you think of it. It's still being developed,
but once it's stable and we like it, I'll propose that it gets
added in. Note that this script is running in dry-dock in my
directory. It does not
interface in any special
way with the nomic code. It's just a prettier way of sending data
to the vote.cgi script, which is in charge of actually making all
the file changes. Please post suggestions, since I'm terrible
at user-interface design! --AdamBliss
- You might include a feature that shows if your vote is a deciding vote (for or against). You could also show which proposals have already passed, but not yet been activated. Or maybe that belongs a separate page. --CubeSchnaider
What would everyone think of a turn-based system? Here's how
I'm thinking of implementing it:
- At every moment there is exactly one on-turn player, whose id is stored in the file turn.txt.
- Proposals may only be activated or removed when the player who proposed them is on-turn.
- Activating or removing a proposal changes the on-turn player (e.g., it cycles one step through the players.txt file).
- activate.cgi might change to allow any player to activate a proposal once it has sufficient votes (to prevent the on-turn player from blocking play this way).
This would allow a system closer to Suber's original plan. It
would lend itself much more to a point system: for example, a
player might get a random number (1-6) of points each time it's
his turn; there might be a penalty of 10 points for removed
proposals, and there might be a bonus of 10 points for voting
against a succeeding proposal. These rules, I think, would only
stifle play in this asynchronous mode, but make turn-based play
more fun. Thoughts? --AdamBliss
Umm.. it seems like it would be really easy to stall the game. Say it's my turn. If I have no proposals in my name and I don't decide to make any, how would the game ever advance? The only way to switch turns in your system is for one of my proposals to be activated or removed, which would never happen.. At a minimum you'd have to add some more conditions (probably time-based.. like the way slashdot moderator points expire.. :-) anyway, I don't think we need a turn-based system until stuff is happening a lot faster. Or until we have more of an actual 'game' going on. --TimBuchheim
I'm a little confused. I activated the proposal that added me a
user. Should I have been able to do this? --CubeSchnaider
- Yes. Reading the activate script, that's how new users are supposed to be added--after a sufficient number of votes, the user activates (him/her)self. --MichaelVrable