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!
