rails-devel

[Rails-devel] Load/Save games.

[brett l. <wak...@gm...>]

I agree with Erik, I think Loading and Saving games ought to be the
next feature we add.

I suppose the big question is...  how?

I don't think we necessarily need to worry about people tampering with
the saved game files. Most anti-cheat measures are futile unless we
commit to providing constant updates to an anti-cheat system.

So, I think a saved game can just be an XML file that stores the state
of the game.

Due to our setup, we'll need to define saved game data specific to
each game. For example, 1856 needs to store amount of debt a company
has, while 1830 doesn't.

We're probably going to want to define a DTD for each game to provide
a template for saved game files of a particular game type.

Then, we can just build the saved game based on the DTD.


Thoughts?


---Brett.

Re: [Rails-devel] Load/Save games.

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

> I agree with Erik, I think Loading and Saving games ought to be the
> next feature we add.
> 
> I suppose the big question is...  how?
> 
> I don't think we necessarily need to worry about people tampering with
> the saved game files. Most anti-cheat measures are futile unless we
> commit to providing constant updates to an anti-cheat system.
> 
> So, I think a saved game can just be an XML file that stores the state
> of the game.
> 
> Due to our setup, we'll need to define saved game data specific to
> each game. For example, 1856 needs to store amount of debt a company
> has, while 1830 doesn't.
> 
> We're probably going to want to define a DTD for each game to provide
> a template for saved game files of a particular game type.
> 
> Then, we can just build the saved game based on the DTD.

I see two alternatives:

1. Serialize all classes that hold the current state.
I have no experience with serializing, so I don't know
if this really is a good idea.

2. Store the Undo stack.

The second option presupposes that we create a stack of atomic
actions, which can be played back (Undo) and forward (Redo) as
far as back to the start of the game (as you can do in
Lemmi's moderator). Loading a saved game then would amount to
ReDoing the whole stack (e.g. an XML file consisting of a sequence
of <action> tags).

The nice thing about this last option is that one solution can
provide for two needed features. But, again, I'm not sure if
this really is a good idea.

Not the least reason that I'm bringing forward these alternative
ideas is, that I think these are a lot less work ... for me ...

Erik.

Re: [Rails-devel] Load/Save games.

[brett l. <wak...@gm...>]

On 6/30/06, Erik Vos <eri...@hc...> wrote:
> I see two alternatives:
>
> 1. Serialize all classes that hold the current state.
> I have no experience with serializing, so I don't know
> if this really is a good idea.


This seems like a non-trivial amount of work, including reworking many
of our existing classes.


> 2. Store the Undo stack.
>
> The second option presupposes that we create a stack of atomic
> actions, which can be played back (Undo) and forward (Redo) as
> far as back to the start of the game (as you can do in
> Lemmi's moderator). Loading a saved game then would amount to
> ReDoing the whole stack (e.g. an XML file consisting of a sequence
> of <action> tags).
>
> The nice thing about this last option is that one solution can
> provide for two needed features. But, again, I'm not sure if
> this really is a good idea.
>

I agree, that Undo/Redo is a much needed feature. However, I don't
think it eliminates questions about how to store the data and defining
game-specific templates of what to store.

I think we're going to need a DTD (or similar template) to define the
syntax of the saved game file.  Having it hard-coded doesn't seem like
a wise idea.  Though, I certainly could be wrong here.

I am also concerned about the time it will take to load a saved game
if we're going to go with the 'replay all steps' model.  Perhaps we
should store both the state of the game when saved, and the list of
previous plays?  This would allow us to only need to reload the game
state while still having access to the previous actions for either
loading later or loading asynchronously.

What do you think of this?

Also, one other alternative is to allow undo/redo during a game, but
not save it to the file, and just decide that undo/redo after the
application closes is just simply not supported.

I suppose it really depends on how much effort we want to put into
this paticular feature. My initial inclination is to keep it simple
and expand on it later if there's demand for the additional abilities.

---Brett.

Re: [Rails-devel] Load/Save games.

[John A. T. <ja...@ja...>]

brett lentz wrote:

>This seems like a non-trivial amount of work, including reworking many
>of our existing classes.
>  
>
So would any other way of getting the state from a save file into the 
tree of objects.  You could probably do it with the least impact on the 
interface of the existing objects by creating a save state object and 
passing it down the tree to a restoreSave() member or similar, and each 
object would have to know enough to construct its child objects and then 
pass the saved object down to their restoreSave() member etc.  However, 
that is likely to be more work than simply making all of the classes 
important to the save state be serializable.

>I agree, that Undo/Redo is a much needed feature. However, I don't
>think it eliminates questions about how to store the data and defining
>game-specific templates of what to store.
>
>I think we're going to need a DTD (or similar template) to define the
>syntax of the saved game file.  Having it hard-coded doesn't seem like
>a wise idea.  Though, I certainly could be wrong here.
>
>I am also concerned about the time it will take to load a saved game
>if we're going to go with the 'replay all steps' model.  Perhaps we
>should store both the state of the game when saved, and the list of
>previous plays?  This would allow us to only need to reload the game
>state while still having access to the previous actions for either
>loading later or loading asynchronously.
>  
>
I agree that could be a problem, depending on how long it will take.

>What do you think of this?
>  
>
You still have the problem of getting the state from the file into the 
hierarchy of objects, and if you don't do it through a log replay 
mechanism then you need something like option 1 to be able to load the 
data into the objects.  Even in the case of the log replay 
implementation, you still have to expose connectivity to all these 
objects (or add pass-through calls to higher level objects) that know 
which child objects to pass the replay entry down to.

>Also, one other alternative is to allow undo/redo during a game, but
>not save it to the file, and just decide that undo/redo after the
>application closes is just simply not supported.
>  
>
I think you are missing his point -- it wasn't so much about preserving 
the undo history after a save, but rather using that to perform the 
save.  If you do the save by a different mechanism, then I agree it is 
not necessary to save the undo history (though it wouldn't be hard to do 
at that point, you just have to serialize the undo log objects).

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Load/Save games.

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

> >This seems like a non-trivial amount of work, including 
> reworking many
> >of our existing classes.
> >  
> >
> So would any other way of getting the state from a save file into the 
> tree of objects.  You could probably do it with the least 
> impact on the 
> interface of the existing objects by creating a save state object and 
> passing it down the tree to a restoreSave() member or 
> similar, and each 
> object would have to know enough to construct its child 
> objects and then 
> pass the saved object down to their restoreSave() member etc. 
>  However, 
> that is likely to be more work than simply making all of the classes 
> important to the save state be serializable.

That was indeed my point: serializing is a existing mechanism to save state.

I understand that serialization propagates automatically, as long as
contained objects are serializable too. But I don't know what happens if the

containment is circular, of which we have quite some cases.
Is Java smart enough to recognize that?
Easy enough to try out one of these days.
 
> >I agree, that Undo/Redo is a much needed feature. However, I don't
> >think it eliminates questions about how to store the data 
> and defining
> >game-specific templates of what to store.
> >
> >I think we're going to need a DTD (or similar template) to define the
> >syntax of the saved game file.  Having it hard-coded doesn't 
> seem like
> >a wise idea.  Though, I certainly could be wrong here.

Does having a DTD save any coding then? 
I'm not aware of that, but perhaps you know better?

> >I am also concerned about the time it will take to load a saved game
> >if we're going to go with the 'replay all steps' model.  Perhaps we
> >should store both the state of the game when saved, and the list of
> >previous plays?  This would allow us to only need to reload the game
> >state while still having access to the previous actions for either
> >loading later or loading asynchronously.
> >  
> >
> I agree that could be a problem, depending on how long it will take.
> 
> >What do you think of this?
> >  
> >
> You still have the problem of getting the state from the file 
> into the 
> hierarchy of objects, and if you don't do it through a log replay 
> mechanism then you need something like option 1 to be able to 
> load the 
> data into the objects.  Even in the case of the log replay 
> implementation, you still have to expose connectivity to all these 
> objects (or add pass-through calls to higher level objects) that know 
> which child objects to pass the replay entry down to.
> 
> >Also, one other alternative is to allow undo/redo during a game, but
> >not save it to the file, and just decide that undo/redo after the
> >application closes is just simply not supported.
> >  
> >
> I think you are missing his point -- it wasn't so much about 
> preserving 
> the undo history after a save, but rather using that to perform the 
> save.  If you do the save by a different mechanism, then I 
> agree it is 
> not necessary to save the undo history (though it wouldn't be 
> hard to do 
> at that point, you just have to serialize the undo log objects).

Exactly. 
Saving the undo would not be a goal, but a means to achieve reloading
cheaply.
But reloading this way might not be a pretty sight.

My (still vague and provisional) plan would be to start working on Undo,
trying to include Redo as well. If Redo works, we would have a 
potential save/reload mechanism. Would that not work or be too ugly,
then we could try serialization or XML.

Of course there is a lot more work to do (because of which I find assigning
version number 1.0 at this stage a bit overpromising):

- Implementation of the Route concept and all features that need it:
tile laying validation, revenue calculation, effect of tokens).

- Help (still very rudimentary).

- UI improvements.
I expect most user comments will relate to the UI.
And there are still glitches (the Game Status has started flickering again
in certain cases. I know it is caused by something I did recently, 
but I don't remember what that 'something' is....  Old age, I suppose).

- Client/server operation & Internet playability 
(I think the latter is more complex than the former,
because authentication and other safety measures come into view).

- Implementing other games.
For me, this would be the most interesting thing to work on,
and I can hardly wait to start implementing all games I have (quite a lot).
But I think that finalizing the base code for 1830 with all the
above extra features is more urgent now.

Erik.

Re: [Rails-devel] Load/Save games.

[brett l. <wak...@gm...>]

On 7/1/06, Erik Vos <eri...@hc...> wrote:
> > >This seems like a non-trivial amount of work, including
> > reworking many
> > >of our existing classes.
> > >
> > >
> > So would any other way of getting the state from a save file into the
> > tree of objects.  You could probably do it with the least
> > impact on the
> > interface of the existing objects by creating a save state object and
> > passing it down the tree to a restoreSave() member or
> > similar, and each
> > object would have to know enough to construct its child
> > objects and then
> > pass the saved object down to their restoreSave() member etc.
> >  However,
> > that is likely to be more work than simply making all of the classes
> > important to the save state be serializable.
>
> That was indeed my point: serializing is a existing mechanism to save state.
>
> I understand that serialization propagates automatically, as long as
> contained objects are serializable too. But I don't know what happens if the
>
> containment is circular, of which we have quite some cases.
> Is Java smart enough to recognize that?
> Easy enough to try out one of these days.
>


I'm going to need to read up on serialization. I know very little
about it, so I can't really make a good decision on whether we should
use it or not.


> > >I agree, that Undo/Redo is a much needed feature. However, I don't
> > >think it eliminates questions about how to store the data
> > and defining
> > >game-specific templates of what to store.
> > >
> > >I think we're going to need a DTD (or similar template) to define the
> > >syntax of the saved game file.  Having it hard-coded doesn't
> > seem like
> > >a wise idea.  Though, I certainly could be wrong here.
>
> Does having a DTD save any coding then?
> I'm not aware of that, but perhaps you know better?
>


A DTD defines all of the allowed syntax for a particular XML file.  It
serves as a guide for what tags and parameters are valid.

It might save work, but I not completely certain. One thing it does
afford is clarity in the format of the saved file.

> > >I am also concerned about the time it will take to load a saved game
> > >if we're going to go with the 'replay all steps' model.  Perhaps we
> > >should store both the state of the game when saved, and the list of
> > >previous plays?  This would allow us to only need to reload the game
> > >state while still having access to the previous actions for either
> > >loading later or loading asynchronously.
> > >
> > >
> > I agree that could be a problem, depending on how long it will take.
> >
> > >What do you think of this?
> > >
> > >
> > You still have the problem of getting the state from the file
> > into the
> > hierarchy of objects, and if you don't do it through a log replay
> > mechanism then you need something like option 1 to be able to
> > load the
> > data into the objects.  Even in the case of the log replay
> > implementation, you still have to expose connectivity to all these
> > objects (or add pass-through calls to higher level objects) that know
> > which child objects to pass the replay entry down to.
> >
> > >Also, one other alternative is to allow undo/redo during a game, but
> > >not save it to the file, and just decide that undo/redo after the
> > >application closes is just simply not supported.
> > >
> > >
> > I think you are missing his point -- it wasn't so much about
> > preserving
> > the undo history after a save, but rather using that to perform the
> > save.  If you do the save by a different mechanism, then I
> > agree it is
> > not necessary to save the undo history (though it wouldn't be
> > hard to do
> > at that point, you just have to serialize the undo log objects).
>
> Exactly.
> Saving the undo would not be a goal, but a means to achieve reloading
> cheaply.
> But reloading this way might not be a pretty sight.
>


That's what I'm worried about.


> My (still vague and provisional) plan would be to start working on Undo,
> trying to include Redo as well. If Redo works, we would have a
> potential save/reload mechanism. Would that not work or be too ugly,
> then we could try serialization or XML.
>
> Of course there is a lot more work to do (because of which I find assigning
> version number 1.0 at this stage a bit overpromising):
>

>From the beginning, I've said that 1.0 is simply working hotseat play
of 1830, which is what we've currently got.  Beyond that, it's just an
arbitrary number to tell us that we've hit our first major goal.

I'm not really invested in any particular versioning scheme. If
there's one you prefer, I'm willing to consider it.


> - Implementation of the Route concept and all features that need it:
> tile laying validation, revenue calculation, effect of tokens).
>
> - Help (still very rudimentary).
>
> - UI improvements.
> I expect most user comments will relate to the UI.
> And there are still glitches (the Game Status has started flickering again
> in certain cases. I know it is caused by something I did recently,
> but I don't remember what that 'something' is....  Old age, I suppose).
>
> - Client/server operation & Internet playability
> (I think the latter is more complex than the former,
> because authentication and other safety measures come into view).
>

This is going to be a big task even if we leave out the security
aspect.  I'm hoping we can find at least one more person to actively
to help out before we tackle this.

> - Implementing other games.
> For me, this would be the most interesting thing to work on,
> and I can hardly wait to start implementing all games I have (quite a lot).
> But I think that finalizing the base code for 1830 with all the
> above extra features is more urgent now.
>

If this is the most interesting to work on, then let's do this.  I
agree that these other features are important, and we'll deal with
them eventually. However, being that it's just you and me working on
this project, we are free to pursue the features that we're most
interested in.

Being that few people have expressed more than passing interest, we
are the only "customers" that we really need to worry about pleasing
at this point.

Let's just go ahead and start working on adding the next game.  Is
there one you had in mind?  I'm leaning towards 1870.  There's only a
handful of minor rules differences, so it shouldn't be a huge effort
now that we've got much of the basic infrastructure built.


---Brett.

Re: [Rails-devel] Load/Save games.

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

 
> >From the beginning, I've said that 1.0 is simply working hotseat play
> of 1830, which is what we've currently got.  Beyond that, it's just an
> arbitrary number to tell us that we've hit our first major goal.
> 
> I'm not really invested in any particular versioning scheme. If
> there's one you prefer, I'm willing to consider it.
 
I'm of the school that starts with 0.1 and reserves 1.0 for something
that is pretty final, but in this case we will never have a really
finished product (if only because new games keep being published)
so the assignment of 1.0 is arbitrary anyway. My preference would
have been to give 1.0 to a version that at least includes Routes
(and all that) and better Help. But I don't really mind much about
starting at 1.0.

I would propose to make a distinction between major upgrades (1.1)
and minor changes (1.0.1), the latter for instance applying to a new
version in which Alessandro's issue has been fixed (payout for shares in
IPO).
 
> > - Implementation of the Route concept and all features that need it:
> > tile laying validation, revenue calculation, effect of tokens).
> >
> > - Help (still very rudimentary).
> >
> > - UI improvements.
> > I expect most user comments will relate to the UI.
> > And there are still glitches (the Game Status has started 
> flickering again
> > in certain cases. I know it is caused by something I did recently,
> > but I don't remember what that 'something' is....  Old age, 
> I suppose).
> >
> > - Client/server operation & Internet playability
> > (I think the latter is more complex than the former,
> > because authentication and other safety measures come into view).
> >
> 
> This is going to be a big task even if we leave out the security
> aspect.  I'm hoping we can find at least one more person to actively
> to help out before we tackle this.
> 
> > - Implementing other games.
> > For me, this would be the most interesting thing to work on,
> > and I can hardly wait to start implementing all games I 
> have (quite a lot).
> > But I think that finalizing the base code for 1830 with all the
> > above extra features is more urgent now.
> >
> 
> If this is the most interesting to work on, then let's do this.  I
> agree that these other features are important, and we'll deal with
> them eventually. However, being that it's just you and me working on
> this project, we are free to pursue the features that we're most
> interested in.
> 
> Being that few people have expressed more than passing interest, we
> are the only "customers" that we really need to worry about pleasing
> at this point.
> 
> Let's just go ahead and start working on adding the next game.  Is
> there one you had in mind?  I'm leaning towards 1870.  There's only a
> handful of minor rules differences, so it shouldn't be a huge effort
> now that we've got much of the basic infrastructure built.

Well, the first requests already have arrived: Undo and 18EU 
(one of my favourite games too).

I'll think about it. Perhaps we can follow a two-track approach
(pun intended): gradually adding game features, most of which should
not take to much work, and starting to work (or at least think about) 
basic aids like Undo (which I consider highest priority indeed), 
which will need a lot more work (or so I expect).

Erik.

Re: [Rails-devel] Load/Save games.

[brett l. <wak...@gm...>]

On 7/1/06, Erik Vos <eri...@hc...> wrote:
>
> > >From the beginning, I've said that 1.0 is simply working hotseat play
> > of 1830, which is what we've currently got.  Beyond that, it's just an
> > arbitrary number to tell us that we've hit our first major goal.
> >
> > I'm not really invested in any particular versioning scheme. If
> > there's one you prefer, I'm willing to consider it.
>
> I'm of the school that starts with 0.1 and reserves 1.0 for something
> that is pretty final, but in this case we will never have a really
> finished product (if only because new games keep being published)
> so the assignment of 1.0 is arbitrary anyway. My preference would
> have been to give 1.0 to a version that at least includes Routes
> (and all that) and better Help. But I don't really mind much about
> starting at 1.0.
>
> I would propose to make a distinction between major upgrades (1.1)
> and minor changes (1.0.1), the latter for instance applying to a new
> version in which Alessandro's issue has been fixed (payout for shares in
> IPO).
>

I agree.


> > > - Implementation of the Route concept and all features that need it:
> > > tile laying validation, revenue calculation, effect of tokens).
> > >
> > > - Help (still very rudimentary).
> > >
> > > - UI improvements.
> > > I expect most user comments will relate to the UI.
> > > And there are still glitches (the Game Status has started
> > flickering again
> > > in certain cases. I know it is caused by something I did recently,
> > > but I don't remember what that 'something' is....  Old age,
> > I suppose).
> > >
> > > - Client/server operation & Internet playability
> > > (I think the latter is more complex than the former,
> > > because authentication and other safety measures come into view).
> > >
> >
> > This is going to be a big task even if we leave out the security
> > aspect.  I'm hoping we can find at least one more person to actively
> > to help out before we tackle this.
> >
> > > - Implementing other games.
> > > For me, this would be the most interesting thing to work on,
> > > and I can hardly wait to start implementing all games I
> > have (quite a lot).
> > > But I think that finalizing the base code for 1830 with all the
> > > above extra features is more urgent now.
> > >
> >
> > If this is the most interesting to work on, then let's do this.  I
> > agree that these other features are important, and we'll deal with
> > them eventually. However, being that it's just you and me working on
> > this project, we are free to pursue the features that we're most
> > interested in.
> >
> > Being that few people have expressed more than passing interest, we
> > are the only "customers" that we really need to worry about pleasing
> > at this point.
> >
> > Let's just go ahead and start working on adding the next game.  Is
> > there one you had in mind?  I'm leaning towards 1870.  There's only a
> > handful of minor rules differences, so it shouldn't be a huge effort
> > now that we've got much of the basic infrastructure built.
>
> Well, the first requests already have arrived: Undo and 18EU
> (one of my favourite games too).
>
> I'll think about it. Perhaps we can follow a two-track approach
> (pun intended): gradually adding game features, most of which should
> not take to much work, and starting to work (or at least think about)
> basic aids like Undo (which I consider highest priority indeed),
> which will need a lot more work (or so I expect).
>

Sounds good.  We've more or less been following this kind of approach
anyway, being that you and I have almost always been working on
separate sections of the code.

---Brett.

Re: [Rails-devel] Load/Save games.

[John A. T. <ja...@ja...>]

Erik Vos wrote:

>I understand that serialization propagates automatically, as long as
>contained objects are serializable too. But I don't know what happens if the
>
>containment is circular, of which we have quite some cases.
>Is Java smart enough to recognize that?
>Easy enough to try out one of these days.
>  
>
All of the standard serializable containers deal with circular 
references.  However, if you built your own or especially if you built a 
tree of objects that may be circular (such as token connectivity), then 
the container object needs to be smart about serializing its children.

Also, the nasty bit of serialization is that you will frequently have 
data in child objects that you don't want to save, such as a cache.  
That means you have to write your own serializer routines and properly 
serialize the right children, and then rebuild the cache when the object 
is recreated from the serialized stream.  In my experience, only the 
most trivial object hierarchies don't have to explicitly be told about 
serialization (at least for the composite objects).

>Does having a DTD save any coding then? 
>I'm not aware of that, but perhaps you know better?
>  
>
It seems to me the value of a DTD is for interoperability with other 
programs reading the XML file.  In this case, it doesn't seem reasonable 
to think there will general value in having other programs read a Rails 
save file.  Not to mention that if the serialize route is chosen the 
output won't be XML anyway.

>Exactly. 
>Saving the undo would not be a goal, but a means to achieve reloading
>cheaply.
>But reloading this way might not be a pretty sight.
>  
>
I would think you would just disable display updates until the log 
replay completes, or at least those that reference the models being built.

>My (still vague and provisional) plan would be to start working on Undo,
>trying to include Redo as well. If Redo works, we would have a 
>potential save/reload mechanism. Would that not work or be too ugly,
>then we could try serialization or XML.
>
>Of course there is a lot more work to do (because of which I find assigning
>version number 1.0 at this stage a bit overpromising):
>
>- Implementation of the Route concept and all features that need it:
>tile laying validation, revenue calculation, effect of tokens).
>
>- Help (still very rudimentary).
>
>- UI improvements.
>I expect most user comments will relate to the UI.
>And there are still glitches (the Game Status has started flickering again
>in certain cases. I know it is caused by something I did recently, 
>but I don't remember what that 'something' is....  Old age, I suppose).
>
>- Client/server operation & Internet playability 
>(I think the latter is more complex than the former,
>because authentication and other safety measures come into view).
>  
>
Even if you are playing it locally, the safety measures ought to be 
considered anyway, so to my mind these are exactly equivalent other than 
perhaps some lobby or opponent finder function you might want for the 
full net-enabled version.  The thought that some network-accessible 
program is only going to be used locally and therefore security isn't 
designed in from the beginning is why we have so many MS security holes.

>- Implementing other games.
>For me, this would be the most interesting thing to work on,
>and I can hardly wait to start implementing all games I have (quite a lot).
>But I think that finalizing the base code for 1830 with all the
>above extra features is more urgent now.
>  
>
I suspect this will turn out to be quite a bit of work, since discussion 
of features needed in other games was tabled until after 1830 was 
complete.  I believe you will find that many of them will require 
significant re-factoring of classes to get general functionality for the 
other games.  Of course, the closer they are to 1830 the less work it 
will be to get them working -- for example, 1889 has different companies 
with some special private abilities, a different map, 50% to float, and 
diesels can get a higher off-board area -- other than that it is the 
same as 1830.

-- 
John A. Tamplin					ja...@ja...
770/436-5387 HOME				4116 Manson Ave
                		 		Smyrna, GA  30082-3723

Re: [Rails-devel] Load/Save games.

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

> Also, the nasty bit of serialization is that you will frequently have 
> data in child objects that you don't want to save, such as a cache.  
> That means you have to write your own serializer routines and 
> properly 
> serialize the right children, and then rebuild the cache when 
> the object 
> is recreated from the serialized stream.  

Yes, I expected so.

> >But reloading this way might not be a pretty sight.
> >  
> >
> I would think you would just disable display updates until the log 
> replay completes, or at least those that reference the models 
> being built.

Yes.
 
> >- Implementing other games.
> >For me, this would be the most interesting thing to work on,
> >and I can hardly wait to start implementing all games I have 
> (quite a lot).
> >But I think that finalizing the base code for 1830 with all the
> >above extra features is more urgent now.
> >  
> >
> I suspect this will turn out to be quite a bit of work, since 
> discussion 
> of features needed in other games was tabled until after 1830 was 
> complete.  I believe you will find that many of them will require 
> significant re-factoring of classes to get general 
> functionality for the 
> other games.  Of course, the closer they are to 1830 the less work it 
> will be to get them working -- for example, 1889 has 
> different companies 
> with some special private abilities, a different map, 50% to 
> float, and 
> diesels can get a higher off-board area -- other than that it is the 
> same as 1830.

In the early stages I have tried to look forward and include features
of other games as well, or at least keep objects as generic as possible. 
Quite a number of non-1830 features are already configurable, though no
other game is complete yet.
For instance, the 1870 ledge should already work, as well as the 1835 minors

(except the Pruissian conversion). I've also implemented three 1835 start
round
variants (though the current UI only offers the standard one - to be done!).

Much extra work will of course be needed on new mechanisms, such as special 
private properties/special tokens, mergers, connection runs etc.

Erik.