Re: [Rails-devel] Play by email

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

It is perhaps worth noting, that saved game files currently do not contain
the current game state but the sequence of player actions. When a game is
reloaded, it is effectively replayed (without display). This was the easiest
way to implement Save/Load.
I'm not saying that it is impossible to compose a game state: it's the total
of all objects derived from the State class (plus a few more, like the
Players and the game options chosen). But nothing is yet keeping track of
what State objects exist.

Erik.

> -----Original Message-----
> From: brett lentz [mailto:wak...@gm...] 
> Sent: Friday 28 November 2008 20:37
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Play by email
> 
> On Thu, Nov 27, 2008 at 8:44 PM, Dave Mitton <da...@mi...> wrote:
> > Hmm... somehow I broke a filter and these messages were landing in
> > the wrong folder...
> >
> > On 11/25/2008 01:19 PM, brett lentz wrote:
> >>On Mon, Nov 24, 2008 at 6:05 PM, Dave Mitton 
> <da...@mi...> wrote:
> >> > Oh... I don't know about that.
> >> >
> >> > It's not jumping ahead a turn, it would be the ability to
> >> retroactively change
> >> > a turn or an asset that would bother me.  "I should have 
> bought that
> >> > last turn..."
> >>
> >>Until we implement an actual PBEM facility, the undo feature allows
> >>you to do this.
> >>
> >> > I would feel more comfortable in this kind of dynamic if the game
> >> generated a
> >> > crypto hash of the game state and made it visible to all players
> >> in the report.
> >> > And then it should be checked on subsequent turns so 
> that everything
> >> > was consistent with what was before.
> >> >
> >>
> >>
> >>What stops someone from generating that hash after they've saved a
> >>bogus game state?
> >
> > The hash would be generated in the log record between every turn.
> > The hash would reflect the game state, and re-entering the 
> same moves
> > should generate the same hash.
> >
> >
> >>Being an open-source project, there's nothing that prevents someone
> >>from compiling and using their own modified version of the game that
> >>generates correct checksums for invalid data. Being a small project,
> >>we simply don't have anyone volunteering to implement and maintain
> >>additional security mechanisms.
> >
> > I don't think it's really that hard, but I'm just talking 
> aloud here.
> > Indeed the mechanism should not care "how" the move got 
> entered, just
> > that the state of the game is "checksumed" if you will in a 
> manner that is
> > easy to verify and re-check after the fact.
> >
> >
> >>Further, we let the user manually input the value of their 
> train runs.
> >>Not only is this error prone, but it is an easy way for someone to
> >>accidentally give themselves an invalid amount of money. In my
> >>opinion, having someone getting patches in to implement automated
> >>route calculation will reduce a major potential source of 
> error and/or
> >>cheating (depending on your perspective).
> >
> > Another user reality that I came to quickly is that you will have to
> > correct or have users correct their moves.  People will screw up,
> > particularly if they don't have people looking over their shoulder
> > until the move is posting.   An Undo facility is necessary.
> > People make mistakes and I don't expect the game to get the rules
> > exactly correct.
> > Even if does, there will be times to override.
> >
> 
> I'm not sure if we're really understanding each other here.
> 
> I'm not arguing for removing the undo capability.  I'm saying that
> until we automatically calculate the value of the routes, giving the
> user the ability to manually input the value of the route is a far
> greater source of potential exploitation.
> 
> >
> >>I really don't think this should be a big concern. The nice thing
> >>about implementing a board game is that everything the app 
> does can be
> >>done by hand. If you want to validate that the calculations are
> >>correct, the math is fairly basic and well-known. It should 
> be trivial
> >>to find out if something isn't right.
> >
> > The math can be correct and still things go wrong.
> >
> 
> Like what?  I can't really think of anything that isn't easy to
> manually verify. We _are_ talking about a boardgame, after all.
> 
> Now it seems like you're just fear mongering.
> 
> >
> >> > I don't know if your code has this feature, but I put it 
> in my 1830
> >> > program when I was debugging.
> >> > An auditor pass would run between every turn:
> >> >         It would count up all the certificates, tokens, 
> anything I
> >> > could think of
> >> >         (and that should include cash) to make sure 
> everything was
> >> > accounted for
> >> >         and that the program didn't "leak" or "duplicate" any
> >> game materials.
> >> >
> >> >
> >> > Dave.
> >>
> >>We currently do not audit the game to that extent. Patches are
> >>welcome, if you'd like to add it.
> >>
> > Maybe one of these days.... at the moment I've been doing some
> > 10am-11pm hours C++ network authentication programming on 
> Vista.  I'm
> > not the happiest camper.
> >
> 
> Understandable. Just using Vista makes me unhappy, I'd hate to
> actually have to develop for it.
> 
> > Dave.
> >
> >
> 
> ----Brett.
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>