Category Archives: Best Of Comments

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? ;) ).

Best of Comments: Ad-hoc and GDC

Posted on by
Reply

It’s time again to highlight the people that keep us authors on our toes and instigate the excellent discussion that we really want as part of this blog.  I know I said I wanted this to be a weekly feature, but it looks as if we’ll be doing them a bit less frequent than that, which is fine.  But for now, on with the show!

Jay responds to my post on Ad-Hoc Tools Teams saying:

I want to argue that an ad-hoc tool team is ok provided the following:

* It is always good when an idea for a tools comes from the people who are going to use it.
* Even better, if they can come up quickly with an early implementation that is functional and effective.
* The official tool team can be shown what the tool does and why it is needed. Then the early implementation done by the ad-hoc team can be promoted to a fully featured tool with the support of the official tool team.
* The ad-hoc tool team understands that its main goal is to respond to a critical need (not to replace the official tool team if there is one).

I agree that giving the developers that are going to use the tools the ability to prototype them is an excellent idea.  An official tools team should never take the place of developers doing prototypes.  However, I think Jay gets to the heart of his issue with his last bullet point:  you can’t have your ad-hoc teams be support team, or worse the only tools team available to you.  Prototyping is always important, but once the prototype is proven, move it over to a team that can actually support the “product.”

On the same post, Ben asked the question:

[W]hat would you say are the main problems with permanent tools teams? Lots of people have had really bad experiences with centralized tools teams, especially at big companies.

I think this comes down to a cultural issue, and I see that it’s going to need a full post.  In general though, I think the biggest problem that comes along with centralized tools teams occurs because they’re not considered part of the larger team.  This hurst both your tools team (which feals left out) and your main team (which feals the tools team is aloof and unresponsive / uncooperative).  Always have members of your tools teams in close contact with the rest of the team (on the same scrums if you’re doing agile).  The helps bridge the gap between tools team and dev team, and will result in better communication and better tools.

Jay also posts another reason to consider contracting out custom tools developmen:

Often, developers need a tool right now to help with the game they are working on. Then, they move on to another project and the tool may be lost. However a contractor can anticipate the tools evolution with regard to game play, competitive requirements and technology progress.

Lastly, David asks about GDC:

Can you guys make an effort to grab any resources (slides) from these talks and post them here?

In certain cases, yes.  I’m sure Geoff will post the slides to his talk, and I will certainly post the notes from the Tools SIG Roundtable, but everything else is up in the air.  I will ask that, if you go to any of these talks, please send me your notes and I will be happy to post them!

Best of Comments

Posted on by
4

Quite often in the world of blogging, comments get ignored by the general readership. And that’s a damn shame, because often the comments are just as insightful, if not more insightful, than the actual post. To combat this, and in an attempt to open up dialog about the problems we all face as tools developers, we’ve decided to dedicate a post every so often (hopefully every Monday) to highlight some of the more insightful comments.

To start, Erik, in response to Dan’s 6 Reasons, give’s a 7th reason your game tools suck:

7. Not enough dogfooding
Often, the people who develop the tools don’t actually use them. This can lead to a number of problems, including an overly complex interface and a host of usability issues.

I absolutely agree here.  If you want anyone to make something better, make sure they have to use it in their daily work routine.  If this isn’t possible, I’d say at least make them sit, silent, in the same office as a user and witness all the user frustrations first hand.  Sure, you might loose a day of programmer time, but certainly gain a lot more than that in team productivity.

Anthony Brien comments on build process, making points about team communication and what I call isolated builds:

On large teams, you also need a way to effectively communicate with everyone the status of the build, you may want to block all other checkins until a fix, and if your team is large or in disconnected location, a system to know if someone is working on a fix to avoid multiple programmers working on the same fix.

…

[O]ften developers will break the build cause they simply do not have the time at each checkin to compile the multitude of targets (platforms, configs, tools, etc). It would take hours to validate at each change. Some programmers will rely on the build system, but this can paralyze the entire team.

The CI server Team City, though it lacks the automated pipeline system from Cruise, actually has a built in system to allow programmers (or others actually) to claim responsability for a broken build, and say they are going to fix it.  However, I think the actual solution to your problem a combination of an issolated build and a checkin gauntlet.  An issolated build gives you the ability for anyone to request  the speed and processing power of your build server using the code / assets on their machine.  This allows users to check their builds without checking in, which is nice (and saves you from the hassle of code lock downs).  The  check-in gauntlet is even better, and essentially it’s the ability to reject entire changesets from entering source control because they break the build or fail some other requirement (code review or user testing for example).  Unfortuantely, both of these require custom solutions, though apparently Microsoft’s Team Server has the ability to set up such rules.  It might also be possible with certain use cases of distributed version control (Mercurial, Git, Darcs or Bazzar) or with Perforce’s new bundling system.

Geoff’s posts on events and delegates brought in some questions about the use of boost, and questions about whether boost would be easilly portable to consoles, including PS3.  Here’s snk_kid’s response:

Most/all components in boost are independent of each other and self-contained.  However, they try to target many platforms and compilers so they have a relatively complicated header files and preprocessor configurations to deal with the varying compiler C++ ISO standard conformance and have workarounds (if they exist).

Pretty much the majority of boost components are generated from macro and template meta-programming (but some components do generate static/dynamic link libraries), most likely using Boost.Preprocessor (a very useful preprocessor library and works with pure C compilers) and boost::mpl (template meta-programming library).

I don’t know but (ignoring all the potential issues with compilers for consoles and hardware constraints) it might be a bit daunting to try and make a port but you can easily talk to the authors on the dev mailing lists. If there is something you’re not sure about.

So far, we’ve had a great first week with lots of great comments.  Thanks everyone for helping make the relaunch of our blog a huge success, and I hope you’ll enjoy reading in the future as much as we’re enjoying writing.