In Retrospect: Voodoo Cheval (Part 2)

Click here to see Part 1.

The previous post left off with the re-introduction of snakes in Wave 6 of level one, so we'll pick up from there.

Wave 6

The snakes are significantly faster than zombies, and paired with their capability to split in two should the player make a wrong move, they prove to be a significant challenge when tossed into the spawn wave mix.  

Up until this point, the player has been able to get by with just drawing circles of various sizes on the screen, fighting off larger and larger hordes of zombies.  With the addition of snakes, I wanted to keep a similar pace to what has been developed so far without having to place a large emphasis on a new enemy type, hence why two snakes were placed in this wave, along with 4 zombies.  

As snakes appear first on the screen, it gives the player a moment or two to process what they are seeing and try to recall where they had seen it before.  This was, in hindsight, the wrong way to go about it.  Snakes should have been a part of the mix from the beginning, considering we introduce them so early on in the experience.  This could have even further prevented the use of the exploit (discussed in the last post) from the beginning, keeping it from even being called an "exploit" in the first place.

Thankfully, if they fail to react and kill the snakes in time, we have placed a check point here to avoid the frustration of starting over at Wave 1.

Wave 7

A bit of a throwback to the lesson I was aiming to teach in Wave 2, with the single, large grouping of zombies.  This wave, an arrangement of 8 snakes that were split into 2 straight lines, were meant to suggest visually that the player could chain together multiple snake kills with a single drawn line.  Two lines of snakes were used instead of one to, again, avoid slowing down the pace too much when introducing a (possibly) new idea.

Waves 8-10

More practice in iteration, applying concepts I attempted to develop since Wave 1.  Overall, I'm pretty happy with the way these placements turned out, they strike an odd balance between symmetrical and random.  Enemies are, for the most part, consistently pouring in from every direction into the screen, without favoring a particular side.  This keeps the player actively analyzing the entire scene, making quick decisions as to which enemy to take out first.

Wave 11

The last enemy that gets introduced in Level 1, the "Demon".  The demon comprised of 3 possesed skulls, all chained together by magic.  The idea was that to defeat the skulls, you would have to trace the chain that connected them.  Sometimes, this suggestion would be a little more vague than others (see above screenshot). 

This was a bit of an odd one to work with, as his prefab asset was designed to randomly place him on the map, with the skulls placed in a somewhat random arrangement up to a certain distance from one another.  Originally, we had aimed to have 10 waves in total for Level 1, but somewhere during development of the other levels, it was decided that the demon should be introduced earlier in the game.  I don't recall if we even had discussions of offering the demon a tutorial like we did the zombie and the demon...  But I liked the idea of giving him his own wave, and letting the player figure out how to defeat him.  The chains, being connected in straight lines, should have (hopefully) suggested what action to take.

Waves 12-15

The last set of iterative levels.  Now that I have played through the whole game a few times, these last few felt anti-climactic... I'm unsure as to why this ended up being the case, but the only thing that I can recall was worrying about the integration of the random demon spawn with the rest of the enemy placements.  Placing that asset required thought and timing in relation to when the other enemies would appear on screen; I didn't want to run into the situation where the player was unfairly overwhelmed.

I am pleased to see that, for the most part, I remained consistent in applying the concepts from earlier parts of the level (varying sizes of zombie hordes, grouping of snake-lines), as it certainly added variety to my input actions.  The game never quite felt stagnant, the only change between waves that I could feel upon re-playing the game was a rise and fall in flow .

Conclusion

"Voodoo Cheval" has it's flaws, but as "my first shipped title", and my time working with a large team on one project, I enjoyed the experience and am rather proud of the final result.  Joining VGDA made me a few friends, but I also got the opportunity to learn a lot of development practices and concepts first hand.  These lessons may seem obvious to you as a seasoned developer; they're obvious to me now even with only a year or two of experience under my belt.  But these lessons were important nonetheless, and sometimes the only way you will learn them is the hard way:

• Play-test early, play-test often, play-test with everyone.
• It's obviously important to play test your game frequently and thoroughly, but it's also important to try to play with a mindset of someone who has never seen your game before.  This is the job of the average QA tester, someone who will dive into a game and try to break all of the rules; accounting for every possible thing that could go wrong or could be done differently than what the designer anticipates (see 'The Exploit' in part 1).  This could yield better results in the long run when you take your game to external play-testing.
• Play-testing the whole game (or level, in my case) sounds exhausting, and I'm pretty certain I had my aversions to the idea during development (even though my part of the game lasted only 5 or 7 minutes...).  But it's truly the only way to really gauge the difficulty curve of the experience as a whole.
• Look outward for inspiration.
• Something I realized looking back at this development process was that I never ventured outside of Voodoo's bubble to gather inspiration on how to approach the spawn-wave design.  I would often try to sketch waves on paper and try to determine the best way to use the pieces at hand, or simply drop assets into Unity and adjust their locations until I had a wave that simply "felt good".  Now that I have a few other projects under-way, I am constantly doing research and looking for inspiration to better the game-play experience overall.  I can't help but wonder how different this level could have been if I had put that into practice earlier.
• Open and constant communication.
• This wasn't a lesson so much learned as much as emphasized.  As a college student, working on a game part-time with a club, your priorities shift often.  Class work builds up, exams get brutal, and tasks that you either aren't payed for or graded on will get pushed aside.  Communication in this kind of situation is huge if a project is going to see completion by a deadline, as assigned tasks that you might not be able to complete can be handed off to someone else.  As VGDA did it's best to mimic an Agile environment, there were several techniques and tools that I had to become familiar with, like Trello or weekly Scrums, that assisted in keeping communication open and updates constant.

Overall, as small of a game as Voodoo Cheval is, my time developing it was worthwhile.  I've since continued working with VGDA on our next title, and I can't wait to see what challenges we overcome together.