Re: [Rails-devel] Starting on a client/server

[Erik V. <eri...@hc...>]

> > Perhaps you should create a new branch in CVS for it?
> >
> 
> Once it's in CVS, it can't be deleted. I don't want to check it into
> CVS only to scrap it entirely or need to completely redesign it.
> 
> I'd prefer to keep our CVS tree populated with active code, rather
> than my random ideas. ;-)

I'm not familiar with CVS branching, but I thought it would allow us to work
on different versions in parallel, of course with the ultimate goal of
merging those versions in a later stage. Never mind.
 
> >> So, you're welcome to check the current state of things here:
> >> http://github.com/wakko666/18xx/tree/master
> >
> > I have downloaded it and tried to run client and server, but
> > 1. The compiler reports an error in the client:
> > The method actionPerformed(ActionEvent) of type 
> NetworkClientWindow must
> > override a superclass method    net/sourceforge/rails/client/ui
> > NetworkClientWindow.java        line 77 1225706052046   65163
> 
> Hmm...  I'll have to double-check that all of my changes were merged
> with the last push. For now, removing the @override decorator should
> remove the issue.
> 
> > 2. I can't find a Server main method.
> >
> 
> There is no server main method. Right now, when you hit the "new game"
> button, it launches both server and client (which currently don't do
> much of anything). 

OK, it now works.

> I haven't yet added in the interface for starting
> a standalone server. I haven't quite decided what that interface will
> look like. I'm debating either a command-line interface, or adding a
> button onto the client start-up interface.

As I'm currently always running from Eclipse, just a main() method would do.
Outside an IDE you'll need some kind of a command-line interface anyway.
Ultimately I would package it in two separate (executable) jars.
 
> >> There's some fairly major reorganization that I've done, and I've
> >> totally refactored the XML parsing.
> >
> > Can you elaborate a bit on how you see XML parsing be done your way,
> > and what the perceived benefits are? What exactly was wrong with it?
> >
> > It strikes me that the XMLParser API has the dreaded 
> Document, Element and
> > NodeList
> > types that I have so carefully hidden inside Tag last year...
> > Will XMLParser replace Tag, or will the former just be used 
> by the latter?
> > In any case, GameInfoParser isn't using Tag.
> 
> Correct. There's nothing wrong with abstracting away the details of
> the XML DOM, per se. Tag does a fine job of that.
> 
> I don't think our current method is doing anything wrong. Mainly, I
> wanted to see what it looked like to collect all of the
> configureFromXML methods into one single parser structure.
> 
> The one benefit that this different method adds, is that we don't have
> to wait until we initialize a specific game object in order to parse
> the XML for that object. This provides access to that information to
> things outside of that specific game object. This will avoid similar
> issues like we had adding in variants and game options.

The only thing is, that then in some cases the XML must be interpreted to
know which game-specific XMLParser class must parse some part of it. 
 
> At this point, I would consider this experimenting with a different
> method for code organization. I'm happy to scrap it to retain the
> existing methods if it doesn't provide any real benefits, or has some
> obvious problems.

OK. I'm not too happy with the larger number of classes we will have, but
I'll drop that comment if definite benefits show up.


I actually see one potential benefit, although I'm not sure if you will
judge it as that. Equally well, it might just be one of the goals you are
aiming for.

As I think I have explained before: I want to get rid of the many static
methods in various classes that return non-static and game-dependent
information. Bank.format() is an obvious point in case. The reason is, that
when the client/server split is complete, the server should be able to
accomodate multiple simultaneous games (at least potentially).

These static methods are currently needed to give all kinds of object access
to properties of "remote" objects: objects that are not directly related to
it. Ways out of this problem include:

1. So far I have been moving towards making all these objects directly or
indirectly known to GameManager, and passing along the GameManager object to
all places where such access is needed. I think this is a dead end: there
are too many different objects around, and putting a GameManager reference
into all of them looks ugly to me.

2. We could try to make all relevant classes a subclass of one common class
(call it GameObject extends Object), and putting the GameManager reference
into GameObject. That would fix the problem in one fell swoop, but I'm not
sure if we wouldn't run into multiple inheritance problems; this need be
checked, but I think not.

3. The common GameManager reference could also be put into XMLParser, and
then all objects that have an XMLParser companion would have easy access to
it. But that would leave out those objects that do not parse XML, and I
think we have some of these as well.

Actually, option 2 looks best to me, if there are no other top classes
getting in the way. To be honest, this idea only occurred to me when
thinking about my previous post in this thread.

> Well, I don't know of any specific things in the game engine that need
> reorganizing. I know that when we talked about this last, you
> mentioned that you had wanted to take a different approach on some
> things.

I only meant, that I would have started bottom-up by gradually loosening the
ties between client and server code until we have one class where all
messages would be channeled through, and then insert the communications
channel there. Your approach is top-down. Perhaps we need both: yours for
the framework, mine for the details, but we'll see.

Erik.