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

Your plan is very ambitious, and also very impressive
Good luck.

On Sat, Oct 24, 2009 at 2:34 PM, Chris Babcock <[email protected]>wrote:

>
>
> 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
>
>  
>