Skip to main content
Game Development

Return to Answer

added 16 characters in body
Source Link
moonshadow
moonshadow
  • 201
  • 1
  • 5

Versioning system. 

With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles. 

Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project). 

Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts. 

If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.

Versioning system. With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles. Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project). Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts. If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.

Versioning system. 

With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles. 

Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project). 

Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts. 

If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.

Source Link
moonshadow
moonshadow
  • 201
  • 1
  • 5

Versioning system. With a roll-your-own approach you'd effectively end up rolling a versioning system, so better to use an off the shelf one that's already had years of design/code/test cycles. Keep the assets in a separate repository from the source, to make it easier to keep checkout / sync times to a minimum and take different decisions on how much history to retain (though disk space is cheap, retain it all whenever feasible. Individual textures don't change that much over the life of a project). Mark XML files as binary, merge tools tend to be very bad at merging nested markup and artists aren't likely to spot broken markup if the tool thinks there are no conflicts. If you can, arrange a syntax check or even asset build on every commit and reject the commit with an email back to the person committing if it fails; this will save a great deal of team time.