Curious Games: Post-Mortem for Nitrogen Narcosis

adventures in gaming, curious games, indie, Process Writing, research

(With the Curious Games Studio coming to an end, here’s my report on the creation of Nitrogen Narcosis – why it was made, what I found interesting and challenging, what my poor playtesters thought, and a bit more about myself than I usually talk about.)

I have been making video games since January 2013 and this is my third game. I never expected to be doing this – I thought that I might fall into video game writing somehow because video games are something that I enjoy and I like to try new things, but I didn’t expect that it would happen so soon, or that the urge to keep making more would hit so hard. The opportunities to keep making games keep coming. It started with the Pixelles Incubator – I applied but didn’t get in, and decided to do the follow-along program anyway.

While I was following along with Pixelles, I wanted to write an article about Global Game Jam 2013 – watching the participants, seeing what they were up to, maybe providing some suggestions or copy editing help while I was there – for the JEKA GAMES and the TAG blog. Less than twenty-four hours before this year’s Global Game Jam, I came into possession of a laptop that actually made it possible for me to help with the game making if I chose, and as soon as I was at the Jam listening in, the infectious energy of the whole affair was basically irresistible. I’m someone who likes to create; I’m moving next week, and I have four boxes of art supplies moving with me. After GGJ2013 and the Pixelles Follow-Along (and the Pixelles were extremely supportive and let me showcase my game along with the other participants), I heard about other opportunities to learn about games like the Curious Games studio, or my next project, a game for the Critical Hit Collaboratory. So, while I feel like a bit of an impostor (I had no training in making games at all up until the Curious Games course), as long as people keep giving me the chance to make games, I’m going to keep on making them – and if they ever stop, I’m still going to make them.

I wanted to participate in the Curious Games studio to hear about Pippin Barr’s approach to making games, because the current scope of my games is similar to the kind of games that he makes, and the games that he makes make me feel like I’m sharing in a great joke while all the while being teased a bit myself, and I like that. I wanted to make a game like that. But what to make?

I have already made a game about scuba diving – it’s one level, it’s what I developed in six weeks spending about six hours a week during a semester of grad school for the Pixelles Follow-Along, and the mechanic is basically that you swim around collecting points and will get more points by following diving safety rules like coming back with a certain amount of air in your tank. With that game, what I wanted to do was share a space that I love with other people (Morrison Quarry in Wakefield, Quebec) and learn the basics of using a game making tool and developing sound. I am also currently SSHRC-funded to write a master’s thesis in creative writing about coldwater Canadian diving. So, when I started to think about ideas for the Curious Games Studio and what kept coming back to me was a single experience that I had a few years ago, I wondered if I should really be making another game about diving. But then I thought, why the heck not? Cormac McCarthy wrote one book about cowboys in Texas, and he liked that so well that he wrote another one, and then another one (this is a poor paraphrase of something that Josip Novakovich says in his book on writing, Writing Fiction Step by Step).

What I finally decided was that I wanted to impart an experience, and that what I had in mind was an experience that not many people are likely to have had. I thought that that was a good premise for a curious game. The experience in question is: “What it feels like to try to complete a simple task one hundred and thirty feet underwater.” The task is tic-tac-toe. The thing that I don’t mention in that description is that at 130 feet, most people are experiencing at least mild symptoms of nitrogen narcosis or are suffering other (mild) ill effects from the pressure and, in the case of coldwater divers in Canada, the cold. A person’s thoughts are slowed and their motor skills are adversively affected. So, the symptoms of Nitrogen Narcosis hit in the game at random in the form of those very dramatic scene changes. All these effects are compounded by my having the player wear some actual scuba gear – it doesn’t look like much, and personally I’m pretty well used to it, but scuba diving equipment is awkward and limits range of movement and dexterity very effectively.

The germ of the idea for tic-tac-toe specifically came out of my first experience with really deep diving. A deep dive in recreational scuba diving is any dive below sixty feet, which is the limit of the first level of certification. When I say “really” deep diving, I mean more than doubling that depth to 130 feet. As part of my deep diving certification, my instructors took me down to 120 feet or so and had me play tic-tac-toe against one of them. I didn’t get fully “narc’d” as we divers would say, but my ‘O’s looked pretty much like small outlines of continents. That my motor skills were so dramatically affected was a total shock to me, and that was part of what I wanted to transmit to the player. I would have loved to create some kind of interface like the one in YOU HAVE FORGOTTEN HOW TO USE A PEN, but I think that if I had tried that might have been the only thing that I managed to finish, and this was a game about being immersed in an underwater environment.

What I find interesting about Nitrogen Narcosis is how well the seemingly trivial aspects of the game such as the user-enforced rules of wearing scuba equipment and actually following the rules for playing tic-tac-toe lend themselves to the game experience. What I couldn’t do with programming, actually slowing a player’s movements down with the mouse on screen, or really creating feelings of confusion, the scuba equipment achieves. The mask fogs up on the player’s face, and the thick neoprene gloves make the keyboard keys much more difficult to press, the buttons on the mouse more likely to be mispressed or the mouse directed to an area of the screen that the player wasn’t aiming for.

I also find it interesting that even after working on it for the duration of the class, I still have a lot of fun playing the game, even though I must have playtested it hundreds of times in all its various stages – although of course this is partially the delight of seeing my work, well, work! Even more interesting is that the late addition of the two-player mode is what really makes Nitrogen Narcosis feel like a finished game. It creates a collaborative (or maybe adversarial) aspect to the gameplay and really highlights the ways in which this simple task is made more difficult by the gameplay aspects. Player One, who places the ‘O’s, only needs the nine keys that correspond to the nine spaces on the tic-tac-toe board, and they’re not forced to wear anything. That means that the general reaction from most of my Player Twos was a good-natured “hey, how come I have to wear this and they don’t?” which enforces the idea that this is no simple game of tic-tac-toe right from the get-go.

Some schools of creators (like the OULIPO artists and writers) say that constraints are great for creativity. Nitrogen Narcosis is a game that proved that to me because I had plenty of constraints: I am not a programmer, I’m not a professional 3D or even 2D artist (the farthest I get is graphic design in Photoshop and maybe “inking” my scanned drawings), and I only had eight weeks to make the game. To be fair, I do have a bit of fine arts background, having taken a DEC in Communications: Arts, Media and Theatre in CEGEP, which is basically a program where they let you paint, draw, sculpt, take photographs, and make movies while they also teach you about journalism and cultural studies, but I have no idea how to use Maya or Blender or any of those tools. At the core, I’m a writer who dabbles in other mediums. I also decided that it wasn’t the time to learn to use a modeling program, especially since I don’t know which one to use, so I resolved to make art that I could draw using my fingers in Photoshop on the trackpad. There is something really satisfying about this kind of art – it’s something like fingerpainting and it makes me appreciate the existence of each asset as I have painstakingly taken the time to draw it – and the trackpad on a Mac draws way better than I ever would have expected it to.

The immediate repercussions of my relative inexperience were that I had to find simple ways to get the effects that I wanted and that I had to feel my way through the programming parts of anything and everything that I wanted to put in the game. This forced me to think about the challenges of the game in different ways. Even as late as our last class’ worth of studio time, I added the multiplayer mode and was both delighted to find that I had reached a point where the programming (although it is visual programming in Stencyl) came easy and that the two-player mode added dimensions to the game that I never would have expected.

Initially, I had wanted to program an AI to play tic-tac-toe against the player, but this proved too difficult and, as it turns out, this was a blessing since it resulted in the eventual addition of a two-player mode, which I feel really makes the game feel complete. Programming a tic-tac-toe AI was more complicated than we had realized, and with the added difficulty of fighting the Stencyl interface, I decided instead to try having the player play against themself. This is how the game remained for quite a while until we playtested again and decided that there was some missing impetus – some missing motivation to take the player through five sections of playing tic-tac-toe, especially against themselves, even if interesting things were happening all around them.

Another feature that I wanted to implement but wasn’t able to was actually making the perspective/player move up and down when the player “controlled their buoyancy” by pressing the blue and black buttons. An artefact of this is that both of those buttons still make appropriate noises if pressed on – but only one of my playtesters pressed on them and they were a scuba diver. I find this artefact interesting and decided to leave it in because of one of the discussions that we had in class about human/player psychology: that we have a strange belief in buttons – that we believe in their power to create agency for us out in the world. Apparently, in some countries, the close elevator door buttons don’t actually work (although at least the ones in the EV building at Concordia where the Curious Games Studio met seemed to work).

A major challenge for me was debugging. I tried to be as methodical as possible, but oftentimes I couldn’t tell the difference between a bug that Stencyl had created because it generates code and has some flaws and something that I had actually introduced with my code. Sometimes, I couldn’t get the bugs to reproduce, and often times, if it was a Stencyl problem and not a Jeka problem, I basically had to “rewrite” that section with the exact same stuff that had been in it before. Additionally, towards the end of the process while I was fine-tuning something, the graphics card in my laptop took sick (I can’t exactly say that it died because it still works in fits and spurts). I thought that I had a bug that was crashing the game, but it turned out that it was the graphics’ card. This could have been disastrous: for a few hours I was completely unable to turn on the laptop. Thankfully, I was finally able to turn it on long enough to back up everything related to the game. It was a scary moment – the kind that you hear about. So, that laptop that got me started on making games all those months ago basically died for me to make this game.

One of the resolved challenges that I feel particularly good about with this game is randomization, which I managed to learn how to do within a range of numbers in order to have some events occur at random – particularly events within the different scenes and the scene changes themselves. I wanted the game to have an element of the unexpected every time a person played. The end result is not that varied, but I think that it’s better than having static scene changes and totally scripted events. I am also pretty satisfied with the sound design – the breathing noises, freeflow noises, and button-press noises are all things that I made myself in Audacity using resources from Freesound.Org, and I was surprised that they actually sound comparable to similar sounds in a prototype that I discovered yesterday for the Oculus Rift, World of Diving (honestly, I hope that this prototype changes drastically because I’d love to play it but it’s clearly meant to be a simulation and already there are many things wrong with it from my perspective as a diver – for example, that diving is largely about planning, so you’d never carry around all those pieces of equipment with you, and that buoyancy control is something you usually really need to pay attention to).

One thing that I’m still not sure that I have one hundred percent right is the timing of those scripted events – as I’ll discuss later, it’s a problem that I ran up against in playtesting.

The greatest influences that I can identify for the overall perspective and look in this game are the Doom and Wolfenstein interfaces. I’m talking about the combination of that perspective with the art style of the assets. In terms of tic-tac-toe gameplay, I wanted to mimic the interface of those older PC versions of Chess with the flat board and flat pieces. It was also important to me that, as in many FPS, you be able to see parts of your equipment to give you a sense of perspective. Other influences, especially in regards to actually making the player wear or use equipment while playing are games like Hit Me!, Painstation, Propinquity, and the Wii, where the physical world that the player inhabits has in-game effects. In Hit Me!, for example, the size of your opponent relative to you affects how easily you’ll be able to reach them (I found out just what an impact this has on gameplay by playing Hit Me! with my 6’ 5” friend Jordan).

I playtested the finalized (well, sort of finalized) version of the game on two separate formal occasions. The first time, I asked my fiancé Tom and my friend Colin (from Red Rings of Redemption) to test it. Tom is an experienced scuba diver – he even introduced me to the sport and has been listening to me talk about the development of the game since I started on it. Colin had heard a bit about the game, but didn’t have any real idea what to expect.

On the first playthrough, Tom took the role of the first player, or the person who only has to press nine keys and doesn’t have to wear scuba equipment, and Colin graciously accepted to wear scuba mask and gloves, although he drew the line at putting the snorkel in his mouth (this is not one of the requirements to play Nitrogen Narcosis). The result was almost utter chaos: in every level, they seemed to hit the random events – particularly the scene changes on the lower end of the time ranges for the randomization. Scarcely had they touched their tiles did it seem that the scene was changing and they were on to some relatively wild stuff. The effect created was a kind of confusion – which is kind of nitrogen narcosis-like – but it was not the desired sort of confusion, really. On a second playthrough, with each of them knowing what to expect and with Tom now playing the role of “person with loads of equipment in their way”, things went more smoothly. They did find a few physics bugs for me which then mysteriously fixed themselves (or rather, I haven’t been able to reproduce them).

Colin’s suggestion was that maybe the game should provide more explanation about what nitrogen narcosis is, but I decided that this was not what I wanted for the game. For me, the context of having to wear scuba equipment and hearing underwater breathing noises, seeing fish, suggests that Nitrogen Narcosis, which is the game title and even sounds like a medical condition, is some kind of scuba-diving related affliction.

Both of them suggested (and I observed for myself) that things were happening a little too fast. So, the upshot of this playtest is that I adjusted the time intervals for the random events and scene transition, and debugged a little further.
The next day is when my laptop graphics card started to really give up the ghost, so I spent a few hours over the next two days assuring myself that I had managed to back everything up and that I could still alter the files from another computer.
After that, I playtested with my parents, Michael and Judy. Michael’s reaction was to initially refuse to wear any scuba diving equipment at all, so I suggested that he start as Player One and decided to try and change his mind later.

My mom, Judy, during Nitrogen Narcosis playtesting.

My mom, Judy, during Nitrogen Narcosis playtesting.

Judy, starting as Player Two, was a pretty good sport but griped about my father not having to wear anything. Now, my parents can be described as casual gamers at best – they play Angry Birds on my father’s Kindle and maybe a few other similar touchscreen games. With them, the game seemed to hit all the right notes. Although my mom told me halfway through the first game that, “personally, [she didn’t] care for this at all,” she then went on to play two more games, complete with trashtalking my father and cheating (they both cheated a little bit when they realized that the tic-tac-toe rules are completely player-enforced). My father suggested that the “taking turns” rule of tic-tac-toe should be enforced with programming, but I so appreciated the generative play of them each trying to play faster than the other and moving each other’s pieces around that I definitely think this should stay as is. When they were exploiting the loopholes and player-enforced rules, they seemed to be having the most fun.

When it came my father’s turn to be the ‘X’s, I could only convince him to wear the neoprene gloves. Throughout the game, he became so frustrated with the way that they limited his motor skills that he actually tore the gloves off. My father is one of my “constant readers” – I basically have him check out nearly everything that I create, and so he is skilled at stepping back from himself and giving me a considered perspective even of things that he doesn’t necessarily enjoy. His main reaction was, “I see what you’re trying to do here, and I think that it works. I just don’t want to wear those gloves again.”

After their playtest, I tweaked the positioning of the ‘X’s so that they all start in a pile on the side rather than scattered on the board – this had caused some confusion for my parents, since one of the rules of tic-tac-toe is that you can’t place your piece on a square with someone else’s pieces, and the ‘X’s start in certain positions. If the player is trying to follow the rules to the letter, that’s a legitimate concern. It was simple to change so I decided to do so.

Overall, the playtesting experience was positive and very constructive. I’m looking forward to see what people who don’t know me think of Nitrogen Narcosis. Creating the game has given me a much better handle on Stencyl and I’ve learned quite a few new tricks. It feels good to have finished this game – I think that I’ll lay off the scuba diving games for a while.

(I’ll be posting the game online soon, along with a possible list of alternate equipment for those players who don’t own their own scuba equipment.)

Curious Games: Backing Up Your Stuff

adventures in gaming, curious games, indie, Process Writing

My laptop is on its last legs. Basically, it’s a five-year-old macbook pro that I acquired on kijiji for 250 dollars at the end of January and the graphics’ card is dying. It would need a new logic board and that would cost more than double what I paid for the laptop. Macs are expensive to fix!

My games and some of my thesis writing were/are on the hard drive, but thankfully I backed everything up to Google Drive. That means that it’s much harder for me to work on my game right now because I have to be at home on my PC or bring an external hard drive everywhere and install Stencyl on all my friends’ computers. I also can’t replace my laptop until my SSHRC funding comes in..which I am told may come in as soon as the end of the month, although there’s no definite answer and the process takes a long time.

So, since this happened on Friday, I’ve made relatively little game progress: I spent Friday into Saturday building and inhabiting a giant cardboard fort (the pictures of which are up on my Instagram account on my @jekagames / @jekawrites twitter feeds) and then spent Sunday celebrating Father’s Day with a rained-out barbecue (we cooked with umbrellas but while my yard is equipped for the twenty people that were at the barbecue, my house is pretty tight quarters).

Today is also the first day of the Critical Hit incubator! So, I’m spending forty hours a week for the next ten weeks making a game about a zombie cyborg girl (grrrl) named Rosie. She’s a tattoo artist living (if you can call it that) in the big city.

I think that at this point, with two-player play implemented, my best strategy is to figure out any bugs that crash the game or make it unplayable (now knowing that the game may have been crashing because of my graphics card and not because of a bug) , continue to playtest with people to tweak rules/timing, and to write my postmortem. I am happy, if not totally satisfied, with the results of the game, especially when coupled with the scuba equipment. I guess that maybe I should make up an alternate list of things that you need to play the game to make it awkward? Maybe the neoprene gloves and scuba mask can be substituted for winter gloves and ski goggles, or something like that. I’ll think about it. All in all, other than the playtesting for bugs and, you know, to hear opinions of the game, Nitrogen Narcosis feels complete!

Curious Games: Bugs and Lags

adventures in gaming, curious games, indie, Process Writing

This week, I added some more actors and events to my game and started to do the work of playtesting. Some new features that you can expect to see are the very dangerous freeflow — complete with bubble animation, loss of air sound effect and corresponding loss of air from the air bar, a cameo from the Diver Quest divers and some very happy flowers.

I also started to playtest and ran up against one of the limitations of flash: handling many actors at once. It turns out having all those fish and all them animated flowers in the background in addition to the normal actors I have in the scene makes flash lag like nobody’s business. I spent nearly an hour and a half trying to figure out what I thought was a scene transition bug, only to find out that the game was going so slow that it just hadn’t reached the scene transition yet.

It is with great regret that I have halved the number of fish that swim in front of the player’s face in the happy level, and also had to decrease the number of flowers. Pippin suggested to me that I might want to create an animation of the fish rather than having the fish be one-by-one actors. That would save an awful lot of resources, and I may yet, but it also means that I can do one of two (simple) things: make a fairly detailed animation of however many fish comprise each actor, or have the fish move all one way. Right now, they’re each set on a slightly different wave pattern, which makes it look like they’re moving differently and therefore “independent” of the school somehow. I like that.

I have temporarily halved the fish so that I don’t have to make a decision on this right away: it doesn’t lag quite so much now. Having to do a whole animation seems like a lot of work for something that already works, really. But I have to work within the limitations of the resources that I am using. I want to do the larger, more complicated animation. If testing and debugging goes well, I promise that I will attempt to do this.

In other debugging news: everything seems mostly fine but I have only played all the way through the game a handful of times — I always run into something that I want to tweak and then end up tweaking it/playing with it.

This weekend, though, I am going on an overnight trip with scads of divers – a whole bunch of them! Ideally, I will get some of them to playtest it in full scuba gear (although I am leery of bringing my laptop around the water). If I do this, I promise I will also get pictures.

Curious Games: I more than fixed it!

adventures in gaming, curious games, indie, Process Writing

This Friday, I met with Pippin to figure out how to program Tic Tac Toe on Stencyl.

We didn’t. But, instead, we decided that I should focus my efforts on other areas of the game, like pushing the experience of having nitrogen narcosis and being underwater even further.

I set up some goals that I thought would be manageable by the end of the allotted time for this project (there’s only a few weeks left in Curious Games Studio). I decided to stay in the lab where I had met with Pippin to use our amazing 3D printer (a Makerbot Replicator 2 known as “Bob”). I then proceeded to accomplish all the goals that I had set out for myself in one afternoon. Pippin suggested that this might be because I was tethered to one place, and I think that’s true, but I also think that it was partially thanks to Bob, who plays tones as he works. When he makes ovals, it sounds like he’s playing the blues.

Those goals were:
– make a silt animation for when the player interacted with the tic tac toe pieces.
– randomize what pieces appear and where on the game board, and randomize when the scene switches (thus randomizing in-game events).
– create floating game tiles that would increase the difficulty of playing the game because the pieces don’t stay where they’re put.

I couldn’t believe that I managed to figure it all out in one afternoon! Now my plan is to create more conditions for the game (more scenes/animations). I think that I may add a bubble animation for air and a silt-out condition. I also want to leave time to play test and fix any bugs that might come up. One of my main worries is that I won’t be able to export the game, which is something that happened with ‘Diver Quest.’

It’s time to get started on stretch goals!

Curious Games: I Broke It

adventures in gaming, curious games, indie, Process Writing, research

Last week, I was considering different solutions for altering the conditions of play and mood in my game. Pippin suggested that I use attributes, which can save certain information across scenes and across play sessions. What I decided to do is create different scenes and make them virtually identical to the initial scene, the only differences being the mood music and anything that I choose to add to increase the atmosphere of either euphoria or fear. I realized that it doesn’t even matter if you can play Tic-Tac-Toe in those versions of the scenes as long as the countdown is consistent across them and so is the number of games won. That seems doable.

However, after I duplicated the scenes and the code and made sure that code was pointing to all the right objects within the world, I somehow broke the other scenes (which means that really, they weren’t working in the first place). In the first instance, the console no longer appears even though I have visually placed it in the environment as an actor. Also, I am unable to move the actor that is supposed to move the camera around the level. The other level has the same problem, but compounded: neither the inflator nor the console show up in this level.

I’m going to debug by enabling and disabling parts of the code and seeing what I can do. Not looking forward to this! But that’s all part of the process, right? Then again, so long as I can get the camera to move, I am thinking that perhaps there’s a certain logic to not having those elements in those levels.

By the logic of the game, a euphoric person thinks that there’s nothing wrong in the world, and wouldn’t be concerned about readings on their console that say that they only have so much air left, or are at a certain depth. Similarly, in the “fear” level, the loss of the inflator could be considered a kind of loss of control over the player’s circumstances. But I still want to figure out what’s wrong. If I end up leaving them in, I want it to be intentional, not because I couldn’t figure out how to fix it.

I’m also getting very close to the point where I can no longer put off adding Tic-Tac-Toe to the game because a lot of things (like testing that score stays consistent…unless I want to program artificial scoring conditions) will only be able to be properly tested once I do that.

The rest of my work will involve adding more and more – Tic-Tac-Toe is the last absolutely essential element. That means more crazy euphoric animations of dancing fish (I have decided that this needs to be a thing in my game), more flashing lights, more bizarre decal-style photoshop brush effects appearing in level, more ominous things like perhaps dead fish floating around…More camera shake!

Please enjoy this picture of a fish. More soon.

UPDATE: I appear to have fixed the motion problem (I just had the actor’s speed set too slow) but apparently my sound is creating some of my bugs.

Curious Games: Musical Adventures

adventures in gaming, curious games, indie, Process Writing

After finding out about Wolfram Tones, I was adamant that I wanted to use it to make music for the game – specifically, during the “euphoria” and “fear” parts of the game, I wanted to have appropriate music. Well, it turns out that Mac no longer supports the QuickTime plugin in-browser. Wolfram uses QuickTime, so I couldn’t play anything on my Mac as I composed it. That made using Tones pretty much impossible, so I went over to my desktop, made some awesome music, then sent the midis to my email and tried to open them on my Mac. On to the next adventure: the midis can’t be played in Audacity, which is the audio editing software that I’m using. So, at first I tried to find a midi to mp3 converter, but couldn’t find a free one and am too cheap to pay 30+ dollars for something that I likely won’t get much use out of. Instead, I updated QuickTime to QuickTime 7, opened the midis there, and recorded them with the computer’s microphone directly into Audacity. Since I don’t have a recording studio, I had to restart several times as my fiance chatted to me, not realizing what I was up to, as people passed by our open window, and as my future in-laws moved about their house. But, at last, victory is mine!

I now have “Happy Music” and “Sad Music”! I’ll try to eventually get them up here for you to listen to. Meanwhile: Wolfram Tones is awesome, but much easier to use on a PC. Give it a shot!

Thinking about how to implement some of the randomness: I’m thinking that the easiest thing might be to set timers and have the scene change for some of the more complicated of my “special effects” – like the euphoria/fear effects. It would also fix my fish problem (that the character needs to be created in the scene to be able to follow a character in the scene). I’d just have to find a way to keep the score for the tic-tac-toe games consistent across the scenes. That’s probably more trouble than it’s worth, but this is not actually a game about playing tic-tac-toe (did anyone think it was? okay, maybe it is). If I can keep the game board and score consistent across the scenes, then this is the perfect solution (if a bit complex. I’ll of course be looking into other solutions).

Curious Games: “Best Practice”

curious games, indie, Process Writing, research

This week, the Curious Games Lab gang talked about heuristics and best practice, and how they’ve evolved from efficiency models in the workspace. Here’s an article that takes a tour of these heuristics and recommendations and analyzes some games in terms of them:

Sweetser, P., Johnson, D., Wyeth, P. and Ozdowska, A. (2012) “GameFlow heuristics for designing and evaluating real-time strategy games”. In Proceedings of The 8th Australasian Conference on Interactive Entertainment: Playing the System (IE ‘12). ACM, New York, NY, USA.

Sweetser et al. provide a set of guidelines for making games that have already been made. While there is a great deal of sense in not totally reinventing the wheel and finding a completely different way to deal with every one of these heuristic elements, keeping each of these the same across games removes the incentive to innovate.

I think that it makes more sense to start from a game concept, mechanic, or idea that the developer finds interesting and to work from there and decide what will be best for that game than it does to start with best practices. Best practices are probably useful for conventional aspects of the game that the developer is not trying to highlight – making them the same as most other games in a genre is a good way of effacing them. So, if something is not an important aspect of the game, there’s no sense in reinventing the wheel… or is there?

We discussed the possibility of creating a series of games that basically takes these heuristics and deliberately breaks every single one of them, one by one. I think that’s the kind of exploration that makes best use of these “best practices.”

In my own attitude towards playing games, I think that I’m trained to expect the “best practice” kind of experience (to the point where, when starting Unfinished Swan and being faced with a completely blank screen with just a dot in the middle, I thought that I must need a move controller to play it, but as it turns out I could have just checked the controls to know that I could sling paint with the trigger buttons – which are, in most games that I play, not usually the primary controls, and that I didn’t even think of pressing. Since the screen was blank, I couldn’t judge my progress when moving the joysticks either, so I didn’t know what was going on.) but I don’t want to be trained to expect it (I laughed very hard about the Unfinished Swan thing). I like games that turn my expectations on their ears.

Similarly, while sometimes it’s good to give the player some sign posts, I resent the recommendations in the Sweetser article that recommend a whole lot of hand-holding and that recommend that games should be playable by people of all skill-levels. Some games should just be really hard – not everyone should be able to easily finish them. It’s the same with books, and it’s the same with nearly every other medium. Not everyone appreciates the same experience in the same way.

Games that break the rules tend to be the most memorable and replayable. Katamari Damacy in particular comes to mind: the goal is to roll up the level, and at larger scales the player can literally roll up entire islands and eventually continents. It breaks most of the recommendations for Concentration in the Sweetser article, depending on how you interpret them. Actually, all of these are largely dependent on how you define them for a specific game. Some of them even seem to contradict each other: what is stimuli that is “worth attending to?” and is that stimuli a “distraction from tasks that [players] want or need to concentrate on?”

As a game designer, I have not yet discovered exactly what kinds of games I’m making, having only made three so far (one as part of a GGJ team this year, one for Pixelles, and the one that I’m making for the Curious Games Studio), but I do recognize that what I am doing is trying to make games that I haven’t seen before.

Oh, and because I will recommend this every chance I get and have mentioned Katamari in this post, here’s an in-browser version of Katamari Damacy:
Roll up!

Curious Games: Planning Ahead

adventures in gaming, curious games, indie, Process Writing, research

medical malpractice lawyer says: “very nice post, i actually love the web site, keep on it”

Looks like I’m on to something! You keep on it too, medical malpractice lawyer!

So what I have been doing this week for the game is creating assets and continuing to think about design. So far, the very basic Stencyl file has a custom cursor, screen shake that simulates poor motor skills (but there will be much more to mess with the player’s motor skills if I have my way) and a health bar that starts at 2000/3000 PSI.
(Why 2000? Because in diving, it is recommended to reserve 1/3 of an air tank for the descent to a destination, 1/3 exploring that destination, and 1/3 for the ascent.)

Here are two of the lovely art assets that I’ve made this week: the buoyancy control hose and the console – hand-drawn in Photoshop. (I’m not yet sure if I’m going to have the console have static dials, animated dials, or just numbers).

These are modeled after my own BCD, which the player will be wearing.

These are modeled after my own BCD, which the player will be wearing.

I have this desire to make most of the effects in the game randomized or happen at more or less random intervals… I’m sure that this is relatively simple, but I have to look up how to do it in Stencyl. That can make simple tasks seem daunting — kind of like Nitrogen Narcosis! — so I tend to plan things out in detail when I could probably just start implementing features and see what sticks.

Here’s my game plan (or really, a list of tasks that I need to accomplish and features that I want to include):

– because people with nitrogen narcosis have problems multi-tasking/tend to focus very narrowly on one task, I want a fish to swim by sometimes and for the camera/player’s view to follow/pan on the fish. I want the player to have to find their way back to the game board.

– because of that same narrow focus, I want the buoyancy of the player to occasionally cause the player to start to sink down past the game board, and for them to have to adjust the buoyancy to regain the board (and if they over-inflate, they may end up shooting to the surface — I don’t THINK this is too ambitious).

– because nitrogen narcosis can come with feelings of euphoria or fear: I want to adjust the brightness of the game in tune to either a very happy soundtrack or a very unhappy soundtrack. Preferably either can happen at random from a baseline. I may also include some bizarre actors like dancing fish or divers, or decorative decals.

– I want to blur the edges of the screen somehow (the camera shake effect does somewhat do this at higher intensities) to mimic tunnel vision (another symptom).

– I want to find other ways to mess with the player’s motor control — since I think it will be point and click, maybe I can find a way to at random reverse the mouse tracking (I know there’s a way to do this on consoles with the joysticks…I’m hoping there’s a way to do this in stencyl).

– Continuing with motor control, I was thinking that the placement of the pieces on the board should have to be quite specific – that the collision area of the piece should be quite small relative to the entire size of the piece, making it harder to place each piece.

– Because poor judgment (and, at much deeper depths, hallucination) is one of the major symptoms of nitrogen narcosis, I want to perhaps screw with the player’s perception by making the game board appear different than from how it actually is, or maybe make some game board pieces that can’t be dragged, or that can only be dragged so far.

– Because people experiencing nitrogen narcosis can experience slow thoughts: I want to find a way to slow down the player, perhaps by slowing down the controls or the speed at which a game piece can be moved. I don’t know if this is possible with stencyl. Maybe I can do this by creating a mechanic where the player clicks a piece then clicks the place on the board, and the piece travels at a predetermined speed towards the board. I could set the speed of individual pieces to different values, thus making some relatively easy to place, and some more difficult.

– I want to implement a 3-minute time limit on the game in which the player has to win a certain amount of tic-tac-toe games. How many will probably be determined by a lot of playtesting…

– I also want to have there be the chance that the player experiences some of the other minor annoyances of diving, such as a foggy mask or a free-flow (basically when the regulator gets stuck open and starts to spill out precious air — this is usually quickly fixable). I’m not sure if these will make it into the final game but as soon as I figure out randomization, they’d be easy to implement.

– Obviously, I have to program tic-tac-toe. Pippin has told me that he will help me with this. I was thinking that it might be interesting to have the program have some of the same handicaps as the player as a rational for the program making mistakes in the placement of their pieces.

Where I foresee some challenges is in randomizing these behaviours. I know that I can make the camera track a specific actor (the fish) through an environment. (I don’t know exactly how to allow the character to move the camera back.) I know how to make music play at specific times. I also know how to set collision areas and the movement speeds of actors. Largely, learning how to randomize the behaviour and learning to do it within appropriate parameters so that things aren’t totally at random, seems to be my biggest challenge. There are plenty of Stencyl tutorials about this, though. (Although learning to program Tic-Tac-Toe will be another kettle of fish.) I also foresee that I might have some difficulties with making the character navigate the level with the mouse, but I’m already thinking of ways around it.

I’ll keep you posted, Internet!

Curious Games: Brainstorming

adventures in gaming, curious games, indie, Process Writing

So I’ve decided to make a game about performing a simple task under unusual conditions. The task will be to play Tic-Tac-Toe 130 feet underwater while at least slightly under the influence of nitrogen narcosis, which is basically like being drunk underwater. This usually becomes at least slightly noticeable when divers go below 100 feet and the symptoms disappear when the divers ascend.

Here’s a link to my “Your World of Text” World (be careful: if you edit anything, it’ll be saved) where I’ve been working on a brainstorm that kind of shows my process a little bit. I’m starting to think about mechanics that should be simple enough to code but that will transmit the experience effectively. Ideally, I’d like to switch up some of the mechanics while the player is in the process of playing. I’m not sure if I want to have the controls be based on keyboard or on mouse. There are advantages to both: I can make the keyboard controls be flipped and might be able to actually make the controls switch mid-game.

One thing that I’ve definitely decided is that I like games like B.U.T.T.O.N that make the players enforce rules that can’t be enforced by code/programming/the game system itself. To that end, players of my game will have to wear some scuba diving equipment: a mask, a snorkel, a BCD (Buoyancy Control Device – a vest-looking thing), a regulator and octopus, and either a weight-belt or integrated weights.

Some goals this week: to create some prototypes of the “symptom” program effects and the timer and air limitations.

TOMORROW THE WORLD: Interviewing Lynn Hughes and Bart Simon About Critical Hit

indie, Process Writing, research

This summer, TAG is hosting a game collaboratory called Critical Hit for games for social change. The program will run ten weeks and applications are open until the 29th of April. With that in mind, I spoke to Lynn Hughes, the TAG Centre’s Associate Director, and Bart Simon, the TAG Centre’s Director, about the genesis of the collaboratory and their hopes for the project. To know more about them and what they do at TAG, you can visit our people page.

JRM: When you started TAG, what was your vision for the centre? What kinds of work with games did you hope to foster, and what do you envision for TAG and its projects in the future?

LH: One of the main things was to do something with other departments and involve groups and individuals from outside of the university. We wanted to have a bigger bundle, a bigger mess.

BS: The fundamental idea of the centre was to break the deadlock of disciplinary divides. The research centre model is the best structure we have for thinking of doing that in a way that doesn’t overly burden individual faculty members. Once individual faculties members are actually able to come together and spend time together, we can make it easier for students to do so as well. That’s the real goal: not to change our lives, so much as to the conditions for graduate students and eventually undergraduate students. The idea is to create a structure which enables this kind of interdisciplinary collaboration. With respect to game design, this should have an impact on the kinds of games people think of making and on the kind of games that they actually make.

LH: The idea is not supposed to be that Bart and/or I conceive of a research idea and then a bunch of other people execute it. The idea is that projects are supposed to bubble up from wherever they bubble up from and we see if there’s a way that we can bring people together and facilitate them or support them. It’s supposed to be a lever for other things, not just for us.

BS: Literally, a kind of social-cultural material condition of possibility, right? Until we get a structure where it’s possible for students to breathe long enough that they can imagine doing something else, it’ll never happen. The idea is to make a space where people start to realize that their own education can be something other than what they expected it to be.

LH: In my case, one of the other motivations is to move out of the art sphere and into the games sphere – or more precisely to interbreed the two. That was what this was starting out – more recently, it’s been about trying to promote a view of games that is much broader than the view that you get in the media. It’s also much broader than the view that you get from some people making games. For me, TAG contains a very broad spectrum of stuff, it includes all kinds of things, some of them near art and some of them all the way on the other end of the spectrum.

BS: One of our goals is to think about games in the broader liberal arts sense rather than in the vocational game making sense. Do games have a place in the conception of what the traditional liberal arts mission of the university might be? We’re trying to reimagine what the role of liberal arts is. Rather than making new workers for this industry that may or may not survive, we have a much broader conception of what games can be.

JRM: Montreal is a fairly important city in game development today and fosters a vibrant indie developer culture. How do you think TAG benefits from the community in the city and how do you think the community benefits from TAG?

LH: At this point, we’re getting really well-connected. If you look at something like Mount Royal Games Society, two of the leader-founders are connected to Concordia.

JRM: Saleem Dabbous and Stephen Ascher.

LH: I’ve also known Nick Rudzicz for a long time, but Saleem and Stephen are specifically Concordia connections. In terms of TAG, you can see that there’s a lot of back-and-forth. Bart and I are currently trying to organize something in London and we hope to involve the Mount Royal Games Society ( Or, there’s the IGDA and someone like Jason Della Rocca who was the IGDA director for many years and who is now doing Execution Labs. There’s a very collegial connection – there’s a regular flow of emails and late dinners, talking and exchanging.

BS: Montreal’s game developing community is a bit different than others in part because it’s super-dense. There’s a very large number of media arts-trained people in the development community rather than pure engineering or pure computer science. When Lynn and I started, there was a natural audience, a natural community that extended beyond the University. We used to go to the Montreal Games Summit when it first started up – our students were there, participating in everything that was going on. We used to sit in cafés chatting with everyone about games. Early on, we had projects where industry designers would informally or more formally make use of students. The networks were starting to develop.

One of the crucial things is to have a platform that allows us the time to do that – a platform that says it’s good to go over to Ubisoft, it’s good to go to EA, MRGS meetings, IGDA meetings. The community is very rich: students should go, faculty should go. Out of those connections, which are informal and casual, come real collaborations, and that’s one of the only ways that they come. We’ve been lucky because of where we are in that sense. Montreal doesn’t have the vibrant indie community that other cities have but there is a density that has allowed it to continue developing. We see part of TAG’s role as participating in the building of that vibrancy, given the background of the changes in the industry.

LH: Speaking of the relation between media arts and games here, it’s been unusual. I don’t think that you’ll find that in Toronto or Vancouver the way that it is here. Concordia is a part of that, but it seems to be generally the case in Montreal. If you want to look at TAG’s relationship to that, something like FRACT would be a good example. The FRACT team came here for our first incubator and ended up completely redesigning FRACT using MAX/MSP, which is a media arts approach to doing sound – it’s not at all a games’ approach. They did that with the help of a Concordia student. That’s special to here.

I’d also like to talk about our relationship to Dawson. If we’re talking about Critical Hit, that’s an important relationship that developed somewhat naturally because Dawson is just down the road and because they’re doing similar things to us. Sean Bell from Dawson came and found us and we’ve formed a great relationship that’s very important to the Critical Hit project.

JRM: Critical Hit is described on its website as a “A Montreal-based summer program to catalyse the development of experimental games motivated by contemporary social, cultural and political concerns.” How do you feel about the way that games are currently being mobilized as vehicles for social change?

LH: That covers a broad spectrum! I wouldn’t pretend know what the whole spectrum looks like. There’s a caricature of it that I have in my head – that there’s a superficiality or that the games aren’t very good. I think that’s probably a simplification. I’m looking forward to spending the summer discovering the better games that are trying to mobilize social change. I do have a broader definition of what can be included in that category – not because I have a broader definition of social change although I may have that, but because I have a broader definition of what can be considered a game! I’m looking forward to taking a look out there some more and seeing what I find.

BS: It’s important to note that we don’t necessarily purely subscribe to the definition of serious versus unserious games or games for change versus games that are not for change. Our description of what we’re looking for is trying to get at – I believe – a kind of a level of designer intention that says ‘we believe that in contemporary culture games communicate things about the world and that you can have an idea about what you want to say about the world and do that with a game.’

I’m less concerned about what it says than that the designer would like to say something and has a conception of who they would like to say it to and what they’d like that person to hear. Part and parcel of that is that it isn’t acceptable from the point of view of Critical Hit to have a designer come and say that ‘what I would like to communicate is the need to make more money. I want to make a game that I simply know will make money’ or simply to come up with a game that’s about saying ‘I have a better shooter.’ What we’re asking is for a level of designer intentionality that I wouldn’t say is missing from the games industry but that needs development. It’s there, and people are crying out to be able to make games that communicate something about the world that they’re a part of. What we’re trying to do is open up the space without getting trapped in the definition of what counts as a good game to make.

LH: The way I would put that is to say that we want games that are thinking about games and thinking about the world. A lot of the time, there’s games thinking about games. That’s a good thing but we’d like them to be thinking about the world at the same time. And the question is, what does that mean? Because we want them to be thinking about the world in a way that’s interesting where the game is also interesting. We’d like to be surprised. Whether that will happen right away, I don’t know. Maybe this will happen over the course of the next three years. The first year is going to involve this kind of discussion. Hopefully by the second year but definitely by the third year, people should see the collaboratory as a place where they can bring unusual games or games that might not be accepted anywhere else.

BS: Medium specificity also matters. It’s not like somebody can say ‘I have an idea for a film but there’s no incubator for films so I’ll just try out my idea for Critical Hit.’ That’s not gonna work either. There’s got to be some discussion of why the medium of the game is important. We’re looking for an understanding of what games are, in terms of their mechanics and their futurity – why it matters as a game and not as a novel or a poem or a film or any other medium of cultural production.

JRM: The teams who make it into the Critical Hit collaboratory get to keep all their intellectual property and are actually encouraged to try out more experimental angles that won’t necessarily lead to commercial success. Many incubators do have the goal of commercial success in mind. How do you expect this will change the output of the incubator?

LH: It’ll be better? I don’t know – I don’t know if I think about it that way. I think that we should be looking for releasing new kinds of games. The criteria shouldn’t be whether or not they’ll be commercial successes. Maybe some of them will be commercial successes. I think that it would be ridiculous to be against commercial success.
That’s not the idea – the idea is that that’s not what we’re going to talk about. What we will be talking about is whether or not it’s a good game – and that can help with commercial success. The idea is that it should be an interesting good game.

BS: I’m not convinced that we would entertain any proposal for a game that has no intention of being played. If there’s an intention for it to be played, I think that it’s obvious to begin thinking about commercialization, or at least distribution. We’ve been pretty clear that you don’t have to plan to make a game for iOS and go through the Apple store, although you certainly can. You could instead shoot for a festival venue or something along those lines – both are equally legitimate to us. I think that the notion that one should design with players and distribution in mind is crucial. What commercial incubators are struggling with, is that failure is crucial to innovation. But if you have a business model incubator, your window for failure is much narrower than I would argue ours is. We’re not going to live or die on the basis of the success of the games in our incubator.

What we’re going to encourage is experimentation, innovation, failure – in a productive way, and therefore hopefully affect the broader landscape. It’s not just about us, but about how the games that we’re making in our incubator can actually impact the larger community. How can the games that are made and the process by which we make them in our space influence how people make games in the industry, or in other incubators, or at jams? This tiny little three-year experiment is to see whether our context – a non-commercial context for game incubation – makes sense and to join a larger conversation about game-making.

LH: This is also partly about how universities can work with an industry or the larger community – about what the relationship is between inside the university and outside of the university. The idea in the university is “excellence!” How does excellence translate into commercial success? I think that it should. It’s just that the emphasis here is on taking risks, on innovation, on excellence in a broad, non-stuffy way of thinking about it, and what happens after that.

BS: At the same time, we’re going to encourage excellence, say, through failure or experimentation. But we’re not encouraging flakiness. The idea is not to come in and slack off because the pressure of commercial success is off and you’re not hungry for dollars to survive. We think we can give people the experience of what it’s actually like to make a game under serious conditions while at the same time protecting them from the survival worries that plague commercial incubators.

LH: We’re planning on doing more than one public presentation at the end – that in itself is a deadline. A serious deadline: you have to get up there and make a fool of yourself or show what you’ve done.

JRM: Ideally, at that point, you’re proud of what you’ve done because you’ve been taking the work seriously.

LH: Yes, so that you’re not ashamed to get up there and say what you’ve done.

JRM: What kinds of games are you hoping to see come out of the Collaboratory?

LH: I’m hoping that I’ll see something I didn’t expect! Something exciting, something new.

BS: I’m hoping that we’ll see something different, that we wouldn’t have anticipated we’d see. I’m also hoping we see something ambitious. I’d like to see teams that aren’t interesting in settling, even if that means going beyond the scope of our ten-week project. I’m also interested in seeing what the process itself brings to the team. It would be pretty sad if a team came in with a plan, executed the plan and it was exactly what they planned on doing from the beginning. That wouldn’t say much about the productive space that we’re trying to create.

JRM: It also doesn’t fit how any project ever actually ends up working.

BS & LH: Yes!

LH: If that’s the case, there’s something wrong.

BS: What we need to think about in order to keep this project going is how our process influences exactly those changes that takes place. The outcomes are games, yes, but they’re also processes, and how to understand the process is equally important to us.

JRM: Has TAG been involved in other incubator-style projects? What kind of work came out of them?

LH: Two years ago, we did the first Montreal Games Incubator and we had four projects. One of them was FRACT. We had one large team that came mostly from Dawson, one from Champlain College, one team of independent professionals and one one-person team. The games were all quite different. The whole experience was really a success. The larger team especially told us that they got a lot out of the mentorship.

BS: Our first pilot was just to see if we could run an incubator. We asked people who already had a project and let them make their games.

LH: We had a call just like this one, and about ten teams submitted, out of which we chose four teams.

BS: “CUBE” was the Champlain College iOS 3D puzzle game. “Commander” was from a UdeM one-person team who was looking to improve an already-released game. The big team from Dawson made “Damnatus” which was an online multiplayer tower defense game… we knew that it would have to be cut down. It was a good process to see how the team pared down the project with the help of the mentors and the other teams. “FRACT” came in already having won the student competition at IGF.

Richard Flanegan, the lead designer, already had a good idea of what he wanted to do, and came into the incubator and completely changed his mind because of experiences he had at the incubator. That was a really strange proof-positive that we had something interesting on our hands. We thought that FRACT would be the one game that came out of the ten-week incubator looking ready to go, but it turned out to be the one that got redesigned from scratch, but also as a result is the most robust of the projects. If our incubator space allows for that robustness to develop, then the results should be promising.

LH: We also had a nice presentation night for the games where each team came up and gave a short presentation about their game, after which we had a big party with demos up. Lots of people came and it went very well. We were pleased, especially for something that we just leapt into and crossed our fingers, because we wanted to see what would happen.

BS: Since then, we’ve also done the Global Game Jam two years running and a lot of TAG people got involved with the Pixelles incubator. We’ve been very closely watching Jason Della Rocca’s XL and we were involved in early conversations about what it would look like. We’ve been focusing on game incubation activities since the pilot.

JRM: Is there anything else that you’d like to say about the incubator or the projects going on at TAG?

BS: It’s important for me to understand the Critical Hit project as part of a larger ecosystem. While one of the motivations for Critical Hit is a kind of conversion of space and resources in the summer time – students are off and doing their thing – how can we keep the game developing going 24/7? At the same time, it’s not like we just cycle in and cycle out when the students return. We’re developing relationships and hope to foster collaborations during the rest of the year between students, indie developers, other universities, mainstream industry people and community arts people. The longterm hope is that we’re seeding a major Montreal establishment. In the next five years, we hope to have a vibrant hub – publicly supported and funded – for people to get together and make games. Less than a business incubator and more than a game jam – that’s how I’ve come to think about it.

LH: In terms of community ties, we’re especially happy to be fostering Angelique Mannella and the Decode Global team. Decode Global is an independent not-for-profit company and they’re winning all sorts of awards for their new game, Get Water! We lent them space and have been supporting them, nurturing a relationship with with the outside world under our roof. Also, since Angelique is now going to be managing Critical Hit, we hope that there will be an interesting synergy there. We want to blur the boundaries – or make them permeable – between what’s inside the university and what’s outside.