Distributed teams

GameDev scenarios

Distributed teams inside different distributed studios

Description
  1. The company has different studios around the world.
  2. The engine studio is based in New York. Different studios will push and pull to it.
  3. One of the studios, in London, has different teams that are also distributed in different sites.
  4. The scenario shows a hierarchy of servers:
    • One ‘main engine’ server in New York.
    • One ‘studio’ central server in London.
    • Developers working in centralized mode in London (direct LAN connection to the server).
    • Two additional sites with additional servers. They’ll push and pull from the London server.
    • One developer working from home and having a local partial replica of the repository (or repositories) he needs to work.
Benefits
  1. Multiple servers that can use different underlying technology: suppose the New York studio is a ‘Windows shop’ while the London one prefers to run servers on Linux. Replication will work independently of the underlying operating system and database backend.
  2. Servers running with different database backends and hardware requirements:
    • The New York studio can be a big server (32Gb RAM, 16 cores) using a SQL Server and handling the load of 400 concurrent developers.
    • The London studio can use a big server (16Gb, 8 cores) using MySQL and handling the load of 100 concurrent developers.
    • The developer working from home will run a replicated server running on his laptop and using a SQLite backend (really small memory footprint and only handling single user load).
    • The 2 distributed sites inside the ‘UK Studio’ can use much smaller machines to handle the load of 10 developers each.
  3. Replication between environments ensure proper asset and code delivery.