GameDev scenarios

Centralized Development

Centralized development

  1. Inside a given location, programmers and artists specially, work directly connected to the version control server without any local clone.
  2. This direct connection to the server enables a simpler ‘lock-edit-checkin’ cycle: more natural for artists and developers. Disk space is also saved (considering in game dev projects it is measured in GB).
  3. The main server has to handle a big load from potentially hundreds of concurrent users, avoid unwanted locks, be responsive and fast.
  1. Plastic SCM supports the centralized and distributed scenarios. A Plastic workspace can be directly connected to the central server, no need for intermediate repository clones (although it is a possibility). That’s why Plastic can work in *real* centralized mode.
  2. Plastic supports heavy load on a single server as it is explained in this test scenario. Any team interested on checking how Plastic behaves under heavy load will be granted access to the Amazon EC2 setup to see it in action and even alter the scenario to better reproduce their environment.
  3. Multiple Plastic servers can be configured to split the repository catalog among multiple machines if necessary.
  4. Speed is also remarkably fast as explained in the ‘performance results’ sections, consistently beating established competitors.