Click to Play!

Wednesday, January 8, 2014

Gushing About: Banjo-Tooie


     I'm talking about the sequel to Banjo Kazooie! Mostly because I didn't play the first one until 5 years later but whatever. Banjo-Tooie blew my mind and was a favorite game of mine, rivaling Smash Bros. in my little gamer heart. This game had it all. A huge world to explore, perfect controls, tons of secrets, memorable characters, amazing multiplayer, my favorite bosses, great humor, and unforgettable music that I still have on my iPod today.

    I freaking love Banjo-Tooie, and here's why...

Tuesday, January 7, 2014

DragCore Mechanics


     You may be a bit curious as to what DragCore gameplay is like, so I'll show what I wrote in the design document. These are based the mechanics that I had in the prototype I made in 11th grade. I altered them a bit to better fit a long lasting mobile game broken into small pieces rather than the endless arcade style game I originally planned. Some are subject to change as the final product starts to evolve, but it's basically what I'm going for.

Take a look at the stuff DragCore does.


Monday, January 6, 2014

DragCore's Challenge Menu


     The challenge menu for DragCore is basically the level select screen. It's where you pick a level, check how many crystals you have, see what rewards await you, and what each level will have you face. The image above is a screenshot of the challenge menu I'm currently testing. It's very close to final, but the real version will look move lively with moving enemies on the upper half of the screen and a few changes to the buttons on the bottom half.

I'll explain what everything does after the jump.


Sunday, January 5, 2014

Code Organization (DragCore)


     My code is much more organized this time around. I find that it helps to separate scripts into things as specific as possible. I made one for each game scene (there are five total) and one for each object that moves and animates itself. My old way was to have a giant GameControl script full of commands for different menus and modes. It was controlled my a mode variable stating which scene was active. It was a mess searching through that thing and I kept finding myself putting things in menus where they didn't belong.

     Now I'm using separate scripts, one attached to each game controller object in every scene. This way, the only functions a scene can access are ones that are relative. All without messing up things in other menus and realigning a bunch of curly braces every time I slip up. I also take care to keep my Update() method clean. I used to put hundreds of lines of alignment and setup code in there, making my games sluggish. Now I only setup once by calling a refresh method in the Unity Start() method and make changes when a button is pressed.

     Messy code leads to bugs that I hate with a passion and these practices keep me away from them, just a little more. It seems obvious to me now, but when I started out I never cared what the code looked like as long as the game worked. Now I'm practicing efficiency and dynamic systems which is what code really needs to be in the long run.