rails-devel — List for discussion of Rails development

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

On 7/1/06, John A. Tamplin <ja...@ja...> wrote:
> brett lentz wrote:
>
> >I agree.  I think we could do 1870 and maybe even 1856 without too
> >much trouble or worrying about deeper consequences.
> >
> >
> If you want games that are closer, there are a number of "1830 on a
> different map" games which would require fewer additions than either of
> these.  1889, 1899, 18NL, 18KAAS, 18AL, 18GA, 18TN and others would fit
> in this category.
>

All those will work.  Do you have time to work on the XML data for those?


> >Let's hold off on 18EU until we can do a complete implementation of the game.
> >
> >Ok, so let's prioritize things like this:
> >
> >1. Undo - this seems to be the most important and desired feature.
> >2. 1870 - because it's very close to 1830. Other than the privates and
> >splitting revenue we've already got almost all of the rules
> >differences, so I expect this will be quick to get fully working.
> >
> >
> Share price protection (and the resulting order shuffling), redeeming,
> and reissuing are all implemented?
>

Nope, those are the things we'd need to implement.

> >3. Save Games - while this is important, due to the relative ease of
> >playing a full game in a single sitting, I think we can push this off
> >a little bit.
> >
> >
> I would say route calculation should probably go before this, although
> depending on how #1 is done this may come almost for free.
>

We were waiting on route calculation for someone (you?) to port their
tile data over.



---Brett.

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

brett lentz wrote:

>I agree.  I think we could do 1870 and maybe even 1856 without too
>much trouble or worrying about deeper consequences.
>  
>
If you want games that are closer, there are a number of "1830 on a 
different map" games which would require fewer additions than either of 
these.  1889, 1899, 18NL, 18KAAS, 18AL, 18GA, 18TN and others would fit 
in this category.

>Let's hold off on 18EU until we can do a complete implementation of the game.
>
>Ok, so let's prioritize things like this:
>
>1. Undo - this seems to be the most important and desired feature.
>2. 1870 - because it's very close to 1830. Other than the privates and
>splitting revenue we've already got almost all of the rules
>differences, so I expect this will be quick to get fully working.
>  
>
Share price protection (and the resulting order shuffling), redeeming, 
and reissuing are all implemented?

>3. Save Games - while this is important, due to the relative ease of
>playing a full game in a single sitting, I think we can push this off
>a little bit.
>  
>
I would say route calculation should probably go before this, although 
depending on how #1 is done this may come almost for free.

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

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

On 7/1/06, Erik Vos <eri...@hc...> wrote:

> > Other than getting some work done for the future, I am not
> > sure how much
> > value there is an an implementation of 18EU that doesn't allow minor
> > conversion as that is the primary mechanism of the game.  I think it
> > would be better to implement other games completely that can be done
> > rather than spend time on a partial job, that may be wasted
> > anyway once
> > we get around to finishing it if the other parts change in
> > the meantime.
>
> This is my main concern about rushing the implementation of many
> games before the basics (Undo, Save and such) have been done.
>


I agree.  I think we could do 1870 and maybe even 1856 without too
much trouble or worrying about deeper consequences.

Let's hold off on 18EU until we can do a complete implementation of the game.

Ok, so let's prioritize things like this:

1. Undo - this seems to be the most important and desired feature.
2. 1870 - because it's very close to 1830. Other than the privates and
splitting revenue we've already got almost all of the rules
differences, so I expect this will be quick to get fully working.
3. Save Games - while this is important, due to the relative ease of
playing a full game in a single sitting, I think we can push this off
a little bit.


---Brett.

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] Rails-devel Digest, Vol 2, Issue 1

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

> >Much of 18EU can already be configured.
> >  
> >
> I forgot to mention the buying/selling of stock, as that is fairly 
> common in 18xx games besides 1830.  The initial offering is 
> held in the 
> company's treasury and pays dividends to the company.  It may buy or 
> sell its own stock during the OR, and stock in the pool doesn't pay 
> dividends.  There are some restrictions on selling stock as well.
> 
> >Such minors can already be configured, and work.
> >  
> >
> Where do you configure inability to lay green track?

That is not yet configurable.
 
> >If we agree that at least a partial 18EU implementation 
> would be nice to
> >have,
> >I'll be happy to start working on it. Don't hold your breath for the 
> >minor conversion, though.
> >  
> >
> Other than getting some work done for the future, I am not 
> sure how much 
> value there is an an implementation of 18EU that doesn't allow minor 
> conversion as that is the primary mechanism of the game.  I think it 
> would be better to implement other games completely that can be done 
> rather than spend time on a partial job, that may be wasted 
> anyway once 
> we get around to finishing it if the other parts change in 
> the meantime.

This is my main concern about rushing the implementation of many
games before the basics (Undo, Save and such) have been done.

Erik.

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

Erik Vos wrote:

>Much of 18EU can already be configured.
>  
>
I forgot to mention the buying/selling of stock, as that is fairly 
common in 18xx games besides 1830.  The initial offering is held in the 
company's treasury and pays dividends to the company.  It may buy or 
sell its own stock during the OR, and stock in the pool doesn't pay 
dividends.  There are some restrictions on selling stock as well.

>Such minors can already be configured, and work.
>  
>
Where do you configure inability to lay green track?

>If we agree that at least a partial 18EU implementation would be nice to
>have,
>I'll be happy to start working on it. Don't hold your breath for the 
>minor conversion, though.
>  
>
Other than getting some work done for the future, I am not sure how much 
value there is an an implementation of 18EU that doesn't allow minor 
conversion as that is the primary mechanism of the game.  I think it 
would be better to implement other games completely that can be done 
rather than spend time on a partial job, that may be wasted anyway once 
we get around to finishing it if the other parts change in the meantime.

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

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

> >Excellent ideas.  I know 18EU has been extremely popular, so it
> >certainly makes sense to include it sooner rather than later.   I've
> >only played it once, so I'm not familiar enough with how different it
> >is to those that I have played more frequently.

Much of 18EU can already be configured.

> >
> The rules are available at 
> http://www.deepthoughtgames.com/games/18EU/ 
> but here is a summary of differences:
> 
>     * There are no privates, but instead 15 minors.  The auction is a
>       bit unusual, but after that they operate as normal corporations
>       except for a different train limit, inability to lay 
> green tiles,
>       and they always split 50/50 with the owner (there are 
> no shares).

Such minors can already be configured, and work.
A new StartRound subclass should be developed to handle the auction.

>     * You can't start a corporation normally until the first 
> 5.  Before
>       then, you have to exchange a minor to start a new 
> company, and you
>       can exchange multiple minors for shares.  The company gets the
>       assets of any minors traded in, which means they can avoid going
>       backward the first time (usually).  You can choose any 
> corporation
>       available to start, and as it gets the tokens of the 
> minors traded
>       in that determines where it starts.

No exchange/merger mechanisms exist yet.
That would be a major addition.

>     * There are Pullman trains which can be bought, but can't run
>       separately from another train.  Instead, they increase the value
>       of another train's run.

No big deal.

>     * There are red-to-red bonuses.

We don't have route calculation yet, so this should be done by hand anyway.

If we agree that at least a partial 18EU implementation would be nice to
have,
I'll be happy to start working on it. Don't hold your breath for the 
minor conversion, though.

Erik.

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.

[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.

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

brett lentz wrote:

>>I would say one thing that is needed (at least something I couldn't find) is
>>an "undo" feature. Ideally this would be both buffered (undo the last n
>>actions in order, once per click) as well as some kind of manual correction
>>mode but the latter could probably be forgone.  I'd also like to throw in a
>>shameless plug for my favorite game 18EU but I understand the differences
>>there from 1830 are quite radical and may not make the most sense for the
>>next game.
>>    
>>
If the undo log replay is chosen for game save/restore, it is unlikely 
arbitrary edits would be allowed.  However, I don't think that should be 
a big deal as the idea is that the code would exactly support the rules 
of the game, so there shouldn't be a need to make arbitrary changes.

>Excellent ideas.  I know 18EU has been extremely popular, so it
>certainly makes sense to include it sooner rather than later.   I've
>only played it once, so I'm not familiar enough with how different it
>is to those that I have played more frequently.
>  
>
The rules are available at http://www.deepthoughtgames.com/games/18EU/ 
but here is a summary of differences:

    * There are no privates, but instead 15 minors.  The auction is a
      bit unusual, but after that they operate as normal corporations
      except for a different train limit, inability to lay green tiles,
      and they always split 50/50 with the owner (there are no shares).
    * You can't start a corporation normally until the first 5.  Before
      then, you have to exchange a minor to start a new company, and you
      can exchange multiple minors for shares.  The company gets the
      assets of any minors traded in, which means they can avoid going
      backward the first time (usually).  You can choose any corporation
      available to start, and as it gets the tokens of the minors traded
      in that determines where it starts.
    * There are Pullman trains which can be bought, but can't run
      separately from another train.  Instead, they increase the value
      of another train's run.
    * There are red-to-red bonuses.

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

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

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

On 7/1/06, Bill Skulley <bsk...@ho...> wrote:
> >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.
>
> Don't underestimate the amount of interest in what you are accomplishing
> here.  I am a longtime lurker (wishing I had the skills to contribute) and
> am much impressed by what you've gotten done in Version 1.0 (I've not gotten
> time to run a game all the way through but so far... wow!).
>

You already have plenty of skills if you're interested in
contributing. We need much more than just coders. There are things
like writing documentation, or even simply playtesting and reporting
any bugs you may find. Anyone can do these without any technical
ability.

I definitely didn't mean to imply that there wasn't anyone else
interested, but simply that only a small few have been at all vocal
about where they'd like to see this project going.  Despite being
project leader and guiding the project, I'm definitely interested in
hearing what others have to say, especially about how we prioritize
certain features.


> I would say one thing that is needed (at least something I couldn't find) is
> an "undo" feature. Ideally this would be both buffered (undo the last n
> actions in order, once per click) as well as some kind of manual correction
> mode but the latter could probably be forgone.  I'd also like to throw in a
> shameless plug for my favorite game 18EU but I understand the differences
> there from 1830 are quite radical and may not make the most sense for the
> next game.

Excellent ideas.  I know 18EU has been extremely popular, so it
certainly makes sense to include it sooner rather than later.   I've
only played it once, so I'm not familiar enough with how different it
is to those that I have played more frequently.

> In any case.... great work!
>

Thanks!


---Brett

Re: [Rails-devel] Rails-devel Digest, Vol 2, Issue 1

[Bill S. <bsk...@ho...>]

>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.

Don't underestimate the amount of interest in what you are accomplishing 
here.  I am a longtime lurker (wishing I had the skills to contribute) and 
am much impressed by what you've gotten done in Version 1.0 (I've not gotten 
time to run a game all the way through but so far... wow!).

I would say one thing that is needed (at least something I couldn't find) is 
an "undo" feature. Ideally this would be both buffered (undo the last n 
actions in order, once per click) as well as some kind of manual correction 
mode but the latter could probably be forgone.  I'd also like to throw in a 
shameless plug for my favorite game 18EU but I understand the differences 
there from 1830 are quite radical and may not make the most sense for the 
next game.

In any case.... great work!

Thanks
Bill

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.

[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...>]

> >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.

[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.

[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.

[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.

[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.

[Rails-devel] Version 1.0 released into the wild.

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

I've just posted the JAR file to SourceForge. It is currently
propagating out to the mirrors.

As soon as it's widely available, I'll make the announcement to the
Yahoo 18xx list.


I'd like to thank everyone for helping to getting us here.



---Brett.

Re: [Rails-devel] Game end

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

On 6/28/06, Erik Vos <eri...@hc...> wrote:
> >
> > > BTW I hate that long batik jars list.
> > >
> >
> >
> > I don't think you need all of them in the classpath right now. I think
> > we're only using the transcoder.
>
> Well, I tried a while ago, and got ClassNotFound exceptions
> until I had included all of them.
>
> What is your classpath then?
>

These are the only Batik classes that are in my classpath:

batik
batik-awt-util
batik-bridge
batik-dom
batik-ext
batik-gvt
batik-parser
batik-rasterizer
batik-script
batik-swing
batik-transcoder
batik-util

There's around 10 others that aren't currently necessary.


---Brett.

Re: [Rails-devel] Game end

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

> 
> > BTW I hate that long batik jars list.
> >
> 
> 
> I don't think you need all of them in the classpath right now. I think
> we're only using the transcoder.

Well, I tried a while ago, and got ClassNotFound exceptions
until I had included all of them.

What is your classpath then?

Erik.

Re: [Rails-devel] Game end

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

On 6/28/06, Erik Vos <eri...@hc...> wrote:

> BTW I hate that long batik jars list.
>


I don't think you need all of them in the classpath right now. I think
we're only using the transcoder.

---Brett.

Re: [Rails-devel] Game end

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

> Ok, so the bankruptcy code works great. Unfortunately, now I'm having
> difficulties making a JAR. It's giving "file not found" errors on all
> the tiles.
> 
> Can you see if you get the same problem on your end when you try
> running from a JAR?

No, it works, after I had updated my jardesc to include the tiles.svg
directory,
and added that endless list of batik jars to the classpath.

BTW I hate that long batik jars list.

Erik.

Re: [Rails-devel] Game end

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

> Ah ha!  Ok, I'll do some testing and, if everything works out, do a release.
>


Ok, so the bankruptcy code works great. Unfortunately, now I'm having
difficulties making a JAR. It's giving "file not found" errors on all
the tiles.

Can you see if you get the same problem on your end when you try
running from a JAR?

---Brett