June 2nd 1999 Client Developers Meeting Summary


This was an extremely productive meeting, both in the sense that we discussed a lot of things (and decided a few), but also because it gave a lot of people a chance to talk to each other directly, and organize plans to work together on a number of little projects.

Both before and after the meeting there was some good client discussion. The discussion from prior to the meeting is included in this summary, the stuff afterwards is not, but may be of interest to demo developers. http://www.worldforge.org/website/irclogs/coders199906030907.irc

World Editor

Phil discussed his plans with the world editor prior to the meeting. His approach will be to focus the editor specifically on map creation and graphics assembly, and leave rules-specific world editing to another tool. [Any developers interested in making an Entity (character/monster/object) editor?]

The current world editor is fully capabile of laying out the graphics for creating game worlds, but the copy in cvs isn't functional. Phil will be creating a statically linked binary for Solaris and Linux. This is something that could likely be used as part of the Demo package.

Phil could use a person to write user docs for this editor, perhaps in a week or so. He's going to work on polishing things up over the next week to make it easier for a documenter.

He and I discussed some aspects of STAGE as far as how it might affect the editor (and clients). STAGE holds the properties of entities in tables that map string -> Parameter. A Parameter is our own custom designed class that encapsulates a variety of different data types (string, int, double, list, vector3d...). Each entity will have several of these tables - one for transitory traits such as hit points or mana that fluctuate a great deal with time, and another for more static properties like skills, descriptions, and such. As well, each Entity will have defined to it a "Species" - a type that contains similar lists of properties, and that is shared among many, many entities. When searching for a particular property, the server will first consult the Entity's tables, and if not found, will consult the tables in the Entity's Species. The idea being, for critters that are very similar, all of the common traits can be shared among them, and only the uniquenesses (e.g., hitpoints) can be maintained individually. Species can also be used to maintain common behaviors (i.e., functionality) as well.

STAGE divides its world into 100m x 100m x 100m boxes to containerize things. Phil wondered if he should output from the editor, "world chunks" sized to fit these boxes. He's going to try something like this for now, but will not "hard wire" it. Being able to pull or submit entire boxes will be handy and probably "intuitive" for developers, although we also want to have the capability to "pick and choose" bits from the world to work with, eventually. (And even more eventually, we'd like to do this while the server is running!)

Phil recommended that I look at the Signal event system from Gtk--, and a paper on the theory of it.

QServer / QuADAS Availability

Another pre-meeting question regarded the availability of a server for client network testing.

QuADAS and QServer 1.0 both use a similar network command interface, and both compile and (mostly) work. Both are available in CVS. QServer is a bit more current than QuADAS. QServer's use of unix sockets mean that it probably cannot be compiled easily on Windows. QuADAS runs on Windows and Linux just fine.

For client developers under Windows, it was requested that we establish a round-the-clock running test server for them to play with. This could be made to kill and restart every ten minutes, in case it might get broken from being played with too hard.


Sal is working hard on XEngine, the rendering portion of the client. It will be uploaded to CVS (along with binaries I trust) soon.

Sal gave us a quick preview of a new tool he's developed, in relation to XClient: XTerra. This (Windows) program allows editing of relief maps of a world, as well as importing of DEM (Digital Elevation Map) files. He hopes to integrate XEngine into it sooner or later. He'll upload this and make an announcement tonight. Its scale is 1:250,000 currently.

Sal is hoping to release XClient immediately after STAGE is released. [Heh, hopefully it won't take that long Sal...] He is going to wait until the Atlas protocol is solidified. Sal is thinking of switching from using XEngine to CrystalSpace.

Phil and Sal discussed integrating XClient functionality into the world editor.

Bloodsport and Sal made contact and discussed at great length (off line from the meeting) regarding production of 3d art for xclient.


John updated his wiki page with new instructions on installing and using tkClient, as well as a new package that includes all the necessary extensions. In tkclient you can display maps and move Johnny's animated character around. He's achieving about 15 fps, but thinks he can achieve a bit higher by switching to tk canvas. http://www.worldforge.org/website/client/tkClient/installation

John's just started the networking code for tkClient (no doubt busy right now integrated qserver2...)


Karsten has improved the speed in general: the screen is only updated when needed and for scrolling uclient now uses a caching buffer that is slightly larger than the viewport. Music and sound have been added, too. It can play MOD, streamed WAV, and Midi (which sounds bad sometimes). Karsten hasn't been able to get Oliver Matla's MIDI's to work in uclient yet.

There was discussion about sound libraries. Karsten says that for music and sound uclient he uses libmixer from SamLantinga(SDL) and timidity and mikmod, and recommends looking at http://www.opensound.com.

Karsten has started a lib for packaging groups of images and textfiles in a compressed archive. I have a class from a previous game development project that I worked on, that could do this; I've got permission from the author to use it, so will be forwarding it on to Karsten, along with a Pacman game I wrote that demonstrates use of the code.

Cross-Client Modularization

We've got a number of different client projects underway with a lot of good stuff, good screenshots, and code. Each of the clients is unique in many ways, but there are some parts that could be shared between the different clients. We feel that breaking these sharable parts into independent library modules, each with its own caring developer/maintainer, it will help us out a great deal.

Several of the developers pointed out that with clients being developed in various languages, care would need to be taken either to ensure the libraries worked in various languages, or to provide versions of the libraries in multiple languages. As well, it was thought that if the libraries are written in languages other than C or C++, it could force the game player to install Yet Another Dependency in order to use it. Karsten mentioned that he'd be willing to include Python as a dependency for uclient if people wanted to develop libraries for him in it.

Phil wondered if Atlas was one of the tasks for the client developers to tackle. The server developers are hoping to provide this as a "pluggable" module (as qserver2 is providing). Sebastien can hopefully provide more insight into this later. Certainly, Sebastien should gather input from the client developers regarding how Atlas interfaces on the client-side. The client developers were curious (hopeful?) regarding use of libxml in the implementation of the protocol.

We discussed the potential of modularizing the GUI aspect of clients, but pretty much felt like there was too high a degree of variation, and too much difference in style and functionality, for this to be worthwhile. There may be some potential here, such as what we're doing with sharing SDL and U, but this is not likely to spread "across the board" on every client.

Some other potential libraries we discussed were: Sound & music, config file loading, user command definition/scripting, graphical overlaying, character information caching, and world data caching. We felt that an XML config class, and a map file loading set of routines would be handy. Some of these can probably be pulled out of existing code (or used in place). Peregrine commented that any caching things would be good libraries, and would encourage client developers to be bandwidth conscious. Karsten thought user command/scripting would make a nice portable lib.

John mentioned an interest in creating a Python library for uclient to overlay animation files, write out composites, etc. This would help the media people in, for instance, creating clothing for character animations. He requested that Karsten and Sal and others contact him and let him know how he can be of service in this regard.

John Sheets summed up by saying, the main thing here is to lay out some good boundaries for the various modules. And like GNOME we should shoot for being as language flexible as we can. If we define a concise set of client modules, then client developers can swap them out without tipping over a bunch of dependencies.

Establishment of Generic Client Requirements

Currently, it's possible for someone to show up, get a wiki account, create a new client with a few screenshots, get it posted to the site, and then disappear never to be seen again. We then bear the burden of having this client listed on our page, even though it is (as far as we can tell) unsupported and unlikely to be finished. Thus I proposed we establish a client 'spec' for a client to provide in order to be 'accepted'.

It seems that these requirements could serve a dual purpose, of providing client developers with a 'spec ladder' to climb, with several steps to achieve on their path to completion. As well, they'd provide the end user with an indication of which client is most mature for their purposes.

We briefly discussed a few ideas for requirements but it was clear they'd take more thought. We decided that whatever the requirements, we'd need to take the following into account: The requirements should be clear and unambiguous, so developers know themselves when they've achieved a given level of completion. The requirements should include goals beyond code and features, for instance, documentation, regular submissions to CVS, or regular releases of distributions. We also agreed that the requirements should allow for the existance of a variety of different classes of clients. E.g. end-user client, editor client, scripting client. Each class of client might have slightly different requirements.


Arnan came by to give a report on his newly released Version 2 of QServer (aka QPeer).

Mike, James, and Arnan have been working on modifying Qserver into a 'Peer', or client + server on equal footing, in one binary. The idea behind this is that the client and server are actually the same code. Clients built on the peer can automatically communicate with each other and the client server communication is symmetric meaning it shouldn't ever be broken. This has been checked in as qserver2 in the forge/servers directory of cvs.

The other advantage is that it encompasses all the parsing and entity database stuff so that that is automatically compatible between clients and servers too. And finally, it allows a lot of code sharing.

So a 'client' should actually be a user interface for the peer. The 'client' should display the Peer's Map, and should talk to the Peer's Agent. It can also be thought of as a library for the client, as opposed to a separate daemon. All of the client's access with the game server is through this peer. In a future incarnation this will use STAGE's libAtlas. Thus, all clients would share the same API to interact with the remote server. Peer is just networking, communications, entity databasing, and map maintainence, though: everything else is provided by the specific client.

John Sheets inquired about dependencies. "Will this work for SDL apps, GNOME apps, QT apps, etc." Arnan noted that the only library it has compiled in is libpthread (which may not be very necessary anyway), and otherwise it's plain C++ with STL.

Peregrine brought up an important point, in that this library may not be usable with non-C languages, such as Perl or Python. In this case, it could be wise to make the peer a daemon. In any case, we all know Perl is nothing if not a "glue" language so there must be a solution or three to be found for it. If nothing else, since the code is open, it can be translated into Perl (or Python). CORBA is, of course, another good option. We decided that the door must be left open for client developers to choose not to use QPeer if their situation requires something different (in which case, the client developer accepts the burden of keeping up with the protocol).

QServer2 was very well received by the client developers, who found it to be a very cool idea. They're all rushing off to get it from CVS and check it out. Arnan wants to get some feedback on the notion of using this peer architecture, and he promised to be modifying the code over the next week, and posting some decent documentation to the website. We'll be focusing on getting uclient hooked up to this system as an example.

Media Q & A

One of the things that came out of yesterday's meeting with the media folks was the strong, strong need for more information about client capabilities and features. Unfortunately we didn't have time to discuss these things in as much detail as I had hoped, but at least the client developers have been given some awareness to the needs of their media suppliers.

3d animation for XClient was discussed. Sal didn't want to force artists to buy expensive software in order to produce animations, but felt that .3ds was the format he'd prefer. Shaman mentioned that there may be a conversion tool in the CrystalSpace CVS, and Sal thinks he could code a converter for .3ds, and probably for Truespace too, if garg can send a file format spec.

The client developers (well, Sal at least) need a bit more time to research matters before being able to answer the graphic artist's questions properly.

Graphics Archives

One thing that was mentioned by Uta yesterday, and a very good point, is that we probably shouldn't mix different styles of graphics in the same archive (e.g., 2d topdown tiles, with 2d iso tiles, with 3d textures).

Today we decided that we'd like to differentiate both on basis of perspective (top down vs. iso vs. mesh), and on artistic style (drawn vs. rendered, simple mesh vs. complex). Division based on world (sci fi vs. Dural) will also be needed. Exact implementation of the division scheme will be discussed on the mailing lists. The 3D client will have specialized needs (height fields, textures, maps...)

It was asked about how the clients will be able to download all of the graphics as they go. Obviously, the majority of the graphics would be pre-downloaded, and only newly changed or added files would be re-downloaded and cached.

We are also going to need a standard location to be storing the images on the user's hard drive. This is another question TBD.

Client Support for Real Time Strategy or Turn Based Mode Games

Some questions have come up recently regarding whether the existing clients will be able to support RTS games such as WarForge, or turn based gaming, or else if specialized clients will need to be developed. John, Karsten, and Sal each immediately agreed that putting in TB or RTS support should be doable with the existing clients (perhaps even embedding the capability within Atlas. When there is a demand we'll look into it more.

Server Questions / Comments / Requests

Phil would like to know if Atlas will support sending bursts of ~200 entities, thus allowing the client to buffer nearby regions. He also inquired into the potential security issues this could bring with it.

Another question Phil brought up is, how will the media server and main server be guaranteed to be sending consistent graphics and graphic id's to the client. A related question is, how will we establish a common typing system to identify graphics independently of the media type (e.g., ID4523 "Grass" corresponds to a 2D iso grass tile, a 2D top down grass tile, and a 3D grass texture, interpreted dependant on the client type.) I mentioned that ydkj had mentioned having some ideas along these lines last night, and Phil said he'd like to hear about it, before he goes ahead with implementing something.

It was commented that work on Atlas seems to have faltered a bit. Or, as one person put it, we're kicking the soccer ball around but no one is getting around to scoring the goal. We need to get a 1.0 of the protocol assembled soon, folks!

John would really like a test server to hook to, for testing his client against. There was also the question, when the demo deadline is?