Category Archives: Tool Design

Best of Comments: Sweat and Development

Posted on by
1

Again, here I am late with the Best of Comments post, but, hey, better late than never right?

My post about Darius’s ad-hoc level editor by far created the most traffic and comments so far, and a lot of people made some excellent observations about the simple, yet effective tools. First, sjml reports on an interesting 2D level editor used by EA for prototyping in 2D:

[W]e set it up so that we could use Photoshop as the level creation tool.

Each layer or color could be assigned meaning in an accompanying text file — you could say that a red pixel on layer 2 was an enemy, and a green pixel on layer 5 was a poison trap, for example.

I’m a big fan of leveraging existing tools, especially for quick and dirty solutions. It turns out that Photoshop is already a really polished, stable program that most game developers already know how to use. Some relatively simple image parsing code, and we didn’t have to worry about bugs in the tool, teaching designers a new program, etc. Saved a bunch of time and let us focus on actually making levels and learning about our game.

Leveraging tools that developers already understand is always better than developing something they have to learn. This was a little bit more complicated (I’m sure) than Darius’s quick solution, but functional none the less.

Casey O’Donnell also posts about how easy it is to over-think simple tasks:

It is also frighteningly simple to over-think tools sometimes. Once I had a massive CSV file that I needed to convert into XML for importing into a database. At first I started writing a little command line tool to do it. As I was staring at the file in Excel to make sure I was doing it right, it dawned on me to just generate the XML tags using formulas. Even selectively excluding tags when data wasn’t present. What was going to take me a bit was done in less than 30 minutes.

Lastly (on this particular topic), Duncan talks about why this tool was fine for what it was, but why it shouldn’t be looked at for more than it was: a simple tool for an embedded platform:

Working with a real tool chain for data structures intended to be used in a Windows (or any sufficiently sophisticated programming environment) is much different than designing something for a micro environment.

I’ve spent the last 4 years programming 8-bit micros in assembler. I’ve used Excel to create all sorts of pre-baked data tables. Most of it only has to be done once, and the data has to be formatted in such a way that it can then be popped right into the code. It doesn’t change, it doesn’t need to be dynamic, and writing a tool just to do it would take longer than needed.

The smaller you constraints are, and the tighter the data, the less you need fancy tools to create it.

In addition, we had some great comments on Dan’s post about A New Way Of Developing Tools. Joseph Young points out the major hurdle for getting programmers to accept foreign tools:

One of the biggest challenges we face is the “not built here” mentality that many studios have. Even though the tools do not contribute to the ROI of a game, many of the developers would rather build the tool themselves than hire another company to do this. We see this as detrimental in the long run if you don’t have a dedicated team to work on tools. In my past development experience, the person writing to tools was often the game programmer who wrote a system in the game and now needed to provide an interface for designers. These tools are often thrown together with duck tape and barely work. But then these tools get used for the next 3 games, with more features taped on the side. This is where it really starts to hurt the game developers.

How would you get around the problem of the “not built here” mentality that faces so many studios?

This was my major argument against ad-hoc tools teams. Jeff Massung, however, responds with an actual answer to the question:

Certainly the “not made here” mentality is prevalent. That mentality exists everywhere – both in- and out- side the game industry. Most importantly, the reasons for that mentality are universal, and usually misguided. It’s important to attack each of these concerns head on. Point out the flaws in the misguided ones, and then show how Robotic Arm Software handles the real ones.

This post is way too long to repost here, so I suggest you read if for yourself. It’s definitely worth the read (maybe we can convince Jeff to formalize it and guest post it eh? ;) ).

Sweating the small stuff

Posted on by
25

I have a co-worker, Darius, who is creating a game for a small game system called the Meggy Jr.  Watching him work on this, I was impressed with the tools that he came up with.  He’s not a (really) a programmer, but still somehow can make tools that serve his needs pretty well.  I’ll let him explain:

This is the level editor I’m using for a roguelike game I’m building for my Meggy Jr. The level is just a 16×16 bitmap array. Each cell of the array is a different color, and each color is a different object. 6 is blue, and it’s a wall; 5 is purple, and it’s a door.
A level editor in excell

A level editor in Excel

I built this level editor in Excel. I set the cells to be 20×20 pixels, big enough for me to work with conveniently, and I used conditional formatting to map the background fill colors to correspond to the Meggy Jr’s color mapping. If you look to the right, you’ll see that I’m using CONCATENATE statements to pull together the numbers into the bracketed statements that I literally just copy and paste into my array declaration in code. With this system I can make a level in a minute, and drop it into my code with a couple of mouse clicks. It only took me five minutes to build this level editor.
I’m always pulling crap like this: I love using Excel to abstract things out and then generate code for me. I would never do it for a big project, but for my own hacking it saves me a ton of time.
As tools developers, I think we occasionally forget that a real, actual, useful tool can be made in minutes using something as common place as Word or Excel, given the correct understanding of the problem and its simplest solution.  We’re always quick to jump to the custom solution, using some complex API, even when there’s something that would work better and faster right in front of our face.
This is especially important to understand when you’re a very small shop that can’t afford a second programmer, much less a dedicated tools team.  It may feel dirty, but you should always at least think about taking advantage of the fact that Excel not only has it’s cell equation system, but an entire programming language and forms system behind it.
Now, this partially goes against my previous post about ad-hoc tools teams, which I still think are a bad idea.  The key difference, for me, is a question of team use and support.  I consider these tools similar to one-off scripts or small prototypes.  They’re find when teams are small and everyone is on the same page.  Once things get bigger, by all means, still use Excel where it makes sense, but make sure you’ve got a rock solid team supporting it.

Middleware Survey

Posted on by
3

Mark DeLoura, probably known most famously as the creator of the excellent book series Game Programming Gems, is conducting a survey on game industry middleware.  And what is middleware than one giant tool right? From his blog post:

After some discussions with game engine middleware manufacturers, I decided to post a couple of surveys to see if I could get the pulse of what game developers are thinking.

There are two different surveys, one for technologists and one for producers, and I encourage everyone to go over and give Mark a piece of your mind.  Or at least some data for him to work with.

On a somewhat unrelated note, the Tools SIG will probably run it’s own survey in the future, and it will be one of the things on the table at the GDC talk next month.

The Problem With Ad-Hoc Tools Teams

Posted on by
9

Regardless of what they think and regardless of whether it’s formalized, I think every game company has a tools team in some form or another. Every field of game development needs tools, and every field very frequently needs custom tools to get their jobs done more efficiently. Certainly, designers, programmers, and artists have the most obvious needs, but QA, and production frequently need ways to track changes and bug fixes beyond what a bug tracker will provide, or ways to automate test and bug reports. The thing is, when people don’t have these tools, they tend to go out and make them themselves, forming your “ad-hoc” tools team.

Ad-hoc tools teams cause many problems, which, in some cases, form the groundwork for the 6 reasons Dan posted earlier. So, how does this happen, and what problems does it cause?

The way any ad-hoc tools team starts is with a need. When someone as a problem they need a solution to, their first inclination is to fix it, and when someone needs a tool to solve a problem they have *right now* they’re going to rush to put that tool together to help them solve their problem. By definition, Ad-hoc tools are always rushed, and as a result these tools are usually buggy and badly designed. In addition to being rushed, anyone making an
Ad-hoc tool designs for themselves, not for general use. Since the person making the tool very frequently believes he or she is making a “one off” tool, the tool’s interface is made in such a way that only the creator understands it.

The way an ad-hoc tools team evolves is when others have the same need. Here, one of two things will happen, either others will know about the ad-hoc tool or they won’t, which results in either developers duplicate the work of others by recreating the same ad-hoc tool, which is obviously bad because it simply results in lost man hours, or ad-hoc tools enter general use without support or documentation, which is bad because now you have many people using a tool which is almost always far from what’s needed, but better than the alternative. What’s worse is when a combination of both problems occurs and multiple tools serving the same need enter the workflow, serving complementary needs but supported by two different groups. Here, you have lost man hours AND tools that don’t actually serve anyone’s needs properly.

Finally, your ad-hoc tools team devolves when the developers that made the tools get pulled away on “more important” tasks, leaving those using these ad-hoc tools in a state of limbo: unable to use the tools because they’re too buggy or badly designed, but unable to not use them because they do actually solve a legitimate problem. In this case, your developers are only slightly more productive than they were without the tools, but can’t complain because there’s really no one to complain to. The tool’s developer is long gone on other tasks.

This whole cycle creates a whole lot of problems that you might not notice unless you took a really close look at how your developers spend their day.

  1. Tools made by ad-hoc tools teams are rarely made available or announced to the rest of the team, and thus potential performance improvements are lost.
  2. Tools made by ad-hoc tools teams have no clear support chain, and often no way to report bugs or request new features. As a result, most users don’t think of this as an option available to them.
  3. Since ad-hoc tools team members are constantly in flux, there is no central location to go when you want to request a new tool or feature. This leads to lunch room conversations that start “wouldn’t it be nice if…” but go nowhere.
  4. Since no member of an ad-hoc tools team things of himself as a part of a tools team, they take no time or initiative to fix potential problems with the tools, and no time learning actual use-cases.

As a member of an ad-hoc tools team in the past, I can tell you I’ve witnessed this all first hand, and I’m sure many of you that work in locations without tools teams can say the same. Interestingly, you can actually make the case for a tools team occasionally by showing management the tools that are being created without a tools team, and the frustrations that are occurring because of them. It doesn’t always make the full case, but it can be a start.

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.