Curious Games and Critical Hit: Playtesting

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

Yesterday, the Curious Games Studio showcase joined forces with the first Critical Hit playtest. So bitter! So sweet! So bittersweet! (By which I mean I’m really going to miss having Pippin Barr around – he’s our first Visiting Game Designer and he leaves Montreal today. Pippin is excellent at giving creative feedback and working with him during the Curious Games studio has changed the way that I think about game creation, especially in regards to my role as a game creator and in terms of what it is possible to do in a game, even with limited resources. Thanks, Pippin!)

Something especially interesting about this joint playing was that I have a game for the Curious Games studio (as you all probably know) and I had a paper prototype of our game for Critical Hit out as well. This is something else that I never would have expected – having enough games in progress to playtest two of them at once. Madness. (Really – I spent a lot of time trying to move between both games. Unfortunately, that probably means that they were both a little underplayed – but it still felt good to have that much to show.)

Another upshoot of this was that I didn’t get as much of a chance to playtest other people’s work, but, at least for Curious Games studio, I know that there’ll be an effort to put all of the games online, and I’ll be sure to post them here, and I’ll have other opportunities to playtest my fellow Crit-Hitters’ (hey, how’s that for a group name, TAGsters?) games. What I did get to playtest was all a super-effective use of our eight weeks of class-time: a creepy home invasion game with a sinister ending (this is a pun about fire – all the internet points if you kind of get it although it’s not a very good pun), a game where you just can’t win with your high-maintenance significant other and a game where your job as the game’s camera is to keep Sir Capsule alive by properly panning around and alerting him to dangers ahead (Capsule being the default sprite in Unity if you don’t create a model).

So, here are some of my notes about the playtests as I think through what people’s reactions mean:

NITROGEN NARCOSIS
There were two major physical problems that I didn’t anticipate during the playtest. One is something that would only ever occur if it was necessary to play the game in a room full of people: it’s really annoying and almost impossible to put headphones on over a scuba diving mask. A solution might have been to use earbuds, but in my experience (at Pixelles when I forgot to bring headphones), people are reluctant to share earbuds, and probably rightly so. The other is very simple, and something that should have occurred to me since I wear them half the time myself: glasses. Scuba diving masks and glasses. When I mentioned it to Pippin, he said basically that it was another opportunity for something funny to happen: people having to lean in close to their screens to play. Maybe. I can’t really think of another solution. I have the option of wearing contacts that I usually carry with me, so it didn’t occur to me, although maybe it’s not a problem I would have been able to fix even if I had thought about it ahead of time.

From a programming perspective, I noticed a bug when playing the game through multiple times: the air sometimes doesn’t reset to its original levels and I noticed that people had a lot of trouble with accidentally clicking on the whistle instead of the piece that they wanted and that they usually seemed to forget entirely about being able to move the perspective around using the arrow keys. The whistle thing was intentional, although I disliked that it interrupted the gameplay and might try to do something like make it even smaller or put it someplace where the player is unlikely to click it by accident.

People seemed to mostly enjoy the novelty of the equipment and sort of marvelled at the difficulty of playing the game in the equipment compared to without. I should add that using the particular mac mouse that we playtested with was plenty difficult without gloves as well. Something that I wasn’t altogether satisfied with but that I think is overall unavoidable is that I found the process of getting on the equipment and the process of adjusting the mask sizes to be slow and cumbersome to the process of playing the game. Honestly, it does mimic reality: getting equipment on and off is something that divers have to deal with and we all have our rituals of what goes on first, what goes on last, and everything in between. But I hadn’t intended for the equipment process itself to be a part of the game because I only really needed the difficulty to be part of the gameplay.

I watched about six pairs of people play the game. I was again struck by the way that the interaction between the two players is really what makes the game – the experience of playing together and laughing together was wonderful to watch. I also got to think more about my own design and how I seemed to have unconsciously embedded more aspects of nitrogen narcosis than I had thought: for example, it’s possible to play five games of tic-tac-toe throughout the game (or more if you run into extra time and Player 2 is willing to drag around Player 1’s ‘O’s for him to the right spot and not cheat…) and tic-tac-toe is a simple enough game that that’s arguably pretty repetitive. As I watched people play yesterday, I remembered a story that I had heard about a diver whose responsibility it was to tie a line to a wreck. He wasn’t able to tie the knot properly and someone else took over for him. Later on, at depth, he found an end of rope that wasn’t tied to anything, and, being narc’d, he started to repeatedly tie knots in it, as if trying to fulfill his earlier responsibility. He would have done that until he ran out of air had his buddy not noticed and brought him up (it’s my understanding that the knot-tying diver was actually violent in his desire not to stop his work). I’d say that out of the six playthroughs that I saw, in four cases both players seemed to really like it, in one playthrough the players seemed a little mystified, and in one case the equipment seemed to interfere with the enjoyment of the game.

What seemed the most successful overall was the interaction between programming and the physical world – how what someone was wearing in the physical world affected what they were able to do in the programmed space. That’s pretty cool.

ROSIE ASSEMBLED/THE ZOMBIE CYBORG GAME

For this playtest, I was specifically trying to see how people felt about our two gameplay mechanics: the ideograms (if they were communicating properly and were fairly easy to interpret) and the block puzzles (specifically: how people felt about them and their relationship to the body that they created).

The answer for the ideograms is a resounding yes: people almost always got the sense of what they were supposed to mean without any help (although there may be a slight learning curve to learning the “language” of our particular ideograms), and what’s more, they really enjoyed them. I think that it would not be difficult to expand our ideogram “vocabulary” as much as we want, because all that’s involved is drawing a 2-D ideogram with no frills – just an outline, really. When the ideograms weren’t clear, people sometimes chose them because they enjoyed their ambiguity.

The answer for the puzzles is unsurprisingly complex, and it revealed a great deal of complexity in regard’s to people’s thoughts about body image.

How the playtest worked:
I provided written instructions to the players and then tried to step back (although most people didn’t really read them and I ended up explaining things that were on the sheet every time anyhow – I don’t mind, it gave me a chance to interact with the playtesters).

So, as I mentioned, the ideograms really seemed to work. Where things get much more difficult is in the matter of the block puzzles. As a mechanic for sorting out which body parts the player got, the block puzzle seems to work well metaphorically. Where things get more complicated is in terms of which body parts are included in the puzzles.

One person noted that she would have chosen Rosie’s body parts except that she didn’t want to have tattoos (Rosie’s body has tattoos because of her backstory) – she didn’t like tattoos and didn’t feel that they properly represented what she wanted. That’s really interesting because it points to stigma that we didn’t consider: it’s true that there are still some people who feel strangely about tattoos – especially, for example, in a professional workplace (although I’m under the impression that this is less of a problem than it used to be, I really don’t know).

On the other hand, this is a game about being pressured to make choices that the player doesn’t necessarily want to make – in terms of what their body should look like and what career they will end up in. This same player felt that we should include more varieties of body part (maybe we can vary them between the puzzles, because we do have a limitation for the number of blocks that we can include in the puzzle). She also suggested throwing in one other accessory to help narrow down the character’s role – something that the player gets to choose. In terms of blocks, we do have two pairs of skinny arms (that was to increase the likelihood that the player would feel the need of choosing a skinny block) and we could change one for something else, but we really have to think about what that choice would mean.

Another playtester said that they weren’t sure whether they were happy with their body: “I found it hard to tell if I was ‘happy’ with my body… I didn’t have any sense of its utility, for instance. I was inclined to just like it because it was mine.”

Personally, I don’t want players to dislike the body that they end up with – I think that the reframing of the body will only happen when they interact with other zombies – which, for the playtest, were simulated by the crowd of people and the ideograms – and people were allowed to choose whatever ideogram they wanted. In the context of the game, the zombies will be choosing from a more limited set based on what body parts come out and what “stereotype” object the player has.

Similarly, the “stereotype” object is represented in the paper prototype by a small gift box (I felt that it was a waste of resources to make a mini-version of each object for inclusion in the puzzle), and I had whoever the player chose as their assembler assign them whatever object that they want. In the game, we want the player to experience each of the five stereotypes one by one.

I think that forcing the player to take out the objects from the puzzle in a specific order (say, legs first, then arms, then torso, then “present”) might help constrain people’s choices in the puzzle while creating more of a sense of difficulty, since, as it has been pointed out, people can just take out any body part opportunistically right now. I don’t know how difficult that would be but it would make sense if the body were being built from the ground up.

I’ve got a lot to think about!

Thanks to everyone who came out to the playtest and thanks to the Curious Games Studio students and the Critical Hit participants for sharing their games.

Curious Games: Nitrogen Narcosis Up on Kongregate!

adventures in gaming, curious games, indie, Process Writing

Hey everyone,

So here’s a link to Nitrogen Narcosis up on Kongregate.

You will need:
– a scuba mask (or a ski mask, or swimming goggles – these can be bought at the dollar store)
– neoprene gloves (or gardening gloves, or work gloves).
– a mouse (with those gloves on, your trackpad won’t detect your movements all that well)
– Optional: a scuba vest with 10 lbs of lead weights in it or a vest with 10 lbs of something else in it.

We’ll be playtesting the Curious Games Studio games at Concordia this Wednesday, the 26th, in the afternoon. Get in touch with me if you’d like more information!

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.

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: Two-Player Mode!

adventures in gaming, curious games, Process Writing

Yesterday, I had a very productive game-making day. I brought in a pair of scuba gloves and my mask and tuba with the intention of play testing the game myself, which I did. To my delight, the gloves alone have the effect of making the game that much harder and of slowing down the player (at least for me) in exactly the way that I couldn’t figure out how to do with programming. Pressing the teeny little arrow keys with sausage-fingers is really hard, and the trackpad doesn’t actually detect touches made with the gloves, which means that it’s necessary to use a mouse — which is even more fun to use with gloves on a mousepad.

After testing, making game adjustments and failing to find any more bugs, I asked Pippin to try things out for me. The verdict: everything seems to be working to good effect but there’s got to be a way to create more incentive for the player to sincerely be trying to play tic-tac-toe. We thought of patterns and of course it made me realize why I had wanted to program an actual tic-tac-toe game in the first place, but in the end we settled on a simple and elegant solution: make it an unbalanced multiplayer.

(You can see Pippin playtesting over here on Instagram).

We both knew that this was within my coding capabilities but I never expected that I’d be able to map out the keys for the second player and have a two-player mode up and running in less than an hour. Something that I may change: the player in charge of the O’s can place up to 9 and I’ve asked them in the instructions to stop after placing five, as well as asking them to follow the rules of tic-tac-toe. I’d like to basically tell Stencyl: “after five ‘o’s have been placed, don’t let the player place any more/disable the keys” — I haven’t quite got that worked out yet.

Mapping the keys was simple: I just took the first nine letter keys in a grid from the left of the keyboard (since the controls for the other player are on the right).

Instructions for Playing Nitrogen Narcosis.

I then had my friend Colin from over at Red Rings of Redemption and my fiancé, Tom, play test the two-player mode for me. As it turns out, the random scene changes confused them, they didn’t like that the board was reset in each scene, and the scene changes were happening too quickly (of course they happen at a random time between a range of two numbers of seconds, but they just happened to get on the lower end every time). Also, Colin argued that while I was eliciting an emotion from him successfully, he had no idea of how to interpret it – he felt like he needed context. They suggested that I put a definition of Nitrogen Narcosis somewhere after the front screen or something.

I perceived this to actually be a timing problem – that they needed more time in each scene in order to be able to enjoy the randomness. I held onto my guns on the whole explanatory thing: I feel that the name of the game, the ambient noises, the scuba equipment that the player is asked to put on, and the environment (the fish, the air supply, etc) are all signals that the player is scuba diving, and even if they don’t know exactly what nitrogen narcosis is, it sounds like some kind of medical condition and that after that it’s up to the player to interpret the signals. As it turns out, once I slowed things down a little and tweaked a few other settings (which introduced some bugs that I’m still working on, but I’ll get to that later), I had them play again. Overall, they seemed to enjoy themselves much more — that might just be because they knew what to expect a little more, but they also had more time to actually play a game on each screen, because really, with the addition of the gear and a second player, things take a little longer — especially because placing the pieces is so difficult in the gear.

So, what I tweaked: I made it so the pieces couldn’t leave the scene and I turned back on the “float” behaviour for the O’s, meaning that the player placing the O’s can still be messed with a little – and the other player CAN actually move the O’s — it’s just that that means breaking the rules of tic-tac-toe. The bug that the “cannot leave scene” setting created is really weird, and maybe I can just create a barrier at the top of the screen since they’re unlikely to leave any other way: it seems to turn physics back on for those pieces that have floated to the top and been unable to leave. Once the player tries to drag them again, they sink like a stone. This is a stencyl problem, not, I think, a problem with any of the code on my end. I think I’ll just create an invisible barrier of some kind that the pieces cannot go through instead. A platform, or something. But first I have to make sure that that’s what’s breaking the physics.

I’m really happy that I was able to implement a two-player mode so quickly though, and I think that it makes the game much better. I thought going in, yesterday, that I was basically set to just clean up the bugs and finish up the game, but I’m extremely pleased that that’s not what ended up happening.

Time to try fixing that bug and sucker in more playtesters!

Coming soon: a final report/post-mortem on the making of this game.

Curious Games: “Masocore”

adventures in gaming, curious games, playthroughs, Process Writing

“Masocore” is one of the ways that “games people” refer to devilishly difficult games that, basically, you’d have to be a masochist to want to play. I guess the second part, the core, comes from these games being “hardcore” and difficult. There are lots of other words for it, but I find that one nicely poetic. This week, the Curious Games studio explored some masocore games like “Kaizo Mario” and “I Want To Be The Guy.”

Actually, the most masochistic part for me was trying to get either of these to work on a mac (Wine, Wine Bottler, x11…what a nightmare)…and I’m only partially kidding. In the end, I just went and played on a PC instead. I decided to play “I Want To Be The Guy” and get as far as I could. I also didn’t install any of the mods that are on the site. After an hour (at least it felt like an hour), I finally realized that I had to go out through the top instead of going through the bottom of the level, made it through the first cherry tree screen pretty easily, then died disconcertingly often on the spiky cloud screen, remembered that I could change directions midjump and finally got past it, then remembered about the invisible blocks in Kaizo Mario and made it by the next screen. At the Game Over screen, it didn’t occur to me to go back the other way until, after spending about 4 hours with the game, I decided to watch YouTube videos of other people playing this game. I was trapped in the idea that the game should progress to the left because that was what I had done so far. I watched people cakewalk through level after level and turned off my computer, shuffling away sadly to get my scuba gear ready for the weekend as Charlie Brown music played in the background.
Okay. So. These masocore games: when things were working and I was playing well, it felt amazing. I felt like a totally badass gamer. When things were going wrong, I felt like I was some kind of fraud who couldn’t even make it past three screens of a platformer.

I guess what I’m used to doing is either having to solve puzzles or perform motor skill and hand-eye coordination feats – not both at the same time. The only way to prove a hypothesis about the puzzle/level that you’re working on is to try it and see, and if it doesn’t work, die and start over. I also don’t often play platformers, so my skills were definitely subpar. The last platformer that I played was Braid. The truth is, I usually don’t find platformers all that interesting, and given limited time, I’m much more likely to play something else.

However, my fiancé and my friend Colin love this kind of stuff, so I decided that instead of just giving up on “I Want To Be The Guy,” I’d take it to them. We played for a while, they agreed it was hellishly difficult, and I decided that it was much more engaging to play as a group. Then, since Colin has totally legally acquired every NES and SNES game ever, we decided to play other “difficult” (i.e: masocore) games. We played “Kid Icarus” for a while and “Goblins and Ghouls,” and a few others. There are so many dumb ways to die even in these games that are not billed as masocore but are just generally considered difficult that I felt better about the whole experience in general. If I ever have some spare time and “I Wanna Be The Guy” is the last game left on earth, I think that I could eventually get farther than I did – maybe even go all the way. For right now, I dedicated the time that I could to it, and “IWBTG” took me out like I was a total n00b.

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: Expressive Play

curious games, Process Writing, research

When Pippin told us to go off and play expressively/personally, which is to say go and play a game in a way that deviates from the standard modes of play, it made me consider how much agency I really have in games. There are a lot of games where the kinds of play are fairly limited – where there’s not a lot of “world” to go and explore, or where there aren’t as many glitches to exploit. There’s also a lot of games where it seems like you have a lot of agency, but you have limited controls or in the end you’re being forced towards certain paths anyway.

After thinking about that a bit depressively for a while, I thought about instances of exploratory play that I had already engaged in. For example, in Skyrim, I engage in two activities that I also practice in real life: “scuba diving” – which is diving around on all the sunken boats in the environments, especially up north in the cold, and “rock climbing” – which is where I go over mountains that it should be impossible for me to walk on instead of finding the path in or around. I could list similar behaviours for all sorts of games: Unfinished Swan (where I would use the freeze time for paint globules function and then load up 100+ of them to make things like plants grow, or painting entire sections of the world completely black), all the GTAs, Fallout (where I would go off and explore the maps until I had visited every section possible, especially the secret vaults), and loads of others. I thought of doing it for Minecraft but decided that that was too easy since we were playing it this week anyway.

But, I wanted to choose a game for this and start some exploratory play in something completely new. So, I decided to play Fable 3 for the 360 and see what happened. I hadn’t yet played Fable 3. I had played Fable 2 and remember it being a fairly open world with interesting things to do, and what’s more, I remember it also being a fairly funny game.

After a few minutes of play, I started to run into things that said ‘unlock blah blah blah on the Hero’s Path to be able to do blah blah blah.’ What? This was not the Fable that I remembered, where anyone could do anything so long as they had the skill and the money. Well, I didn’t let that daunt me, although it did curb my enthusiasm a little bit.

In the end, I shook hands with everyone that I met (if you hold it to the sweet spot, you do a ‘handshake plus slap slap fist bump’ and people are pretty enthusiastic about it) and then, using the “hold hands” function, lead anyone who would hold my hand to one spot in Brightwood village. Then I played the lute for them in my own impromptu concert. They mostly liked it.

Honestly, there’s so much preamble to newer games that I should have known better than to choose an RPG/adventure game, but I find the worlds that are involved in those games particularly interesting. I didn’t have much success finding creative things to do in Fable 3 (since I haven’t even unlocked eating yet or something…in the old game, you could eat until you were really, really large and slow and you also had an “attractiveness” factor). So, instead I think I’ll go back to snorkelling in Skyrim.

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.