Author Archives: Eric

Game Design Technique: The Ranjit Range


Most of the blog posts we put up here are high-concept entries about game design or other abstract ideas. But today we wanted to write about something more concrete and practical – a method we’re using to adjust and balance variables in a game under development.

On a team project, it’s always good idea to externalize tweakable variables to a file where everyone can access them and try out different settings and combinations without having to alter the game’s code. Externalizing variables like starting player stats, enemy strength and movement speed, or amount of rewards for various actions let you try out various possibilities as you search for the sweet spot of resistance, challenge and reward to give your game system moments of meaningful choice.

I’ve been doing this kind of thing since I started making videogames 20 years ago. At the Brooklyn Game Ensemble, we use a particular technique for describing a certain kind of random variable. In my own practice as a game designer, this technique evolved over the lifetime of my now-defunct company Gamelab, although it’s been used in one form or another by other game developers as well. We now call this type of random variable a “Ranjit Range” after Ranjit Bhatnagar, Gamelab’s former lead programmer and technologist. Ranjit Ranges are extremely useful for structuring how you can tweak and list variables in any kind of digital game.
Continue reading

New directions for Borges


It’s been several months since we’ve put up a posting here, but believe it or not, we have continued to develop our game. (New working title is simply “Borges” – in reference to Luis Borges, who wrote The Library of Babel story that inspired the game.)

After pursuing our previous version of the game with mixed success, we decided this spring to rethink everything and start again from scratch. Part of what moved us to take this radical step was a talk by designer Dan Cook at the Game Developers Conference in March. Dan spoke about the process of developing games with experimental game mechanics, and knowing when to walk away from a game that is simply not working.

According to Dan, game developers often stay with a project because of previous time investment, stubbornly clinging to it even though it may not have the potential to become a fun or successful game. Dan advised that you should only keep working on games that have momentum – a feeling that the design is growing organically in directions, even solving its own problems and extending into lots of potential directions that feel interesting. If a game has momentum, the potential to evolve into something really compelling, the team will be playing it in their spare time and dreaming up new ways to change and improve it as well. That doesn’t mean that you won’t encounter challenges and roadblocks in the development process, but if a game project doesn’t seem to have any momentum in the early stages of prototyping, then – according to Dan – the team should consider setting the project aside and starting a new one.

As a group, we realized that our game suffered from a serious lack of momentum. Despite more than a year of part-time work, and a playable prototype with lots of complex features, the game was confusing, awkward, and not enjoyable to play. As we’ve written here, it was interesting, but not fun. It was time for a serious re-evaluation.


We returned to our original inspirations – the Borges story, the idea of a game about language and meaning, a design with the procedural recombinability of a roguelike – and each of us pitched the group on an idea or two. The pitches turned into a paper prototype – which was incredibly enjoyable – and the direction we decided to take ended up combining a few of the pitched ideas.

The good news is that a few months later, we have a working prototype that does have momentum – we are moving forward more swiftly, the design is unfolding with a kind of natural flow, and we are actually enjoying playing the game.

What is the new design? We’ll go into more details in future blog posts, but in some ways we have moved further towards a classic roguelike model. The game is turn-based and takes place on a grid as the player explores the infinite library. You navigate through rooms filled with nonsense, looking for words that actually mean something, while avoiding agitated words wandering about. The game feels more contained, and smaller in scope – but also quite fun and intriguing.

The new direction definitely stands on the shoulders of the previous version of the game, but it also represents something quite new. Here’s hoping we can keep the momentum going!

Feature in Polygon

Screen shot 2013-01-14 at 8.12.36 PM recently published an article about the Brooklyn Game Ensemble and our library project. All I can say is kudos to writer Marcus Beard for being able to squeeze an entire feature out of the somewhat incoherent babblings of Naomi and myself during our interview with him several weeks ago. Our overeager enthusiasm about the ideas behind the game, combined with the fact that we didn’t have a prototype to show him, must have made Marcus’ work particularly challenging.

But the article makes a good read, as Marcus takes a look at the theory behind the project, relevant titles that Naomi and I have worked on, and aspects of our process that are moving the game forward (or perhaps doing just the opposite, as “iteration fetishism” implies).

Since the interview took place, we have actually made leaps and bounds in making the game more playable, more coherent, and more of a finished design. But more about that in our next post.


Turning a corner

In an attempt to hammer out the basic game structures, we held a number of intensive game design sessions recently. The result is what feels like a big deal – we have turned a major corner on our game design.

The image above is the first page of a multi-page game design schematic that outlines the new game design, as a series of diagrammatic storyboards. The new game design direction takes the previous procedural puzzle game, in which the player is sorting words into their proper rooms, and adds a new layer of interaction by letting the player actually make meaning in the library.

There are many new concepts at work here, including “blocks” that the player can “label” in order to create energy and open up new rooms to explore. Too much to detail here. Hopefully the picture above is worth at least several hundred words.

I’m not sure how this looks from the outside. From the inside, we’re excited.

Ladies and gentlemen, we have a game

Finally, some progress.

The Brooklyn Game Ensemble has been plugging away at the Library, and the good news is that we have a playable game – more or less. The game we have is very very very far from complete (you can’t really win yet, 100% of the visuals are placeholder, etc.) but we think we have the basis of what will become our final game.

Continue reading

Easy is Shit

One year on this game. Wow.

To be working on a game for a full year and still be struggling to pull a playable prototype together is not a happy place to be. To be fair, none of us in the Brooklyn Game Ensemble have been working anything even close to full-time on this project. Last spring and summer, we met occasionally to toss ideas around, and this past fall we started getting together for a full day of design and production each week.

Given this extremely part-time process, our pace of development has been slow. Still, it often feels like we are caught in an endless cycle of iteration – trying out ideas, modifying the gameplay and game logic, gradually migrating the overall concept and player experience. We’ve tried out hundreds of ideas on paper and in code – the image above are notes from today’s design discussion. But because things haven’t fully settled yet, the game still plays more or less like an early prototype – ugly to look at, clunky to interact with, and completely baffling to anyone outside the development team.

Creating an experimental digital game that is not just an interactive slideshow or a platformer with a clever twist – in other words, a genuinely experimental game – is fucking HARD. There is a tremendous amount of uncertainty, and we’re generally taking several steps back for each step forward. Perhaps the one advantage of slow-motion development is that you have a lot of time to live with your ideas, to chew on them and refine them as they gradually are implemented into code. This is in contrast to a more typical development process where deadlines are looming, everything is happening at once, and there is no time to mull over each decision. But maybe we have too much time to think things over.

I’ve been involved with many many experimental games, on and off the computer. Sometimes it is possible to stumble upon a satisfying core mechanic early in the process and  build the up an entire game around that single kernel of fun. In the case of the Brooklyn Game Ensemble, it’s a much more gradual process. We’re slowly and painfully constructing the machine of our game, based on our group faith in the core ideas of the project, but very little about the prototype is actually enjoyable.

Why is this project so difficult? If you look at the design goals we set out for ourselves, they are based on making a game with a procedural (ie, strongly nonlinear) structure, based on a content theme (being in a library) that isn’t typically found in games. Many standard game elements that could form the foundation for a design, from the structure of the game space to things like enemy combat and a straightforward point score, just do not fit our project. It’s as if we’re not just writing a book – we’re also having to cut down the lumber to press our paper pulp, and mix up the chemicals for our writing ink. But perhaps that is the only way to end up with something genuinely new.

It’s easy to lose heart. But as my Uncle Lenny likes to say, “Easy is Shit.” If it’s not a challenge, it’s not worth doing.

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

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

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