Voodoo Cheval is the first (and at the time of writing, the only) game that I have worked on that has been published onto a distribution platform. If you are unfamiliar with the title, it is an action game intended for mobile devices, where the player is tasked with defending their beloved horse from an onslaught of zombies, snakes, and other monsters by drawing particular shapes on the screen to destroy them.
I was brought onto the project rather early in development, signing up for a role that sat between design and programming, but leaning more towards the design end of things. The team, like myself, were all full-time and part-time students of California State University, Long Beach, who had banded together to form the Video Game Development Association (or VGDA, as I will refer to it from now on). What I found so brilliant about this opportunity was that very fact; we were all students. We all had coursework to worry about, jobs to help pay for rent and tuition, very little free time, and a huge passion for video games.
The team was fairly large in scale, and with each of us only being able to contribute so much time each week to development, tasks were divided into smaller, more manageable pieces. While I had the opportunity to work with other students designing systems, namely enemy behavior and player controls, the bulk of my work was in designing Level 1; an open setting where 3 types of enemies would appear on the screen in waves. By the end of development, there were 15 waves in total, each with it's own purposeful design with the aim losing the player within "the magic circle".
Tutorial
Upon starting the game from the main menu, the player is met with a very brief and simplistic "scripted tutorial" scene, where the player is met 2 types of enemies that they will see throughout the remainder of the game.
Although this tutorial was not of my own design (will give credit when I find out who exactly built it), it had a large influence over how I built the rest of the introductory stages. The goal was to make the tutorial completely interactive, without hindering the start of a play session too much. As the enemies approach the horse on screen, the player will have the opportunity to defeat these enemies in the usual fashion, but if they do not know what to do, the snake and the zombie will pause, staying frozen in place before they can cause any harm. When they freeze, the spell effect (usually visible on the screen when touch input is detected) is animated to suggest what action to take, almost in a "monkey-see monkey-do" kind of way.
No pop-up windows, no invasive companions to say "Hey! Check this out!". Just a simple suggestive animation paired with a brief safety buffer before the game really begins. For a new player, this brief encounter establishes the foothold that the following enemy spawn waves will build upon.
Wave 1
Looking back on it, I'm pretty sure I over-thought some of these enemy placements... It was clarified before I started that enemy spawn would not be random, but placed. With replay-ability being a concern, I felt it best to keep these placements a little on the unpredictable side. Hence, this asymmetrical placement of the first two zombies. An easy win, but it also should have served as an indicator that, from this point forward, there will never be just one of these guys on the screen at a time.
Wave 2
The idea behind this wave was to re-enforce an idea that might not have been obvious to every player: the fact that you can kill more than one enemy with the same attack. Even if you attempted to draw a circle around a single zombie in this grouping, you are bound to rope in another one with how close together they are. This was also meant to establish the idea that the size of the shapes you will draw can vary, which we will find out later can either help or harm you immensely.
Waves 3, 4, and 5
The third wave was intended to push the player to use the different sizes of circles that were demonstrated between waves 1 and 2. The zombies on the left and right are the first to appear, and they are spaced relatively far apart. It would be fairly easy to circle each one individually or circle them both together. The grouping at the top of the screen comes shortly after, a little more tightly knit together, and finally there's the big grouping at the bottom, appearing slightly behind the grouping at the top.
At this point, the player may start to feel a little frantic, drawing circles around zombies the second they pop onto the screen. But if they are patient, they may be able to see that by allowing the zombies to draw in closer, they can draw one big circle to take them all out at once.
Unfortunately, we never implemented any sort of reward system for combo kills. Something that would have made this design process a little more meaningful.
Wave 4, shown below, tries to make that idea of the risk and reward of patience a little more obvious, having the zombies enter the screen in the form of an actual circle.
In hindsight, it might have made more sense to swap Waves 3 and 4 to make this point, but I think it also works in regards to replay-ability. Now that you are fully aware of how this kind of strategy could pay off, you might want to play through it again and see how many zombies you could kill with a single drawn circle. An unexpected issue that this design may have contributed to, however, is the discovery of an exploit that many players would try to abuse,which I will discuss shortly.
Wave 5 was simply a zombie rush, with assets placed in various positions in an attempt to establish rhythm, but while avoiding predictability. Designing waves like this one (there are many others in Level 1) was simply an iterative process, where I would place the zombies in various positions and re-position them until the wave felt like it could hold a "flow"; not too challenging, but not to boring either.
The Exploit
Something that become apparent to us rather quickly during play testing was the fact that the player could, in fact, draw circles big enough to wrap around the whole screen, if they were quick enough to make the beginning and ending points of the line connect. I don't quite recall at what point or which wave that play-testers would come to this realization, but I'm pretty sure it was around waves 3 or 4.
When a discovery like this one is made this early on, it makes the "strategic placement" of enemies essentially moot. Even more unfortunate, the team never got around to properly addressing and fixing the issue.
 |
| A (rather poor) demonstration of the exploit being used in Wave 3. |
Looking back, there are a few reasons I can think of as to why this wasn't fixed. One is the deadline; as students, the goal was to make one small game over the course of a semester, all the way up to the week of final exams. While we did do a fair amount of internal play-testing, this issue wasn't really brought to our attention until we had students from other colleges play the game at the Student Game Developers Alliance Summit in May, not long before our deadline. At this point in time, we were no doubt scrambling to get bugs fixed and the final art assets in place, which ultimately still resulted in a cohesive experience we were all proud of by the end of development.
Another reason that comes to mind is how ineffective this strategy becomes after Wave 5, as snakes are re-introduced for the first time since the tutorial.
Something that might not have been made clear in the tutorial is this particular trait about snakes: if you accidentally draw a circle around them, they "split", and form two smaller snakes that the player now has to deal with. If the player were to simply sit there and spam large circles on the screen, without paying attention, they would be overrun within moments.
I recall at the time feeling that this enemy design would counteract the exploit so easily that it would be abandoned after Wave 6, which could also be how the rest of the team felt when the exploit was discovered. In either case, it taught me to try to play-test my own work from a perspective of someone who doesn't know what to expect. This seems so obvious to me now, after reading books and articles on bug testing or human centered design, but as this was one of my earliest projects, I'm willing to forgive myself and move on.
No comments:
Post a Comment