Tag Archives: LinkedIn

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.

Usability Usability Usability

Posted on by
3

Some of you may have read my recent Gamasutra article, Game Tools Tune-Up: Optimize Your Pipeline Through Usability but I wanted to discuss something that writing that article has really brought to the forefront of my mind.  As an industry, we aren’t very reflective on the methodologies we use regarding the development of tools.  This blog as well as other sources may be bringing about a change in that regard, but it is progressing very slowly.  There are techniques in use in other industries that have significantly increased the usability of software, and many have been around for many years.

While at GDC this year, the idea of usability came up at the Tools Round Table.  Now, I’m pretty sure John had included the topic at the round table, in part because he had gotten a very early preview (and several revisions) of my article before it went up on Gamasutra.  I appreciated the effort on his part, but I was a little surprised at the total lack of response from the group.  When asked who was using what techniques for usability, the room was completely silent.  I expected that if anyone in the industry was doing anything at all with usability, surely this was the group.

Although it was a bit disheartening, it illuminated a real issue in game development that most of us have known in our hearts for quite a while.  Very few people are serious about making game development tools accessible to their users.  Artists, designers and even programmers spend a great deal of time dealing with tool issues for the length of every new project.  The tools developers wonder why they have so much trouble, without ever realizing that there are techniques in existence that could answer that very question and could help them make better tools that got fewer complaints and more work done.

I recommend every tool developer out there take a look at these resources:

The Usability Professionals’ Association website

 Jeff Sauro’s Measuring Usability website

Also, read Alan Cooper’s excellent books on usability:

About Face 

and

The Inmates Are Running the Asylum

 

The Power of Compositing

Posted on by
Reply

Several years ago, I developed an effects tool at High Voltage Software.  I was rewriting the effects system we had used on Hunter: The Reckoning and a couple of follow-up titles while creating the tool.  The original system had given us some really great results for our first generation Xbox titles and the company wanted to reuse it in an otherwise new codebase.  However, the original programmer had left the company and the code itself was kind of a mess.  Also, there was no tool for creating the effects, just a text definition file that few knew the intricacies of. 

So, I set about creating a system that, at the bare minimum, should have a cleaner implementation than the original, would be capable of recreating all the effects from the Hunter games, and have a GUI for doing so.  The results were excellent.  We used the new system and tool on Dual Masters and Leisure Suit Larry.  The Dual Masters Team was able to take my initial implementation and add some additional features, like keyframing, to create not only all of their effects, but also their very cinematic battle scenes.  On Larry we used it for all of our in-game pickups, censor boxes, and other random effects throughout the game.

This tool was much more than a particle tool, although the particle tool existed within the same interface, and switching between the two was relatively easy.  This was a compositing tool, allowing artists to combine particles, animated models, lighting, and other simple objects together to create stunning visual effects.  Every object could be attached to every other, with offsets, if necessary.  Particle systems could be attached to animated skeletons, models could be attached to individual particles, and new effects could spawn on particle collision.  It was very powerful.

The tool was written in C++ using MFC (that’s how long ago it was), and had a window running the game engine inside the tool, so that the effects could be viewed in real-time while being edited.  The tool was still in use years after I left the company, so I consider it a great success.

We use compositing tools all the time, perhaps without even thinking about it.  Level design tools are compositing tools.  A designer takes prefab objects like enemies, traps, pickups, etc. and drops them in a level (with art created by an environment artist).  The result is a composite of all the level design and art elements with instance data for each.

The power of compositing comes from the ability to combine simple objects to create extremely complex ones whose sum are greater than their respective parts, so to speak.  With the proper tools, these complex game objects can be easily created by the content team.  The possibilities are limitless.  Cinemas, UI, behavior, and countless game-specific systems are all candidates for compositing tools.  It’s a very powerful, easy to use pattern.

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.

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.

A New Way of Developing Tools

Posted on by
9

In these trying economic times, companies are finding ways to cut back on development costs.  This often means job losses.  When one or more games need to be finished and the tools are relatively stable, it’s hard to sell cutting anyone on gameplay or content.  The tools team often bears the brunt of layoffs, especially among the programming staff.  This, of course, leads to another type of loss, a loss of expertise.

Often, tools are created and maintained by a very small group, so any loss to the tools department can cause widespread problems down the road when new features are needed or bugs are found.  Often, the person responsible for a certain aspect of the tool chain is the only one who fully understands it, and the implications that may arise from making certain changes.

The problem is that (most) game companies don’t make money from tools, and the ROI of keeping tools developers around is less apparent than keeping the developers actively working on game projects.  There are also times when the need for tools development wanes, and maintenance is all that is required.  It is tempting during those times to reallocate tools developers to game teams, but this rarely works, as the crossover knowledge between the two is minimal.

So what is the solution?  The key is to know exactly how many tools developers are needed when tools development is at an ebb.  That’s the number required for basic maintenance and bug fixing.  Additional development can be farmed out to a contract company that specializes in game development tools.

Such a company can take the weight off the shoulders of developers so they can concentrate on making games.  Maintenance and full documentation (design docs, user docs and source code documentation) can even be included in the contract.  Expertise is maintained, and even expanded as the tools developer gets a birds-eye view of the industry by working with multiple game companies.  An influx of new ideas and problem solving techniques is injected into every new contract.   

A company that specializes in tools can become an invaluable partner in achieving success for your future projects.  Cultivating such a relationship becomes the contractor’s motivation to deliver high quality work that exceeds the demands of the tool’s end users, while your own company reaps the rewards of happier, more productive employees.

For more information on the benefits of using a tools development contractor, read my whitepaper entitled Build or Buy? Finding the Right Tools Solution for Your Game Company.

The 6 Reasons Your Game Development Tools Suck

Posted on by
9

There are many reasons game development tools fail.  Perhaps not all of these apply to you, but every game studio I’ve seen has had one or more of the following problems.

1. Design as you go
All too often, game companies are in too much of a hurry to allow proper upfront design of tools.  As a result, programmers end up designing the tools, anyway.  Unfortunately, since they have to continually show progress, the tools are designed as they are coded, which doesn’t really save any time at all, and leads to a host of problems.  As tool development gains inertia, the earlier code becomes more and more difficult to change without breaking the entire system.  When given a choice between rewriting code  and creating a workaround, the least expensive of the two (in the short run) is generally preferred.  Major changes to support new features or a more desirable workflow become more and more difficult as the code becomes too brittle to support it’s own weight.

2. The system model of design
When programmers design interfaces, they tend to expose the underlying data structures directly.  That is the most logical method for someone who understands the inner workings of the system, and often gives the most flexibility the the users.  The end user, however, has a different view of the system based on his his own goals.  He doesn’t need to know the underlying implementation details, just the end result. The system model can give the desired effect, but may seem overly complicated or downright illogical to the user.

3. Leveraging the wrong technology
A lot of us, especially with engineering backgrounds, cringe at the thought of “reinventing the wheel.” Recreating something that already exists somewhere else goes against everything we’ve learned, but taking a tool designed for one thing and turning it into something it was never destined to be, will cost more time in the long run than just writing a new tool from scratch.  Often, the remains of the old tool clutter the interface or drag down the performance.

4. Complicating the interface
“The simpler, the better,” should be every tool designer’s motto.  The more interface the user has to deal with, the more difficult it is to use the tool. Focusing on the goals of the end user, should make apparent what interface items should be readily available, and which should be hidden away in a menu somewhere.  The most common operations should be the most accessible and easiest to use.

5. Extraneous features
Often, the tool designers aren’t communicating with the tool users, which always leads to a handful of features that just aren’t used.  They probably seemed really important during design (at least in the programmer’s mind), but time constraints or misunderstanding on the part of the users keep them from fully utilizing these features.  The time wasted on such things should have been used to improve the most commonly used functionality.  Instead, they clutter the interface or add additional steps to a process that should have been much simpler.

6. Designing for advanced users
Let’s face it, there are some people in your company that are more technically skilled than others, and I’m not talking about programmers.  Often, the more technical designers (the ones with scripting or programming backgrounds) are the ones who are able to use the internally developed tools more effectively, leaving the rest of the design staff to struggle.  This is also true of other disciplines, but design has it the worst, in most cases.  Game development tools should target the average user, with advanced functionality neatly tucked away where the more technically savvy users can find it, if necessary, while the more common functionality should be out in plain sight, easily accessible and understandable.

All of these issues lead to one overarching problem — low usability.  Tools that are unusable, do little good to anyone, and higher usability leads to happier and more productive employees.  Every minute that an employee spends fighting with the tools is a minute that could have been spent making a better, more polished game, something every game company struggles to achieve, and addressing problems like the ones above will help tremendously.  I’ll talk more about these and other issues more in-depth in future blog posts.