Comments on: Real-time Collaboration for Games Development I've been working in a french video game development company since 2007 and during 4 years I work in the tools development team. During 3 years we worked on a game creation tool that we called the GameStudio and that did pretty much what you described in your article. If I can't tell you which method works the best in real-time collaboration in game development, I can tell you the downfalls of the one we tried. As you describe in your article, our first step was to integrate a database to hold all the "entities" in the world (props, characters, triggers, environment objects, etc.) and allow game designers and level designers to tweak the values, add or remove components from entities and submit their work on the server. This worked well until we had to deal with conflicts (the GameStudio could be used by around 10 people at the same time). So we implemented a lock system (similar to the one implemented in the <a href="www.perforce.com" rel="nofollow">Perforce SCM</a>) that would help solve the problem: before modifying the objects, game designers had to lock the entities thus avoiding modifications by other members. The lock would be released when the game designer was happy with his changes and submitted his work on the server. This system created a lot of annoying issues to deal with: it was very rigid, not very real-time friendly, and it was a real pain when someone would let an entity locked for no valid reason. Instead of re-thinking the system, we decided to implement the easiest work around available, being able to "force unlock" an entity, which obviously created a whole bunch of new problems to solve... The other problem we had with a centralized system using a database was the inability to bring a laptop somewhere for demo purpose and work offline. So we "invented" (and I wish we hadn't make this choice) something we called the "god mode" that allowed the user to do whatever he wanted on the entities (create, delete, modify). That was kind of "ok" as the user should have been working on an offline version and all the changes done in "god mode" had to be reverted before being able to work online. A few guys in the company, the same that preached for a very rigid lock-based system, found the "god mode" so convenient that they wanted it to be available even when working online... Having all those problems, we decided to work on a second version of the tool, aka the "GameStudio v2", and the path we chose at that time was to favor merging and conflicts solving by providing well formatted and crystal clear dialog boxes and tools instead of locking everything. The history does not tell if we were right to do so, because we abandoned this project to work on something else. I’ve been working in a french video game development company since 2007 and during 4 years I work in the tools development team.
During 3 years we worked on a game creation tool that we called the GameStudio and that did pretty much what you described in your article.
If I can’t tell you which method works the best in real-time collaboration in game development, I can tell you the downfalls of the one we tried.

As you describe in your article, our first step was to integrate a database to hold all the “entities” in the world (props, characters, triggers, environment objects, etc.) and allow game designers and level designers to tweak the values, add or remove components from entities and submit their work on the server. This worked well until we had to deal with conflicts (the GameStudio could be used by around 10 people at the same time).

So we implemented a lock system (similar to the one implemented in the Perforce SCM) that would help solve the problem: before modifying the objects, game designers had to lock the entities thus avoiding modifications by other members. The lock would be released when the game designer was happy with his changes and submitted his work on the server.
This system created a lot of annoying issues to deal with: it was very rigid, not very real-time friendly, and it was a real pain when someone would let an entity locked for no valid reason.
Instead of re-thinking the system, we decided to implement the easiest work around available, being able to “force unlock” an entity, which obviously created a whole bunch of new problems to solve…

The other problem we had with a centralized system using a database was the inability to bring a laptop somewhere for demo purpose and work offline. So we “invented” (and I wish we hadn’t make this choice) something we called the “god mode” that allowed the user to do whatever he wanted on the entities (create, delete, modify). That was kind of “ok” as the user should have been working on an offline version and all the changes done in “god mode” had to be reverted before being able to work online.
A few guys in the company, the same that preached for a very rigid lock-based system, found the “god mode” so convenient that they wanted it to be available even when working online…

Having all those problems, we decided to work on a second version of the tool, aka the “GameStudio v2″, and the path we chose at that time was to favor merging and conflicts solving by providing well formatted and crystal clear dialog boxes and tools instead of locking everything.

The history does not tell if we were right to do so, because we abandoned this project to work on something else.

]]>
By: Aardappel/2011/06/20/real-time-collaboration-for-games-development/#comment-6141 Aardappel Tue, 21 Jun 2011 22:02:21 +0000

]]>
By: Daniel Sefton/2011/06/20/real-time-collaboration-for-games-development/#comment-6114 Daniel Sefton Tue, 21 Jun 2011 10:23:13 +0000 Thanks for mentioning UnityCollab. I hope to have time to finish it this summer! I'm also very sure we'll be seeing more movement in this field. By the way, if you're interested, here's my master thesis about this subject: <a href="http://www.M2H.nl/files/MasterThesis_UnityCollab.pdf" rel="nofollow">MasterThesis_UnityCollab</a> Thanks for mentioning UnityCollab. I hope to have time to finish it this summer! I’m also very sure we’ll be seeing more movement in this field.

By the way, if you’re interested, here’s my master thesis about this subject: MasterThesis_UnityCollab

]]>
By: Daniel Sefton/2011/06/20/real-time-collaboration-for-games-development/#comment-6107 Daniel Sefton Tue, 21 Jun 2011 08:46:28 +0000 When I was in my final year of uni, my research project (which I did with another person, Danushka Abeysuriya) was on exactly this subject, but more to do with programming. We wrote a plugin for the Eclipse IDE which allowed developers to work on the same code in real-time. We came up with strategies for solving a number of the downsides you mention. The strength ended up being that one can see where one’s colleagues are working on the code-base, and so you can avoid merge/conflict issues before they happen – essentially the real-time interaction increases the human element of collaboration (that is, talking to each other about what we are doing), thus reducing the typical collaborative programming problems (which normally arise because programmers are really bad at collaborating).

I’ll see if I can dig up the paper and post a link on my blog.

]]>
By: Daniel Sefton/2011/06/20/real-time-collaboration-for-games-development/#comment-6043 Daniel Sefton Mon, 20 Jun 2011 18:56:44 +0000 It's probably done in a modelling app and all the models/map files are exported from it. I wasn't in the team, my theory is based on the commentaries found in the map files of previous games and some common sense. They say that the files were exported from Max. I'd guess that's 3D Studio Max. And what better way there is to make sure that everything fits together than to edit everything in the same scene? Max's XRefs could've allowed them to add generic models too. It’s probably done in a modelling app and all the models/map files are exported from it. I wasn’t in the team, my theory is based on the commentaries found in the map files of previous games and some common sense. They say that the files were exported from Max. I’d guess that’s 3D Studio Max. And what better way there is to make sure that everything fits together than to edit everything in the same scene? Max’s XRefs could’ve allowed them to add generic models too.

]]>
By: Cedric Guillemet/2011/06/20/real-time-collaboration-for-games-development/#comment-6035 Cedric Guillemet Mon, 20 Jun 2011 17:56:23 +0000 The real-time editing that you describe sounds interesting, but editing the live world (without any form of branching or commiting) is a recipe for disaster. The reason tools like Mercurial and Git have become so popular is because of their powerful branching features. A user can make huge edits in one branch and only need to push their changes to the stable one when they are ready. I would say that branching is probably essential to allow this kind of editing to work with a team size > 1. The real-time editing that you describe sounds interesting, but editing the live world (without any form of branching or commiting) is a recipe for disaster.

The reason tools like Mercurial and Git have become so popular is because of their powerful branching features. A user can make huge edits in one branch and only need to push their changes to the stable one when they are ready.

I would say that branching is probably essential to allow this kind of editing to work with a team size > 1.

]]>