Anyone interested in helping to make an online version of Universalis in mud-form?  The plan I have is turn-based, real-time interaction.  I.e. not a forum -- the players would all be present at the same time.  So the dynamics would be as close as possible to regular play, given the limitations of the medium (e.g. you can't see peoples' faces).

Here's the important bit.  A friend and I already have a running, peer-to-peer open source mud called (curiously enough) p2pmud.  It's located at http://www.p2pmud.com (yes .com, not .org, even though it's open source).  It's written in Javascript and we've tried to make the code as straightforward as we can (we have a roadmap to make it even simpler).  Please excuse the hubris on the site -- it's part of our team's online persona (we started writing muds in 1989).  The nutshell is that each person gets their own mud and you can 'teleport' your character into other peoples muds.  Each person can backup their own mud and build in it offline (no www server required).  It's a standalone Javascript program in the form of a single (large) HTML page and it can back itself up and saves itself automatically.  Right now, mud only runs in firefox.  It's themeable too (and makes julian fries).

So the idea would be to make a version of Universalis that runs inside of this mud, rather than starting from scratch.  I thought this thread might be an appropriate place to lay out the ideas I have so far, since this is a forum about Universalis and all, so I'll paste in the notes I have in the next entry.

Here are the notes I have.  The idea is that a unigame object is the 'game table' that the players 'sit around'.  The actors (mud characters) represent the players and components are other objects in the mud.  Through the unigame object's commands, the actors are able to manipulate traits on components, etc.  Given that Universalis isn't really focused on simulation, I thought I'd keep the simulation aspect of this implementation down to a minimum as well.  So Scene Locations are represented as locations in the mud, and components are represented as things in the mud too, but traits are really just text entries in a list.  There's no combat, etc.  The Unigame object keeps track of control for components, wealth, secret bids, etc.  Here's the notes...

Player -- rather than modifying Actor, this allows an actor to potentially participate in more than one universalis game.  important?
wealth -- total coins
control -- components currently under control
actor -- the player's actor

Locations and Things are modified when they become components
masterStatus -- true if this is a master component
masters -- list of master components from which to inherit traits
hasName -- true if the name has been paid for (otherwise the name is for identification purposes)
traits -- list of traits
controller -- actor controlling this component

Unigame object -- located in the current scene's location, moves with the scene
tenets -- facts about the world
players -- maps actors in the game to player objects
components -- known components
currentPlayer -- actor whose turn it is
events -- log of events for posterity
makes announcements
logs game events so it can produce a transcript

Fact
description
fact id -- for easy revocation with the revoke command
overrides -- list of facts that this fact nullifies (for sub components)
component -- component which this fact is about (or unigame object if it's a tenet)

Commands:

startgame
tenet "text" -- declare a tenet during the tenet phase.  this ends your turn
tenets -- list all tenets so far
challenge
complication "text" -- start a complicatation
pooltype type -- change the multiplayer conflict model (standard, independent, split, individual, allornothing, besteffort)
allocate n actor -- allocate n success to an actor in the split allocation model
draw [trait | n] -- add to your dice pool.  a trait indicates you are drawing on a trait, a number indicates you are buying n dice.
pass -- end your current turn
interrupt -- pay a coin to make it your turn
control component -- pay a coin to take control of a component
bid -- bid (either for scene framing or for a challenge)
endbid -- declare that your bidding is finished ('bid' will reopen your bid)
trait component "text" [mult] -- declare a trait for a component with an optional multiplier
traits component -- list traits for a component
revoke factid [mult] -- revoke a fact (optional multiplier)
override subfactid masterfactid -- declare that a subcomponent fact overrides a master component fact
link component mastercomponent -- create a subcomponent/master component link
miniscene -- create a miniscene
location -- set the location for the current scene (or miniscene)
present "description" -- set the time for the current scene
past "description" -- set the time for the current scene
future "description" -- set the time for the current scene
endgame

Modified commands:
look/examine will additionally list traits, control, wealth, etc.

Fascinating. When you ask if anyone can help, what is it you need help with at the moment? Are you done with the programming? Or does it need more of that? Or are you just looking for players at this point?

Have you read about the IRC and Wiki games that have been played?

Mike

I've read about the wiki games, but not about the irc games.  One advantage of this game is that it would be persistent (our mud is already persistent).  When you quit the game, it saves itself (if you have 'autosave' checked).  When you restart, the unigame object would still be there, keeping track of who has how many coins, etc.

The unigame object will also keep a log of events so it can dump out a formatted HTML page detailing the play session.

We don't NEED help right now -- we've gotten this far already with just two of us.  I'm just sort of making a plea for help, because there's only two of us and we're both married and we're both programmers.  So progress happens, but only in fits and starts in between obligations.

That said, this project does have a track record of progress.  It already runs and networks and everything.  So I'm kind of making an announcement, but I'd really really like it if someone out there would lend a hand.  With just two of us, it's sort of like having only one jogging partner.  If one isn't really motivated, there's a 50-50 chance that things will happen; either the motivated person can motivate the other guy (or work along) or else maybe the unmotivated guy influences the motivated guy to take some time off.  With three or more, I think there's a better chance for peer pressure to affect the project in a positive way.

As far as done with the programming: the notes about Universalis in the mud are just notes.  I'm trying to lay out the architecture and maybe get a second or third pair of eyes on it.  The mud-things are already done though.  So most of the code for Universalis Components is finished -- i.e. there are already locations, 'physical' objects with names and descriptions, containers, lids, etc.  Traits would simply be a list-property on things in the game, etc.  I haven't started on the unigame object, the commands I listed, etc. yet.  I think I'll be doing that shortly.

By the way for those who don't already know, Javascript has a very sophisticated object model and does inheritence very well.  If anyone knows OO but isn't that familiar with Javascript, here's a great page about it: http://www.crockford.com/ (click on Javascript).  Oh yeah, and of course our game is powered by AJAX (in certain cases).  The distinctions are a bit esoteric, but our game is online/offline and it doesn't usually use XML to communicate (it uses mainly JSON), but it does use XML to access some at least one web service (like google's spell checker).

Bill, I'm gonna check out the site and all, but it's julienne fries.  ;)

Hmm, interesting. Per the earlier discussion of object orientation and Universalis, do you have it set up where objects that have a trait that indicate that they are instances of master components are objects that inherit from a master component class? Because if so, that would sorta complete the vision on those things.

Mike

JS only supports single inheritance and a component can have many masters, so I was going to roll my own inheritance for traits -- probably make a getTraits() method that catenates the facts from the parents.  Thats what the masterStatus and masters properties are for.  Oh yeah, every fact needs a time stamp so they can be listed out in proper order (since subsequent facts can partly override preceding facts).  And master components will need a list of their subs, in order to properly compute importance, too.

The link gives me a 403 Forbidden error... a pity since I'm already a fan of RavenBlack's Dvorak bot on his MUD. Those guys would probably get a kick out of this.

Bill,

I'd be interested.  I currently program in Javascript for a living so I can probably help a bit with coding as needed.  PM me if you want me to send you some more information or tell me how to get in contact with you privately.

Sorry I've been incommunicado on this!

Just to update, hackers have been breaking into our site, so my friend took it down.  We just got all the images back from our artist for the random dungeon in the game.  I'm hoping this will put us back on the productivity track.  Having even one more developer would make a great deal of difference, Gaerik, so I'll definitely send you a msg!  I've already talked to my friend about simply putting up a static site until we find something a bit more secure than postnuke (at least the version we're using, anyway).

Was just wondering what the status of this project was. It looked quite interesting from what I read of it, and would certainly simplify the "note-taking" process for an on-line game.

I'm a bad man.  I haven't had time to work on the game for a LONG while, because of my job.  Before the major interrupt, we drastiacally switched p2pmud from Javascript/HTML to Lua/Sauerbraten (http://sauerbraten.org/).  Same concept, but now it's 3D.  I haven't posted code anywhere because it's not very playable, just yet.  Anyone interested in this can send me an email at bill dot burdick at gmail dot com.  Sauerbraten allows collaborative editing, so I think it would lend itself well to Universalis.

Bill