Ring Fling – Developer Diary 3 – The Point
Once I had a working prototype, I knew my velocity was about to slow down. Making the transition from nothing to something can be a very fast process. It’s not always the case, but for Ring Fling, it definitely was. However, going from something to something good has never been a fast process. The next thing to figure out in Ring Fling was what the point was, specifically, how the scoring would work.
When I got started, I didn’t think much about scoring, but in the back of my mind, I had a really simple solution. In my head, every player would start with a certain number of points and when they hit zero points, they’d be knocked out of the game and the remaining players would continue until one player was left standing. It didn’t take long to get this implemented, but in about as much time as it took to program, it became clear that it was fundamentally flawed.
At the time, it was only a 4 player game. If the last two players left were on the same side, especially on the short side of the iPad, the game was effectively impossible. I wasn’t quite ready to give up on the structure quite yet so I tried a number of things. I tried removing the knocked out players from the board completely to give more space to bounce rings, but that didn’t help much. The jaggies (at the time a square) would constantly get stuck in the corner. I also implemented a mode where once it got down to 2 players, those players would shift to the opposite sides of the screen. While this solved the problem, it felt really strange. In theory, if there were 4 people sitting down and playing a game, suddenly one player would have to stand up and move. So while I didn’t move forward with that solution, the code I wrote for it made it pretty trivial to implement the 4 player board.
The next solution I tried was to have score count up. Instead of losing a point every time a jaggie is pushed into your zone, everyone else would gain a point. It definitely felt less clear than the losing point solution. It’s obviously much easier for people to associate one cause to one effect rather than one cause to three effects, but at the end of the day, it worked and the other one didn’t. One other nice upside of this solution was that nobody ever had to sit out and do nothing. I remember when I was in college, the big game was Counterstrike. One thing that prevented me from ever getting into it was that as a beginner, the majority of my time was spent sitting and waiting for a timer. Firstly, with the count up scoring, it’s not immediately obvious when it’s mathematically impossible for you to win. Especially with the frantic action, doing the math is generally not a high priority. Secondly, even if you can’t possibly win, you can still do your best to make sure your nemesis can’t either.
This is a great example of the fastest part of the iterative process. You start coding something up and you just know it isn’t going to work. Sometimes it’s simply obvious, sometimes your experience serves you well. Once you’ve worked out all the obvious stuff, though, it’s time to get some more eyes on it–or in my case, some more fingers. It was time for a play test.