Archive of published articles on November, 2010

Back home

Fighting the tyranny of tools design


At our studio, the lead game designers are also the ones that decide workflows and design tools for the rest of the design team. However, there’s nothing that says good game designers are good tools designers (I’ll talk about this in a future post, and it may be that good game designers are necessarily poor tools designers- not sure yet).

I started my first user story for the tools team this week (a fundamental task I can’t believe we’ve gone 4 years without having the ability to do) and started out by soliciting ideas from the design team- the senior designers especially and ones who I’ve worked with as a technical artist. I got lots of good ideas and feedback, but invariably the conversion veered into ‘You should really ask [Lead Designer X] or [Lead Designer Y].’ To which I always replied, ‘If [Lead Designer X] or [Lead Designer Y] had good ideas, I wouldn’t be asking you because we wouldn’t be in this situation in the first place!’

After that, the designers usually let loose a torrent of complaints at our tools and ideas for how they should work. It is quite sad that approaching the design team directly- you know, the ones using the tools- is considered revolutionary and potentially disruptive. But it is the only way you’re going to get news ideas and find the range of opinions and use cases you need to create great tools or improve crappy ones.

There are times when very talented people are in charge of designing tools, and you can trust their vision. But it must yield positive results in the long term (and you may need to trust their vision when experiencing disruption in the short term). If the same people have been in charge, and the ideas are stale and the results are poor, you need to be the one to break their tyranny, by seeking out the people with new and fresh ideas, using them to inform your own, and believing in your vision.

No Comments

Exceptions vs. No Exceptions


When I moved onto the tools team, I was shocked to find out that the codebase is written not to throw or expect exceptions. I withheld judgement for a little while (because it wasn’t going to change and I have respect for the people who made the decision), but as I get more and more used to it, and discuss it with more and more people, I am more and more convinced it is an archaic and inappropriate convention. Instead of rehashing existing arguments, I’ll tell you a summary of my findings from research and experience:

C++ programmers have brought over this convention into C#. Not having programmed in C++ or C, I don’t know why, just that throwing is not something you do. Not a single argument against throwing exceptions I read was from the last few years or from someone at the forefront of managed language design.

Not throwing exceptions results in verbosity with error codes, or ambiguity by returning a ‘default’ value (null for reference types) if something didn’t work. I won’t talk about managing error codes because I think everyone understands it is a way of the past. A default return value is ok for simple functions with no question about why something fails, (List.IndexOf), but completely unacceptable for complex methods (did I pass in an invalid argument? Was something null that shouldn’t be?).

Not throwing exceptions makes it impossible to enforce contracts. If you don’t use error codes (and I don’t think anyone in a managed environment does, as mentioned above), it is impossible to know whether something failed for valid reasons, or for invalid arguments. If a method cannot run with a null argument, it should check for it and throw a NullReferenceException as the first line of code in the method. Without exceptions, a default value is returned- the same, usually, as if it didn’t work for any other reason! This is a completely unacceptable ambiguity in my eyes.

Every .NET authority I could find was in favor of using exceptions intelligently. This includes the designers of C#, and the authors of the Framework Design and Guidelines, and uncounted numbers of unofficial and respected opinions.

Bad design reinforced bad design. Early on, our game and engine were incredibly slow to start up. So an exception caused you to restart the game to continue debugging (and lose work if you were a content developer). Instead of developing a robust solution to this problem (making more modular code with cleaner interfaces, which could catch and recover from errors in modules), no exceptions were to be thrown at all.

And probably most importantly- the framework is throwing exceptions anyway! I can’t count how many times I’ve seen this in our codebase:

MyClass mc = someObject as MyClass;

Our code is imperfect and it is going to throw exceptions because the framework is designed that way (and in this case, a NullReferenceException if someObject cannot be cast to MyClass). And that’s completely aside from things like this:

if (System.IO.File.Exists(filename))

Guess what. Even though you check if it exists, there’s no guarantee it does after the check. So you can still throw an exception. So you still need to develop some way to deal with exceptions.

I felt compelled to write this post based on my experience, but I can’t imagine people are still creating new systems and codebases that don’t throw exceptions- are they?

No Comments

Rob Galanakis- Tools Programmer


2 weeks ago I made the move onto the Tools Programming team here at BioWare Austin (which is why I haven’t been around on the TAO site or IRC, things are calmed down now though). I moved across the building but then back into the same room I moved out of, because Tools has moved into the Tech Art pit. I’m really enjoying the new team, new codebase, and new tasks. Going from a codebase I wrote probably 75% of to working in one I’ve never seen, that is many times larger, written with different and conventions, in an older version of the .NET framework, and with many areas of dubious quality, has been quite an adventure!

I have 4(!) posts in my drafts folder that I’m trying to finish up and post. I promise at least one in November.