18 Jun, 2012, Runter wrote in the 1st comment:
Votes: 0
So I've been thinking lately that using a commit model (like svn or git or mercurial) for area design might be helpful.

It gives a clear history of who did what changes in this area.

It lets peer review happen quickly and effectively when you don't have to be walked through a zone on a game, or tediously examining what exists, rather than why they exist and what they relate to.

This would also allow us to be able to see that a change in the game was made, and use a command to find out who made the change and what they logged the reason as being. Something like gitblame.

I think this really would be useful for games that have more complex areas. Not just topographic in nature, but scripts and dependancies. For example, if I break a quest chain but only find out a week later, and don't realize how the chain was broken I could use something similar to git bisect to find out the specific commit that did it in a few minutes rather than guessing and debugging.

Anyways, I'm really interested in this idea for a project I'm working on, but I'm absolutely stumped at how to implement it. I guess such systems by nature are complex even with text documents, but dealing with something more complex like arbitrary data structures seems very difficult?

So I'm interested in discussion here. Comments, implementation suggestions, criticisms are all things I'm looking for.
18 Jun, 2012, Idealiad wrote in the 2nd comment:
Votes: 0
Maybe a wiki model would be a good starting point. Conceptually it's not too different from an area.
18 Jun, 2012, Runter wrote in the 3rd comment:
Votes: 0
So I'm thinking a commit is a list of edits. So here's what I'm thinking an early areas commits might look like if I wanted to look at the full history of an area with 3 rooms connected, and 1 NPC placed in a certain room.

#1[Retnur  7:43PM Jun 19]: "Started the newbie area we've yet to name full of tah goblins and loot"
New [Area 1] ->
+name: "goblin place"

#2[Retnur 7:45PM Jun 19]: "Created a basic layout of the 2 room area"
For [Area 1 "goblin place"] ->
New [Room 1] ->
+name: "before the den"
New [Room 2] ->
+name: "in the den"
New [Connection [Room 1 via N] with [Room 2 via S]]
New [Room 3] ->
+name: "the treasure room"
New [Connection [Room 2 via E] with [Room 3 via S]]

#3[Retnur 8:10PM Jun 19]: "Added goblin leader"
For [Area 1 "goblin place"] ->
New [NPC 1] ->
+name: "goblin leader"
New [Reset [NPC 1 "goblin leader"] in [Room 2 "in the den"]]

#4[Retnur 8:15PM Jun 19]: "Decided the names were bad after talking to Shane."
For [Area 1 "goblin place"] ->
Edit [NPC 1 "goblin leader"] ->
-name: "goblin leader"
+name: "goblin boss"
Edit [Room 3 "the treasure room"] ->
-name: "the treasure room"
+name: "the stash"
18 Jun, 2012, Oliver wrote in the 4th comment:
Votes: 0
Why wouldn't you just generate two separate instances of the .area file in question, then use an already-existing utility to generate a diff file? That's essentially what git commits are.

Edit: I guess maybe because they wouldn't be entirely human-readable? Unless the area files in question were intelligible. Still, it would be an easy way to implement a system where you can roll back certain area changes very easily without disrupting others.
18 Jun, 2012, plamzi wrote in the 5th comment:
Votes: 0
Aren't private git repos mostly pay-to-use? SVN is a bit more dated but you can set up a server pretty easily, and it's been good help to us for coding. I would have definitely checked in the world files as well if they were still in flat files.
18 Jun, 2012, Omega wrote in the 6th comment:
Votes: 0
unfuddle.com ; private git-repo, just keep it under like, 250mb (if I remember correctly)

Or you can always setup your own git-repo. gitorious.com's stuff is open source, so truthfully, its up to the user. But I digress…

I use unfuddle for my private repo's, and it works out for me just fine :)
18 Jun, 2012, Runter wrote in the 7th comment:
Votes: 0
Well, the reason I think using existing revision tools wouldn't be appropriate is that they're for actual documents. At least in my games, builders have access to abstract commands rather than having to write code. So its a bit different. So I think the revision system should deal in the same thing as the tools they're dealing in to make the areas. I don't know of any way to take a diff and process it in a meaningful way to know what that line of code is actually modifying. (Like a certain NPCs name)
19 Jun, 2012, Oliver wrote in the 8th comment:
Votes: 0
Runter said:
Well, the reason I think using existing revision tools wouldn't be appropriate is that they're for actual documents. At least in my games, builders have access to abstract commands rather than having to write code. So its a bit different. So I think the revision system should deal in the same thing as the tools they're dealing in to make the areas. I don't know of any way to take a diff and process it in a meaningful way to know what that line of code is actually modifying. (Like a certain NPCs name)


Well, you don't need to save the commands of the builders. Sure, your builders are using commands (some sort of OLC I imagine), but those commands are translated into a difference in the way that the area file is saved. In that sense you can work with actual documents; take a copy of the document (file.are or whatever you use) before the builder makes any changes. After they've done those changes, you can generate a diff based on the difference between the first copy and the new file after they've changed the area.

The difficulty (which I think maybe is what you were trying to get at) is that it wouldn't appear as "Bob created mobile x", it would read "+x~ 2424~ 0~ etc. etc. etc." I.E., it wouldn't be human-readable, but it would work as a revision system.
19 Jun, 2012, Runter wrote in the 9th comment:
Votes: 0
Oliver said:
Runter said:
Well, the reason I think using existing revision tools wouldn't be appropriate is that they're for actual documents. At least in my games, builders have access to abstract commands rather than having to write code. So its a bit different. So I think the revision system should deal in the same thing as the tools they're dealing in to make the areas. I don't know of any way to take a diff and process it in a meaningful way to know what that line of code is actually modifying. (Like a certain NPCs name)


Well, you don't need to save the commands of the builders. Sure, your builders are using commands (some sort of OLC I imagine), but those commands are translated into a difference in the way that the area file is saved. In that sense you can work with actual documents; take a copy of the document (file.are or whatever you use) before the builder makes any changes. After they've done those changes, you can generate a diff based on the difference between the first copy and the new file after they've changed the area.

The difficulty (which I think maybe is what you were trying to get at) is that it wouldn't appear as "Bob created mobile x", it would read "+x~ 2424~ 0~ etc. etc. etc." I.E., it wouldn't be human-readable, but it would work as a revision system.


I think you're not reading what I'm saying too well. The point isn't so I can have some codey diff between area files. The point is for a human readable history that you can review as non-programmers on the history of the development of an area. And the extra benefit would being able to rewind back to different parts in the commit history just like revision tools. I'm not trying to reinvent a revision system, I'm trying to do something I don't see as possible with just using git or svn, or any of the other tools available right.
19 Jun, 2012, plamzi wrote in the 10th comment:
Votes: 0
Runter,

I think several of us assumed at first reading that you're talking about leveraging some of the existing version control systems, maybe building on top of them using system calls or something. But it sounds like you want to write a version control system from scratch, one that will allow for itemized comments and rollbacks.

Well, like you said so yourself, it would be complex. I would add that it would be hugely complex, so no wonder you're stumped. And I think that any sensible cost-to-benefit analysis would show that it's not worth it. Not unless you're planning to create something so incredible and flexible that you can market it next to free solutions like SVN and Git and it would sell like hot cakes. But just to support world edits in enthusiast games? My 2c is 'overkill'.
19 Jun, 2012, Oliver wrote in the 11th comment:
Votes: 0
Runter said:
I think you're not reading what I'm saying too well. The point isn't so I can have some codey diff between area files. The point is for a human readable history that you can review as non-programmers on the history of the development of an area. And the extra benefit would being able to rewind back to different parts in the commit history just like revision tools. I'm not trying to reinvent a revision system, I'm trying to do something I don't see as possible with just using git or svn, or any of the other tools available right.


No, I definitely got that. I pointed it out in my post above that I knew it wouldn't be human-readable.

I was just more getting at what Plazmi said above me– that it might not be worth it when already-existing RCSs can generate non-human-readable diff files.

You could always build on top of something like Git, inserting comments into the diff file that represent a builder's action. A comment might read "create room 500", under which it would have the changes for the .area file; an in-game utility could pull comments out of the diff, using that to show humans what changes were made?
19 Jun, 2012, Runter wrote in the 12th comment:
Votes: 0
Quote
Not unless you're planning to create something so incredible and flexible that you can market it next to free solutions like SVN and Git and it would sell like hot cakes. But just to support world edits in enthusiast games? My 2c is 'overkill'.


Lol, well, fair enough. But people write things tools very complex for enthusiast games, like custom scripting languages and what not. I think the gains could be quite high with such a system in a game that's in production. I'm not sure I'd call it overkill when compared to no revision control at all. It may be overkill when compared to using an existing solution, but don't know too many people using existing solutions in game for revision control at all.
19 Jun, 2012, plamzi wrote in the 13th comment:
Votes: 0
Runter said:
But people write things tools very complex for enthusiast games, like custom scripting languages and what not.


But of course! :) If you're in it just to see if you can do it, just stock up on Advil and go for it.

Oh, and I would start by deciding which flat-file database to use for storage.
20 Jun, 2012, Tyche wrote in the 14th comment:
Votes: 0
If you happen to be using one of the popular rdbms's for storage, you can set up triggers for update, insert, delete events and do transaction logging to a table.
Even if not, you can insert "trigger code" in your builder code to do the same thing conceptually, create a transaction log.
Creating a log of transactions at the point of change, allows you to determine the context of the change, and if anything actually changed at all.
23 Jun, 2012, Runter wrote in the 15th comment:
Votes: 0
Tyche said:
If you happen to be using one of the popular rdbms's for storage, you can set up triggers for update, insert, delete events and do transaction logging to a table.
Even if not, you can insert "trigger code" in your builder code to do the same thing conceptually, create a transaction log.
Creating a log of transactions at the point of change, allows you to determine the context of the change, and if anything actually changed at all.


This sounds like a good idea. Not one I've thought of.
0.0/15