Sunday, February 19, 2012

Beginning World 2

The blog's been a little dead lately. For a while we were focused on just getting world 1 ready for its release onto the Android Market last week. 

That's done now, and we're on to World 2!

Production begins this week, and we have big things planned for the next world. Expect more frequent updates as we get the ball rolling.

One of the biggest complaints I've gotten on the visual side is the blandness of the environments. We remedied that a little bit in more recent builds, but they're still a little lacking. From now on I'm going to try to step it up and put as much care into the environments as I do the animation. Having a fresh start with World 2 will help a lot.

Here's what I have so far for the platform design:

World 2's platforms follow a simple mechanical motif. Lots of beveled edges, gears, etc. I'm not quite sure what I'm going to do for the actual backgrounds yet. 

Any suggestions?

Sunday, February 12, 2012

Wednesday, February 8, 2012

Boss Fights

Hey everybody! Cody here, sorry for the lack of updates. Trying to balance a game, work, and a full engineering course load is difficult at best. But worth it!

I wanted to talk about the boss fight. The first world's boss is done, and it took a lot of thinking to figure out exactly how I wanted to do it. I think I found a decent solution though, and Ill explain why it was so much harder than an enemy or something.

Good programming is all about modularity. You find ways to represent general cases, arbitrary values, etc. Why make a screwdriver when you can make a Swiss army knife? For example, the enemy class is a class that can represent any enemy we have created and (in theory) any enemy we will create. I do this by assuming very little about the enemy being created and letting many aspects such as size, behavior, and sprite sheet be defined when I create the enemy.

public Enemy(Assets assets, int type, int height, int width, int cols, int numFrames, int xPos, int yPos, int xSpeed, int ySpeed) { 
//values initialized here

So why couldn't I take this approach with bosses and make a general Boss class? Well, I definitely juggled with the idea, but the one boss that has been designed is much more complex than an enemy. Combine that with the fact that we don't even know what the other bosses will do yet and it just wasn't going to work out. However, I still need to classify all of my bosses under some distinct label that I can pass into my level. Things get really messy if I can't file all these bosses under some category. And that, my friends, is what Interfaces are for!

//Boss interface gives me a standard format for creating and storing a variety of 
//bosses for the different levels. In retrospect, I should have implemented the 
//player as an interface.
public interface Boss {
 public void draw(Canvas c);
 public void updatePhysics(double elapsed);
 public void update();
 public void killBoss();


There's an Interface, short and simple. And yes, I left the comment in which I lament over past mistakes. Hindsight is 20/20.. Anyways, think of this as a skeleton for a class. I can now create separate classes for every boss I ever want to create that implement this interface. That means they are required to define the 4 methods seen above, and I can call those methods without necessarily knowing what sort of boss I'm dealing with, but I can also write completely separate code for each boss. Cool, huh?

So since the boss is only being used once in one level under one circumstance, I more or less wrapped every detail concerning it into it's class. Most enemies are given a position as you saw above, the boss actually has his position defined inside of his own code. He goes there, everyone else deals with it. Then I just had to whip up some code drawing a huge static body, two animated arms, and animated eyelids. The arms switch animation when he charges up, and then bullets fly in every direction! Whenever we start making a new boss, we aren't bound to any of the limitations on how I developed this first guy; I can essentially rewrite everything and pass it to anything looking for a Boss object. So without further ado, here he is!

As a neat side note, absolutely no collision is defined for this dude. We instead created 2 new tiles, both transparent. One acted like a wall, other like a spike. I then pasted the entire boss onto the map, traced over him with the tiles (wall tiles for the black region, spike tiles for the white), and then deleted him off of it. Worked like a charm!

Hopefully we'll have the public build updated soon with the boss fight and the nifty screen shake and fade to black preceding it. And a new cutscene for good measure. Also, I'm working on rooting my phone so I can record some gameplay for those without Androids who want to see what the game actually looks like. Hang tight!

Monday, February 6, 2012

Winding Down on World 1

We're THIS close to finishing up world 1. Here's the pre-boss scene to tide you guys over

Commence boss fight!