This semester started with me working on the sumo puzzle game. That was quickly scrapped in favor of our ripple game that Willie was initially working on. The first prototype of ripples began with two players controlling their jumps to generate circles that expanded outwards to attack. The game was top-down 2D at the time with scaling sprites used for the ripples. The next iteration took away the player’s ability to jump on their own and instead the characters would automatically jump at set intervals. At this point in time the game was played with just the keyboard and death was instantaneous if an enemy ripple was touched.
QA feed back on the game was positive once people started to get the hang of it. It was also during this iteration that people thought it would be interesting on a mobile device. Since we were working on this game in Unity, and I had some experience working on mobile, I went ahead and made a mobile version of what we had. Initially I implemented four different control schemes to test out. Feed back on the mobile version was positive and it had a relaxed meditative feel to the game. While the mobile version was being made, we also shifted over to controller support creating more range of movement with the analog joystick than the keys.
We had an idea about working music into the game, so David checked out a Unity Plugin called Koreographer, which allowed us to have events driven by the music. We worked on the multiplayer portion of the game a little more, trying to test out various ripples types and ideas that we could work with. The two we tested out at this time was an explosion ripple, which slowly engulfed the screen until it hit something, and a defensive bounce ripple that would deflect enemy ripples. We also shifted from using scaling sprites for the ripples to using the Unity Plugin Vectrosity to draw vector circles for the ripples, which added a cleaner style to the game.
Fast forward a little bit and we have Koreographer implemented into our game, and the matches are now run to the beat of the music. So the players jump to beats of the music, driven by events set up in Koreographer. It also allowed us to make our first boss. The boss had various patterns, based on where we were in the song. One phase had a set path, one would charge the player, and one would drop a special ripple.
One of our biggest challenges we faced, was that our team did not have an artist. So we wanted to go for a simple art style that looked pleasing to the eyes, and allowed the player to still be able to tell what is going on. Sometimes the game play would get a little hectic. So we went to vector art, because it was simple and pure. Half our team is also math minors, so the theme of the game also has a lot of math influence, such as the characters who are all named after mathematical symbols. Their name determines the shape of their ripple, and also their special.
Our first boss we created was Delta. And delta stands for change, so we gave Delta the ability to have control over the size of a special ripple they create, that they can control at will. So we started to build a roster of characters that the player would face in the single player mode. The idea being that any boss the player defeats they can use them to face off against their friend in the multiplayer portion.
Up until this point we have toying with the idea to have some cross platform multiplayer with the mobile and PC versions of the game. But networking would be needed to accomplish this, and we didn’t have the resources to dedicate towards networking at this point. And since it was not a primary focus of the game we decided to drop it and instead just have single player on the mobile version.
Once we got our first boss in, our main focus was in game feedback for the player. We added a special effect for when the charaters got hit. We added health to both the boss and the player. The hardest thing to accomplish was letting the player know when they are jumping and invulnerable. We added feedback by changing the size and color of the player, we also changed the backgrounds color to indicated when the player was in the air. But that wasn’t enough. So we decided to added perspective into the game and shift from 2D to 3D. We added shadows to the characters so the player could tell how close they were to the ground, and we also tested out different camera angles for the game. As of now, we have the game running in a 3D perspective with a tilted camera on both mobile and PC.
What We Learned:
Never underestimate testing. It’s important to get feedback from another set of eyes. That’s one of the things we learned this semester.. Since we had the idea for the game, we knew how to play it. So for example, in game when the characters jump, we as the developers knew what to look for when we jumped and how to anticipate it because we played it enough during development. Bringing it to testing showed us how much trouble people had playing the game when it came to understanding jumping and when they were invulnerable. Each week we would add more feedback to the game to try convey that the character was jumping. And each week we would hear that it was not enough from new and returning testers and that they still had trouble figuring out if they were jumping. Making sure our game was tested each week by those not on the development team was how we ended up shifting from the top-down 2D perspective to the angled 3D look of the game.
Go overboard then scale back. This was the advice that we got from our professor that I found useful. It’s better to go over the top when it comes to adding in feedback to the game and then scale it back as necessary instead of slowly working your way back. That way you can test out multiple at once, and see how players handle the feedback.
I had a great time working with the team that we started with this semester. I am ecstatic that our team was able to move on to next semester as we were a team that did not have an artist. I look forward to working with out new members and continuing to work on ripples.