In this in-depth article, Slightly Mad Studios contractor Tomlinson explains how the firm completed highly-rated EA-published console racing game Need For Speed Shift with a largely virtual team structure, with a personal perspective on how remote working can work even for larger game teams.
[In this in-depth article, Slightly Mad Studios contractor Tomlinson explains how the firm completed highly-rated EA-published console racing game Need For Speed: Shift with a largely virtual team structure, with a personal perspective on how remote working can work even for larger game teams.]
I had wanted to become a contractor for my chosen profession -- video game programming -- for quite some time, but the vast majority of developers in the UK were hostile to the idea. So when I heard about Slightly Mad Studios, I couldn't believe my luck.
Not only is contracting encouraged, but working remotely is the norm. So how can a developer with staff spread over the globe possibly hope to produce a successful AAA project?
Slightly Mad's recent critically acclaimed release, Need for Speed: Shift, is proof positive that not only is a virtual development company possible, but that it can thrive. This article explains how.
The origins of Slightly Mad Studios lie in a modding group called SimBin who produced the much acclaimed GTR2 and GT Legends. The core of the development team, led by Ian Bell, broke away to form Blimey! Games, which led in turn to Slightly Mad Studios.
Thus the company always had a somewhat loose physical structure where geographical diversity was ingrained. By September 18, 2009, the first SMS product, Need For Speed Shift, was released worldwide by Electronic Arts to positive reviews -- the Xbox 360 version currently has an 83 on Metacritic.
Remote working in "virtual companies" is not a new idea; it has been discussed previously on Gamasutra by Jake Simpson, for example, who offers many useful tips. However, rarely has the idea been so completely embraced as it has at Slightly Mad Studios. Max Meltzer has also discussed at length the difficulties in managing a remote team. The set-up at SMS is somewhat different, however, in that it employs remote individuals rather than remote outsourcing teams.
Although some SMS staff choose to work at the small London head office, the vast majority work remotely. The UK is home for a large chunk of the team, about 50 percent, but many are based in various parts of Europe with others in North and South America, South Africa, Scandinavia, and Australia. One staff member's registered location is an Indian Ocean tropical island; as long as you can get a reliable broadband connection, geography is not an issue.
The team members' contractual arrangements with SMS are equally varied. Many work on short or longer fixed term contracts, although traditional employment is available if preferred. About half the team are full time employees, but all non-UK staff are consultants.
A small number of UK staff who own their own companies are also consultants. I personally work through my own limited company, S1m On Ltd, although my relationship is a little closer to SMS than perhaps would be usual for an outsourcing arrangement. Of course, intellectual property rights must be properly dealt with in any contract as must non-disclosure obligations, but this is straightforward.
Ian Bell's open minded attitude is rarely reflected in other game development companies. Before joining SMS I had tried and failed to persuade a number of companies that remote contracting was a workable proposition. The primary barrier to remote working quoted by most companies is communication. How could I possibly participate in the team if I wasn't physically present on the development floor?
Face-to-face meetings still occur at SMS, hosted either at the London office or some other mutually convenient location, but the primary day-to-day channels of communication are electronic. SMS uses two very simple systems -- instant messaging, and a well-structured online forum.
The forum is split into private company areas, and more public areas which are open to the client -- in this case, publisher Electronic Arts. The forum is further split by discipline (Code, Art, Design, QA), by project and down into specific threads to which an interested user can subscribe for notification of new posts.
It is the responsibility of members to stay up-to-date with the forum, and one quickly learns the critical threads; typically a review once an hour using a recent post search is adequate and acts as a natural break from coding.
IM is used where a more interactive discussion is required, sometimes with multiple participants, and usually with conclusions recorded on the forum. The translation issues encountered by Meltzer are avoided at SMS by defining the company language as English -- and all staff must be passably fluent. This might cut the available talent pool somewhat, but not, perhaps, by all that much.
There are some cons. A great deal of human communication is actually through non-verbal means -- body language, facial expression and so on. This is clearly lacking in the virtual company, but you do manage to compensate. After a while I found that I could judge peoples' moods to some extent by the way they communicated; their written phrasing, speed of reply and verbosity.
Of course, though, this is not for everyone -- there will always be some individuals who crave the atmosphere and buzz of a traditional office. The one thing I personally miss is the lunch time Call of Duty multiplayer session. I have to make do with a walk in the countryside or maybe a short nap in the garden, so it's not a bad swap IMHO.
There are also pros, of course. In my experience, and compared to other companies, the SMS forum is not only as good as direct face-to-face conversation, but in many ways it is better. As a user you see the entire range of communication. Decisions made in the art department which have a knock-on affect in tech are less likely to be missed due to lack of visibility.
Users are encouraged to discuss ideas and get involved as much or as little as they want, so everyone has a real investment in the product. There is a permanent record of all discussions which can be searched, referenced and reviewed post mortem.
The practice of using the forum encourages improved brevity and precision in communication -- typing is slower than speaking, so you have time to properly formulate your point of view and make sure your ideas are seen at their best.
All forms of communication can have failures, but the SMS system seems to have fewer than traditional word of mouth: no more "Now what did the lead say about that memory issue on the PS3 at the start of the second hour of the weekly meeting?" Indeed, since communication is a little more time-consuming, I believe there is far less gossip within SMS and therefore fewer distracting ego issues compared to other places I have worked.
Source control, asset management, documentation and bug tracking are provided by tools such as Perforce and FTP, which are used in exactly the same way as in a traditional office, but with somewhat enhanced security measures.
Meltzer discusses problems with asset management and ensuring that a distributed (by time zone) team is up to date. This is circumvented at SMS by employing a dedicated build engineer and applying a strict timetable for asset movements.
Programmers and artists are free to check in assets at any time apart from a period when the "window" is closed. During this time the build manager obtains the current snapshot of code and data assets; the check in window can re-open as soon as the grab is complete, or when the first build confirms the data is valid.
Working builds are created on various platforms as required and uploaded to an FTP server where users can grab the build. In normal development a build could be every two to three days, increasing to daily builds during the crunch period. Coders can of course also grab and build their own snapshots.
Meltzer also mentioned the possibility of a bad asset or code check in paralyzing other users when the contributor is not available to fix the issue, due to going offline in their time zone.
This can happen, but there are many ways to resolve the issue -- source can be rolled back, as can assets, or a coder can make a provisional fix, although it is important to ensure dependencies are as simple as possible to allow this. However, all individuals have a personal obligation to ensure their check in works, and the embarrassment of public vilification on the forum rapidly reinforces this responsibility.
Personally I was caught only once with a bad check-in by an Australia-based programmer, and I was easily able to apply a temporary fix until another member of that sub-team logged on and resolved the issue.
Overall my experience is no worse than an office where a late night programmer can mess up the code. This is a consistent theme here -- mistakes can happen whatever the working structure; a well-organized virtual company is no more susceptible.
Documentation is also important. The project plan, individual tasks, schedules, and core technology primers are all available on an FTP server. Shorter transient documents, images and diagrams can also be uploaded to the forum. New members of the SMS team are also provided with a number of documents to explain their responsibilities within the SMS framework.
My experience of traditional companies is that induction is often left to the immediately senior individual, and is therefore delivered piecemeal and inconsistently -- if at all. It seems that a virtual company needs to be well-planned and organized, but not significantly more so than a traditional company -- or rather, it's more that a traditional office should be equally well-run, but can often get by with more deficiencies than a virtual company can, perhaps.
When the deal was signed with EA, its collaborating and management staff were easily integrated into the SMS communications system. In other companies where I have experienced joint development between U.S., European, or Asian components, the lack of an established remote communication framework has led to difficulties.
This was not so at SMS, since the team was pre-adapted to working with members in different locations and time zones. In modern game development distributed responsibilities are almost inevitable -- the philosophy at SMS is to embrace that diversity rather than trying to fight against it.
The use of international contractors has a number of advantages for both SMS and the individual worker. Unlike traditional employment, the SMS worker is free to choose how and when he or she practices his or her craft, as long as the agreed workload and schedule is fulfilled. You simply register your normal working hours on the forum when you join.
Short absences are fine, as long as there is proper notification; the occasional personal chore or looking after a sick child is far less disruptive than in a traditional "bums on seats" environment. Longer absences and temporary re-arrangement of the working time is also allowed; your IM status advertises to all exactly when you are actually working. This flexibility applies to all staff: employees and contractors.
I guess many managers will now be turning purple with indignation -- how can you run a company when everyone works to their own personal timetable? How do you deal with a rush job in the crunch?
The fact is the games industry is already a global endeavor with developers, publishers, outsourcing providers and testing centers often separated by multiple time zones. Time lags are already present in your working processes; they are simply between groups rather than individuals, so in practice this leap is short.
Flexibility also works both ways. An individual is more likely to agree to work an evening shift from home where he can stop for dinner in comfort than when he is facing a long drive home after an exhausting double shift.
And when there's a multi-skilled programmer to pick up an urgent job in many different time zones, is working efficiency reduced or actually increased? Certainly my experience at SMS is that even outside of crunch time, there is much more of an "open 24 hours" feel.
The company must trust its staff perhaps a little more than normal, but anyone failing to deliver the work they have committed to can be quickly spotted and dealt with. The only true metric of staff efficiency is in what they produce and how quickly they do it; I have worked with several individuals who warm their office seats for long hours but fail to deliver very much in concrete terms. Is it realistic to claim that having staff where you can see them somehow nullifies the impact of lazy or underperforming individuals?
Clearly the virtual office needs strong leadership and well-organized working practices, but if a company cannot provide this it is probably equally likely to encounter difficulties whether it is in a single building or many. In his Gamasutra article, Simpson states, "Management is especially hard remotely, particularly if you have people who require micromanaging in order to make progress." Well, if your staff do require close micromanagement, you may have the wrong staff.
To be fair, SMS is probably not the best of environments for nurturing juniors new to the industry -- so they don't do that. However, Simpson is right in saying that the virtual company philosophy has to be fully inclusive of all the elements of development.
Instead of prowling the development floor, the SMS development manager prowls the forum discussions, responding to issues, making decisions and defining goals that all can see. Furthermore, with the full scope of information at his fingertips, he can operate much more efficiently than a manager in a non-virtual office might.
At SMS, there is solid evidence that the virtual company approach works: the Alpha period for NFS Shift was one of the shortest ever experienced for an EA product. Late night and weekend work did happen, but it was by no means the worst crunch I have personally experienced and the company certainly does not rely on long hours as the norm.
The philosophy at SMS is that out of hours work is strictly voluntary and never enforced, but generally the well motivated staff are happy to oblige on the rare occasions it becomes necessary.
Ian Bell is a firm believer that application of thought and planning ensures extended hours are minimized, and the constant firefighting that I have experienced elsewhere is therefore avoided. Another indicator of the SMS successes is that all the platform submissions passed first time -- quite a rarity, and indeed even more so for the first game produced by a new developer.
SMS also benefits from a de-facto global presence in other ways. SMS staff or contractors are available in most major countries for marketing purposes and for more practical duties such as collecting reference information at the local track. Members can quickly give local feedback on products or other news affecting the company. They also offer a wide cultural context for game design, helping to coordinate how new ideas might be received by a diverse customer base.
The recruitment policy at SMS is unashamedly elitist, as it aims to pick only the best, most experienced developers. The flexible remote working policy clearly enables this strategy as relocation becomes irrelevant; workers only need to move as far as their home office. Not only does this save on recruitment costs for the company and travel costs for the employee, it importantly means SMS is free to attract talent from anywhere on the globe.
Even interviews are performed remotely. There are no issues with work visas, and a new recruits from distant shores can be up and working much more quickly. Diversity is not just geographic but the global reach allows very specific skill sets to be sought -- for example the designer responsible for setting up vehicle physics is actually an ex-race driver -- a rare beast to have to find from a limited local talent pool.
The few of us in the UK who are contractors are also allowed to work on projects outside of the company as long as there is no intellectual property or competition clash, and commitments to SMS are fulfilled. This is beneficial both to SMS and the team member. Diversity of experience promotes growth of the individual which can then be utilized by SMS.
A mobile phone project on the side or perhaps a few hours teaching at the local university is perfectly feasible. Not that you will need the extra work -- savings in infrastructure costs can be passed on to staff in enhanced benefits packages.
Obviously, the use of fixed term contracts also provides the flexibility for SMS to upscale or downscale quickly as projects dictate. But such contracts also open the possibility of short career breaks for the individual.
For the record I have been working with SMS now for over a year. I have met the technical director and development manager once -- for go-karting and beer -- and have never met my programming lead face-to-face at all.
And yet I have felt more involved in the wider project than I have at any other developer were I have sweated it out with 80 others in a darkened room. As a result, I feel more committed and excited about the projects, and while occasional lows still happen, there is no-one around to see me sulk -- so it doesn't last long.
Clearly the distributed workforce and virtual office of Slightly Mad Studios will not suit all developers, but I suspect many readers will be surprised to hear how successful such an arrangement can be. The company places a great deal of trust in the staff, but in my experience that only enhances commitment.
The extreme level of flexibility leads to happy, well motivated staff, with inevitable advantages in terms of productivity. Ian Bell is able to recruit from the cream of the largest possible pool of talent, with attractive rewards and fringe benefits, as well as the lure of joining a truly AAA team.
As Ian boasts himself, "very few people leave SMS!" For companies struggling to find the key expertise vital to their prosperity it may now be time to follow SMS and think outside of the glass and concrete box.
As for me, well I'm just planning my move to a nice little Caribbean hideaway -- with broadband of course!
Read more about:
FeaturesYou May Also Like
