[Blitz Games Studios' (The Biggest Loser, Dead To Rights: Retribution) art director Webb shares lessons and experiences in applying R&D strategies to art, unifying tech and tool chains with artists to create a tighter visual ship.]

I trained as a traditional artist and have worked as an artist for more than 20 years now. The last 12 years have been in the games industry. As soon as I was in my first games job I fell in love with it. I'm constantly fascinated by the way game development requires a crashing together of right and left brain thinking to make art and tech gel together and strengthen each other.

Over the years a lot of my focus has been not only on driving the aesthetic quality of games upwards, but also on constantly improving the means to achieve that quality and then pushing the potential to do more.

This means thinking across boundaries, looking at art, tech, and tool chains together with the aim of driving improvements wherever they can be made.

My current role as R&D art director for Blitz Games Studios allows me to pursue exactly these goals, and I want to share some of our recent experiences with you in the hopes that you can benefit from what we have learned.

In the current challenging economic climate it might seem counterintuitive for companies to spend money and effort on anything beyond their core game teams. Nonetheless I am proposing that having an art research and development team that doesn't make paying games is a significant business win.

The R&D team at Blitz came about because our chief executives had the forethought to encourage and support its growth. Its remit is to investigate strategically significant, multidisciplinary issues which don't easily fit into pure engineering development, but equally cannot be explored safely in a current game project.

The first thing to understand about an R&D team is that while many of its aims involve improving aesthetic quality and pipelines, it is absolutely not just a team of artists. It must be a fully-staffed, multi-skilled development team of programmers, artists, animators, and designers, all working as equal members.

What differentiates it from other teams is its broad remit and a mindset focused on problem-solving away from core engine technology or game specifics. Let me explain further by exploring the different mindsets of different teams, and how those mindsets and a team's best abilities are linked with R&D.

Early problems exposed with vertex formats show need to test early and break things away from dev teams.

A strong independent dev studio will have a dedicated technology team. Blitz has exactly such a team. It is exclusively an engineering team -- the largest single group of programmers in the studio -- and has been in existence for over a decade focusing on the studio's crown jewels, our cross-platform game engine that every game team uses.

This is hardcore tech work. These are the devs who code to the metal, get the prototype kits first, and have crafted a constantly-evolving engine over man decades of work. Their mindset is to be highly focused on making the core and low level systems work, on delivering long term core engineering goals and providing immediate engine support on technical issues.

Again, a strong dev studio will have dedicated, creative and professional game teams. These developers have to focus on their immediate project specifics and their ongoing milestone deliverables which are tightly bound to the current game's theme and scope. The game is king; they cannot afford to be distracted beyond the game's core focus. Nor can they risk the project by using too much unproven functionality or tools. Their mindset is highly focused on the best possible delivery to the scope and deadline of the current project.

Moving to a live game's large volumes of asset production works more smoothly when the art pipeline has been researched and tested.

Typically this produces a studio with one mindset focused on core engineering needs, while others are focused on immediate project needs. Clearly both are crucial, but neither allows the space for strategic exploration of techniques and functionality that won't fit comfortably into either engine development or current game project specifics. This is dangerous, as it is exactly this space between the core tech and game specifics that has the potential to give new direction and edge to a studio, allowing it to break new ground and counter problems that arise in development.

What an R&D team can deliver is work that even before it's finished and is still in "kit form" can be used as a business development tool; publishers will always be happier with what they can see than with what you are telling them you can do. This allows you to pitch for projects that previously you would not have been able to go for, and equally to add value to projects that you would probably already have got, but perhaps now with a higher budget.

The traditional method of incremental improvement in game development is to make such changes during the life cycle of a project, which inevitably means that you cannot take big risks. This limits what you can achieve and can result in your game team or even the entire studio being locked into a genre-trap. The sort of exploration that an art R&D team can undertake allows your studio to evolve by building on your existing achievements and opening up inventive new possibilities.

By now you might be thinking that this sounds well and good, but you still have serious concerns about the cost. It's true that such R&D does not come cheap, but our experience was first that having a separate team made it easier to attract research grant funding (in our case both from the UK and Europe), and secondly that the benefits of the results far outweighed the initial investment.

Consider the facts: the money you spend on your R&D work goes straight into strategic studio needs rather than one-off production needs; it quickly starts to pay itself back in vastly more efficient and effective workflows. R&D develops a continuing technical edge for your current and future games and gives you stand-out business development tools. But above all else, this is reusable technology that you own -- it is not owned by your publisher.

In addition to the technology itself, you have also increased the skills of many of your most talented developers, who can be now be deployed across the studio to pass their new knowledge onto colleagues.

R&D teams are an ideal training ground for new technical areas which people can then take onto new projects. They develop specialists and leaders who will benefit the company as a whole and in the long term.

Perhaps most importantly, they give people not only new skills, but a new perspective on development. By moving people from game teams to R&D and back again, you can re-enthuse developers who are weary after coming off long projects and bring new recruits swiftly up to speed with your most effective techniques.

Skills leveling and continuing professional development are critically important weapons for the independent development studio.

One of the best things about such a team is that they break things, including assumptions, fixed ideas, and the barriers of team and discipline -- but in a safe environment. By breaking these assumptions / the code / the rigs / the models / the shaders within R&D, they protect development deadlines and, just as importantly, protect morale elsewhere in the company. They can break in all the new tools that your technology team delivers, so that by the time the game teams encounter them, the tools are beta tested and thus significantly improved and enhanced.

The R&D pays off in a released game with the high level goals of large amounts of character customization clearly working, and the system totally owned by the studio.

It is important in all of this to emphasize that such a team really needs clear goals and that these are understood and signed off by senior management. It's easy to envisage how in the absence of these it could all go horribly wrong: without clear goals, R&D work can become a massive sink of time and money, resented by the other developers in the studio who can feel that they are working to support it rather than the other way round.

Directorial support and sign-off are crucial not only to retain strategic focus, but also to prevent members of the team being poached when a game project runs into difficulties.

It is equally important that the goals are driven by strategic need and not by random design whim. It's not enough to say “Wouldn't this be a great thing to have?” You need to focus on the elements that will make you a more valuable studio, will win you more and better work and that will benefit the whole company across teams, genres and platforms.

The examples I am going to discuss below are from just such a development; our character generator was identified as a known need, something our publishers wanted and that our competitors already had, and it needed to be available to all teams, genres, and platforms, which at BGS is a broad church indeed.

The plan was initially agreed by the company directors and was acknowledged to be more of a "fuzzy roadmap" than a perfect schedule, because there were so many unknowns; it was understood that the roadmap would adapt and change, and that the timing would be flexible, but that the goals would remain focused and constant.

Although there are clear reasons to be wary when working to a fuzzy roadmap as opposed to a nailed-down development schedule, we found that there are also clear benefits. It means the team can cope better with the uncertainties and fast-changing plans of frequent iteration. It encourages working in short sprints which benefits a fast turnaround, and stops people becoming too precious about the iterative outcomes.

All of this has knock-on benefits for those working in demo and pitch work as well as on game teams, because it develops people who are agile and think strategically. Finally, and once again, it insulates the development teams from the risky unknowns surrounding new technology.

Blitz Game Studios' R&D Experiences

Here then are some insights into what worked for us, and what proved to be dead ends.

1. Look to build quickly, component by component, towards a demo.

Concentrating on the components that will fit together to make a demo breaks the work down into very manageable chunks and keeps the momentum up. It also allows rapid response and change to successes or failures in the demo components and these may then influence the design of the demo.

The demo needs a high level plan. The components will always be a best guess on what building blocks the demo needs, and both will influence each other.

Keep your mind on the high level goals but be prepared to be very flexible about how you get there. One of the advantages of the R&D team is that they can cultivate a much more flexible and experimental approach than a game team can afford to.

Keeping individual components small and swiftly proving that any given component works on its own not only gives you the benefit of a quick turnaround but crucially allows you to maintain much greater control of what you're doing. It also assists with bug fixing when the components are plugged together into the demo; if you know it works on its own, the problem is more likely to lie in the connection with other elements.

Work fast and don't get hung up on polish at this stage; it can be a fatal tendency in our industry to want to polish everything! Force yourselves to ignore it for now and focus on getting it working -- making it shiny can come later.

A small library of debug stock objects and textures helps; these could be skinned cylinders, checker patterns, animated cubes etc.

Look to reuse whatever already exists in the company for tests; it helps to think of things as their most basic component, so for example a specific character can be used as a test case for any hierarchy with a skinned mesh.

Be prepared to be both swift and brutal in your rejection of failed approaches (usually because an assumption is flawed); it's interesting that a large amount of the failures we encounter tend to be less due to actual tech or design problems in themselves, but rather to an assumption having been made about how things should work, which on testing proves to be false. This is really important; you want to uncover false assumptions fast and rethink options. Arriving at this point should not be slowed down by large amounts of fancy assets or agonizing about highly-polished code.

2. Use all your team strengths to test ideas.

Games development is inherently multidisciplinary; the team should be set up to reflect this truth and the work planned to take advantage of it. On a short sprint of work, the whole team is likely to work together at the initial ideas generation stage (whiteboard, research reading, competitor analysis, etc.) They will then come together again as the component parts fit together into the demo.

At the component stage many individual elements can be proved out within one discipline (art, code or design) before testing out in combination. Use this to plan their effective prototyping -- for example the art team proved out many general principals of our compositing system functionality in Photoshop before going near the code. Another strength of this approach is that it avoids the curse of dependencies, which on a game team are necessary but which in R&D can be side-stepped; this helps further to keep everything moving quickly.

Lastly, don't be snobbish about interdisciplinary criticism; if a comment on an art component is helpful and furthers development, it doesn't matter that it came from a programmer! Always remember that players just want a satisfying experience from their games: they don't care how you got there.

Stress testing systems again after the first game showed rigging issues that were then rapidly addressed with custom Maya tools.

3. Force yourself to do a live demo as soon as possible.

R&D needs discipline and focus and to prove its way, and a live demo of the system being developed is the acid test for progress. Don't duck this, confront it head on! Remember that internally you will be presenting to developers who understand "work in progress" systems very well and can usually evaluate fairly what they see. Remember also to take their comments seriously!

Presenting to external clients does need to be carefully handled, but in our experience it has proved overwhelmingly positive. Clients are pleased to see a studio working on developing technology and a competitive edge that benefits their projects without costing them anything. It provides a contrast with studios which have a purely project-by-project focus, and helps to builds trust and confidence in the whole company which will benefit you in the future.

For us, the Company Day deadline for our first live demo really focused our minds. BGS' Company Day is an annual celebration of the work of all the teams within the studio, both development and support; hence we found ourselves demonstrating the character customizer live to 200+ people in a cinema!

This was a very important goal for us and really helped to get buy-in for the R&D team within the company. Much of what we showed in the demo was incomplete or placeholder, but people understood the potential and immediately began enthusiastically to discuss game possibilities.

4. Keep the whole studio, especially senior management, in the loop.

Bearing in mind the importance of the original high level goals and the fact that there may be an unclear route to achieving them, it is essential to keep the support of the CXOs and senior management (for this reason, as for many others, goals must always support the studio's future strategic plans and not be merely the random enthusiasms of team members).

Communication is the vital tool here: let everyone know what you are working on and why. This brings other unexpected benefits such as access to others' ideas and reading; we found the breadth and depth of peoples' contributions constantly surprising.

This sort of studio-wide communication is equally vital to getting the maximum out of your pitch process, as it gives additional ammunition to managers and the pitch team when they are talking to clients. Be prepared to support this, often at short notice, with presentations, videos, screen grabs, stepping in on conference calls etc.

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.

Conclusion

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.