Mixing Humans and AIs in Real Time Diplomacy (Was: [dipai] Re: Controlling End of Turn)

The following is a response to discussion on the dipai group about the
DAIDE method of setting orders as preliminary. I am sending it to
the following distribution lists for the reasons cited:

	dipai - Because the Diplomacy Artificial Intelligence community
	is the launch point for this discussion.

	rtdip - Because these are the players who will be the first to
	be affected by these developments.

	dpjudge - Because I am very likely to include the chat service
	described as the social media context for USPN, my DP Judge
	installation,4200 and allow the DPPD as a method for logging
	into the chat. There is a high probability of DPJudge 2.0 being
	federated with this infrastructure.

	DipWorld - Because this chat service is the cornerstone of my
	plan to revitalize the DipWorld community with a supplemental
	social context, a replacement for Yahoo-based game rooms and an
	automated natural language interface. (The chat server includes
	an email interface and the game room metaphor of the service on
	asciiking.com is inspired by DW game rooms.)

	DWStaff (closed list) - Because this is a description of plans
	that I intimated in my most recent article in the Diplomacy
	World 'zine and I want feedback from the rest of the staff as
	to how to develop this for future articles.

Please keep in mind that the two paragraphs below are taken out of
context. They do not reflect the opinion of the original poster or the
DAIDE community towards the RT Diplomacy community, but rather the
importance of preserving the DAIDE software platform's usefulness for
its original purpose.

> This is DAIDE and we should base the project around the
> development of AIs.  Which means fast games, at bot speeds.  If we
> slow down bots for the instances when humans 'may' be present, I
> think we are doing the project a disservice.
> 
> I would much rather have the aimapper, auto-set NOT(GOF) in the event
> that a message has been received after orders are submitted and GOF
> set by the human.  This would put the humans response time on par
> with the bots, and would mean that bots would not need to envoke
> delays for human players that may or may not be present.  Slowing
> down bot-bot tournaments as a result.

I agree with the conclusion although the formulation of the premise may
be awkward.

The RT and AI communities experience both synergy and conflict. This is
not unusual, unexpected or in any way a bad thing. I am, however,
interested in a roadmap to handle the conflict while preserving the
synergy.

I think an emphasis on core DAIDE tools that is oriented towards AI
development is a reasonable goal that is in unfortunate conflict with
the long term viability of the RT player community. If this is not
resolved then the RT community associated with DAIDE will continue to
languish and RT playing communities will be established independently
of its efforts, erasing the benefit of those accomodations that have
already been made for RT play by programmers in the AI community.

I believe that the solution to this problem is for the RT player
community to migrate to a client-server protocol that is not maintained
by the AI community. The client application should offer the salient
benefits of the AImapper in terms of playing experience (i.e. an
interactive map that is integrated with the client) alongside social
networking tools that are feature competitive with general purpose chat
clients. The server should operate in federation with one that
implements the DAIDE protocol and it should implement one or more Open
general purpose protocols for chat, with access to subscribers of major
commercial chat applications a desirable feature. It is also important
that the server operate persistently on reasonably priced hosting plans
and the client software not be constrained to a desktop environment.

I have identified a protocol, PSYC, and a tool chain (below) that are
capable of serving this role. I am working with the developers involved
to deliver these capabilities for the Diplomacy hobby in general and
the RT community in particular. These are the components:

Eric Wald's Parlance is a DAIDE server written in Python, which lends
itself to portability and extensibility. Eric has been very responsive.
The DAIDE interface in Parlance was written to an extension proposal
orignally drafted by David Norman to implement multiple concurrent
games on a DAIDE server. Care is taken to make the server compliant with
the behavior expectations set by David's DAIDE implementation while
implementing hooks so that the server can interoperate with other
software. Eric has implemented DPP/0.17 on Parlance, an update to the
text protocol on which the DAIDE language is based, in order to allow
Parlance to work with other chat servers, many of which do not
implement non-text protocols gracefully. Eric will also be implementing
a bridge so that players logged into the Parlance server on the DAIDE
standard port (16713) on asciiking.com can chat and receive presence
updates using the AImapper.

Psyced - http://www.psyced.org/ - supports PSYC, Jabber™/XMPP, IRC,
TELNET, HTTP, Applet, SMTP, XML, and RSS natively. I will be providing
a DPP bridge so that the psyced server can operate in federation with
Eric's Parlance server. Federation means applications work together
without forcing others to change the way the work in order to do so.
That means if you have a GoogleTalk identity or a chat client that you
like to use then you can use it with other services that are federated.
The psyced deployment on asciiking.com is already set up to receive
connections from PSYC, Jabber™/XMPP, IRC and TELNET clients. You can
find instructions at http://usak.asciiking.com/chat/ or connect with
an Applet at http://psyc.asciiking.com/static/ using your web browser.

Dyskinesia is a chat client for the PSYC protocol written in C++ with
Qt webkit as its GUI toolkit. Qt is the native user interface kit for
Nokia smart phones and it compiles on Windows, MacOS, Linux and
AndroidOS (iDon't, DroidDoes) as well as Nokia's SymbianOS. One of the
features of webkit is that it builds user interface elements using the
same markup, control and formatting languages used in web development,
meaning that the same code used for the web interface with other chat
clients can be loaded inside the chat window for those who use the
native PSYC client. I am working with the lead developer Ketmar -
http://ketmar.no-ip.org/ - to complete this capability. I will be
maintaining the stable Linux release and hosting Windows and MacOS
downloads when the application is feature complete.

All three of these software components are free and open source. My
contributions will be available under the same terms as the original
programs. That means unrestricted noncommercial use while commercial
implementations of the Diplomacy server must contend with Hasbro/WotC
intellectual property claims and competition from free servers including
asciiking.com, which will continue to operate on a nonprofit, user
supported basis.

The end result is that players will have many choices to connect with
real time Diplomacy games. The federated structure will allow both the
AImapper and a number of general purpose clients to access both chat and
Diplomacy games. Players with only a browser will be able to play and
chat using a Java Applet and interactive web page. The AImapper will
have the admin message functionality extended by the server and receive
results normally. IRC users will be able to log in using their client of
choice as will those using XMPP and, eventually, other chat protocols.
Those players will receive updates via chat and view results in the
interactive web page. Each client will use native methods of access for
interacting with chat and games, including their own methods for
identifying players.

Chris




------------------------------------