All in all it’s a pretty good article worth reading by Mick West. Though it kind of leaves the reader hanging at the end because I don’t think he goes into enough of the very glaring problems someone would need to address for the solution to be workable. Files are a pain to deal with, but they are simple and users understand them. Sure they have their problems, but the alternative he suggests (a database) will have many more that will require a very bullet-proof solution if you don’t want your studio grinding to a halt because a bug just corrupted the central database.
He doesn’t really address the issue of sandboxing and offline development. Often users will want to be able to sandbox some ideas, but this is in direct opposition to the “live edit” environment he envisions. However as soon as you introduce a sandbox system to database back-ended solution it adds the complexity of no longer having a centralized database with transactional operations for everything. Now everything is disconnected and things are being developed in separate branched environments, which eventually will need to be merged back together.
This merge will likely require a very complicated tool designed to take the database differences and present them to the user in a way that will allow them to resolve conflicts. This tool will also need to be able to present the work the user has done in very logical blocks. With files a user can work on a section of the world, find it’s not ready to be checked in for other users to pull down, and decide to leave it on their machine, or they may decide they want to revert that work and only check in another part of the world they modified.
So how would you break it down, by sessions the user worked in, regions of the world, per entity, per property change. There are many choices, maybe the tool offers them all, but still something to consider. Because if the user is unable to revert some of the work they’ve done offline in their sandbox, it kind of defeats the purpose of a sandbox or at the very least cripples its usefulness severely.
Another problem you would need to solve is the interaction with the undo stack (assuming this is a live edit environment). If you don’t want angry designers wielding pitchforks it would probably be wise for this collaborative game editing tool to be able to maintain an undo stack. However, this presents all kinds of dependency/order of operations problems that would need to be solved. Such as, in a live editing environment how can I undo my own work, without undoing other users work that may have become dependent on my work. For example, user A adds an Orc. User B immediately, scales the Orc. User A then attempts to undo his last action, then attempts to redo it. What is now the state of the world? Did the Orc get put back into the world, and does it have the change in scale that user B made?
My immediate reaction would be to say, you just figure out the database modifications that would need to occur to remove the Orc, properties and all and any other change that would occur because of the loss of the Orc, and store those as actions in some kind of undo action table that could be replayed should I decide to redo the operation. That way the state of the world is exactly as expected, an Orc with user B’s scale applied.
Ah, but what if while deciding to redo the operation, user B decides the Orc ‘type’, the definition of this entity that you’ve been stamping around the world is no longer needed. So user B deletes it from the list of types, which in turn deletes all Orcs currently in the world. Now, user A attempts to perform the redo, placing an Orc instance back into the world. But this operation is no longer valid, Orcs no longer exist as a type because of user B’s actions.
Blocking off the world would alleviate some of these problems, as long as you threw away the undo stack as soon as the blocked off area is unblocked, but when a user wants to change something that affects all regions (like the removal of the ‘Orc’ type) those types of changes could be a bit more complicated.
The long drawn out point here, is that your database and editor would need to be incredibly error tolerant as would the capability of your runtime to deal with bad/intermediate-state situations that would be a likely occurrence.
Now of course these problems and more could be avoided, but it may mean changing the way users work and the way they have become accustomed to working and could also mean flat out denying them certain capabilities they’ve been used to having as far back as they can remember.
Though, I do wonder if a day will come where it just becomes second nature to turn to databases to solve the problems of world editors.