Game Design Technique: The Ranjit Range

loop

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

grab9

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.

photo

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

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

The Dreadful Gravity of Hit Points

Take Any One You Want

When we tell people we’re working on game inspired by the roguelike lineage of games, we usually end up making a number of qualifying statements. After all, LIBRARY isn’t set in a dungeon of geometrically ordered tiles, a map of corridors and chambers where you might stumble across a weak goblin or a terrifyingly powerful dragon, a magical sword to smite those enemies with or a healing potion to quaff when the fight is over. The inspiration we draw from roguelikes is primarily in the idea of exploring and attempting to master a procedurally generated space that’s different every time you play. We also love the rich, combinatorial grammar that’s been born out of the rougelike tradition: a wide array of items, potions, traps, equipment, enemies, spells, and more that can combine to produce unpredictable results, sometimes deadly and sometimes life-saving in the nick of time!

For a while I was telling people “it’s similar to a roguelike game, but in a setting inspired by Borges’ Infinite Library.” (In case you’re wondering, a lot of those conversations also ended up either explaining roguelikes, the tale of the Infinite Library, or both.) Later I started saying “it’s inspired by roguelikes, but in a procedurally generated space that’s made out of linguistic meaning.” In October, four of the Brooklyn Game Ensemble were at the Indiecade festival of independent games in Los Angeles. Since one of the most common questions there is “so what game are you working on?” I found myself starting to tell people that we were working on a different kind of roguelike that sought to avoid traditional systems of combat, hit points, and damage — instead using systems of words, letters and meaning.
Continue reading

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

Summer in Brooklyn

It’s been a sleepy summer for the Brooklyn Game Ensemble. Nathalie and Eric were out of the country until last week, and though the rest of the team’s been in New York, we’ve had our hands full with other projects, vacations, and summer hijinx. Still, we managed to get together and meet a few times; I can scarcely believe that I took this photo of the Brooklyn Bridge during one such session. How many people get to work on a rooftop with such a great view of the East River and Manhattan’s skyline? BGE programmer Kris Schlachter does on a regular basis, since it’s his rooftop, and I felt pretty lucky too!

Like a lot of independent game development teams, the Brooklyn Game Ensemble is nomadic, distributed and goes without an official headquarters. Earlier in the sumer, Eric and Nathalie were bouncing between Berlin and Paris while setting up their room-sized art-gallery game, INTERFERENCE. We caught up with them on Skype occasionally, and enjoyed a fascinated squint through an iPad camera at the results of their architecture+game-design+art+mischief collaboration: five hanging game boards of riddled metal filigree studded with poplar cylinders. On other days, we’ve all worked from home and instant messaged, but we’ve always found that we can better focus our thoughts and energy on LIBRARY when we’re able to meet face-to-face. Before the school year ended in May, we were convening regularly at NYU’s amazing Game Center, where we’ve now returned for the fall semester. Through most of the summer we were clasically rootless freelancers: meeting in back yards, rooftops, and even hotel lobbies with free wi-fi on several occasions. (Pro tip from Josh: in fancy hotels that like to think of themselves as experts in hospitality, as long as you look like you’re supposed to be there, nobody will ever kick you out of the lobby!)
Continue reading

Of Chroma, Cameras and Connotation

We’re pleased to announce that Brooklyn Game Ensemble has added a new collaborator to our roster: Vincent LaCava of This is Pop, who is stepping in to guide the art direction and visual style of LIBRARY. Vincent has a well-honed and extremely stylish visual sensibility and we’re excited to have him aboard. Until recently, the visual look of our exploratory prototype reflected an emphasis on rapid iteration and functional placeholders, with relatively little time devoted to feel or style — except insofar as those things arose from the systems we’ve been building and tweaking. In other words, we’ve been working in a rich space of meaning, but with visuals that are one step further than bare-bones “programmer art.” Nathalie has been the leading pioneer of our visual style to date; she’s contributed immensely to decisions about the construction of our library’s procedurally-generated space, the perspective the player sees the library from, and a lot of directions we’ve explored with regards to color — but in recent weeks she and Vincent have been collaborating on taking the visual side of our game one step deeper.

The installation art of Olafur Eliasson come up repeatedly in our discussion of light, color and space. His works have an inimitable way of harnessing qualities of the atmosphere you move through — the transmutation of light and color, the refraction and physical feel of tiny particles of water, even the temperature of the gallery rooms his pieces occupy. Nathalie described one of the pieces she and Eric experienced as floating in a space consisting purely of colors, where the walls and ceiling and sense of structure seemed to fall away or become irrelevant.

Our spatial explorations, on the other hand, have been driven partially by our instincts about mood and feel, but primarily by more formal concerns about objects in the space, player interaction with objects, and clarity of meaning. For several months we were using color as a quick and easy shorthand to denote properties of different kinds of books: were their natures hidden or revealed to the player? What could they do, and how were they important? Did they belong with other books as a set? Was this book the one you’re looking for? As we grappled with the handles and edges of our nascent system, we used simple signifiers of distinct, solid colors to mark our progress and stake down the amorphous, billowing tent of our design problem.

The library seen in earlier posts on this blog have been full of vibrant splotches of color, sometimes rainbow-like, all representing nuances of data in our game (and in the library it represents). At times we’ve relished the candy-like colors, randomly drawn from the full RGB palette — no, really, a lot of the colorful images we’ve been using operate on three random numbers between 0 and 255 for red, green and blue values! The arbitrary, digitally-driven nature of our color values has highlighted the fact that each colorful book is a data object, at times making the navigation of the library feel like a cyberpunk exploration of a world-like database. We wanted to try a different path, more evocative and moody — one inspired in part by Eliason’s work with color — so Nathalie and Vincent led our prototype towards this look:

The recent builds of our game are far more monochromatic — but across the same range of colors as before, simply one at a time. (We plan on restricting the palette in the future to a more curated set of shades.) Using 3D lighting filters and scripts that twist more conventional notions of fog, palette swapping, shafts of light and other effects, we’ve created a world where the player (represented still by a little pawn) floats through single-hued chambers in clouds of color. In lieu of darkness at the edges of the world, away from kindled light sources, we now have an ever thicker fog of color, its intensity increasing until the shapes of our book-stacks bleeds away into formless hue.

We’re still not sure how permanent or useful this look is. As a literal representation of an information space, it’s far more murky than previous builds — but then again, a detailed overhead map would probably be the “clearest” way to represent the procedurally spaces we construct, and that’s not our goal. LIBRARY, at least in its current form, is as much about uncertainty, glimpsed shadows and murky areas beyond view as it is about understanding exactly where you are in a space made of linguistic meaning. More precisely, perhaps it’s about a contentious voyage between those two poles. Along the way, drifting through clouds of color adds texture and shifting, highly interpretable mood to your movements, but also denotes a change of place. Each room is thoroughly infused with a distinct diffuse color; first you are here, and the world is blue. Now you have walked a few paces into a new chamber, of new meaning, and the world is ochre, or mauve, or lavender. Associations with color abound in games, but these colors arise from an algorithmic process. What do they mean? Perhaps only what the player allows them to.

Deprecated: the Cutting Room Floor of Game Development

We’ve recently made some significant changes to LIBRARY and realized that it’s around time we clean up our virtual workspace. After nearly a year of iterating, pruning, trying something completely different, picking up previously discarded ideas, and initiating new experiments, we have a lot of bits and pieces of code and gameplay that aren’t in use. We might come back to them at some point, or use their presence in our accumulated code as raw material for a completely different feature. In the meantime, we’re sweeping up our cutting room floor and putting things away. Among other things, Eric has just finished streamlining all the variables that we weren’t using, and the look and feel of our LIBRARY has gotten noticeably cleaner and less clutered: the virtual world we’re generating mirroring the reduction of chaos in our code and configurations.

Although we’ll probably post some more images of what our rough-hewn virtual library looks like in days to come, for today we thought it might be nice to show the raw sweepings, the deprecated configuration variables that have piled up over the months. These are the knobs and levers that we’ve been tweaking in order to control various elements of the experience. Because our game is highly procedural, with maps, behaviors and clouds of interrelated meaning arising from algorithms and processes, we don’t have anything like traditional “level design,” just lots of different data-sets. These are the pieces of data that we’re no longer using; glancing back through their names is an archaeological glimpse into many of the ideas we’ve experimented with. Take a look and keep in mind: these are the things that no longer exist.

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.