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).
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.