This installment shows the developer tools created by Jonathan Blow, which I used to build Braid’s landscapes. It’s a backstage tour cluttered with scaffolding and pulleys. It’s not pretty, but it’s True. (Disclaimer: The text on the buttons is too big because we changed the font at one point and just never fixed it.)

Last week, after writing about the beginnings of World 2, I found myself adding the finishing touches to those same areas. One of my early goals was to make the game look like a living painting, irregular and ambiguous. It’s quite a challenge in a game which is built from discrete, re-useable components. But the changes I made to World 2 this week make me feel very comfortable about the finished product.

Writing these features has started to feed back into the creative process. It’s helped me draw closer to the long-held intent which so easily gets muddied and compromised throughout a long gestation.

I’ve enjoyed your comments and feedback, too. A lot of people asked about how the art was broken up and assembled into level maps. In response, I aimed Part III at answering that. It showed how Jonathan and I arrived at the design of World 2, and how those concept paintings got broken down into assets ready to be imported into the game. This part continues in the same vein, showing how those assets got arranged into the landscapes you play through.

This is the beginning of 2-1, the first level the player visits after the home world. It looks a lot cooler than it did a week ago, but that’s hard to tell from a still image. There are a lot of animated particles bringing life to different parts of the screen. More about particles in a moment …

With the press of a secret button, we enter Developer Mode! Tim disappears and a number of control panels and developer-only items become visible. We can now toggle visibility of different elements, so let’s take them one at a time.

Foreground: Here we’re just looking at the foreground area that Tim scrambles over. Notice how there are fewer highlights on the grass and rocks, and how the shadowy areas are somewhat less shadowy? That’s because the particles are gone.

Particles: Now we’re looking at the Particles by themselves. In Developer Mode, each particle object bears a large “arrow and dot” icon which is usually invisible. For those who don’t know, a particle object generates many instances of an image, or series of images. For example, some levels are set in an autumn forest, the background full of drifting leaves. I drew a handful of leaves, and threw them into a particle object. The particle object creates hundreds of leaves, each one rotating and falling. There are various parameters you can adjust to dramatically change the end result. Pretty much any movement you see in the landscapes of Braid, except for discrete objects like characters, is particle-based.

At the bottom you can see how particles have been used to add highlights to the grass. The surface of the ground is populated by individual blades of grass, and further down there are fuzzier, zig-zag/wave-shaped particles. When everything is put together, these don’t stand out so much, but blend with the grass to make it look more vibrant and alive. That’s the intent, anyway.

Background: This is the background. The red bounding boxes delineate one piece of the sky. To reduce the number of empty pixels, irregular images are automatically broken down into rectangular sections.

Collision: This part is usually invisible, but it’s the most important. It defines the actual physicality of the world. Without this, you would fall right through the floor.

So how does the “magic” happen? I start by creating a new file and importing a group of pieced images. They all appear in a pile. One by one I lay them out side-by-side like this. Luckily I have a lot more than one screen; I can zip around with the WASD keys. Spacebar allows me to flip back and forth between this and the level I’m working on. I literally just copy and paste (ctrl-c, ctrl-v) these pieces from one file to another, as needed.

Each piece can be scaled, rotated, clipped or tinted. Each one also has a depth value which determines whether it’s in front of or behind surrounding pieces. You can see that piece below the red tinted one is clipped (it has hard edges on three sides). It’s just there to fill in a gap between two pieces that go on top of it. Clipping makes pieces a lot more versatile.

Tinting usually isn’t as dramatic as here; most frequently it’s just used to darken pieces further from the active play area.

For me, this stage of the process is a lot of fun. After the hard work of coming up with new art, I get to play toy blocks and see how it looks in action. Back in the days of creating custom Lode Runner maps on NES, I wouldn’t have thought it could be a job!

Nooo! All my hard work!

That’s better!

19 Responses to “The Art of Braid, Part IV: Developer Mode”

  1. Braid » Blog Archive » The Art of Braid, Part IV. Says:

    [...] David Hellman has written another installment about the art of Braid. This time, he discusses the way we build the in-game scenes: the different elements that we compose together, and what the editing process is like. [...]

  2. oligophagy Says:

    What does the size of each “arrow and dot” icon mean? And is the purpose of the arrow to visually distinguish each particle, or is it simply an artifact of development, like the too-big button text?

  3. David Hellman Says:

    Well, Jonathan would be the guy to talk about the origin or purpose for the icon, but it seems like it’s just there to say “this is a particle object.” The icon just has one dot and one arrow, so no, it’s not an arrow-per-particle sort of thing.

    Particle objects have a default size. When re-sized, the icon deforms proportionally. Particles within the object don’t deform, though; the dimensions of the object just determine the area within which particles will be generated.

  4. Jonathan Blow Says:

    The arrow-and-dot doesn’t mean anything. It is just an arbitrary bitmap that I picked out of Braid’s bitmaps directory to draw, in order to show the rectangle where the particle object is. It is even a lousy bitmap for that purpose since what you really want to know is the boundary of the rectangle, and that’s invisible.

    You just want to see these as rectangles oriented somewhere in space, and the particles appear at random points inside the rectangles.

  5. Lokesh Says:

    Thanks for the series of write ups, a really fascinating read.

    One question. The the pieced images seem to have translucent borders about 10px wide. When you began to layout the level and overlap the images was there a lot fine tweaking to get the overlaps to look natural and not muddled?

  6. David Hellman Says:

    It worked pretty well pretty quickly, which was a fun surprise. But it takes some judgment to place the pieces in an optimal way.

    One thing that helps a lot is that the rocks and grass have noisy, irregular textures. When I put two pieces side-by-side, I try to find some shadow or other shape in one that can link up to a shape in the other. A continuity like that is pretty convincing to the eye, and amidst all the other irregularity, you’ll ignore the things that don’t match up exactly.

  7. Josh Says:

    Thank you SO much for publishing this information. I find it extemely interesting and am honestly jealous of the level builder you have at your disposal :) Was the editor built from the ground up (if so, what development environment was used if you don’t mind me asking?), or was some of it part of an existing solution? Thanks again and I continue to look forward to playing Braid!

  8. Anthony Reddan Says:

    What’s the difference between the brick textured collision rect and the transparent white collision rects (if any)?

    Thanks for this writeup :) .

  9. Anthony Reddan Says:

    Also – in that same screenshot (the collision layer). Is the object highlighted in greeen (presumably selected) an abstract collision shape? If so how is it made – is it just a texture or is there a whole bunch of vertices defining that shape?

    Really cool stuff :) I’m intrigued. I am dying to experience Braid, luckily I don’t have to wait too much longer!

  10. David Hellman Says:

    The brick-textured collision rectangles are sort of the normal ones, while the transparent white ones are linked together — a way of creating a multi-part surface, like a curved hill or uneven ground, without little seams or gaps.

    The object highlighted in green that you pointed out is just the marker for the multi-part surface. It doesn’t have any collision properties of its own.

  11. Kim Says:

    I really enjoyed this description of the art of Braid. I have yet to see the game running in it’s full glory since I have only seen a few videos scattered around the Net that in quality does not do the art justice. Unfortunately I have to wait for the PC version since I do not own an XBox 360 anymore.

    One question David: Does the level editor use a tile based system to save the map or does it create a full image? The reason I ask is that it feels from your description like you can place the pieces as you want and not just in a fixed place like in normal tile based maps (which are normally placed side by side).

  12. David Hellman Says:

    That’s correct, the pieces of art that make up the levels can be placed anywhere … at any pixel location, and at any rotation. They overlap with transparent edges, thereby blending together.

    When the levels are drawn, the engine draws all the pieces in whatever positions and orientations they’ve been set to. So no, it doesn’t “flatten” everything down into a full image per level.

  13. David Fisher Says:

    Do you still plan on releasing a level editor, or is such unlockable by hitting the correct series of buttons on the XBLA version?

  14. David Hellman Says:

    There’s no level editor in the XBOX version. From what I understand, it would not be possible to have a Braid level editor on XBOX … something to do with Microsoft’s rules about … something. (My intentional vagueness should dissuade anyone from quoting me on that!)

    I know Jon wanted to create a level editor for the PC version, and the demand for it is well-noted. Jon is working on the PC version now, as his blog attests. I don’t have any information on its progress, though.

  15. Dev Diary 23: Editor Details Says:

    [...] fixed along grids and all the tiles are the same dimensions. I’ve modeled my editor on the Braid editor and the Aquaria editor, pretty much the gold standard for 2D editors as far as I’m concerned. [...]

  16. 2D Level editors that don’t use tiles | Hoppsbusch - Video Game Design & RPG tips, tricks and secrets Says:

    [...] Level Editor Video Level Editing in Braid Boingo Trailer with editor [...]

  17. 29A Labs » Archivo del Blog » Sunday Blog Dump (Die With a Vengance) Says:

    [...] Las dinamicas del juego son geniales, tenía la impresión por los comentarios que habia oído que la unica dinamica que existia era la de controlar la dirección del tiempo, pero fue gratificante descubrir que cada mundo tiene dinamicas basadas en tiempo pero variadas, me gusto mucho manejar la sombra (fue la que más trabajo me costó asimilar). Las gráficas realmente son muy vividas y como un extra, a alguien se le olvidó el editor de niveles en esta versión y puedes echarle un vistazo al motor del juego y te quedas sorprendido con lo que mueve, claro si no quieres romper tu compra, David Hellman, el artista, nos ilumina un poco en esa area: [...]

  18. Victor Says:

    Hi david
    I really love braid, it’s one of my favorites game off all the time and inspired me to make my own game. Your art is fantastic.

    I have a question, right now I have a problem with the collision with inclined surfaces because I want to implement all the collision logic in all the polygons of collision. In braid there is a different collision logic for walls and inclined surfaces?

    I ask this beacuse in this picture, the wall and the inclined surfaces have differents images.

    By the way this are some pictures about my game
    See ya!

  19. David Hellman Says:

    Victor, your observation is correct, sorta. Basically we had solid objects that were just rectangles that could be collided with from any side, and we had segmented ground slope objects for doing gradual curves. Building curving hillsides, for example, out of separate pieces would result in screwy collision where the pieces meet. If that’s clear. Tim would get stuck running over the seams where two separate pieces met up, if they were at odd angles to each other. That’s how I understand it as someone who extensively used the level building tool, but for a more technical reason you’d need to ask Jon.

    Neat art! So the dude and the crow are friends?

Leave a Reply

To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Click to hear an audio file of the anti-spam word