Familiar Fragments

We’ve been playing with more ideas related to flow of particles through the space of a game, which is one of Kris’s areas of keen interest as a programmer. At the moment, LIBRARY is inhabited mostly by floating clouds of dust that get in your way and are hazardous to travel through, but we’re investigating other angles on clouds and streams of particles as well: things the player might look for, or which could affect their exploration through the library in other ways. Here’s what some of those particles might look like, as a first draft:

This is a 10×10 sheet of 100 different shapes; to think about what these might look like in LIBRARY, you have to imagine them swirling around each other. (Or you could wait until Kris and Josh implement them into the game.) Looking at them spread out in a grid, however, you might notice some familiar forms; these shapes were created by slicing up letters, usually with just one cut across an aesthetically interesting axis. “Broken letters” seemed like a natural fit in a world made of meanings, words, and books; these might be the subatomic particles of our game, the pieces that are too fragmentary to have meaning. What might happen if you stumble into a cloud, a lake, a stream chaotically teeming with letters-that-once-were, or letters-that-might-be? I guess we’ll find out.

Where books come… to life?

Not long after we decided to set our game in a library, we started thinking about how to bring that library to life. We knew we were going to break the bounds of reality somehow, but the possibilities were wide open: a library that grew, disappeared, and returned in myriad forms based on your actions or whims? A library haunted by ghostly clones of little girls, or roaming animals made from ink? We explored ideas ranging from words floating and hovering over the stacks, to fleeing from a shadowy minotaur-like threat through mazelike corridors.

Last week we returned to this topic and started looking at possibilities we hadn’t considered before. We’ve spent a lot of time in recent weeks refining the semantic structure of the library: the organization of books and words, clouds of meaning. As a result, we started thinking about ways that books themselves, or the contents of books, could come to life. We’d briefly considered ideas that involved the illustrations in a book springing off of the pages, but ultimately decided that those kinds of visuals were not only well-explored, but also difficult to create a repeating motif out of without growing tiresome. Still, we knew there were other interesting points of reference out there that we could take inspiration from.

Nathalie and Eric found two videos one evening last week which explore a couple different ways of creating worlds out of books:

The second film was especially interesting to us because of all the ways that the animators found to give their “living books” character. Some of the books have images on their pages which come to life as characters or informational displays. Other books express their personality through movement, texture of their pages and covers, or differences in size from one another.

Although we’re certain that players of  LIBRARY will be interacting with and using books, we’re not sure if books will be the lively characters and companions that Morris Lessmore devotes his life to. There are plenty of other possibilities left to explore: individual letters with character traits and life of their own, or even motes of light that drift amongst the books like fireflies?

Nathalie found these photos just the other day of a forest full of fireflies in Okayama Prefecture, Japan. The images were captured with time-lapse photography, magnifying the number of fireflies in the trees into a gorgeous earthbound galaxy. We’re currently thinking about how we might use fireflies, or other clusters of floating, moving entities, as players explore our own forest-ish landscape of books and meanings.

Fireflies in Okayama

A peek into our process

The Brooklyn Game Ensemble meets once a week for a full day of development work. This once-weekly schedule means that we have to fit our design discussions, production work, playtesting, debugging, and other activities into a single workday each week.

Typically we begin with a group discussion to get our heads back into the project and touch base on the day’s tasks. Sometimes these conversations are production-oriented. Other times, they are more design-focused, as we question what is and isn’t working in the game.

To give you a sense of our process, below I’ve pasted our Google doc notes from today’s design conversation – one in which we decided on a large number of changes to the game. Last week was a bit of a crunch getting the game ready for submission to the Experimental Gameplay Workshop, so this week was a chance to take a step back and evaluate things.

Some details may not make sense out of context. But hopefully the design notes still make interesting reading. Here are a few hints that will help you parse them:

  • Each book in our library space has a single word that floats out of the book when you get near.
  • Each room in the library has books with similar words (animals, music, love, etc).
  • The player uses a number of processes for locating particular books, such as the SEEK action which creates a number of synonyms onscreen that float through the library towards their respective rooms.

Enjoy this peek into our design process.

– – – –

Game Design Notes
Feb 10

Today after the EGW crunch from last week, we did an overall assessment of the state of the game design and development. Our conclusion is that these are the areas where we need to work:
  1. Usability: picking up and throwing books, moving, action interface, etc.
  2. Aesthetics: changing fog to white, adding floor texture, better characters, etc
  3. Level framing: refining the start of a level, the quest for 3 books, etc
  4. Tuning: balancing and refining what we have: more power words, better level layouts
  5. Flatness: Addressing the flat nature of the feeling of the game

Continue reading

Debug Vistas

At some point in the early history of libraries — many millennia before the Dewey decimal system, presumably in the ancient stacks of Alexandria and Mesopotamia — curators of books and records must have realized that they had to get organized. Even an obscure or difficult classification system is better than no system at all, especially in a large collection where it could take years to find a single tome.

I’m somewhat pleased to announced that we’ve reached that point in our own library, decidedly surreal and virtual though it is. We’ve hit a turning point in our design, something we’ll hopefully be talking more about soon, and it hinges upon a way of organizing the books in our infinitely re-created library. What do the books in a single room of this library have in common? How do you navigate through these chambers?

We’re experimenting with these questions as we speak, and some of the results have turned out to be visually fascinating.

Debug Vista

The colored lines represent relationships between books that are scattered across the overlapping spheres that create our library (which you can read about in a previous post!) We’re also exploring the use of color to convey these relationships to the player, but we’re really not sure yet if we want a rainbow-colored library, a monochromatic library (the preference of our resident architect) or something in-between.

Debug Vista

As for what these relationships represent… well, that’s still under wraps for now, because we have no idea if it’ll lead to fruitful gameplay, or end up as an odd idea that we pursue for a while, but fall back from to explore other directions. Fortunately, we’ve found so far that every time we do pursue an avenue that we end up retreating from, we come back from the exploration with some interesting pieces and flavors that continue to inform the overall design. On we go!

Tagged , , , , , , , ,

Oh, the Levels We’ll Make

We’ve started to dig deeper into the possibilities unlocked by the procedural level architecture system that Kris devised to create an endlessly shuffled variety of LIBRARY spaces to explore. LIBRARY draws some inspiration from other games that generate procedural levels every time you start a new game, from roguelike games that build maps of boxy rooms and angular corridors out of a grid of ASCII characters to Derek Yu’s Spelunky, which creates a set of connected chambers that the player can descend through and explore. After less than a day of experimentation with the numerous settings in the system, some interesting variants emerged from Eric’s tinkering:

Am I the only one that kind of wants these patterns on a t-shirt?

As with some earlier diagrams we’ve shown, each little white speck you can make out in these images represents some books in a stack (or possibly a shelf? nothing is certain yet in this library). The rooms of our library are made from thousands and thousands of books that the player can interact with — moving them around, searching through them for valuable meaning, even destroying them or hurling them across the room at a tense moment. The four images above each represent about eight to ten thousand books. What’s fascinating about the four images above is that they each evoke a somewaht different character: some feel much more messy and chaotic, while others have large open spaces, or thick expanses of books separating hard-to-reach areas. We’re thrilled that all of these are produced out of the same lines of code, and hold so many possibilities. Looking at the images above, you can see chambers that you’d have to dig through piles of books to reach, narrow corridors to search down, large chambers that you might get lost in the middle of, and “weak points” where you might choose to break through a wall of texts.

We started this process thinking that we’d find an ideal set of parameters to feed into Kris’s system so that we’d have an endless supply of levels that fit our criteria. Through playing around with our hand-crafted tools, however, we’re starting to feel like we might want multiple types of spaces to explore in succession, so that sometimes you’re pushing your way through a dense, messy cluster of books, and other times you’re exploring wide avenue and corridors. We’re just scratching the surface of possibilities for how these different kinds of spaces might relate to each other, or proceed in succession, or fit into some larger structure, so the best is yet to come!

The shapes and patterns of these level-maps have some of the “digitally organic” feel of Conway’s Game of Life or other cellular automata simulations, as if our stacks of books were bacteria in a petri dish. Eric also likened the endless permutations to John Simon’s Every Icon, a procedural artwork which runs through every possible combination of black/white pixels in a 32×32 grid. Every Icon feels like a performance or recitation of the possibilities of a binary space, and the idea that it contains every possible 32×32 black and white icon is eerily like a pixellated counterpart of Jorge Luis Borges’ Library of Babel, another major inspiration for LIBRARY. I’m just relieved that our system produces interesting, playable spaces in less than 5.85 billion years, which is how long it takes Every Icon to run through the possibilities in only the first 2 lines of its grid! Thank heavens for algorithms.

Finding our way through pathfinding

One of the most common coding tasks in game is pathfinding – making sure that characters in the game can move towards their destination, picking appropriate routes, so that they don’t for example, get stuck in a corner or take a roundabout path.

Kristofer just implemented pathfinding in our game, an implementation of A-star. A-star is easily the most common game pathfinding algorithm. It allows mobile agents to plan an optimal path efficiently: rather than searching the entire space, A-star makes directed guesses about the most probable paths, and then narrows down the field step by step until a path is plotted.

What’s cool about Kristofer’s implementation is that he has created a visual instantiation of a unit’s thought process. This lets him visually debug his code by showing him how it is working. But it also makes it easy for anyone to understand.

Here’s how it works. First, the program generates our game’s procedural level architecture. (If you want more details about how that all works, see our last post about how the game creates procedural level geometry.)

Then we can run A-star, using Kristofer’s tool (that interface on the right). Running it now will make the program plot out the path from the red dot to the green dot on either end of the blue path:

The yellow tiles show the outer boundary of where the program searched for routes as it tried to find the optimal path.

The wider the “cone” of spatial range within which program seeks to find an optimal path, the better path it will find. However, the more that it looks, the more program cycles (and therefore time) it will take to complete the process. The Heuristic Distance slider lets us play with the breadth of the search relative to any path finding so we can see how changes in efficiency affect pathfinding.

Here is a different pair of points, with the Heuristic Distance set high so that it looks at less squares:

Notice the relative lack of yellow search squares. And here it is set much lower, so that it searches a wider range:

Not only is there much more yellow, but the program has found a more efficient path to take. (It goes underneath, instead of above, that last clump of obstacles.)

All of this leaves me with a couple conclusions. First, after some experimentation, it seems to me that Kristofer’s homebrew version of A-star works well even with a very narrow “cone” of search range. And in the heat of a real-time game, perhaps it is good that game characters don’t always take the optimal route. That gives me confidence that we can use a low-range, high-efficiency setting of this pathfinding that will not use up a lot of cycles and slow down the game.

The other conclusion is just that I am thankful to be working with such a visually oriented programmer! By making a quick visual debug tool, Kristofer not only makes his debugging work easier, but he can much more easily share this aspect of the code with the rest of the team for input and discussion.

Procedural level architecture

One of the driving aesthetics of LIBRARY is to create structures that are surprising and replayable. Inspired by roguelike games and their non-digital precedents (such as card-based Solitaire), we want a game that produces emergent, unexpected challenges and experiences.

We are embedding this idea on several levels of the game, including the level architecture. Kristopher has a background in coding procedural cities and terrain, and he has been working with our resident architect Nathalie to create the algorithms that result in procedural spaces for our game levels. I wanted to write a post about the amazing work they are doing together (along with input from the rest of us).

Each level begins as a series of circles. We can set the number, size, randomness, etc of the circles that we want. The software creates a pattern that looks like this (it’s a screenshot from the level creation tool). The circles are actually half-sphere “bubbles” but we’re looking at them from a top-down view here.

The next step is to connect the initial circles with smaller circles – to form “doorways” between the main circular spaces.

Pretty, ain’t it?
Continue reading

New Perspectives

What a difference a splash of aesthetic vision makes!

At this point in our embryonic existence, Brooklyn Game Ensemble consists mostly of game designers and programmers (and one talented hybrid). We’re not devoid of visual aesthetic sensibility — Eric studied painting, for example, I got my start in graphic design back when it was being called “desktop publishing,” and we all have a keen eye for usability and flavor. Still, when we jump into working on a game as programmers and game designers, we want to prototype a structure to play around with as quickly as possible. We leapt from the unformed tohubohu of abstract concept into the actuality of a 3D prototype world, and when the mists first cleared we had this:

Our library consists of stacks of books — and our first books were plain rectangular boxes in a few different colors, piled up in randomly placed stacks. We used this as our workshop to try out various ideas on how the player would interact with the environment, and what objects might exist. (As you may be able to tell from the image, one of the objects we had been considering seems to be represented as a giant ink well… hmmmmm.)

As we moved towards the procedural generation of our library-world, we also started to discuss the perspective and visual style of the world. Fortunately, our team includes an architect: Nathalie Pozzi, who’s making her first foray into digital games but brings enough experience and vision about the aesthetics of space that she’s frequently elevating our game to new levels and new ways of thinking about things the rest of us might otherwise take for granted.

Kris and Josh provided a number of adjustable variables, handles into the code generating and rendering the level which allow the rest of us to affect how our world looked without getting our grubby hands into the nice, clean code. Here’s the “after makeover” shot of our world after Nathalie spent an afternoon tweaking what it looked like:

For now, we’ve chosen a fixed “orthographic” perspective, with stark shadows on the edges of the books. The floor’s bright blue for contrast, and a blank slate in more ways than one, since we haven’t explored too many ideas for what lies underfoot. Making prototypes is one of the most exciting phases of game development precisely because they’re like rickety little boats which you’re sailing into the unknown — but revealing more about themselves to you as you sail along!

Asking questions at PRACTICE

Last weekend, three of the Brooklyn Game Ensemble (Eric, Josh, and Naomi) were at PRACTICE, an incredible conference on game design orchestrated by the NYU Game Center, where Eric teaches and helps coordinate the program. PRACTICE was an unparalleled opportunity to have great conversations about game design and hear about the techniques and challenges that designers are working with all over the industry (and beyond!) Our Ensemble might be a little biased since we know a lot of the people who helped make it happen, but I can honestly say that it sparked my thinking on at least half a dozen deep topics, and it was the most worthwhile symposium of ideas that I’ve been to in years.

Besides all of the amazing information and concepts flying around the space, we also got to show some of our work on LIBRARY in public for the very first time. One of the most popular sessions at PRACTICE involved a series of designers getting up to present their work along with a problem they’d encountered in the design. The rest of the assembled designers shouted out potential solutions and suggestions in an free-flowing exchange of ideas. We kicked off the session by showing the procedural generation of the play environment that we’re experimenting with in the current LIBRARY prototype. The image above shows an overhead view of a space made out of hundreds of tiny blocks, shaped into circular “rooms.” Kris coded this procedural generation technique based on aesthetic ideas that Nathalie provided for the space.

This process started with a whiteboard drawing we created collaboratively while imagining what a journey through LIBRARY might look like. We envisioned circular rooms with interstitial spaces that could be explored through excavation or the happenstance of “walls” with varying thickness. Each member of our team brings something different to the group: Nathalie’s vision of an architected space quite different that what we’re used to seeing in digital games; Kris’s love for algorithmically generated worlds; and my own thoughts about what kind of game experience we wanted to craft. The rest of us were quite impressed when Kris produced some code, just a few days of work later, which could replicate the kind of sketches we’d done on the whiteboard in a digital environment, producing a different set of circular rooms each time.
Continue reading

Paper playtesting

When creating a new kind of game, the only rule is that you need to be playtesting as soon as you possibly can. It’s only when you actually start playing that you know whether your ideas actually work as the basis of a game. As soon as we settled on a general direction for our game – but before the code was playable – we starting making paper prototypes. Continue reading