[CF-Devel] Future crossfire changes/projects <Basic's ideas>

Sun May 27 22:34:28 CDT 2001

Quoting Mark Wedel (

     mwedel at scruz.net

     ):
>

       Now that 1.0 is out, I'd like to get a little discussion/input on future

     >

       changes for crossfire (say 2.0).  

Change: Convert archfiles to xml

Details: The archfile parser is built into crossfire, this tight coupling
between the game-engine and the parser makes it inconvenient for external
programs from using the archfile without re-implementing the parser.

Pros: Using xml as the archfile format would allow the parser to be external to
the game engine, using a tool like Xerces we would have a c, perl and java
parser immediately.

An up to date handbook would be as simple as using cocoon, some stylesheets and
the archfiles for html/web presentation.

Consumption of the archfiles by other programs would be simplified.

Conversion to other formats (like PDF via FOP) would also be simplified.

Potential for new cool things, like syndication (ala my.netscape.com).

Because XML is self-describing, additions to the format would be easier.

Allows for localization/internationalization of the archfiles.

Using Xerces-J as a validating XML parser integration into a project was just a
couple of hours of work (I'll include the code in another post).

Conversion from the current style to XML is trivial.

Conversion from XML to the current style is also trivial.

Cons: New crossedit would be needed.

Lots of work to re-write the archfiles.

Zone builders would have to learn another archfile format.

Developers would have to learn another tool and set of APIs.

Xerces: 

     http://xml.apache.org

Cocoon: 

     http://xml.apache.org

FOP: 

     http://xml.apache.org

==================================================================
Change: Re-write crossedit in java

Details: Crossedit needs to be updated. Crossfire will only be as good as the
zones available to play. Right now crossedit is a chore to use. It does the
basic things as a level editor.

If the archfile are migrated to XML, a new level editor will be needed, and we
want to have a level editor that will work on as many platforms as possible.

Using Java gives us that cross-platform potential.

Pros: Crossedit needs a face-lift and better UI.

Java is cross-platform, so we have a bigger audience of potential zone builders.

OO-design should make the editor easier to extend.

Cons: Java is slow.

Swing can be a pain to work with.

More or less we throw out the old crossedit.

Zone builders will have to learn a new level editor.

Probably will have to support the current archfiles to help in migration to the
new level editor.

Developers may not have Java skill-set.

==================================================================
Change: Re-write client to use SDL

Details: There is the gcfclient, cfclient which run only under unix-like
operating systems. We have the java client, but it does not have a large user
base and only 1(?) developer. We have the dxclient which only runs under
windows.

Cfclient, gcfclient and the java client are open source.

The dxclient source code is currently not available.

The gcflient and cfclient share a common code base. The java client is a total
re-write and since we do not have access to the dxclient source code I cannot
comment.

We have multiple client for several platforms and poor code re-use amongst them. 
What we need is a client that can be easily ported to other platforms, has a
large set of common code, and is open source.

Writing a client using SDL will give the potential for a client that is easily
ported to Linux, MacOS and Win32, with access to Sound API, OpenGL, DMA, DGA,
and Full Screen X11.

Pros: A client that is portable.

A client that has support for a full range of multi-media capabilities.

Code re-use, code re-use, code re-use.

A client that has lots of eye candy to attrack new players.

Cons: Will probably re-implement most of MT's work.

Developers will have to learn a new set of APIs.

Developers may not have the skill-set to work with SDL.

Another level of indirection before you get to the hardware.

Should maybe look at a level editor written in SDL.

SDL: 

     http://www.libsdl.org/

==================================================================
Change: Support WorldForge Atlas protocol

Details: Seperation of the game-end from the client/server protocol. The
re-write of the archfiles into XML pulls out the parser from the game engine,
let's do the same for the client/server protocol.

No need to re-invent the wheel, we can use the WorldForge project as a template.

Pros: Protocol support en extension mechanism

Seperates the client/server protocol from the actual game engine.

Any Atlas protocol clients would become Crossfire clients.

The SDL crossfire client could be used to play on other Atlas protocol servers,
thus drawing more developers to the SDL crossfire client (and to the crossfire
servers).

Could have many different types of clients. Text, 3D, iso, etc..

Crossfire would be support an open source protocol for gaming, thus getting some
good PR on the WorldForge site.

Cons: Evolving protocol. As stated in the battleplan.

	"... it is unlikely that perfection can be achieved right off of the bat
	 - either in the protocol itself or in the various implementations of
	   it. ..."

Total re-work of client and server protocol.

Breaks old clients (unless server supports old protocol).

Main site for protocol

     http://www.worldforge.org/website/protocols/

RFC for Atlas specification

     http://bilbo.escapesystems.com/~aloril/atlas/spec/devel/index.html

Battleplan

     http://www.worldforge.org/website/protocols/atlas/battleplan

-- 
Bob Tanner <

     tanner at real-time.com

     >       | Phone : (952)943-8700

     http://www.mn-linux.org

                      | Fax   : (952)943-8500
Key fingerprint =  6C E9 51 4F D5 3E 4C 66 62 A9 10 E5 35 85 39 D9 