A Case for Evolutionary Tools and Processes

Today, we have out first guest post!  Today’s post is from Jay Taoko the founder of inalogic inc, a software company specialized in game development tools for artists and programmers. Before inalogic, Jay was a programmer at Ubisoft where he worked on Splinter Cell Chaos Theory and Rainbow Six Vegas. Before that, he worked for EA Montrealand for a flight simulator company. Jay’s interests are in real-time 3D graphics, rendering theory, and custom UI components development.

There was an article in February 2009 Game Developer issue, entitled “Introducing new tools to artists without getting spitballed”. In it, the author Bronwen Grimes was explaining the effort she had to go through to get her team transition to a new tool she wrote. She went through all of the stages needed to convince management and the team that the tool was needed. Naturally, she had to answer that age old question: “the current system works, so why change?”.

It got me thinking. As an independent developer, I can write any tool I want if I believe there is a need for it. No need to ask anyone about it. And yet, I still face that same question: “what we have works, why should we use your tool?”. Even more difficult to answer this one when you are a complete outsider to your client team. Well I believe the answer is part of the question itself. Chances are, if the system a team is using “just works” then it is likely it has been so for a long time and only limited resources are dedicated to maintain it. In the game industry, a long time can be as short as the time to develop one or two projects. After that, team members move on to other projects or other companies, a new hardware generation comes along and there is nobody left to understand or maintain that system that “used to work”.

At the very least the team should consider, if the system they use is making their skills obsolete. The game development process does not remain still. It moves as the hardware and software industry progress and as gamers demand for more. A new tool that makes things better and faster can bring along a new set of technologies and methods that game developers have to learn and master. It may take some time to train on a new tool but it is the only way to remain productive and competitive in this industry. Also, as a tool matures, training becomes a matter of discovering what each new version has to offer.

Part of the role of a tool developer is to anticipate its clients’ needs. And that is what keeps a tool developer active and alert on technologies and practices that can bring definitive advantages in game development. I use XSI as DCC tool and every time a new version is out, I know it fixes some bugs of the previous version, brings new features that will be standard tomorrow, and probably makes better use of the multi-core capability of my CPU. Although I may not have a use for all the new features it brings, I like to know about them just to stay up to date in case me or one of my clients as a need for it.

Every tool has to earn its place in the developers arsenal. Tools developers have to connect with their potential clients. Understanding their issues and showing them, not how the tool works but the benefits they will get, is crucial. That was the essence of that article in the Game Developer magazine. To answer the question, “why change a process when it just works?”, I say it is not so much about change; it is about the necessary evolution of the process.

If you would like to contribute a guest article to the Toolsmiths, please feel free to email us at toolsmiths -at- igda.org.