Complete.Org: Mailing Lists: Archives: freeciv-dev: November 2000:
[Freeciv-Dev] Windows COM client
Home

[Freeciv-Dev] Windows COM client

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Freeciv dev" <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Windows COM client
From: "Arlo Belshee" <arlo.belshee@xxxxxxxxxxxxxx>
Date: Tue, 21 Nov 2000 08:30:14 -0800

Hello all.

Before I get started, I just want to say that I've been a long-time observer
of the project. I am a huge Civ fan, and have toyed with creating my own
empire builder from scratch on several occasions. I really like what you've
done here, and intend to contribute to the project.

I am looking to create (another) native Windows port of FreeCiv (client
first). I have been meaning to do this for about 18 months now, but have
been continually stopped by one thing: the current codebase. In particular,
the current code is a massive wall of plain C, without obvious components or
structure: there is no way to break it down into digestable pieces. When I
wanted to figure out the networking protocol between client and server (26
months ago, when I was looking into creating a client-side AI), I ended up
having to understand the whole system (much of which I didn't intend to use)
and gave up in disgust without ever getting started.

There is a structure which would make all of this much simpler: a component
architecture. If I could understand (or better yet not understand and just
reuse) the networking code without having to look through any of the other
code, I could have made that client-side AI work two years ago. I still have
a client-side AI in pieces that I could never get to talk to the system so
didn't bother finishing.

So now I would like to program the Windows client. For this, I'd like to use
a simple multi-threaded component architecture, using Visual Basic for the
GUI, C++ to write certain GUI components (like the map and backside
drawing), and C++ for most of the back-end. However, this is a great
division from the direction dictated by the current codebase. My intention
would be to program something entirely new that integrates with existin
systems but is more flexible and extensible. I don't know this audience: are
you receptive to such a change in direction? This definately goes against
the way that things have been done, so what are the reasons that you used to
choose to do it this way? I can construct several arguments for an alternate
approach, and would be happy to if asked (some interesting new directions
for the project); I want to make sure that we choose to do this correctly.

That said, I eagerly await your feedback.

Arlo




[Prev in Thread] Current Thread [Next in Thread]