Indie Game Development: Hardware and Software Tools
When you set out on the path of indie game development, you are setting yourself up for big challenges. Not least of which is: What tools will my team use to develop a game?
Walk into the office tower of any large firm, no matter its business, and you will likely find a common denominator: Centralised, standardised IT systems. Hardware is stamped with serial numbers, software packages are mirrored, employee tools are dictated top down. As icky as all that sounds to gamers, it usually works. Large organisations, such as professional services firms, have hundreds of thousands of employees and tens of thousands of clients. Each one is feeding the business private, sensitive data. Without centralised IT, a USB stick containing draft financial statements for Apple could end up on a subway.
Is such a system appropriate for game development? Does a small, multi-disciplinary team work best if a central authority dictates what tools people will use, and how? Will Unknown Worlds (UWE) perform best if people are told what hardware and software to use? This post cannot answer that question. But it will provide you with a window on what we do at UWE, and why we think it works for us.
When someone walks in to UWE for their first day of work, they are presented with a blank slate. Some, like Hugh, have bring in their own PCs. Some, like Steve, choose to have a work PC provided, so it is, with a skeleton of tools installed. It is persons’ responsibility to figure out what tools they should be using, and install them. People have total freedom: Steve likes using a particular Integrated Development Environment, Vim, so he installed it. There is no standardisation. Sometimes, standardisation occurs naturally. For example, Cory and Hugh work together on multimedia projects, and therefore decided converge into Adobe Creative Cloud to allow for sharing of work.
Hardware choice is similarly arbitrary and diverse. The most recent two additions to the office were custom built for Steve and Andi (above), feature i7-3770’s, GTS 550’s, multiple SSDs/HDDs and 16Gb of RAM. Max prefers his development environment to be totally mobile, so chooses to use a MaxBook Pro for all his work. Hugh prefers his work PC to be utterly ridiculous, so uses a custom-contained i7-3930k / GTX 590 / fully watercooled contraption overclocked up the wazoo. Some of our hardware started life as an off the shelf purchase, such as Cory’s Dell (below). Since purchase, it has had its guts ripped out, mega-GPUs, extra HDDs, and beefier power supplies added.
This choice of hardware and software tools is beneficial in multiple ways. It frees up resources in the company that would be otherwise spent deciding what tools people will use. Having diverse PC hardware in the office, and encouraging a culture of custom modding, keeps us grounded in the PC community that our products are supposed to serve. A diverse range of hardware and software allows us to test games on a wider variety of possible end-user environments, mitigating our lack of dedicated Quality Assurance (QA). Allowing people freedom to choose how and with what they will perform work instils a natural culture of initiative, creativity and independence. People never have to feel like they are square-pegging a round hole because someone forced them to use particular tools.
Of course, some tasks are best performed by standardised hardware. Several mundane tasks are performed by off-the-shelf Dell server hardware. For example, creating prototype builds of games, or running scripts to collect data from our social media streams. Some software tools are not mandated, but have become de-facto standards, such as gtalk for communication. These standards arise organically, and neither Charlie nor Max ever tell people that they ‘must use’ a particular piece of software.
It is not always a free-for-all fairytale. When hardware and software are standardised, machines can be replaced quickly upon failure. When Steve and Andi’s PCs were built, a CPU/Motherboard incompatibility delayed their start of work by a day. Security can also be an issue. With no standards for anti-malware or acceptable use, a virus was introduced into our network earlier this year, resulting in a loss of two days of development time. (The virus never got close to machines responsible for generating builds, and Valve screens all builds pushed to Steam). These incidents are undoubtedly undesirable, but their marginal effect on UWE’s productivity do not outweigh the benefits we have reaped from our diverse hardware and software ecosystem.
UWE’s experience has been that granting total freedom over hardware and software has been good for productivity, good for employee satisfaction, and good for the products we deliver to our customers. We would venture that this is evidence of a a wider principle: When you have a highly motivated and skilled team, removing top-down management is good management.