rails-devel

[Rails-devel] Re: XML data files

[<ia...@co...>]

> 
> >I know from experience that as XML files become large, it can become very 
> >difficult to edit them or write them accurately - lots of simple mistakes 
> >creep in and unless a lot of effort is put into the parsing software, the 
> >error messages can bear no relation to the root cause.
> 
> Yep. I've experienced this pain too. That's what brought me to suggest=
>  breaking out each 
> major class into it's own XML settings file.
> 
The are arguments in favour of both approaches: one of the issues with XML is the general assumption that just because you CAN edit it with a text editor, you SHOULD use a text editor. That said, I'm happy to go along with multiple files.

> >Rulesets have to be human readable and modifiable, so XML is a good
> >choice. 
> >However, for saving the state of the game, I think that Java Serialization=
>  
> >would be a better choice. The volume of data involved is relatively small 
> >and the coding for straightforward serialization is simple, certainly 
> >several times less effort than mapping all objects in and out of XML.
> 
> Sounds good. I agree that the mapping a save file to XML will probably be a=
>  lot of work. So, 
> if there's a simpler way, I'd favor using it.

Binary saves are a very, very bad idea: do I really need to explain why? Creating and reading XML for the saves is not difficult. 

Iain.

[Rails-devel] Re: XML data files

[<ia...@co...>]

>> Binary saves are a very, very bad idea: do I really need to explain why?
>> Creating and reading XML for the saves is not difficult. 

>Please explain.  It seems to me that the only thing you accomplish by
>saving in XML is to enable players to cheat in multiplayer games by
>editing the save file.

Players can always cheat and edit a save file, making it a little less easy doesn't stop them doing (search for 'security through (or by) obscurity' for more information).

You need a human readable format because it makes testing much easier, and bug hunting later much easier. It is also much, much easier to provide backward compatibility. Look at the problems Peter Nowak is reporting getting the new version of the Vassal/18xx to read his old saves. Java serialisation is great for live system-system communications, it is very fragile as a persistence mechanism because when you change the class signature, you find that you cannot load old saves. If your upgrade adds a new attribute, either your new XML reading code can cope with the absence from an old save, or you can easily provide a migration script for old saves. Let's not even get into byte-ordering issues different hardware classes.

Basically, 'It's too much like hard work to do human readable saves' is lazy, and will land in a deep hole later, it's also just not true with XML as good libraries are freely available to do the hard work.

It also means that someone else can much more easily write a tool that will work with your save files: e.g. someone might want to take a game log, and produce an animation of the map development. If your log is in a well-known, easy to read format, they'll just get on with it, and suddenly your project has more features. Keep it friendly for other people to work with you, and you'll get more friends working with you.

Iain.

Re: [Rails-devel] Re: XML data files

[Brett L. <wak...@ea...>]

>
>Players can always cheat and edit a save file, making it a little less
>easy doesn't stop them doing (search for 'security through (or by)
>obscurity' for more information).

I agree.  Cheating isn't really a concern of mine unless Rails ends up=
 being looked at for tournament play.

If we get to that stage, I think we can revisit the cheating issue. Until=
 then, I don't really care if someone can 
modify the save file to their advantage. The only person they cheat is=
 themselves.

Additionally, in another Java app, PCGen, just last night I was able to fix=
 a bug in a data set on my own simply because the data format is=
 human-readable. In the early stages of development, the more we can=
 facilitate bug discovery, the better.


>
>You need a human readable format because it makes testing much easier, and
>bug hunting later much easier. It is also much, much easier to provide
>backward compatibility. Look at the problems Peter Nowak is reporting
>getting the new version of the Vassal/18xx to read his old saves. Java
>serialisation is great for live system-system communications, it is very
>fragile as a persistence mechanism because when you change the class
>signature, you find that you cannot load old saves. If your upgrade adds a
>new attribute, either your new XML reading code can cope with the absence
>from an old save, or you can easily provide a migration script for old
>saves. Let's not even get into byte-ordering issues different hardware
>classes.
>
>Basically, 'It's too much like hard work to do human readable saves' is
>lazy, and will land in a deep hole later, it's also just not true with XML
>as good libraries are freely available to do the hard work.
>
>It also means that someone else can much more easily write a tool that
>will work with your save files: e.g. someone might want to take a game
>log, and produce an animation of the map development. If your log is in a
>well-known, easy to read format, they'll just get on with it, and suddenly
>your project has more features. Keep it friendly for other people to work
>with you, and you'll get more friends working with you.
>


All good points. In my opinion, speed of development is an important issue,=
 but so is long-term 
managability. I think XML is widely accepted enough that we won't have too=
 much of a 
problem finding tools to work with it.


---Brett

[Rails-devel] RE: Various comments

[<ia...@co...>]

>> Has anyone read the 18xx-softdev archive yet? A lot of good 
>> ground was covered there (not all by me ;-)), and I think the 
>> discussions here would benefit from using this as a base. 
>> Specifically look at the thread(s) on a game definition file.

>Just looked again, but it is hard so sort out the few pearls from that mess.
>The thing I see so far is your data model in message #127, which we
>indeed would do well to keep handy (I"ll print it out).
>Marco Rocci"s summary of the 1830 private auction process in message #478
>might also be useful.
>Any other messages you find worth revisiting?

I have a vague overview in my head, I'll have to browse through it again myself to find the good bits. Reading it has value in that there are some useful items (your vote of confidence in my data model appreciated), and some useful discussions, and one can also see many dead-end discussions, which might be avoided here if people have read that list- "Those Who Are Ignorant of History Are Condemned to Repeat." 

>There is one interesting idea that I would add, inspired on message #238
>from Gregor Zeitlinger: creating subclasses for game-specific processes.
>The question is to what extent we can configure options in a config file.
>At some point things might get so complicated or game-specific that we
>need to write special code. 
>The idea is to do that in game-specific subclasses of generic classes
>which handle the more common cases.
[ Decent example snipped for brevity.]
>Such classes should be instantiated by a class factory.

Yes, with a decent data model, many things are possible through configuration: it is a question of understanding and modelling the range of behaviour a component might exhibit (e.g. company). There will always be a point where a rule in one game is so unusual that it is best dealt with through a new class. This is where defining the datatypes through interfaces, and instantiating them through factories becomes a very powerful technique. It's a little more effort up-front, but the payback is enormous.

Iain.

Re: [Rails-devel] Re: XML data files

[John D. G. <jd...@di...>]

ia...@co... wrote:
> Binary saves are a very, very bad idea: do I really need to explain why?
> Creating and reading XML for the saves is not difficult. 

Please explain.  It seems to me that the only thing you accomplish by
saving in XML is to enable players to cheat in multiplayer games by
editing the save file.