Biography of Eric Chahi (Another World / Heart of Darkness / From Dust)

Reposted from the Gamelier


I have such strong memories of first playing “Another World”, aka. “Out of this World.” A friend lent me a floppy disk with it on it, and I loaded it up my parent’s PC without any idea of what it was. The lack of introduction only amplified the mystique of starting a game with no instructions, no on-screen tutorial, and no explanation of what you were supposed to do. I had never played another game like it, nothing so beautiful, exciting, and mysterious.


So I can safely say that Eric Chahi is one of my personal heros, and I was delighted to pick up this book about him. “Eric Chahi: Parcours d’un créateur de jeux vidéo français” is written in French by Daniel Ichbiah, in a light style with lots of pictures.

For some reason, I just imagined that Eric Chahi woke up one day and wrote “Another World” out of nowhere. But of course, the real story is a lot more complicated, and a lot more interesting.

In fact, Eric Chahi has been writing and publishing games since 1983, when was 15 years old. Back then, he programmed on the the “Oric 1” [TODO: picture] an 8-bit machine with 16 kilobytes of RAM and a link to a cassette deck for loading and saving. Like a lot of the old home computers, the components were all packed into the keyboard, and you would hook it up a TV instead of a monitor.

His first game was called “Frog”, and a friend of the family helped him sell it to a local computer importer in exchange for a printer and 2 joysticks. Unfortunately, the game never hit the shelves.

Even at this stage, technology and graphics played a huge role in selling games. Just a year after “Frog”, Eric Chahi had a new adventure game, called “Sceptre d’Anubis”, that he wrote in BASIC. But when he tried to sell it, the studio compared the graphics unfavorably to a game called “L’Aigle d’Or” that had fancier graphics.

For this reason, Eric Chahi wrote his next game, “Doggy”, in assembler. It was the only way he was able to get better performance, and thus higher quality graphics, out of the machine.

I’ll skip a few years (and a few games later), until 1987, when Chahi gets an Amiga 500. From all accounts, Amiga made incredible machines that raised the bar for both graphics and sound. Chahi learned how to make striking animations with Deluxe Paint, a drawing and animation programmed that was also used for Monkey Island. It’s through his work as a graphic artist, and not as a programmer, that he is hired by Delphine Software to work on “Les Voyageurs du Temps” (“Future Wars” in English) with Paul Cuisset, who did the programming and game design. Interestingly, Chahi and Cuisset work independently at their homes, and only met every 10 days or so to compare work. And the game was done in just 6 months!

The game was a point-and-click adventure that was infamously difficult, but received fantastic reviews and sold very well, even internationally. So well, in fact, that it gave Chahi enough money to live on for 2 years. He turned down a job as a full-time artist for Delphine Software and started out on his own to create “Another World”.

Graphically, Chahi was inspired by “Dragon’s Lair”, which had breathtaking graphics for the time. In fact, the arcade version used Laserdisc, and the Amiga port used special “streaming” techniques to load from diskettes, but Chahi imagined that it used polygons. And it was this idea, drawing polygons on the screen instead of bitmaps, that would give Another World its distinctive graphical style.

Amazingly, much of “Another World” was improvisation. Chahi started with the opening animation, and made up the story, and the world, as he went. Only when he got to the 2nd level did he have the idea of adding a laser gun. He kept the experience fresh by imagining the player’s expectations and then surprising them with something different. To get the pacing and camera angles right, he watched the opening sequence to “Return of the Jedi” over and over again. He did use rotoscoping to draw the moving car and the gun, but the rest was done by hand.

Programming-wise, he had to build his own game engine and editor in assembler. Another World was ported onto a good number of platforms, including Super Nintendo, Mega Drive, and 3DO. Since other programmers couldn’t figure out what Chahi was doing in his code, he had to make the ports himself. As playtest results came back, Chahi made a few changes that made the game easier and a bit longer. This led to some funny hacks, like the “Secret UFO Death”:

One detail that I love: Nintendo balked at the “bath house” scene, where you can the top of alien butts, and made him erase those offending pixels so that it looked like the women were wearing bathing suits.

There actually was a sequel to “Another World”, called “Heart of the Alien” that was made by Interplay for SEGA Mega-CD, without Chahi’s help. It didn’t have a lot going for it (it wasn’t even vectorial), and was a flop.

Pretty quickly after the release of “Another World”, in 1992, Chahi got sucked up into an ambitious project, “Heart of Darkness.” The story revolves around a young boy who is scared of the dark has to confront his fears to fetch his dog from another universe. Although they would assemble a talented team, the game would take 6 years to produce, and would be quite painful for everyone involved. As the author points out, the early 90s was a tumultuous time in the game industry, with games like “7th Guest”, “Doom”, and even “Super Mario 64” setting new expectations for graphics and gameplay. Console technology kept changing too, from the 3DO to the SEGA Saturn to the Playstation.

As the project dragged on, the team would have to change editors several times. At one point, Steven Spielberg and Jeffrey Katzenberg invite the team to Dreamworks’ offices in California. They were so impressed by the opening sequence to “Heart of Darkness” that they want Chahi to abandon the game and turn it into a film instead. But Chahi and his team stick to their original vision, and eventually put the game out in 1998.

After that experience, Chahi disappears from the game scene for almost 10 years. He travels extensively, and becomes obsessed with climbing and photographing volcanoes. He shows up again in 2007, when he comes to Ubisoft with a new game concept based partly around his travels. The original concept of “From Dust” is that both people and geology are ephemeral: they are born, grow, and then die and return to dust. The characters would only live for 5 minutes, and would have to pass on their knowledge to the next generation in order for the tribe to survive.

Chahi decided to work with Ubisoft so that he could benefit from their workforce and project management. Things are a bit slow to start, but once the legal department signs off on the project in 200!, the team quickly grows to 10, and then 40 people. In late 2009, though, following a meeting with top Ubisoft management, Ubisoft apparently loses confidence in the project. The team has to review and change major parts of the game design. Soon after, the team is reduced drastically, from 40 to 16 people. It was quite a blow.

It was at this point that Chahi and his team made critical changes to the gameplay. They had a level editor in which they could manipulate the terrain in real time. It was so fun that they decided to give the player this ability. And so the project was transformed into a god-game. They also had to give up the ephemeral nature of the characters, which made the gameplay too difficult. The ecosystem of the game, which was meant to be quite rich in interaction, had to be heavily cut back. But they did add an excellent feature to the terrain simulation: water could carry sediment, which meant that steep valleys would gradually smoothen out and create attractive landscapes. The final major decision was to make From Dust available only as a downloadable game, on XBox Live and then the Playstation Network. This made the game much cheaper to market and distribute.

The book ends there, but I have a little epilogue to add: I recently had the enormous pleasure to meet Eric Chahi in person! He works in Montpellier, in a shared office with two indie studios: The Game Bakers and Swing Swing Submarine. He showed me a few screens of his current project: simulating volcanic eruptions for a museum exhibition. It looks beautiful…

Share Button

RedWire Game Jam

Reposted from the Gamelier

Creating games from scratch is hard. What if we could “remix” existing games, just like we do for music?


That was the aim of the RedWire game jam that took place in Paris over the weekend of July 25-27. The event was a collaboration between four organizations: the Center for Interdisciplinary Research (CRI) has been developing RedWire; Jam Shaker organizes game jams on a monthly basis; Mozilla encourages and supports people to develop new things for the web; and the Gamelier is a game development club who run a variety of game events in Paris related to game, science and education.


RedWire is a new online game engine made specifically for remixing and mashing up games. Unlike other engines, the focus is on making individual parts like bricks that can be put together without conflicts and fitting each other. RedWire is an open source project, and all the games made on it are open source as well. When you find a game you like, you can examine how it’s made, fork it, make your own version and drag and drop parts of other games to remix them.

We organized a very unusual event! Most game jams have a very similar format : a theme is announced at the start, participants brainstorm and present their ideas, and then they form groups around the ideas that they want to work on. From then on, everyone stays with their team in their own corner until the games are presented at the end of the jam.

Because we wanted to focus on remixing games, we decided to take a radically different approach, separated into three phases. On Friday night, I presented a short tutorial on how to use RedWire. Then, the whole group brainstormed ideas for gameplay “bricks” that we could create and reuse in a variety of games. Most of Saturday was taken up translating those ideas into runnable code on RedWire. Starting Sunday night, we came up with complete game ideas that involved assembling those bricks. Sunday was about finally creating those games and demoing them in front of the others.


Around 20 people showed up over weekend. For the most part, they were programmers, but with varying levels of experience in different languages.

What came out of it? Here are a few of the gameplay bricks that we programmed:

  • Tileset system to generate backgrounds from
  • Score counter
  • Falling blocks: Blocks with letters on them fall from the top of the screen. Pressing the corresponding letters gains you points
  • Menu that you navigate with your keyboard
  • A psychedelic animation that changes color schemes with every mouse click or keypress
  • Teleporting enemies that disappear and reappear
  • Dialog system with image and HTML text

I was fun to see the games that resulted from these blocks. Click on the links below to play the games:

Two sides, by Alexis Moroz and Hugo Hilaire: The player must destroy as many enemies as possible as they travel across the screen. Then the player joins the other camp, and replays the same sequence, but this time carefully avoiding all the projectiles that they fired off in the previous sequence.

Capture d’écran 2014-08-06 à 15.02.23

Soundefender, by Maxence Bouhenic, Clement Jacob and Clement Bourgoin: A game for two players, in which one uses the mouse to target enemies and the other fires. Hovering over an enemy with the mouse plays one of 3 sounds (low, high, or medium) and the player controlling the keyboard must respond with the same sound in order to destroy the enemy.

Capture d’écran 2014-08-06 à 15.03.27

Je de doigts, by Gaëtan Vergeot and Donat Bihr: 2 players work together to hold down the keyboard keys for the letters that have fallen to the bottom of the screen. New letters keeping falling and replace the old ones, forcing the players to do a  fun “keyboard dance” of sorts.

Capture d’écran 2014-08-06 à 15.03.53

Home, by Rémi Leblanc and William Huam: A space shooter in which you must carefully pick between the enemies and neutral ships. The only difficulty is that they look identical.

Capture d’écran 2014-08-07 à 13.58.08

But my favorite is a remix of a remix. Alexandre Vaugoux took Soundefender and added his SYKIK layer on top of it to yield SYKIK Soundefender.

Capture d’écran 2014-08-07 à 13.58.53

In one action-packed weekend, we learned quite a bit about RedWire. We were happy to find that “circuits”, self contained blocks that have their own logic and memory, worked well for sharing between games. Another feature was the sound support, which lead to some really excellent sounds generated by jsfx. On the downside, people had trouble understanding how exactly the engine is executing the code. Many expected that the chips would be executed in order rather than concurrently. Also, they didn’t get how to pass information from one chip to another.

Coming off from the jam, we are considering a bunch of changes: a means to chain multiple chips in sequence, a more JavaScript-like way of wiring chips together, and integrated collision detection routines. Finally the most requested improvement was extending the standard library of chips to include the most common operations, including drawing shapes, detecting collisions, and reacting to user input.

Thanks to everyone who participated in the jam, the project is going to evolve much faster in the next few months.  For more information about RedWire, check out our tumblr blog and follow us at @RedWireIO. Or just get started making your own game.


Share Button

Experience and Education by John Dewey


Originally posted at Gamelier.

I’m not accustomed to reading philosophy, but really enjoyed reading Experience and Education, by John Dewey. It’s a slim book of not even 100 pages, but is beautifully written, exceptionally clear and intelligent.

Experience and Education was written in 1938 as a followup to an earlier book, Democracy and Education, which he had written in 1916. It’s incredible to me that already at that time there was the notion of the “progressive” vs “traditional” education. Progressive education includes learning by doing, problem solving, working in groups, and personalizing education to fit the student, among other things. Interestingly, Dewey frames these schools of educational thought in reference to systems of government. The traditional schools were autocratic, the progressive schools democratic.

Dewey starts Experience and Education by stressing the need for an “educational philosophy” based on experience. I gather that he fears a backlash from the traditional viewpoint that sees the progressive schools as disorganized and lax. He points out that creating a school around a rejection of previous ideas is not the same as beating a viable new path. The book lays out the foundations for such a philosophy. Dewey places “experience” at the center because he sees education in general as a series of experiences, each of which changes the person experiencing them, impacting what experiences the person will seek or avoid in the future, and what they will learn from them. Certain experiences can stimulate growth, widening the possibilities for the person, whereas others can stunt growth, making them avoid whole areas of potential experience.

This reminds me of James Paul Gee’s description of a “damaged learner” in What Video Games have to Teach Us about Learning and Literacy. Once damaged by a bad experience in a school subject, which made the student feel overwhelmed and bored, the student could be put off the subject whenever possible, and even build their self-image upon a rejection of the subject.

Next, Dewey discusses how discipline in schools comes down to the social context of the environment. As Dewey says: “The [traditional] school was not a group or community held together by participation in common activities. Consequently, the normal, proper conditions of control were lacking. Their absence was made up for … by the direct intervention of the teacher, who ‘kept order’. [In the new schools], the primary source of social control resides in the very nature of the work being done as a social enterprise in which all individuals have an opportunity to contribute and to which all feel a responsibility.” Once again, this sounds to me much like how Lee Sheldon sees the teacher’s role as a “dungeon master” in The Multiplayer Classroom, organizing opportunities for learning rather than directly passing on ideas to students.

And yet, not just any kind of communal experience will do. The later chapters of Experience and Education expound on the meanings that Dewey attaches to “freedom” and “purpose”. For Dewey, the kind of freedom that should be prized in schools is not the ability to do whatever one desires at a particular time, but rather the “power to frame purposes, to judge wisely, to evaluate desires by the consequences which will result from acting upon them”. In short, the power for students to fix goals and set out concrete steps to achieve them.

Finally, Dewey points out the connections between the experimental method in science and the progressive model of education. In science, ideas are not simply received as final truths, but tested as hypotheses. Experiments are carefully designed, observed, recorded, and analyzed. Once again, playing games can also be seen as performing the scientific method in miniature, though most often players do so informally.

Share Button

RedWire post for EduGamesHub

I guest-wrote a post for the EduGamesHub blog about the RedWire hackathon in London.

Share Button

New Rules for Classic Games

Reposted from Gamelier

It’s a bit hard to find, but New Rules for Classic Games, by Wayne Schmittberger, is full of intriguing ideas and creative takes on well-known games. It was originally published back in 1992. As the subtitle says “Recycle those old boards for thousands of hours of fun with new rules for Monopoly, Scrabble, Risk, Go, Trivial Pursuit, and more.” In modern terms, these new rules are remixes of classic board games.

It delivers on what it promises, but I was delighted to find it more than just a catalogue of alternative game ideas. The author applies successful game mechanics taken from one game to another, and in doing explores the space of game design possibilities.

Already in Chapter 2 “Fixing a Flaw”, the goal is to create a better game by analysing a balancing problem with older board games and testing different solutions to it. In doing so, the author shows how approaches like the “pie rule”, the “bidding rule”, and playing multiple boards at once can be applied to almost any game of this type.

Chapter 4 “Changing the Number of Players” talks about the challenge of three-player games, which suffer from the “petty diplomacy” problem of 2 players easily being able to team up on a third. The author talks about an approach used by a three-player variant of Japanese chess in which the attacks from 2 players on a third is automatically detected by the game rules, at which point the 2 players must form a team, and the third player is given extra advantages that balances the match.

The discussion of handicapping (Chapter 6) is a mine of great ideas, taken from games like Go and Shogi that have elegant handicapping systems. The author has applied these principles to games as different as Trivial Pursuit and Monopoly, which demonstrates how general they are.

Hidden among the number of game variants of Checkers are some entirely new games like Fields of Action and Epaminodas, which use these cool mechanics of moving lines of checker pieces in order to battle each other. Emergo is another one, in which captured checker pieces are stacked on the bottom of the capturing piece, and the capturing player continues to move her stacks like a single piece. When a stack itself is captured, pieces are taken off the top, so that a player can get their pieces back again.

There are also some fantastic chess variants, such as Extinction Chess, in which you need to keep at least one of each type of piece in play, and Racing Kings, where the goal is to get your king to the other side of the board safely.

The book ends with a description of “postal play”, a practice that I had never heard of. Though I imagine it has since been replaced by the Internet, it was fun to hear how players used to send post cards back and forth to each other, making moves on several games at once in order to be more efficient. Apparently some players appreciated the slowness of process, beause it gave them more time to reflect without the pressure. POstal play posed challenges for simulating randomness (such as a dice rolls). The book proposes elegant solutions to these problems, based on using public, verifiable, but random information such as the daily temperature of London of the closing proce of the stock market. There is also the “diceless dice games”, in which players write down each possible dice roll, and get to use each exactly once during the game.

Finally, the book ends with a bunch of guidelines for “creating your own successful variants”, though I think of them as general game design principles as well. Here are some highlights:

  • Prefer rule changes that give players more choices
  • Improve offense, weaken defense
  • Experiment with changing the goal of the game, or the geometry of the space
  • Try simulaneous movement instead of sequential movement, or letting players do more than one thing on a turn
Share Button

Vehicles by Valentino Braitenberg

With the excitement and activity of A-MAZE calming down, I finally have a moment to write about a rich book that I will want to read again and again- Vehicles: Experiments in Synthetic Psychology by Valentino Braitenberg. Since it was written in 1984, I’m truly lucky that a colleague from the Gamelier recommended it to me, or else I doubt I would have ever discovered it.

The principle of “Synthetic Psychology” invoked in the title is that relatively simple machines can exhibit complex behavior that we would classify as “living”, “instinctive” ,” willful”, “smart”, “attentive”, etc. The author does this by setting up a series of thought experiments. He begins with a “vehicle” with a single motor activated by a sensor that is attuned to the temperature of its immediate surroundings.

Things get immediately more interesting in the next example, where a vehicle has a motor and a sensor on both sides. Depending how the connections are made between the motors and sensors (same side or crossed), and whether the connection is positive or negative, the vehicles would circle a source of heat, charge right at it, run away from it.


This is only the beginning. Each chapter introduces new layers of complexity into these simple vehicles and then explores how the vehicles would behave in such and such circumstances. He explores non-linear activation, thresholds, connections networks, selection, resistant connections, and many others. Some of these concepts reminded me of the little I learned about neural networks in school, but the author explains each wrinkle gently enough that I don’t believe any prior knowledge is necessary to enjoy it.

Ultimately, the book nicely sidesteps the question of “intelligence” that pollutes common discussions of artificial intelligence. By the time you are in the middle of the book, you have to admit that the machines behave in a way that you only associate with living things, and yet they are made only of sensors, motors, and wire.

The appendix to the book is filled with biological references for the mechanisms introduced as purely mechanical. Given that the book is now 30 years old, It would be interesting to know what new has been discovered since then.

Oh, and there are lovely line drawings placed in the middle of the book that evoke faraway worlds and fantastic machines. This reminds me of what an incredible video game it would make, especially the complex “social” aspects of having a world of such vehicles!

Capture d’écran 2014-05-01 à 17.48.00

Cross-posted from the Gamelier

Share Button

What Video Games have to Teach Us about Learning and Literacy by James Paul Gee


“What Video Games have to Teach Us about Learning and Literacy” is a book about how video games motivate players to learn how to play them, despite or even due to their complexity and difficulty. James Paul Gee compares how players learn video games to how people learn in school, and discusses how schools and other learning environments would benefit from imitating these aspects of video games.

In that way, the book reminds me of Jane McGonigal’s “Reality Is Broken: Why Games Make Us Better and How They Can Change the World”, which also takes the tack of discussing how video games motivate players to take on difficult challenges, with the idea of applying these tactics to other domains (see my review of Reality is Broken). One difference is that where McGonigal focuses on forming personal habits (like weight loss or cleaning the house), James Paul Gee is more interested in school learning.

For me, the most interesting sections of this book dealt with the importance of identity. James Paul Gee argues that learners take on an identity with regards to a field of study. The identity can very well be positive- someone who is good at the subject, who learns quickly, performs well, etc. But they just as easily be negative, in which case the learner will be scared and put off by taking on the subject in the future. The author says that such a learner is “damaged”, and that such damage is difficult and time-consuming to repair.

This rings true of my own experience. I always did fine in school, but definitely formed negative relationships with certain subjects. In particular, despite five years of studying Spanish in junior-high and high school, I never really learned enough to converse. I therefore decided that I was a “language idiot”, and that I was forever handicapped in that area. I suppose that this demission was comforting, since it meant I didn’t have to try. When I ended up in France, it was so frustrating to not be able to understand and relate to those around me that I was extremely motived to learn. And the reality is that I can learn languages just fine. I still wouldn’t say that I’m “talented” in languages, but putting in hard work over a long enough period of time is likely the secret to learn anything at all.

The author show how the notion of identity extends to the people who work in the field. For example, doing science effectively makes the learner a scientist. The closer the learner associates themselves with the values of a scientist, the easier this learning becomes. Once again, the opposite is also true. A person could be easily put off a field by not wishing to associate themselves with the a negative identity they associate with it.

This now makes a few books that I’ve read which make this argument that school teaching techniques should import game design principles. But though I accept that video games mentioned do teach something, and may teach them very well, it is hard to find an example of an existing game that teaches something of value outside the game itself (besides side-benefits such as hand-eye coordination, willingness to experiment, or positive self-esteem). May it be that not enough games are built around real systems? Or is it fundamentally harder to get people to play a game about physics or language than it is to get them to jump on platforms, associate colors, and aim at zombies? Could it be that games mostly motivate people to learn intuitively, and not formally? Is school just not playful enough, or is it just harder to make certain subjects both playful and meaningful at the same time?

Ultimately, both educators and game designers are asking a person to invest their time and effort. If you don’t believe that the benefits are worth the investment, than why put in the time? Many (perhaps most) games offer some kind of immediate benefits of pleasure, both spectacular and of solving problems. Could school subjects offer the same?

Crossposted from the Gamelier

Share Button

Rules of Play


Rules of Play: Game Design Fundamentals was written by Katie Salen (who co-created Quest to Learn) and Eric Zimmerman (from the NYU Game Center). Its is a BIG book, by which it means it covers a lot of ground, but also that is very long. I have to that I wish it went about twice as fast it does. But perhaps I’m not the target audience, as I already know a lot of material covered from other places. Also, I’m not as interested in game studies as I am in design and development, and so chapters on “games as culture” don’t exactly float my boat.

My favorite part of the book is the game design challenges/exercises, which include the excellent Exquisite Corpse Game Game, which I’ve gotten a chance to try out at Gamelier and found it a lot of fun. There are also some new games, commissioned just for the book, and include essays by the creators explaining their design path and choices. I can’t wait to playtest them.

There are also quite a few points that made me pause to reflect. Here are my notes:

  • Page 34: The notion of meaningful play encompasses the principle that players should be presented with choices that have a impact on the future of the game experience, and that players understand this (implying a tight feedback loop).
  • Page 63: In order to analyze how meaningful the choices presented to the player are, they can analyzed in terms of: what happened just before the player was given the choice, how was the choice conveyed to the player, how did the player make the choice, what was the result of the choice, and how was the result conveyed to the player.
  • Page 91: The four traits that distinguish video games are “immediate but narrow interactivity”, “manipulation of information”, “automated complex systems”, and “networked communication”.
  • Page 155: The complexity of games can be analyzed as lying along a spectrums: fixed (meaning no complexity), periodic (a simple cycle), complex (the sweet spot), and chaotic (essentially random). The goal is to make a system that is truly emergent, neither random nor unrelated to the interactions of the system itself.
  • Page  224: Feedback loops affect games in different ways. Negative feedback stabilizes the game, and positive feedback destabilizes it. Negative feedback prolongs the game, whereas positive feedback ends it. Positive feedback magnifies early successes, and negative feedback magnifies late ones (an interesting insight that I hadn’t grasped before).
  • Page 268: Players can be categorized in terms of how and why they break the rules. Unsportsmanlike players and cheats violate rules where they can in order to win. Spoil-sports simply don’t care about the rules, nor about winning!
  • Page 425: Ace of Aces was a two-player dogfighting game created as a picture book! Like a choose-your-own-adventure, except each player sees a hand-drawn picture from the point-of-view of the cockpit, and picks from a large set of maneuvers. Both players announce their moves, then turn corresponding pages in their books to find out what happened. You could even play by yourself!
  • Page 450: The “immersive fallacy” is the idea that video games are moving towards a completely immersive experience of 3D sound and video and touch and smell, as portrayed in TV and movies (The Matrix, Star Trek, Caprica, etc.). Instead, the authors argue that gamers are always playing on several levels, including meta ones in which they know they are just playing a game, and that’s a lot of fun of it. Also, a lot of media can be “immersive” without overloading the senses- like books!
  • Page 546: The “icehouse set” are a bunch of plastic pyramids that have spawned a whole bunch of new games, all “free” once you have the set of pieces. Books have been written describing the games.
  • Page 581: Suspicion was an unpublished game to be played over time in an office. Each player gets cards assigning them to two groups: one sect and one institution. They can team up with either of the two in order to win, but no one knows who is who, and so there’s a lot of double crossing going on. Too bad I can’t find out much about it on the internet.


Share Button

Reality is Broken


I finished reading “Reality Is Broken” by Jane McGonigal.

It’s a pretty long book (370 pages), but very well written. I highly recommend reading at lest the first few chapters. The author explains how playing games is essentially doing “work” for our brains and bodies, and how, quite logically, humans have evolved to enjoy doing work. But the activities that we consider games are tweaked in such a way that this work is enjoyable- having clear goals, difficult but not impossible obstacles, rich feedback on our progress, and “fun failure” (I would also add pleasurable surprises to this list). She then gives examples of how we can turn what normally is considered “work” into a game experience. This is very close to what is considered “gamification”, but not in the shallow sense of the points and badges to which this term often refers.

Near the end of the book (chapter 10), she brings in theories of happiness from the positive psychology movement. She believes that psychologists already know what makes people happy (making a positive impact on the world, valuing others and being valued by them, feeling productive and in control, etc.) but that despite the backlog of self-help books, people have trouble making themselves behave in ways that lead to their happiness. And so she designed games that are expressly made to make people happy in ways that align with positive psychology theories.

The most curious one takes place in a graveyard. Apparently, thinking about death is supposed to make us happy, by making us more appreciative of our health and  opportunities, as well as more forgiving of the “small stuff” that annoys us. It seems that graveyards used to be spaces for events outside of funerals, but now most graves are only visited 2 times after the funeral, if ever at all. And so she made a game called Tombstone Hold’em to make players reflect on death and have fun doing it.

Share Button

Darwin DeathMatch

Darwin DeathmatchThe Nightscience Hackathon just finished, and I’m writing this on the long train ride home. It was a lot of fun, and though we didn’t get nearly as far as we had naively hoped, I’m happy that we have a decent proof-of-concept to show about our evolution game.

Please go ahead and play it, but don’t be afraid to come back if you need some explanations. We mostly tested it under Google Chrome, but it should work in other modern browsers as well (perhaps without the sound).

My night train was canceled due to the horrible train accident near Paris, and so I arrived just before lunch. I found that the Hackathon had already split into groups that had rallied around an idea. Not all groups included programmers, and they discussed improving education and research through technology and open data. But one of them wanted to make a game, a game about evolution.

That, unfortunately, was about all the group had agreed on, and so we spent almost the whole day exploring and trying to agree on what game we could make that would be fun, educational, and of course do-able during such a short time. Luckily Marc Planard (@corpsmoderne) was in the group, a talented and excited game programmer working at MekEnSleep. We also had Stéphane Libois, Laurent Arnoult, Cecile Quach, and two others whose names I have lost. But we didn’t have any artists in the group, which made is so that the game is pretty ugly.

We debated many ideas. I was originally pushing having creatures moving along on a map, meeting and breeding with others. Then we focused on an idea of breeding “champions”, like horses or plants, that you use to fight adversaries. Through applying artificial selection to them, you could make strong creatures that are powerful enough to beat your opponents. But we had a hard time at first making this idea work. How could the creatures interact in an interesting and non-obvious way, and yet still allow the player to pursue a goal?

Around 6 in the afternoon, we eventually hit upon the idea of having a single strand of “genes” that determine how each creature behaves. There are 3 types of genes: attack, defense, and reproduction. When two creatures fight, they take turns attacking and defending each other. Each group of attack genes count as a single attack. If there are more genes in that group than in the opposing defense gene group, counting from the top, then the attacker scores a point. And now the other creature can attack.

Darwin Deathmatch fight

If a creature loses a fight, he disappears. But luckily you can mate creatures together. When you do this, the two strands are crossed, producing two “children” that are mixes of the parents. There’s also a random mutation factor built-in that keeps the derived sequences from becoming two similar.

When the player has a creature that they think is good enough, he take on the boss. Unlike the randomly created creatures at the games start, the boss was crafted to have a moderate difficulty. In a full game, each level could have its own bosses of increasing difficulty.

We wanted to have something quick to show on the web, so we wrote it all using Javascript. We started with the RaphaelJS graphics library, but ran into problems with dragging and dropping groups (or sets) of shapes, something that it does not support well. So we switched to KineticJS, which neither of us had used before, but which worked pretty well for what we were doing. We also used Buzz for the sound, which was fine, though it took me a while to understand that fading in and out a sound clip did not make it play or stop as I had imagined!
Future ideas

Of course, there’s a million things that we could do better with this game concept. First of all is the graphics, which need some serious help. Also, we originally wanted this to be a multiplayer game, so that players could confront the creatures they breed.

There’s also the reproduction gene, which is currently just “dead code” in the genome. But the original intention is to have the number of reproduction genes be proportional to the number of offspring that a creature can have. This would force the player to keep enough reproduction genes to avoid having the lineage come to a sad end.

Another interesting tradeoff would be have a lifetime associated with each creature, determined either by a number of “health genes” or inversely proportional to the length of the genome, if it was allowed to vary.

Where’s the code?

Under the extreme time pressure, I’m not putting this code out as an example of good coding practices… it’s pretty ugly! But if you’re interested, please grab the code on Github and hack away.

Share Button