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.

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.


I just finished reading Game Mechanics: Advanced Game Design.

Overall, its focus is squarely on modeling game economies, rather than other types of mechanics, which do not apply as easily to the kinds of games that interest me. However there are a few tasteful tidbits in there that are well worth mentioning:

The categorizations of game mechanics (physics, internal economy, progression, tactical, social) are a useful way to make sure to consider other possible mechanics to introduce into the game. The discussion of emergence vs. progression in games, and how the two can be mixed, is also an interesting perspective.

The heart of the book presents a way of modeling game economies with a model called Machinations, which you can find online. For small examples, the approach provides a way to visualize and to simulate feedback mechanisms in game economies. Economies are a natural way to understand some types of games, like Monopoly and war strategy, but other games need to be twisted a bit to fit into this framework. Nevertheless, recognizingpositive and negative feedback loops is  a key tool for any time of game design, and one that the book explains in good detail. The book also provides a few “design patterns” based on this framework, which are recognizable from examples.

The book has an extensive discussion on different types of key-and-lock mechanisms, and describes how one of the most important jobs of the level designer is cleverly disguising keys and locks as other things, such as new weapons, new spaces, etc.

The last chapter was a real treat, as it discusses how simulations differ from games, and how serious games differ from entertainment games. They also discuss how game mechanics can be given meaning, and how conflicting layers of meaning can provide depth to otherwise trivial games. The discussion is rooted in semiotics, which I didn’t know about before and was happy to learn.

Black ball up on Runaway Parade

Black ball is up!

Pretty exciting for me. This has been a lot of work for Quentin and I over the past year, if can believe it. Not that it’s really a year’s worth of work, but just that we had a lot of false starts (originally it was a game set in ancient greece about a character who could move objects with his mind).

There’s a lot that we didn’t do in the end, and a lot of things that I would like to take on in the future, if it get’s a good response.




Dog Eat Duck – 2nd version

Although it took quite a bit more effort, I’m glad to say that JC and I managed to update Dog Eat Duck with two major enhancements – animations and sound.

Both make a big difference, and made me realize once again how easy it is to overlook incredibly important stuff. Which is not to say that we hadn’t though that it would great to have the ducks move. But without them moving, a bunch of people though that they were just looking at screenshots!

The sound is also a big help. Although it took me longer than it should have, I finally did manage to get SoundManager2  up and running with a few small MP3s, and the result just makes me smile.


“Duck Eat Dog” – 1st version released

 Time: on and off over 4 weeks

Team: Me, Ben Wertheimer, Julia Himmelstein, Jean-Christophe Letraublon
Another project for  Runaway Parade. This time the theme was “decoy”, and Ben and I decided to make a Django web app to run it. I had never uesd Django before, and found it pretty cool- though finally I’m not sure if Tornado wouldn’t have been better…
Anyway, the theme got me thinking of the  classic icebreaker “2 truths and a lie.” What would happen if you made that into an online game? In a way, the lie is a decoy. But to make that fun, and not so much about learning about people, I thought it would be better if there were more lies than truths. So it because “3 lies and a truth”.
As I was talking this over with my sister Julia over vacation, she thought it would be fun if you “shot” the lies with a gun, like you were going hunting. She photoshopped up a little screen showing a few wooden panels and a gun at the bottom. The gun image was of a pistol, which didn’t look quite right for a hunting theme, so I did a little google search on hunt gun, and somewhere saw an image of the good old Nintendo zapper!
Before long, Julia and I just came up with a whole new design that plays with Duck Hunt. Of course, not only can you watch youtube videos of duck hunt (including funny ones where people go past level 99 and stuff gets crazy) but you can also load emulators to see how the old game use to work. And watching the old game gave us some good ideas that we could bring into ours.
One thing that seems to work well so far is to have people create their own levels. What’s tricky about accepting input, of course, is how to weed out the bad ones, and mostly how to deal with spam! I looked up the voting and ranking algorithms used by sites like Reddit and Digg, and have tried to use the Wilson score interval, as proposed by a few different sources. It has been hard to incorporate voting into the the game, though, without breaking the flow of play. We’ll have to see how that works out.
Another fun thing has been to work with lots of different people on these game projects. Ben and I had done SporksUp together, but this was the first time that he was programming- and he’s a quick learner! Also, JC and I had wanted to do a game before but it didn’t take off, so this is our first real project together too, and he really knows his photoshop! Same goes for Julia, actually, despite the fact that I make her discuss game ideas a lot with me, and she’s always very helpful.
Of course, we have a bunch of new ideas, which we really didn’t have time to put into the current version. That is, to have more animations and sound (of the bird, the dog, and so forth) but also include a timer. When the timer goes off you lose…
JC is helping me tons with this new version, and I’m hoping that we can get it out before we show up on Runaway Parade and people start playing.


“Mixed Beats“ Postmortem

Time: on and off over 6 weeks- probably about 15-25 hrs total

Team: Me, Quentin Jouret, Philippe Birgy, Pwikmasta


Well, time is definitely up for my contribution to Runaway Parade. On the theme of “Three’s a Crowd”, Quentin and I had brainstormed a bit and came up with idea of having simple machines that make repetitive sounds. The idea being to synchronize them to make looping music. Think Stomp, if you could click on people to start and stop them.

Well, time is definitely up for my contribution to Runaway Parade. On the theme of “Three’s a Crowd”, Quentin and I had brainstormed a bit and came up with idea of having simple machines that make repetitive sounds. The idea being to synchronize them to make looping music. Think Stomp, if you could click on people to start and stop them.

This reminded me of my few (and always poor) attempts at mixing records, where the challenge is matching tempos as well as times. I thought that by fixing the tempo, mixing would be a lot easier. I also imagined that by quantizing it (like in Ableton Live) so that the player could only start a machine “on the beat” rather than slightly before or after, it would make something easy to play with.

What’s the link to “Three’s a Crowd”? Something about trying to make several people play/work/live together nicely…

1st Try

By the 1st attempt, it became clear that we were no longer trying to have little machines, because making them and finding appropriate sounds could take a long time. Instead, we went for imitation drum machines, with little markers that move down the screen to show where the beat should be (à la Guitar Hero) . Except that you need a second set of markers to show where your own beat is playing.

Quentin did the graphics, which have a nice hand-drawn feel that I love. We opted for a single play/pause button, and a little light that showed when the beat was matched correctly. When you got all three beats correct, the level was over. We made a menu and credits screen, and a volume slider, and we were on our way.

Meanwhile, Philippe was nice enough to do the music on very short notice. He split up the rhythms into 4 sections, each in their own mp3.


When I finally got the 2nd attempt working and had ironed out most of the bugs, I had the feeling that it wasn’t perfect. But when I watched other people trying to play it I realized that it was really far off! First of all, its not obvious to people how to use it. Second, it’s hard to line up the beats using just the audio, and yet lining up the beats is ridiculously easy just by clicking the play/pause button a lot until things line up. Finally, the music is fun but not challenging in terms of the game, mostly because I had trouble finding time to meet with Philippe or Guillaume to show them exactly what I wanted.

Had I more time, I would take this thing apart and do it again, having the player just do one instrument at a time. This would be simplify the controls (only one instrument at once) as well as make it easy to coach the player (“too early”, “too late”, etc.). The sound would always start playing at the same point, and it would stop automatically after playing once if the beat is incorrect. You might also need a button to hear what the sound is supposed to sound like. Finally, it would be a nice touch to have sounds when the beat is correct or not.