Following up, what has been the impact of these rising development costs and a dwindling economy? What concerns have increased most for developers in recent years? […]Here we find interesting new news. Rapid prototyping enables a developer to more quickly draft and test game concepts for fun in the early stages of a project, and also use the prototype to acquire funding. Rapid iteration gives one the ability to quickly try out many ideas during development, improving the game through frequent experimentation and fine-tuning.

If rapid prototyping and rapid iteration are weighing heavily on people’s minds, what are they using now? And how many studios have live preview on the target platform in their current content pipelines?

It looks like they probably create one-off C++ applications, sketch things out on paper, or use Flash or Lua. I had suspected that more developers would be using C#/XNA due to the ease of quickly knocking out quick test applications with it, but only 5% of the responders said they are using this for prototype development. (However, 76% of developers are using C#/XNA for tool building.)

If rapid iteration is also a growing concern in game development, how many developers currently have the ability to do live preview on the target platform for their content developers (artists and designers)? According to the results, 62.5% currently have this capability. Several responders noted that they preview on a PC version of their engine and that this is good enough for most work. Certainly using the actual target platform would be even more valuable though!

This is one of many reasons why I think that increased effort in the Tools SIG will be important in the coming years. We should not only be helping people create prototyping systems (or building on those already available), but pushing for sharing of information that would allow things like live preview on all platforms, cutting turn-around time for all studios, and thus cutting costs.

As I said in the previous post, the Tools SIG will probably be running its own, similar survey soon, which will hopefully give us some ideas on where to focus our attention to make the biggest impact in tools development.

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 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.

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!

From the site:

Angel was originally made by a group of employees at Electronic Arts Los Angeles for use in a GameJam they were planning for April of 2008. The source was opened in January 2009.

Angel provides:

• Actors (game objects with color, shape, responses, attributes, etc.)
• Texturing with Transparency
• “Animations” (texture swapping at defined intervals)
• Rigid-Body Physics
  • A clever programmer can do soft-body physics with it
• Sound (.wav only)
• Text Rendering with multiple fonts
• Particle Systems
• Some basic AI (state machine and pathfinding)
• Config File Processing
• Input from a mouse, keyboard, or XBox 360 controller
  • Binding inputs from a config file
• Tuning Variables that write out to a config file
• In-Game Console
• Logging

It should be noted that Angel is not a framework for beginning programmers.  Again, from the site:

Angel is designed for experienced engineers. That doesn’t mean that it uses all sorts of crazy programming techniques or is difficult to use (quite the opposite: see #1), but nor does it hold the developer’s hand very much. It’s expected that a developer has at least some experience exploring a codebase to see how it works.

I think this is fine for a prototyping framework, as they’re made to get “out of the way” so that a programmer can do exactly what they want quickly.

I look at prototyping frameworks as one of the key tools a company can provide to programmers. It allows them to quickly and easily investigate a new system in your game without having to go through the complicated mess of your engine (and, yes, regardless of how awesome your engine is, it’s still a complicated mess). In my mind, this is a big thing, and I hope it continues to evolve over the next few years.