[FreeCiv-Java] Re: FreeCiv-Java proposal

[Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx>]

On 27 Oct 1998, John Goerzen wrote:

> Esben Haabendal Soerensen <ehs@xxxxxxxxxxxxxx> writes:
> 
> > > least) two threads implicitly: the GUI thread and the thread for
> > > everything else.  It has this without you creating any thread.
> > 
> > The word I focus on most in the above is "implicitly".  The most
> > efficient way to make code harder to understand is to do to much
> > implicit.  This is true on the syntax level (I love making Perl code
> > imposible for other to read :-) ) but even more true on the design
> > level.  The more of the concepts of the design that are made in an
> > explicit way the more easier the complete design is to grasp.
> 
> You're looking at this from a bit of a different perspective than I
> am.  I do come from different programming languages where you have to
> worry about these things.
> 
> The Java Way is that you don't worry about the GUI.  You tell it to do 
> something and it does it.  It automatically is around to wait for
> actions from the user, repaint things, etc.  (This is even more true
> in JFC/Swing).  It happens to use a thread to accomplish this, but
> adding an additional thread for everything non-GUI will only add
> complexity.

I don't understand you here.
I know that JFC/Swing uses a thread (or several..) to handle things
such as listening to user input and doing repaint of windows when
overlapped.
But this does not mean that you should not use threads for everything
else your program has to do.  Java has made thread programming
very easy, at least compared to what I other languages, and I happen
to think you end up making your program more complex by NOT adding
the needed threads.  Using threads is a very handy tool to handle
complex problems where you have several paralellel things going on.

Face it.  Multithreaded programming is the way of the future ;-)

> > And we seem to generally agree about how working of the design
> > have to be, we just need to decide how to actually do it.
> 
> Yes.

Great :-)

> > Take the network listener thread I have mentioned.  It is of-course
> > true that in your current code there is a thread dedicated for
> > that, namely the thread that started the main() method and
> > settles in the while(true) loop.  I would prefer to let the main()
> > method initiate any nescesary Thread classes and then finish.
> > I prefer to think of the main() method as a bootstrap method.
> 
> There's no real problem moving the while() loop elsewhere.  There's
> no terribly good reason one way or the other regarding whether or not
> main() should be allowed to exit before the program does.  In some of
> my programs, it does; in others, it doesn't.

Well then I happen to be more consistent :-)  I always (except for
very small programs perhaps) the actual tasks (call them processes or
threads) to actual Threads.  This is my way of making the number of
threads and the nature of what they have to do more explicit rather
than going the implicit way.
The end result might be the same, of-course.

> > > (ie, the client receives a packet from the server saying what the
> > > timeout is, and then displays a counter and keeps it updated itself)
> > 
> > Ahh, now I see what you mean.  I need to get one thing clear (having
> > no experience in the freeciv code):  Does the server send a packet
> > when the timeout period has run out ?
> 
> No.  The only thing the server ever does with the timeout is inform
> the client when the timeout changes (when the server-op sets it to a
> different value, not each second).  Hence my assertion that the
> timeout is basically a GUI-only thing; only one packet is received and 
> nothing more for potentially hundreds of turns.

So this is the reason for the timeout in the current client being
so unprecise :-)  I often (on my slow computer) experience that my
counter only reaches 2 - 4 when the actual timeout happens...

> > Let's do some coding!! :-)
> 
> OK!
> 
> > And what about this:
> >   Make a freeciv java-server and a freeciv applet-client !
> 
> A java server would certainly be interesting, but not something I have 
> a particular interest in at this time.  (Perhaps after a java-client
> is working though...)

I could not agree more!  Let us make this client work before even
considering whether to make a java-server.

> >   Then when you start the java-server anyone with a browser
> >   can play :-))
> 
> It actually won't be hard to make a Java client runnable in a browser, 
> once browsers appear that support JDK1.2.  Otherwise, we have to ship
> the swing.jar file along with the rest of the program, and that's not
> pleasant (swing.jar is huge).

So lets cross fingers, and hope that both MS IE and Netscape will support
JDK 1.2 soon :-)

> > > I'm not quite following.  If there is a chat window, it's not directly 
> > > between clients, but between one client and the server (the server
> > > passes on the mssage).
> > 
> > True as it is now.  But wouldn't it be cool to be able to open a
> > chat window with only selected players being able to see the messages ?
> > It would make it to have aliances with more than two players.
> 
> Yes.  This code already exists in freeciv, just not with a separate
> window.  More like /msg in IRC.

I know that, but it is not excactly what I have in mind.  Think of the
communication you need when making a 3-player alliance.
It would be nice to be able to be able to send a message to both
your allies in one go without anyone else seing this.
And another thing that would be nice was to have the chat messages
seperated from the server generated messages.  And this we could easily
do with the current server :-)

> > > An AI is no different than a normal client.
> > 
> > Well.  In the end there is a big difference.  It would be stupid
> > to talk to an AI, and it would therefore not make any sense to
> > open a chat window to any AI players
> 
> Not necessarily.  Remember that it is possible for there to be a
> client connected to an AI player, and a live human at that client.
> The human wouldn't have much control over what happens, since the AI
> does all his work at the start of the turn.  However, people often do
> this to learn and watch the AI, or to just be part of the game and be
> able to chat with others.

Sure, but my point is still somewhat the same.  No point in trying
to negoiate an alliance with an AI.  It will not work even if a human
is watching him ;-)

> A conventional AI has no corresponding client connection, and so looks 
> to other clients just like a normal connectionless player, and we can
> assume that it accepts no messages.
> 
> > True.  But my point is that en an abstract way there is a big difference
> > between AI and human players.  When I play I handle AI players and human
> 
> On the server, perhaps, but not even much there.  The main difference
> is that if the player is an AI, at the start of a turn, the server
> calls a function that makes the moves for the AI player.  That's about 
> it.

Yes, but I am thinking in a more abstract way.  Seen from the player's
(not the coder's) viewpoint there is a big difference between AI and
human players.  When doing the OOD you basically wants to make your
model represent the users view of the world as much as possible.  So
if the user sees a big difference between AI and human players so
should we.  And by doing this we might see some opportunities later
on for great improvements of the gameplay.
Anyway it would not be much work to do this, so why not ?

> > humans the discussion should be if we should make the distinction by
> > using two different classes (with a common superclass) or just use an
> > attribute in the Player class.
> 
> An attribute is fine.

An attribute is fine with me to.  But derived classes are better.
As you might have guessed I am very fond of the OO way to do thing :-)

> > I would go for the first, as this would make it possible (and easy) to
> > add methods to the human Player class that makes no sense for an AI
> > controlled player (such as opening a player specific chat window).
> 
> But as I've said, it can make sense :-)

It depends.  First of all it was only one thing we discussed.  It should
be possible by time to think of even more things to do between human
players, and these might not make any sense at all with AI controlled
players.
And I don't think it is very important that a human player might
be watching the AI.  He must be allowed to watch, and chat with
the general interface, but no more.  He does not need to have all
the extra facilities that we hopefully will come up with, as he
is not playing.

And we should try to see this in a perspective.  There have been this
discussion about allowing multiple players to play together with
a shared race.  And the best way to prepare for such a thing is
to make our OO model as close to the "real world" as possible.
By making shortcuts in your OO model you might win a small decrease
in complexity but you will loose a great deal in the flexibility
to implement future interesting ideas as easy as possible.  By
doing the design "the right way" you try to prepare for the unknown.
Preparing the design (and thereby code) to be make it easy to
implement the next "great idea" somebody comes up with. And the
next one, and the next one... 
Only imagination sets the limits :-)

> > But changing the way the threads should not make much difference
> > regarding to speed.  By making a network specific thread instead
> > of just using the main() thread would not make any difference in
> > speed, but would IMHO improve the clarity of the design.
> 
> I have nothing against moving code out of main() into somewhere else.
> Perhaps it would be possible to do this now, and if it becomes
> necessary to add threads later, they can be added then?

I have already done the this.  I just moved the listening code
into a method called run() in the SocketListener class.  All their
needs to be done is to do this
  new Thread(civsocket);
and we are there :-)

> > In the end there will probably only be one realy sensible way to
> > do this thread thing.  I can not foresee if we are going to do this
> > different at some point, but at the moment we seem to agree on
> >  * a thread to handle the network listening (be it main() or some other)
> >  * a thread for handling the gui (the internal swing threads...)
> > 
> > But I would prefer to add one more.
> >  * a gui update thread
> > 
> > This could be done just by letting the network listening thread call
> > some method which then does this.  But this would change the task of
> > the network thread to also handle all the gui updating.  Although
> > I aggree that the scheduling of Java (at least with green_threads) is
> > extremely poor, why not make a design where the network thread just
> > passes the messages (packets) on, and then lets a dedicated gui update
> > thread handle all the updating of the threads.  This seems to me
> > to be the right thing to do.
> 
> This won't help things much, because most if not all packets must be
> processed in sequential order; processing them out of order doesn't
> help.

Which is why you have FIFO queues.

> > And if we can make this multie-threaded design work the result can
> > be much more effective than the other basically single-threaded
> > design (ignoreing the internal gui thread).
> 
> I would say to not add extra threads now, but with a good design as
> you've put forth, it should not be difficult to do so later.

I have already added the network thread....  But then again I have
"removed" the main() thread.
The gui update thread we might just wait and see when we get there.
Ok ?

> 
> > 
> > No wait.  Are you going to make a freeciv-java list ?  I would like
> > this.  Even if we are only two the mail-archive would be great :-)
> 
> OK, I made one.  freeciv-java@xxxxxxxxxxx (aka
> freeciv-java@xxxxxxxxxxxx of course).  It'll have an archive in a few
> minutes.  I am not announcing this publicly for a few days (to the
> other freeciv lists anyway).  I shall make a public announcement in
> due time.
> 
> subscribe, of course, is done by writing to majordomo@xxxxxxxxxxx and
> in the body type "subscribe freeciv-java".

Great!  I have sent in my subscribtion, but have not got a reply
yet.
I will send a CC anyway.

-- 
/Esben  (bart@xxxxxxxxxxxxxx)

You want it in one line?  Does it have to fit in 80 columns?   :-)
             -- Larry Wall in <7349@xxxxxxxxxxxxxxxxxxxxxxx>