Skip to main content
Game Development

Return to Answer

Added reply to examples after question edit
Source Link
SkimFlux
SkimFlux
  • 348
  • 3
  • 7

I think a database/filesystem replicated across environments with a 'check-out' procedure would be best.

So, whenever a designer wants to make some modification to the world, he would check-out/lock all assets he wants to modifycreate/modify on all copies of the database (development and production), so no other player or designer could modify it. He would then work on the development database until the new design is finished, and at that time the changes would be merged with the production database and those assets would be checked-in/unlocked in all environments.

Player edits would work in much the same way, except the database/filesystem roles would be reversed - they work on the production database, and all updates are uploaded to dev when finished.

The asset locking can be limited to the properties where you want to guarantee no conflicts: in Example 1, you'd lock ID 123456 as soon as the player starts crafting it, so the developers will not be assigned that ID. In Example 2 your developers would have locked the script name assignFrenchAccent during development, so the player would have to chose a different name when developing his modification (that small nuisance can be reduced by namespacing, but that by itself will not avoid conflicts unless you give each user/developer a specific namespace, and then you'll have the same issue with managing the namespaces). This does mean that all development would have to read from a single on-line database, but all you require from that database in these examples are the object names, so performance should not be a problem.

In terms of implementation, having a single list oftable with all keys and asset state (available, locked from dev, locked from prod) synchronized/accessible in real-time across environments should be enough. A more complex solution would implement a complete Version Control system - you can use an existing system like CVS or SVN if your assets are all in a filesystem.

I think a database/filesystem replicated across environments with a 'check-out' procedure would be best.

So, whenever a designer wants to make some modification to the world, he would check-out/lock all assets he wants to modify on all copies of the database (development and production), so no other player or designer could modify it. He would then work on the development database until the new design is finished, and at that time the changes would be merged with the production database and those assets would be checked-in/unlocked in all environments.

Player edits would work in much the same way, except the database/filesystem roles would be reversed - they work on the production database, and all updates are uploaded to dev when finished.

In terms of implementation, having a single list of all keys and asset state (available, locked from dev, locked from prod) synchronized/accessible in real-time across environments should be enough. A more complex solution would implement a complete Version Control system - you can use an existing system like CVS or SVN if your assets are all in a filesystem.

I think a database/filesystem replicated across environments with a 'check-out' procedure would be best.

So, whenever a designer wants to make some modification to the world, he would check-out/lock all assets he wants to create/modify on all copies of the database (development and production), so no other player or designer could modify it. He would then work on the development database until the new design is finished, and at that time the changes would be merged with the production database and those assets would be checked-in/unlocked in all environments.

Player edits would work in much the same way, except the database/filesystem roles would be reversed - they work on the production database, and all updates are uploaded to dev when finished.

The asset locking can be limited to the properties where you want to guarantee no conflicts: in Example 1, you'd lock ID 123456 as soon as the player starts crafting it, so the developers will not be assigned that ID. In Example 2 your developers would have locked the script name assignFrenchAccent during development, so the player would have to chose a different name when developing his modification (that small nuisance can be reduced by namespacing, but that by itself will not avoid conflicts unless you give each user/developer a specific namespace, and then you'll have the same issue with managing the namespaces). This does mean that all development would have to read from a single on-line database, but all you require from that database in these examples are the object names, so performance should not be a problem.

In terms of implementation, having a single table with all keys and asset state (available, locked from dev, locked from prod) synchronized/accessible in real-time across environments should be enough. A more complex solution would implement a complete Version Control system - you can use an existing system like CVS or SVN if your assets are all in a filesystem.

Source Link
SkimFlux
SkimFlux
  • 348
  • 3
  • 7

I think a database/filesystem replicated across environments with a 'check-out' procedure would be best.

So, whenever a designer wants to make some modification to the world, he would check-out/lock all assets he wants to modify on all copies of the database (development and production), so no other player or designer could modify it. He would then work on the development database until the new design is finished, and at that time the changes would be merged with the production database and those assets would be checked-in/unlocked in all environments.

Player edits would work in much the same way, except the database/filesystem roles would be reversed - they work on the production database, and all updates are uploaded to dev when finished.

In terms of implementation, having a single list of all keys and asset state (available, locked from dev, locked from prod) synchronized/accessible in real-time across environments should be enough. A more complex solution would implement a complete Version Control system - you can use an existing system like CVS or SVN if your assets are all in a filesystem.