[Freeciv-Dev] Re: MacOS X gui-cocoa/ and AI...

["Bobby D. Bryant" <bdbryant@xxxxxxxxxxxxxxx>]

Brian Olson wrote:

> See a screenshot of the almost playable MacOS X freeciv client.

I don't have a Mac, but hey -- it looks nice, and I'm always happy to see my 
favorite game migrated to yet another platform.



> As for creating client side AI, it could be argued, that the AI should have 
> exactly the same information that a human might get from a GUI.

Agreed.  In particular, I don't like AIs that have access to information not 
privy to a regular player, nor AIs that can cheat.  (Lots of games' AIs work 
that way.)



> As one who's just written most of a gui-layer for civclient, I think this 
> could indeed easily be done with one proviso: Document the interface. What 
> functions are called by civclient to give notification, what functions are 
> called by the gui/AI layer to get information and make commands.

This would be useful in any case, since people might want to create their own 
GUIs, even for platforms where one already exists.  (I might be tempted, if I 
had a clean, well-documented API to look at.)

If you have the time and patience, you are now in a pretty good position to 
create some draft documentation of the game-GUI interface.  I remember that 
another guy was asking about starting a KDE interface a week or two back, and 
if he had notes from you he could "test drive" them while working on his own 
interface, touch up your notes based on his own experiences, and then 
contribute them to the hackers' guide.



> Currently, the civclient/gui-layer interface is strongly organized to cause 
> GUI events to happen. There are many calls to popup-some-user-element. If 
> these calls were reorganized into a more generic set of 
> notification/information/command functions, leaving the GUI to make the 
> decision to notify the user, then that set of functions could become an easy 
> common base for AI/Scripting and user interface. An AI/Scripting layer could 
> even be transparently interposed- it would usually pass information and 
> notification back to the user, but intercept and handle some things.

I'll just mention in passing that while I was working on those tech patches 
just before Christmas I saw that some code that was reduplicated in several 
GUIs could be migrated back to the common code base.  For instance, there is 
logic for displaying a list of all techs that could be researched within 11 
steps.  It would be possible to write a GUI-independent function that just 
returned a linked list of all those techs; then the GUI could just call the 
function and do whatever it needed to do to display the elements that came back 
in the linked list, without concerning
itself with rules-oriented logic such as which techs were already known, which 
were reachable, etc.

This kind of thing would be a little extra trouble up front, but it might pay 
off in the long run by making it easier to create new GUIs or to create GUIless 
AI clients, and also make code maintenance slightly easier (e.g., changes to 
the tech system would not require hacking every single client, as was the case 
with my patches).

I did not spend much extra time looking around, but I would guess that other 
similar simplifications of the GUI's interface to the game would also be 
possible.

Bobby Bryant
Austin, Texas

p.s. -- FWIW, the LyX team is busy at work converting LyX to a GUII ("GUI 
Independent") system.  (LyX is an open source document processor.) It might be 
worthwhile opening a dialog with them to exchange knowledge and experience, 
since presumably you guys have already figured out some things that might be 
worthwhile to them, and vice versa.  You can get an overview of what's going on 
over there at http://www.devel.lyx.org/.