[Ohrrpgce] Subversion-like game updates

[Ralph Versteegen]

2009/12/3 Jay Tennant <hierandel8 at crazyleafgames.com>:
>> From: James Paige <Bob at HamsterRepublic.com>
>> Sent: Tuesday, December 01, 2009 2:09 PM
>>
>> On Wed, Dec 02, 2009 at 08:42:29AM +1300, Ralph Versteegen wrote:
>> > 2009/12/2 Jay Tennant <hierandel8 at crazyleafgames.com>:
>> > > I'm getting 6 guys together to work on a game idea a friend has, and it occurred to us that we cannot work together simultaneously on the game file. That is, one person would be building the game file, and everyone else could work on content. Which is ok.
>> > >
>> > > However, it'd be _very_ nice if we could each have a copy of the game file, and if one updates a section of the game, those updates could be merged with the other game copies. For example, if John edits maptile set 0, and Frank edits maptile set 3, a single file will merge the updates of John's maptile set 0 and Frank's maptile set 3.
>> > >
>> > > That's the concept. It's not too unlike using subversion to update the ohr wip. Feel free to expand on this. Has this sort of thing already been done? Are there other projects converting the files to other format structures, ie. xml?
>> >
>> > All game data is stored in fixed length records (possibly as little as
>> > 2 bytes in length), with very very few exceptions that I can think of:
>> > script related lumps, which is not a problem because all of them are
>> > generated from the .hs file, fixbits.bin, and music & sound effect
>> > files.
>> >
>> > Therefore, doing a dumb binary merge of each lump after importing the
>> > latest scripts and ignoring identical changes (eg. upgrades and script
>> > trigger corrections) should work extremely well, breaking basically
>> > never unless two people try to both add a new textbox or something at
>> > the same time, or to edit the same record.
>> >
>> > I've never actually tried it or heard of anyone else trying it though
>> > or even suggesting it. It only occurred to me right now how easy it
>> > would be. Bug 656 would be irrelevant.
>>
>> Interesting. Good point. I was thinking that bug 656 would allow you to
>> ignore most conflicts in the gen lump, but as you say, a dumb binary
>> merge would do the trick.
>>
>> > SVN itself refuses to do binary merging.
>>
>> I read up on the SVN FAQ, and it appears that SVN actually does support
>> binary merging internally, but refuses to do it by default on files
>> marked as binary.
>>
>> You should be able to enable binary merging by manually marking binary
>> files as text with svn setprop, and making sure that have svn:eol-style
>> that won't break anything (I think either unix or windows would be okay,
>> since they are consistent, but native would be breaky)
>
> Interesting. So the files would need to be augmented somehow? I won't pretend to understand subversion that well. The only experience I have is with a client downloading the updates to the ohr wip. I'm looking into setting up my own project repositories, though.

SVN keeps a list of properties for each file. You can set the end of
line property to Unix on a set of files with "svn propset
svn:eol-style LF *"

I would not use svn for binary merges. I would not expect doing clever
(although, actually I fine svn's diff and merging to be a bit stupid
compared to other tools) line-by-line merging on binary data, when
what you want is dumb byte-by-byte, to work in all cases.

You can make the svn client use an external merge tool with a
commandline option. Not sure if you can set it to use one by default,
such as if you're using tortoisesvn.

> I'm interested in researching the sections of code dealing with saving and loading map data. This requires loading/saving of tilesets, map tiles, map walls, map layers, map npc's, map doors, other map data (like harm tiles, etc.). Which files are these operations located in?

What a coincidence, I was just about to post a topic titled "New map
format". Well, later today or tomorrow, I mean.

The preparemap gosub in game.bas loads a map.

Partially converting map layers to slices has created confusion about
who should hold onto map data.

Tilesets are loaded by loadmxs+loadtileset in allmodex.bas.
The foemap isn't loaded into memory, but read directly from file as
needed. A relic from the real mode days that noone has bothered to
clean up yet.
I believe everything else is in loading.bas

>> I really want to try this now :)
>>
>> I'm pretty sure that git could do this too, but I am not clear on the
>> details.
>>
>> ---
>> James
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
>
>
>
> _______________________________________________________
> Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting
>              http://www.doteasy.com
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>