Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Art For Art's Sake: Why Your Studio Needs An R&D Team
View All     RSS
September 26, 2020
arrowPress Releases
September 26, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Art For Art's Sake: Why Your Studio Needs An R&D Team

October 20, 2010 Article Start Previous Page 4 of 4

5. Read all research but be prepared to go simple.

It's important to accelerate internal research by using external research as much as possible, so try and stay aware of as much research outside your company as you can.

Other games companies can be very generous with their technology talks and papers, so take full advantage of this and budget time and resources for team members attending conferences.

Once you've gathered your research, try to replicate it quickly (and be prepared to reject failed approaches just as fast). The technology and ideas may be great but equally they could be a complicated distraction from achieving your high-level goals. Don't be seduced by technology for technology's sake, hard as it is to resist!

We became intrigued by some SIGGRAPH papers on melanin content which looked to be a really interesting way of adjusting skin tone very flexibly in the customizer.

In the end however, this proved to be a distraction as we managed better results which gave more control using simple map blends and some colour pace correction.

Many areas of research will open up as systems evolve. Procedural variant generation was focused on as it fitted studio goals and attracted funding.

6. Break out things with potential.

You have high level goals and a fuzzy route to them which involves rapid testing and rejecting of potential approaches. You need to remain focused on the main goal of a research sprint, but you should also be prepared to harvest from that effort anything that looks to have potential in other areas.

It's valuable to recognize such potential even if you don't immediately have any resources to devote to it; if nothing else, record anything that looks promising and if possible allow small amounts of time for very initial tests. The results from these should also be recorded for returning to when time and money allow.

In the customizer we did a lot of work on flexible real time compositing of textures. When we showed publishers the effects on the male model (facial hair, for example), they were pleased but when we started to show them the female model with makeup, they became far more enthusiastic.

Our options for make-up were further developed as a short side project by an artist experimenting in Photoshop and After Effects; this work did not go into the first demo and live game, but that small investment of time heavily influenced further work on the global texture compositing systems, allowing us to introduce photo-editing-style functionality.

7. Sanity check what you think you have achieved.

It's incredibly easy to be sold on the success of your new systems or technology, but you must resist the temptation; your job as R&D is to break and test things. You must therefore be very open to other people's feedback, and even more importantly keep testing things yourself.

An example from our own experience: by the end of the customizer project, a lot of effort had gone into facial rigging, but when we set up a three day internal character demo to test all the new tools and systems, facial rigging turned out to be very vulnerable. It made assumptions about the base body hierarchy which had not been revealed on the demo and this seriously reduced its flexibility.

Once identified, this was addressed with some fairly simple scripted tools that allowed one button creation of the rig on any base hierarchy, and additionally gave poses and set up mirroring functionality. Without the brief internal test, those limitations would have been revealed by the first game team to use the functionality, with the likelihood of a negative impact on their schedule.

8. Use beta tools and create prototype pipeline tools alongside research.

I talked earlier about how technology teams generate the systems tools that are used by all the games teams in a given studio, and how these teams have a mindset geared towards engineering (and rightly so). The multidisciplinary nature of the R&D team means that all the skills of the end users, those who will be using the tools, are there in one place; it therefore represents the best opportunity to investigate pipeline issues and to test and break the tools before they are unleashed on unsuspecting game teams.

During the customizer work, the BlitzTech shader editor was used heavily for the first time within the R&D team. Their direct feedback and tools suggestions made the Technology Team's job easier, while the artists on the R&D team gained invaluable experience and became evangelists for the rest of the studio.

Similarly, the prototype customizer raised many pipeline issues and the R&D team created a lot of scripted preview tools before ramping up production for the first use of the system in a live game. This all helped to make the studio more efficient as well as introducing the new technology across the company.

Don't rely on memory and word of mouth. The R&D team documents every process and system on the Studio wiki and creates linked tutorial files.

9. Allow time for documentation and education.

It is just as important to document and educate within your company as it is to develop the new functionality to begin with; failure to do this will inevitably lead to the R&D team turning into direct project support, thus losing all the benefits we have been exploring in this article. Don't rely on memory!

The whole purpose of the team is to move the studio forward, which means the ability to replicate work. Documentation and tutorials are the best way of ensuring this. At BGS we produce training tutorial files with step-by-step run-throughs on our internal wiki, and encourage the R&D team members to practice their presentation skills. Artists, designers and programmers from the team have all spoken publicly about their work this year.

We also run internal workshops, some of which are system-based while others are more focused on specific (often art-based) techniques that we developed during the research. Not only does this spread the knowledge through the studio, but the confidence of those team members teaching the techniques increases as well as their skill sets.


I'll be honest. All of the criticisms you've heard of having an R&D team are true: they are expensive, they do break things, they have high staff turnover within the team and are almost impossible to schedule. But in our experience the benefits far outweigh the costs and inconvenience.

They are a massively useful business development tool which has kept interest in the studio high and contributed to landing new projects. We have utilised them to bring a good deal of funding into the studio.

We have developed re-usable tech that we own and about which we are already getting enquiries about licensing. We deepened our experience in a lot of new areas and smoothed off a lot of pipelines, and thus saved time and money. We really pushed the education and development of a lot of staff and contributed to our studio's "can do" philosophy.

In conclusion: you may think you can't afford an art R&D team, but if you're a medium-sized developer and especially if you develop your own middleware, in truth you probably can't afford not to have one. It's the only way to stand out from the crowd and protect you from becoming yet another 'me too' development studio.

Article Start Previous Page 4 of 4

Related Jobs

Visual Concepts
Visual Concepts — Agoura Hills, California, United States

Camera Designer
Remedy Entertainment
Remedy Entertainment — Espoo, Finland

Senior Cinematic Scripter
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States

Senior Technical Designer
Insomniac Games
Insomniac Games — Burbank, California, United States

Lead Level Designer

Loading Comments

loader image