Re: [Rails-devel] Play by email

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

On Mon, Nov 24, 2008 at 6:38 PM, Chris Shaffer <chr...@gm...> wrote:
> Well, yeah, I can see why you might want that.  But for now, a stable
> release could permit PBEM among trusted players.
>
> Since there are no random elements, another way to solve the problem
> is to generate a human-readable game log.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>


We already do. It's location is configured in my.properties and
written out as 18xx.log

---Brett.



> 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..."
>>
>> 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.
>>
>> 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.
>>
>> On 11/23/2008 09:28 AM, Chris Shaffer wrote:
>>>I think I trust everyone - particularly since there are no random
>>>elements. It's not like we wouldn't notice if the game jumped forward
>>>an OR!
>>>
>>>When do you anticipate the next (relatively) stable release?
>>>
>>>--
>>>Chris
>>>
>>>Please consider the environment before printing this e-mail.
>>>
>>>
>>>
>>>
>>>On Sun, Nov 23, 2008 at 6:17 AM, Erik Vos <eri...@hc...> wrote:
>>> > Yes, you could do it this way (provided that the players trust
>>> each other to
>>> > behave by only playing their own turns).
>>> > For the future we foresee a central server picking up and validating moves,
>>> > and sending around the results, but that may still be a while away.
>>> >
>>> > Be warned, though, that the latest version (1.0.5) is somewhat
>>> buggy, so you
>>> > may want to wait for a next release. The latest available source
>>> code may be
>>> > better, if you can work from that. The trouble is, that adding new features
>>> > occasionally breaks some old code, and so far we have not been very good in
>>> > regression testing.
>>> >
>>> > Perhaps we should better organise releases, for instance by bringing out
>>> > betas and giving people some time to file bug reports (and we must learn to
>>> > remember to actually look at these bug reports!)
>>> >
>>> > Erik.
>>> >
>>> >
>> ...
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
> -------------------------------------------------------------------------
> 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
>