Diplomacy on Twitter?
Chris Babcock
burn by turning my eyes towards the Twitter API. One of my first
experiments is running now (2009-Aug-01): http://twitter.com/TwitDipl
I've dabbled enough on Twitter to understand that I don't really get it,
so I'd love to have someone who speaks native Twitter help edit the game
messages. It would also be good to have playtesters and those with more
real time play experience help with fine-tuning the play settings. I'm
not entirely sure whether I'm going to use nJudge, DAIDE (Eric Wald's
'Parlance') or Diplojuge for the backend. I'm putting hooks in the USAK
site to try to bring over some users, but unlike the web interface for
the judge I don't expect 100% command compatibility for the Twitter
implementation.
This the workflow for the 3 basic tasks that TwitDipl will need to
manage:
Registration
- Player follows TwitDipl.
- Twitter sends email notification to TwitDipl.
- Judge sends direct message to player with link to registration.
- Registration page contains:
+ Link to official Diplomacy rules
+ Rules of conduct for TwitDipl
+ "Do you also want to play by email?" question
+ Short quiz to prove that player looked at the rules.
+ Duplicate detection.
- TwitDipl follows registered players.
- TwitDipl sends "fresh meat" message.
Idle / Forming Game
- TwitDipl checks periodically for updates, DMs or @messages from
players.
- At a certain threshold, or if triggered by player, TwitDipl tries to
start a game.
- TwitDipl send @messages to recently active players to promote
forming game.
- Players reply to TwitDipl updates (send @message) or DM TwitDipl to
join forming game, set preference and/or set availability.
- TwitDipl tweets new player notice.
- When game fills, TwitDipl send individual links via DM to each
player asking for confirmation.
- TwitDipl attempts to secure alternates while waiting on
confirmations.
- First 7 players confirmed start the game. TwitDipl announces players.
Game in progress
- Players submit orders via DM. @messages will be accept if no DM
provided, but players will be cautioned that their order may be
visible to opponents.
- Players use @messages with #tags to TwitDipl to signal readiness.
Acepted tags are #ClearOrders, #PrelimOrders, #FinalOrders. Tags are
not case sensitive.
- Fuzzy matching will be use on all orders. Order sets requiring fuzzy
matching will be flagged with a warning but not an error.
- TwitDipl will poll for new @messages every 60-90 seconds during
negotiations.
- TwitDipl will accept orders during negotiations, but have a separate
order entry period. While negotiations can't be stopped, it would be
inprudent for players to continue if they have not submitted orders.
- There will be an undocumented ~30 second grace period on order
submissions.
- TwitDipl publishes result maps with the TwitPic API.
Any input on the language, the timing, workflow, etc. is welcome. I
don't expect Twitter and email to mix in same game here. I am mostly
looking for experience with a (near) real time server.
Chris
John Robinette
I have some experience working with diplojuge when attempting to write
an adjudicator for playing on IRC. Although I never got it fully
functional, a few friends and I played a slightly dysfunctional game
of the Hundred variant for a few years before it broke down. I must
warn you, if you use diplojuge, and find need to hack on it any (you
will), that most variable names are in French. So provided you can
think carte, pion, mer in place of map, unit, sea (and so on), there's
not much to worry about.
Also, the last time I downloaded diplojuge from the official website,
it hadn't been updated since 2004, and has some hardcoded features to
only work with command line input. I modified a few functions to make
it usable as a library, and I believe one or two of the documented
command line options weren't working properly, so I fixed that too
(although I can't remember which ones). If you use diplojuge and would
like, I could dig up my old code and pass it along. Who knows, with
all the work you've been doing recently on ASAK and now this TwitDip
deal, I might eventually get enough fire under me to redesign the IRC
interface. Considering that I first had the idea my freshman year of
college, and now I've got several years of design and coding under my
belt, I could probably do it much better now. But that's another
topic!
- John
Chris Babcock
John Robinette <mod...@gmail.com> wrote:
> I have some experience working with diplojuge when attempting to write
> an adjudicator for playing on IRC. Although I never got it fully
> functional, a few friends and I played a slightly dysfunctional game
> of the Hundred variant for a few years before it broke down.
I'm interested in Diplomacy over asynchronous protocols as well as
Diplomacy over Social Networks. The Twitter implementation hits both
and feeds my other need - procrastination. I'm putting off learning
OpenSocial (protocol), coding an interface to read stored press on
USAK and finishing an XML Schema all at the same time that I'm waiting
for the PSYC protocol <http://about.psyc.eu/> to stabilize. I'm awesome
at multi-tasking.
Jonathan Amery had a Jabber interface for nJudge running on UKYS for
awhile. There are a couple social reasons why that's not taking over
the world right now, but the technology was sound. Jabber (now called
XMMP) is the native protocol for Google chat and has gateways available
for other chat protocols. That kind of feature would be a good add-in
for a web site as an alternative to email for push, but it doesn't add
discoverability for the server, which is what I'm aiming for with
Twitter.
I'm also not expecting anything as low bandwidth per transaction as
Twitter to be the lone transmission vector for game data. The strength
of chat protocols is their ability to publish links and notices in
real time... and to identify when contacts are on-line. Neither DPJudge
nor any of the phpDip implementations have the capability to push game
formation the way that a chat engine could because a website needs to
have a lot going on in order to create "presence". Running a play by
post Diplomacy forum, you've probably discovered the problem of
"there's nobody online." Well, they *may* be online, but unless they
are either logged in to the site or keyed in to your particular node of
the ad-hoc chat network built around the group then you probably won't
know. PHP bulletin boards create meaningless activities (often called
"searches") to create presence and serve ads to players. I think that's
a phenomenally disrespectful thing to do to players and I want find
alternative ways to identify when players are online that aren't such a
waste in order to have Real Time games consistently available.
> I must
> warn you, if you use diplojuge, and find need to hack on it any (you
> will), that most variable names are in French. So provided you can
> think carte, pion, mer in place of map, unit, sea (and so on), there's
> not much to worry about.
I don't have much of an active vocabulary in French any more, but I was
fluent when I was 4 years old. It came back easily enough in highschool
French, so I'm sure that's not a factor.
Mostly I just need something that works from the command line and likes
pipes. Losing the convoy specification from Ken Lowe would be a bonus.
Unlike many programmers in the hobby, I'm not at all interested in
writing or implementing an adjudication algorithm. My interests lie in
design. Writing code is just an occupational hazard. I use CRM because
it handles strings well and behaves well with most anything that runs on
Linux.
The USAK web site generates something like an email message for server
transactions then does the equivalent of "cat msg | formail | rdip" to
feed the message to the judge in a way that makes it look as though it
came in off a mail server. I'm working with Griffith Young to create
ways for the website to perform all its read-only operations on judge
data without writing a message to the judge.
> Also, the last time I downloaded diplojuge from the official website,
> it hadn't been updated since 2004, and has some hardcoded features to
> only work with command line input. I modified a few functions to make
> it usable as a library, and I believe one or two of the documented
> command line options weren't working properly, so I fixed that too
> (although I can't remember which ones).
I wrote to the developer about a year ago and he considers the
application mature and complete. If you have contributions, especially
any that make it more usable as base code, then it would be good to
share them back. See "secondary goal" below. :-)
> If you use diplojuge and
> would like, I could dig up my old code and pass it along. Who knows,
> with all the work you've been doing recently on USAK and now this
> TwitDip deal, I might eventually get enough fire under me to redesign
> the IRC interface. Considering that I first had the idea my freshman
> year of college, and now I've got several years of design and coding
> under my belt, I could probably do it much better now. But that's
> another topic!
That is a secondary goal of my activity and one that has been going
pretty well. There's a new GPL Diplomacy app written in PHP that looks
pretty good in the developer preview. Development was stalled until I
started shaking trees on SourceForge looking for collaborators. Since
development on phpDip and its major branches is stalled (hopefully not
permanently), this is a good thing. David Norman has just supplied a
patch for a five year old nJudge bug in response to a threat that I
made to implement one of my solutions and Griffith Young is working on
refactoring nJudge so that it can be implemented in a framework.
This last bears some explanation because the benefits aren't as obvious
as a new user interface. The benefit of the framework is that consistent
definitions of the interface between different components of the server
mean that developer in the hobby can focus on the parts that interest
them and they don't have to write a complete game server in order to
implement their ideas. Instead accepting the tradeoffs and division
inherent in having a Web Interface specialist, an adjudicator algorithm
specialist and a core logic specialist implementing different servers
that each reflect the strengths and weakness of each programmer, a
server implementation can choose best of breed for each component in
his specific environment.
Everything that I'm writing is designed to work with something else
mostly in the way that the particular something else works. In keeping
with that, I'm really interested in how the ICQ Diplomacy Guild worked.
I think moving to forum was a small gain in discoverability at the
expense of presence. Unless players log-in and haunt the forums, it's
hard to know who's on-line. If you didn't use that feature effectively
in ICQ then it's a good trade, but if you did then I'm very interested
in knowing how play-by-ICQ players found eachother, organized games and
played in detail - mechanisms used, timing parameters, social contracts
- when I say "detail" I mean anything and everything, the more the
better. Feel free to take it offlist if you like. This email address
works.
Chris