Category Archives: Production

When to Throw in the Towel

Posted on by
3

I got an email recently asking for my advice on bug fixing vs. completly rewriting a broken tool.  The email described  the complexity of the tool in question being caused by the addition of new features on top of an already shakey starting point. 

This sort of problem always comes down to time and money.  The perception among management may be that this is going to waste time.  After all, why rewrite something that seems to work fine, and if there are issues, isn’t it easier (and cheaper) to fix a few bugs than to write something from scratch?

Well, that may be true, but not necessarily.  After all, buggy tools waste the time of everyone using them.  If ten people waste just ten minutes per day, over the course of a single project that lasts a year, then you’ve lost  over 10 weeks worth of work during that project.  The actual amount of time may be much greater of course.  I’ve worked in some studios where tools were so slow and buggy, it wasn’t uncommon for individuals to lose several hours in a single day.

I knew a programmer who would write almost every piece of code twice.  He would completely scrap the first implementation in favor of his second try.  The first was basically a learning experience, and once he figured out how to solve the problem, he could do it much more cleanly on the second go.

Rewriting a better tool may be much faster than the initial implementation.  The team has learned from their mistakes and may have a much clearer vision for how the tool should be designed and implemented.  There may also be some re-usable code, so not everything needs to be wasted; individual modules may be able to be salvaged.

Now comes the real decision point though.  Does a rewrite make sense for the current project or should it be put off for a later time? If you’re in beta, rewriting a tool now isn’t going to help you get your game done.  Consider how long a rewrite will take in man-days and calender days.  If you can get the new and improved tool into the hands of your developers fast enough to save them more time than it took to develop it, then I say, go ahead.

Tools of 'Love'

Posted on by
3

Here is an interesting video of the tools Eskil Steenberg has engineered for his game Love:

His integration with Uni-Verse is definitely an interesting take on what life as a content creator could be like without having to deal with load/save/export via files on disk. Verse seems to disconnect where data is stored and how its managed from the user. It comes across to me as fitting the client/server paradigm of the web into content creation tools for games.

A Case for Evolutionary Tools and Processes

Posted on by
Reply

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.

Why Is My Middleware in Perpetual Beta?

Posted on by
Reply

When I was in college I was a double major — computer science and English.  I know, I know, strange combination.  Anyway, of the few things that people have said over the years that have really stuck with me, one such pearl of wisdom came from an English professor.  He said that a piece of writing can be written and rewritten and edited over and over again forever, but at some point you just have to stop and go with what you have.  Eventually, a piece of writing stops getting better regardless of your effort.  It’s what Economists call the law of dininishing returns.  As additional production effort is applied to a system the output gained from each unit of effort dininishes.  It is sometimes more beneficial to stop the current effort and apply what has been learned to something completely new.  It’s a lesson the game industry should learn.

Middleware companies sell complete packages for AI, physics, UI, animation, you-name-it, but what constitutes a “complete package” anymore?  What a lot of middleware companies deliver seems no where near complete, even for the subset of game development technology of which they are supposed to be the leading industry experts.  They release new versions monthly that game studios have to integrate to get lastest features and bug fixes.  Are we game developers, or simply beta testers for middleware companies? 

Many of these companies have great customer service.  They offer support tickets so developers can submit bugs and feature requests, but at this point, they’ve gone from middleware provider to service provider.  They customize a solution intended for the masses to the needs of individual companies, when what they should really be doing is applying the effort spent on maintenance of the current version on developing the next version.  After all, once a few games have shipped on the current product, its viability has been proven.  STOP DEVELOPMENT!  Give us what you have right now and put your development effort into making the next version that much better.

Sure, those companies that shipped games probably needed workarounds.  And the other companies out there with games in development have workarounds too.  Some of the currently supported features have unexpected results, or just don’t give you what you want. But do you really want to wait around for the “fix” anyway?  Waiting around holds up your production.  You have to remember that you are not their only customer.  It may be months.  It may never come.  It could be the fix that breaks everything else in your game.

You can’t rely on it.

So what can game developers do?  Well, the next time you’re shopping for a middleware solution for your project, and the salesperson tells you about the cool new features coming in the next or upcoming release, don’t plan on getting them in your lifetime.  If you can live without a feature, design your game without it.  If it isn’t there now, and you really need it, shop for another solution.  I don’t want to be a beta tester any more.  Neither should you.

The Tech Behind the Tools of Insomniac Games

Posted on by
1

Thanks to everyone that was able to show up to my talk at GDC. I thought it went very well, and I got a lot of good questions and feedback after the lecture.

The focal points of the lecture were:

  • Indirection of file locations using unique IDs instead of string paths to allow files to be moved around efficiently
  • Organizing data within asset definitions using a modular attribute system, and classifying hard engine types based on those attributes
  • Our flexible data-driven properties systems (Nocturnal’s Inspect) coupled with C++ reflection (Nocturnal’s Reflect) providing extremely flexible and highly extensible property editing
  • Sharing general processed data results using signature-based cache files to remove processed data from revision control
  • Perforce for code and assets storage, branching for milestones, and the virtues of less live assets coupled with our continuous integration system for keeping users working reliably through an increment of content creation

The slides are available from GDC’s website here.  If anyone has any questions I will be happy to handle them as best I can in the comments.

Happy hunting (bug hunting), folks :)

Scheduling Tools

Posted on by
1

Scheduling tools is tricky business.  Most tools aren’t even started until they’re needed, unless you’ve got some very forward thinking management (an unlikely scenario at many game companies).  The time constraints are impossible since they’re in sync with an equally impossible game production schedule, and budget constraints can be equally constricting.

So, how do we get tools into the developer’s hands as quickly and cheaply as possible, while still delivering high quality software?  Well, if you’ve heard of the quality-speed-cost triangle, you know that if you have to have high quality, and you need it fast, then it’s going to be expensive.  Most game companies choose cheap, fast and low quality when it comes to tools, but I believe we can wrangle the schedule a bit to get pretty fast, pretty cheap and very high quality.  Unfortunately, it takes a great deal of upfront planning to get there – something game developers aren’t very inclined to do.

First of all, schedule in design.  At least 25% of your total time should be devoted to designing the tool.  If you have a week, schedule an entire day (or two).  If you have a month, schedule a week.  If it’s a large project with a GUI, include a mock-up of the the UI.  The design should also include a list of features for each of the other milestones in as much detail as possible as well as goals for each one.  These go beyond features to explain what all the features are meant to achieve.  A milestone should meet these goals, and not just the features, to be considered complete.

After the design is finished, the next major milestone (there may be smaller milestones in-between) comes halfway through the development process and is what I’m calling the “first usable version”.  This is similar to the “vertical slice” almost every game has to go through these days, and includes core functionality only.  The goal is to deliver a tool that the developers can use to get their work done, and isn’t meant to be pretty or user-friendly.  Subsequent milestones will add usability features to the tool.  It take a great deal of planning to pull this off without creating work that will get thrown away later, which should be carefully considered in the design phase.

The alpha and beta milestones deliver the final promises on quality.  It’s useful to sit with the representative users and get feedback on remaining issues. Formal usability studies can be performed if time permits and those problems addressed.  The final deliverable should include documentation on using the tool, something that has been sorely lacking in the game industry.  Too many times, frustrated users turn to the developers for help on common problems which could be easily documented, saving everyone a great deal of time.  Tutorials are also important, as they can give users a chance to see how the developers intended the tools to be used. 

 As you can see, we’re able to extended the speed side of the triangle to reduce cost and improve quality, and add a stop-gap in the middle to get users up and running quickly and cheaply.  When these components are included in the schedule, then we are not only able to get something to the users in a timely fashion, but we can also (eventually) deliver something of high quality, as long as management doesn’t see the first usable version as finished.  They must be informed that the first usable is something to build on, and not at all final, and that increasing the usability of the tool beyond basic functionality will improve the development process greatly.

Of course, this is just one aspect of scheduling tools, but any more detail would too long for this blog.  Maybe we’ll talk about the other issues in an upcoming post, or you could leave a comment describing your own process.