Sign in to follow this  
mikeman

Synchronizing the level editor

Recommended Posts

I was wondering, how most engines/level editors handle the fact that there could be more than one designers working on a level? I don't have much experience with Source Control, can something like SVN handle that automatically,by just working on the level files, or must the level editor handle the synchronization explicitly? If so, how is it usually done, and to what extent? I mean, I imagine if 2 artists are painting splat textures in the same terrain, their work will conflict and there's no way to synchronize it? Can anyone describe in general terms what is possible in this area(synchronization), and how is it usually implemented? Thank you.

Share this post


Link to post
Share on other sites
Most level editors don't handle this situation, because it isn't easy to implement and has to be planned for from the start. Source control doesn't help much here because either the level is in binary format and can't be merged, or it's stored as text but merging doesn't produce valid results. In other words, the level editor has to be explicitly designed and implemented to handle multiple users possibly working on the same data at once, since it's the only tool that really knows how the data is stored and modified.

EDIT: As far as implementation goes, it depends. The most straightforward approach is to split the level into separate chunks and let each artist work on a chunk, merging them together in the end. Or if you want the artists to be able to work on the same part of a level at once, a shared database could be used which stores changes they make to the level. The database backend handles all the race condition nastiness while keeping both artists in sync. Then at the end you just reconcile the database data into a file. Keep in mind that I've never actually implemented suh a system, so these ideas are off the top of my head :)

Share this post


Link to post
Share on other sites
Different games / engines do different things with respect to maintaining valid game assets even when multiple persons work on the same data.

Game level is often split into layers, e.g. sound, region A, region B, logic where each such layer is stored in a separate file. If you want to modify layer you have to "check out" that file exclusively from repository (e.g. p4, svn) to prevent others from messing up with it in the meantime. This is approach used with Unreal Engine. So, in Unreal Engine two people can't / shouldn't edit same piece of data because they have no way to merge that data later.

Another - slightly different and popular - approach is to let people edit same assets at the same time but then provide way of merging these edits. One way to achieve this is to store all data in sorted XML files (sorting prevents random changes in XML layout due to serialization differences) and rely on text file merging (all repository systems have that built-in). XML merging is better than you think. There may be conflicts of course (when 2 people modify same line of the XML file at the same time), but it's typically very rare and if happens can be resolved manually. Also, it seems this one was used for asset data base when developing Uncharted 2 (can read about this in Game Engine Architecture). I've also seen others use this approach.

That is also an approach I prefer.

You could also develop your own custom merging of your binary data but I'd imagine this would be very difficult on a large project with complex data structure. Haven't seen anyone do this.

Also, all above solutions apply to just about any data type, not just levels (an example may be an asset pack).

Hope that helps.

[Edited by - MickeyMouse on February 20, 2010 5:42:34 PM]

Share this post


Link to post
Share on other sites
Thanks for the answer! I have to ask, most engines(from what I've checked, even big engines like UE3/UDK don't do this, AFAIK in UE3 the levels are stored in a single binary file), don't implement that sort of feature because it's just not worth it? Ie there isn't much gain, it solves a problem that doesn't really exist? Or the feature would be useful, but it's just too much work to implement? What do you think?

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
Thanks for the answer! I have to ask, most engines(from what I've checked, even big engines like UE3/UDK don't do this, AFAIK in UE3 the levels are stored in a single binary file), don't implement that sort of feature because it's just not worth it? Ie there isn't much gain, it solves a problem that doesn't really exist? Or the feature would be useful, but it's just too much work to implement? What do you think?


Implementing merging of the binary packages for Unreal would be extremely difficult (need to traverse all objects, references between them and compare that between 2 files).

Using XML for all your assets like levels / asset packs helps, but it's also trade off between serialization speed (with XML being quite slow) and convenience (XML usually merges quite well).

Also, when you choose XML, then it's clearly some intermediate format because no serious large game wants to load levels from XML files (slow!). Unreal stores everything in its final binary format which is meant to be efficient and also eliminates need for an intermediate format (so, the export process is shorter & simpler; on the other hand Unreal format contains lots of editor specific data even in final game version which is a bit crap).

Share this post


Link to post
Share on other sites
Well the Cube/Cube2 engine supports working on the same level and even on the same thing at the same time by multiple devs.

http://cubeengine.com/
http://sauerbraten.org/

Share this post


Link to post
Share on other sites
The only thing that I've seen that comes close to what you're looking for is the Cube engine (seems to be called Cube 2: Sauerbraten nowadays). It's specifically designed with collaboration in mind. Most level-design tools aren't made for user-scenarios like that though.

But it'll take more than good tools for two people to work on exactly the same area at the same time. I think it's not all that efficient to have such a fine granularity of collaboration, given how likely it is that they'll be getting in each others way. Splitting up levels into multiple areas will likely suffice, perhaps with some locking mechanism in place to prevent two designers from modifying the same area at the same time.

Version control is still a good idea here, but not for merging purposes.


EDIT: Ninja'd by 2 people... :P

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this