From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12833 invoked by alias); 20 Nov 2003 02:15:32 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 12587 invoked from network); 20 Nov 2003 02:15:31 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 20 Nov 2003 02:15:31 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id hAK2FUnc022826 for ; Wed, 19 Nov 2003 18:15:30 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 19 Nov 2003 18:14:56 -0800 Received: from apple.com ([17.112.76.143]) by scv1.apple.com (8.12.9/8.12.9) with ESMTP id hAK2Ewww013904 for ; Wed, 19 Nov 2003 18:14:58 -0800 (PST) Message-ID: <3FBC23C2.80204@apple.com> Date: Thu, 20 Nov 2003 02:16:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xconq Subject: Xconq language thoughts Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00819.txt.bz2 In all the discussion of extension languages for Xconq, the one thing I look for is "what is it for". It's always lots of fun to talk about languages and their good/bad points, but what do the game players and designers get for it? For instance, many of the games in Xconq are based on a randomly generated world, the purpose being to provide a new and different experience each time. This is completely opposite to 95% of commercial game design, where everything is so predetermined that you can buy a printed walkthrough at the bookstore. Random generation is harder; you can't just write a script for AI behavior, the AI actually has to be able to do its own analysis. In return, you get a game where you can't win by knowing to send a full transport to 34,45 after turn 30; transports may even be the totally wrong strategy. Now if people want to write scripted scenarios for Xconq, that would be an interesting addition; but I haven't seen very many requests for that. Another consideration is that there is a tension between generality and specificity; if you generalize everything a lot, you get more flexibility, but you also have to do more work to get something working. In the most extreme case, you end up with one of those generic "game engines" that amounts to little more than a poor reimplementation of event loop and memory manager. Xconq is consciously designed to support only a very specific class of games; in return you get lots of functionality that "just works". For instance, there has long been an ability to write AIs customized for a particular game design, but so far everybody has preferred to just sponge off the generic AI instead. (Not too surprising, since AI writing is hard, and there is no possible API that can help you with the hard parts.) So when thinking about language integration, don't think about resumes or user familiarity or whatever; think about how much Xconq machinery you want to use as-is, vs how much you want to change. Stan