By DrRandle 1 Comments
WarioWare: DIY is a great way to find out how much you know about game development. After browsing the YouTubes and seeing some of the bi-weekly "contest" winners, that fact can become quite apparent. Now granted, programming and me go together about as well as two things that don't go well together, but I have spent a lot of time studying game design specifically. And I don't just mean playing games and going "oh okay, that's fun," I mean I've taken courses on it in my "spare time." Turns out those don't really grant credits to someone going for a Creative Writing major.
In any case, I'm not trying to be all Self-inflated Ego Guy (Ok, maybe a little. Let me have this), but I think the few games I've been working on in DIY can back up some of my talk. Regardless of whether or not it does, I did want to kind of chronicle my game creating experiences now and again, to maybe get some pointers, and maybe teach someone else how to make quality WarioWare games. I'm here to share, and if anybody else would like in on some of this WarioWare DIY community action, let's start trading. My friend code is 2966-1083-9598; let's do this!
I wish I could actually show my progress here, but I don't have any capturing equipment and I'm not going to be that guy on YouTube who holds his cell-phone camera up to the DS and hopes for the best. So let's just use our imaginations!
When charged with the task of entering the "creatures" contest, I remembered that Mewtroid was one of my favorite WarioWare Twisted mini-games, and that I would pay homage to it with a "sequel." Below you will find footage of the original WarioWare: Twisted title Mewtroid:
It's more fun than it looks thanks to the tilting mechanic, but in any case, you can see the appeal right? Adorable kitten who shoots things = instant gold. Knowing that I couldn't replicate the experience directly without the aid of on-screen directional buttons (something I'm not a fan of), I decided create a different game. However, I couldn't possibly resist that cute animation, so I re-created it as best as I could. Then I gave the cat one enemy to fire upon: The Father Brain. So now I had an objective, and a few art ideas (put a top-hat and mustache on Mother Brain = Father Brain), but I still needed an actual game-play mechanic.
I decided to try my hand at the classic WarioWare gameplay of waiting for a bar to fill up to press A (or tap, if you will). There would be an on-screen bar that would fill up and if the player hit the on-screen "Fire!" button, then all would be well. With that idea, I began drawing up the rough conceptual art and then put my game into motion.
Being that this was my 3rd game, I'd learned my way around the tools. However, there's one thing I still never got the hang of: cycling animations. Before Mewtroid II, I had been working on a Micro-game that involved a clown juggling some balls, and you would have to guess which hand the green one ended up in (similar to the Knife Guy mini-game in Mario RPG). I never did figure out how to get the animations to cycle back and forth between each other without creating a solid AI that always ended the same. There's no fun in games that end up like that, I believe, so I eventually had to scrap the whole project. In Mewtroid II, I ran into a similar issue when I tried cycling animations of the bar filling up. I couldn't make the animations and the programming work together to give me what I needed, which is a win condition when the bar is full and the player presses the "Fire!" button. I knew I had to scrap it, and thought that the whole game was over.
Fortunately a new trick came into mind: Overlap. I created a new power-bar, one that was just all red with a green spot on the top. I then created a second sprite that was just a white line that would travel up and down the bar. If it was hovering over that green area, I used the Overlap command to turn a switch on for as long as it was there. If the player presses the fire button while the reticule is hovering over the green, then it turns the "Fire!" button's switch ON, which won the game. It took some tinkering to get the animations on the reticule and power bar lined up, but it worked, and now I think I may actually have a better game for it.
In Mewtroid II, the game starts with the cat in a laying position, who at the 1-4 time mark rolls on to his side and exposes his weapon. If timed properly, this can happen as soon as he turns over, otherwise he is stuck laying on his side and waiting for you to time the tap correctly. Meanwhile, Father Brain approaches from the right side, pipe in maw, to destroy you. If you fail to fire by the end, he will reach you and the game will be over. This made Time the only way you could fail the game, which wasn't bad at first. But then I gave the game to my roommate to test out, and he discovered a problem: players could just spam the fire button until it went into the green and they would win every time. Well that just removes the skill portion of a timing-based Micro-game completely! I devised a new trick. For every shot the player attempts to fire while the reticule is in the red, there will be an audio queue, the slashing sound effect, that will warn them that they're not doing it right. If they misfire 4 times, the gun explodes and the player loses. Now there's a penalty for spamming, the game is just a little more complex, and better in the long run.
I had some issues getting the animations working, namely trying to find a convincing "Hyper Beam." What I originally went for ended up looking like the cat (Seamus, by the way) was just hosing off the Father Brain. What I eventually did is just created a singular, large beam attack that flies form the cannon and off screen. Overall it looks good (turning the Father Brain's upper torso into a bouncing fish-bone for no reason), unless the player is successful in pulling off the first possible shot, in which case the angle seems a bit off. In the end, however, I would call it a success. (It also allowed me to free up a few more animation cells, which I used elsewhere in the project.)
There's not a real random factor to the game, but there is an increasingly difficult skill-factor, which does exactly what I wanted to have in the first place. I had to rework some mechanics and some animations, but in the end I think it all came out perfectly.
And on one last note about the music: I'm not at all a competent composer. Which sucks, because I really like music, and I've been toying with it, trying to self-learn compositions, or at least figure out what sounds "good." What I ended up doing for this was borrowing a frame out of 9-Volt's Metroid remix. I replaced the first track with cat sounds and doubled the notes, giving it a more fast-paced feeling. I also toggled a couple settings on the other layers to switch things up, and I think it came out fairly well.
Please hit me up with your friend codes so we can start trading games. If I'm only delusional and not making good games, I want to know so i can start learning how to make them better. I know for most people this thing might be a fun little gadget, but for me, I'm trying to take it like a serious project. 1 Game a week is my goal. So far I've got three total games (and all of the tutorial stuff) under my belt, and I think I'm running strong.
Also let me know what you think of this article. Is this kind of "pseudo-developer diary-ish thing" a segment I should continue updating? Let me know if there's some different info I could give to help you out, or if this is even remotely helpful at all. Leave feedback below and let's get something done, together.
As always you can follow my sparse but informative(?) posts on Twitter: @DocRandle