ForTheLoss.org » Game Release

“Defective” Now on NewGrounds and Kongregate!

Ralph — Mon, 02 Apr 2012 14:39:04 +0000

Hey guys, a quick update on Defective. As you know, last week it was released on ShootingGamesFree.org – the sponsor’s website. After a week of exclusivity, you can now play the game on NewGrounds and Kongregate. Go check it out and don’t forget to vote, please – it helps me out a lot!

In other news…

So what have I been doing these past two weeks? Nothing terribly exciting. I have a really good grasp on programming games for Android using Eclipse/Java and Open GL ES 1.1.

As a result, I’ve been laying down the basic foundation for my first mobile game, which as of right now I intend to be a multi-directional space shooter, somewhat like Defective. The main differences being the art-style, which will heavily resemble older 8-bit games, as well as the actual gameplay, which will be much simpler and share many elements with arcade games like Galaga and Bosconian.

Right now I’m doing a lot of stress-testing and tweaking to get things to perform perfectly. The art you see in the screenshot is temporary, and I only drew it up just to get away from all the placeholder squares I had moving around. How similar the final game art will be to this art is still unknown.

Right now however, things look very promising. On a mobile device, I have 1,000 alpha’d objects flying around, rotating and everything, at a solid 50+ fps – this with no optimizations at all (aka batching). I’m really starting to love OpenGL – it makes me want to give Stage3D another chance now that I have a basic idea of how GPU-based programming works.

“Defective” is Released!

Ralph — Tue, 27 Mar 2012 17:00:15 +0000

You don’t know how bad I wanted this post to be on April 1st, just for shits n’ giggles, but hey, what are ya gonna do?

But that’s right, Defective is finally out in the wild. Go play it and tell me what you think.

A big thanks to Andy over at ShootingGamesFree.org for sponsoring the game. Defective will be exclusively hosted on his game site for the next few days before it’s available on sites like Newgrounds / Kongregate.

As most of you know, I started Defective back in May 2011 where it was a completely different-looking game for a quite a while (I even uploaded a few videos of me drawing the characters, here’s one of them). Then, after I had my spine ripped out, I completely scrapped it, started anew, and finished the project somewhere around September 2011. Here are a few of the selling points:

12 levels of shoot-em-up action… in space!
3 intense boss fights.
5 beautiful, custom-made music tracks just for this game!
Storyline with a beginning and ending cutscene.
5 different upgrade types to find, 2 in each level.
5 different enemy types, not including 4 smaller “minion” enemies and 2 “turret” enemies.
The player can transform into any of the main enemy types after destroying and absorbing 3 of their “souls.”
Particles, particles everywhere.
Achievements, who doesn’t like achievements?
Save / load functionality with 2 separate “save slots,” players can pick up from where they left off later!
Beautiful and polished graphics.

Speaking of selling points, another shout-out to Dave Fleming for scoring all of the music in Defective.

Alright, that’s it, go play the game already.

Increase Game Performance By Using Bitmaps

Ralph — Sat, 25 Jun 2011 21:31:09 +0000

Hey guys. I’m going to try a new thing with this blog of mine. Instead of just rambling on about my own game development news and whatnot, I figure I’ll also throw in a tutorial post every now and then. Sound good? Good.

First, a little background. This concept of using bitmaps instead of the standard MovieClips that everyone is used to came to way back when I first began development on Don’t Panic. I had run into a strange problem that I hadn’t encountered before in either Weapons on Wheels, Oil Spill Escape, or Christmas Defense. The problem had to do with the game lagging up very badly when there were more than about 4 or 5 enemies on the screen.

After some help from the FlashGameLicense.com forums, I realized the problem was the enemy MovieClips – the vector graphics for the enemies were just too detailed and thus the game was having a hard time rendering them every frame. (Vector graphics are essentially just a bunch of math equations that the CPU has to process in order to draw the image on the screen – you could imagine how a bunch of detailed vector graphics could take a toll on your processor.)

Anyway, this is how I came across this method of handling my game art assets. Ever since I’ve learned about it, I’ve used it for Don’t Panic, the late Hero Dude, and my current WIP – Defective. This method isn’t exactly blitting (which is slightly more advanced and is another tutorial all together), but sort of a middle-ground between it and the traditional usage of MovieClips. So, let’s get started, shall we?

The Classes

Alright, now, from here on out, I’m going to be showing you how I utilize this method. Take from it what you will and use it however you want/need.

To begin, I create two classes:

BMPLoader.as – This class is what “loads” the BitmapData information from your MovieClips and stores it in memory. (It essentially takes a MovieClip and outputs a Bitmap of it.)
BMPObject.as – This is what you will extend your game objects as. For example:

package
{

public class Player extends BMPObject
{
}

}

So far, so good. Now let’s get into what each class does. Let’s begin with BMPLoader.

BMPLoader.as

Alright, this is the class where all of the magic happens, it’s not very difficult once you just look at what’s going on. (I’m just going to throw a disclaimer here that from this point on there may very well be optimizations and better ways to do what I’m trying to accomplish. Feel free to experiment and change things to your needs or even comment on this post telling me what to change.)

Here’s the entire class, commented completely to help you understand it better.

package
{
// Imports for this class.
// Nothing more to say really ;).
import flash.display.BitmapData;
import flash.display.DisplayObject;
import flash.display.MovieClip;
import flash.geom.Rectangle;

public class BMPLoader
{
// This is an important part of this class.
// Here is where I declare a Vector of type
// BitmapData for EACH MovieClip that I will
// be transforming into a Bitmap. So I'd have
// one for Bullet, Coin, Enemy, etc. Here I
// have one for the Player graphic, just for
// this example. Also important - note how the
// Vector is PUBLIC and not private.
public var vecPlayer:Vector.<BitmapData>;
// This class also needs a DisplayObject which
// will act as the reference to the coordinate
// space to use. This may sound confusing, just
// use a reference to the Level, World, Stage -
// whatever the "global parent" is.
private var levelRef:DisplayObject;

// The constructor doesn't do anything other than
// assign the "global parent" variable a value. This
// is important to do!
public function BMPLoader(_levelRef:DisplayObject)
{
levelRef = _levelRef;
}

// This destroy() function is more of a personal thing
// I add to each of my classes in order to clean up and
// help for garbage disposal and the freeing of memory.
// Think of it as the opposite of the constructor - the
// destructor, it cleans up the objects and prepares it
// for deletion. Here all I do is null all of the Vectors
// I've created as well as my "global parent" reference.
public function destroy():void
{
vecPlayer = null;
levelRef = null;
}

// The load() function - here's where all of the magic happens.
// This functions takes two parameters, a MovieClip (to transform
// into BitmapData) and a String (which is the name of the Vector
// in which we will store this BitmapData).
public function load(mc:MovieClip, vecString:String):void
{
// First check if the Vector is already populated, if so, skip
// and don't bother. If the Vector is already populated, this means
// that this MovieClip has already been loaded into memory before. Cool!
// ---------------------------------------------------------------------
if (this[vecString] != null) return;

// Alright, so the Vector isn't already populated. Okay, so take the
// Vector and initialize it. Then, fill the Vector with the return
// value of a new function, convertMCToBitmapData().
// -------------------------------------------------
this[vecString] = new Vector.<BitmapData>;
this[vecString] = convertMCToBitmapData(mc);
}

// Alright. This is the function that manipulates the MovieClip into BitmapData.
// It first takes the MovieClip and iterates through all of it's frames. While it
// does this, the function takes notw of the maximum width and height of the
// MovieClip. This maximum width and height is then used in the second part of
// the function where BitmapData object is initialized (it requires a width/height
// parameter). After this, the built-in draw() function is used to convert each
// frame of the MovieClip into BitmapData. Finally, this BitmapData is pushed into
// a Vector which is eventually returned as the result of this function.
private function convertMCToBitmapData(mc:MovieClip):Vector.<BitmapData>
{
// Initialize variables we'll need for this function.
// Not much to go into here, as we'll see these all later.
// -------------------------------------------------------
var curFrame:int = 1;
var maxWidth:int = 1;
var maxHeight:int = 1;
var boundsWidth:int = 1;
var boundsHeight:int = 1;
var bmpData:BitmapData;
var vec:Vector.<BitmapData>;
vec = new Vector.<BitmapData>();

// Alright, first part of this function. Time to get the
// maximum width and height of the MovieClip. Using a while
// loop, we will iterate through each frame of the MovieClip,
// noting the maximum width/height we come across. (This is
// where that "global parent" reference is used, since the
// getBounds() function requires it.
// ---------------------------------
while (curFrame <= mc.totalFrames)
{
mc.gotoAndStop(curFrame);
boundsWidth = mc.getBounds(levelRef).width;
boundsHeight = mc.getBounds(levelRef).height;
if (boundsWidth > maxWidth) maxWidth = boundsWidth;
if (boundsHeight > maxHeight) maxHeight = boundsHeight;
curFrame++;
}

// Now that we have the maximum width/height stored appropriately
// inside of maxWidth and maxHeight, it's time to move onto the next
// part. Here we are once again using a while loop to iterate through
// each frame in order to translate each frame of the MovieClip into
// BitmapData using the draw() function.
// -------------------------------------
curFrame = 1;
while (curFrame <= mc.totalFrames)
{
mc.gotoAndStop(curFrame);
bmpData = new BitmapData(maxWidth, maxHeight, true, 0x00000000);
bmpData.draw(mc);
vec.push(bmpData);
curFrame++;
}

// Finally, return the Vector of BitmapData.
// -----------------------------------------
return vec;
}

}

}

Now let’s move on to the next class, BMPObject.

BMPObject.as

This class will be extended from all of your game objects that will be utilizing Bitmaps instead of traditional MovieClips. So, for example, the Player class, Bullet class, etc. The real purpose of this class is to make it easy for you to assign a Vector of BitmapData from the BMPLoader class (above) to a particular object as well as make it easy for you to iterate through said Vector to animate the Bitmap – just as if it were a MovieClip. Here’s the entire class – again fully commented.

package
{
// Imports for this class.
// Nothing more to say really ;).
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.MovieClip;
import flash.display.Sprite;

public class BMPObject extends Sprite
{
// Here are the properties of this class. Note how
// they're all PROTECTED - this is important. The Vector
// "vecMyBitmap" will reference a Vector in the BMPLoader
// class and will hold the BitmapData of this object. The
// "bmp" variable will be the Bitmap - the actual "face" of
// this object. Finally, the last variable, "bmpFrame," simply
// stores the current position in the vector (used for animation).
protected var vecMyBitmap:Vector.<BitmapData>;
protected var bmp:Bitmap;
protected var bmpFrame:int = 0;

// The constructor does nothing.
// Very simple, no?
public function BMPObject()
{
}

// Again, the destroy() function, just a personal
// preference of mine to help with garbage disposal
// and the freeing of memory. Here I just remove the
// Bitmap and null the Vector and Bitmap.
public function destroy():void
{
vecMyBitmap = null;
if (bmp)
{
removeChild(bmp);
bmp = null;
}
}

// The setupBitmap() function is called to, well, setup
// the Bitmap for this object. It takes the first value in
// the Vector of BitmapData and creates a Bitmap out of it.
// The Bitmap is then added as a child to this object and then
// moved so it is centered properly.
protected function setupBitmap():void
{
bmp = new Bitmap(vecMyBitmap[bmpFrame]);
addChild(bmp);
bmp.x = -bmp.width * 0.5;
bmp.y = -bmp.height * 0.5;
}

// The animateBitmap() function, well... take a guess what
// it does. It animates the Bitmap by iterating through the
// "frames" of the Vector (and loops to the beginning when it
// reaches the end.
protected function animateBitmap():void
{
// Move position along in the vector.
// ----------------------------------
if (bmpFrame < vecMyBitmap.length-1) bmpFrame++;
else bmpFrame = 0;
// Change bitmapData of bitmap.
// -----------------------------
bmp.bitmapData = vecMyBitmap[bmpFrame];
}

}

}

Still with me here? Good, because we’re pretty much done at this point, now we just get to use the two classes we’ve created!

How to use these classes

Alright, now we get to the good part. How do you use these classes? It’s simple, really.

First, you obviously need to initialize the BMPLoader class. I typically do this in the parent of all of my game objects, typically the Level object or something.

bmpLoader = new BMPLoader(this);

Then just place this code in the constructor (or init() or whatever) function of your game object (your Player, Bullet, Coin, etc):

bmpLoader.load(new PlayerSkin(), "vecPlayer"); // Obviously change these to your needs.
vecMyBitmap = bmpLoader.vecPlayer;
setupBitmap();

As the comment says in the code, obviously change new PlayerSkin() to the MovieClip you wish to turn into BitmapData and vecPlayer to the name of the Vector inside of BMPLoader in which to store said BitmapData.

Then, in your game object’s loop function, you can simply call the animateBitmap() function and the BMPObject class will animate your object just as if it were a MovieClip. Neat, huh?

Conclusion

Now, there are three major things you must remember by utilizing this method:

In order to be able to convert a MovieClip into BitmapData – the MovieClip’s registration point must be set to (0,0). To avoid clipping, your MovieClip art must at no point in any of it’s frames extend less than the x = 0 or y = 0 point. If it does, the BMPLoader class will produce a Bitmap of your MovieClip which is clipped (and not very pretty-looking).
Be aware to not attempt to populate a Vector in the BMPLoader that doesn’t exist or you’ll obviously get an error. For example, doing bmpLoader.load(new PlayerSkin(), “vecPlayer”); and not having a vecPlayer object in BMPLoader will cause you some problems.
Since your game will no longer be using crisp-looking vector-based graphics, you may encounter times in your game where your art doesn’t look as good as it does in the Flash IDE when you were drawing it. This is normal, since you’re now using Bitmaps. Your art will look perfectly fine as long as you don’t zoom in or rotate it during gameplay. I’m not saying you can’t do those things, but if you do the art will become slightly jagged-looking. Not necessarily ugly (unless you zoom in 100x’s or something), but it’ll be noticeable.

Alright, I think I’m done here. I hope if you found this article by Googling a problem you’ve been having that it’s helped you out. If not, tough noogies. Well, either that or leave a comment and I’ll see if I can help .

I’ve been writing this post for two hours now. That’s insane (for me). Excuse me while I go rest my back and watch some TV before dinner.

PS – Today’s the 1 month anniversary of my back surgery. Pretty cool, huh?

PPS – First Weekly Game Update in a long time scheduled for tomorrow. Pretty cool, huh?

PPPS – Pretty cool, huh?

Don’t Panic Released!

Ralph — Fri, 06 May 2011 18:49:03 +0000

No, really. I’m not lying this time. I know over 90% of you are probably sick of hearing me talk about it for the past 3-4 months, so just go play it already.

Play Don’t Panic on ArmorGames

Big thanks to Dan and ArmorGames in general for sponsoring my game, I’m very honored to have such a big site be interrested in one of my games.

Feeling generous? Don’t forget to vote it up!

I’d post more, but I’m in the middle of doing other nonsense. WHAT IRONY.

Christmas Defense Released!

Ralph — Thu, 09 Dec 2010 20:19:14 +0000

Hey guys. I just wanted to make a quick update that Christmas Defense was released today.

Play it on NewGrounds.com.

Play it on Kongregate.com.

Don’t forget to rate it! I appreciate it.

I want to give a big thanks to the site Coolbuddy.com for sponsoring the game. Without any sponsors, odds are I wouldn’t have the time to make games like this.

I’ll update this post when the game is released on Kongregate and ArmorGames as well.

Go play it and tell me what you think!

“Oil Spill Escape” Released – Go Play it Now!

Ralph — Sat, 24 Jul 2010 15:22:46 +0000

“Oil Spill Escape” (aka my Secret Project for the past four weeks) has been released this morning! I’m really excited about this game because it truly is a very fun and addicting game.

Play it exclusively on Juggernart.com – Play Oil Spill Escape.

I actually completed the game in about 12 days, which is quite speedy for only my second game ever. The remaining 14+ days was spent just letting the game chill on FlashGameLicense.com waiting for a sponsor.

Bla bla bla, I’m sure you all care about that stuff, right?

Anyway, maybe I should tell you what the game is about. (As if you can’t tell from the title.)

The idea for this game was actually a result of some accidental collaboration between this person I know friend Paul D’Amora. You might know him as since he’s one of the three commenters on this site.

The game is obviously inspired from the ongoing oil spill in the Gulf of Mexico. The gameplay itself is very similar to that of the classic “Helicopter Game“. As in, you control a fish trying to escape a cloud of oil by dodging rocks and eating fish. Sound easy? Well, it’s not.

The objective is to simply get as far as you possibly can and then to compare your score with the scores on the scoreboard. This is where it gets addicting, trust me.

Anyway, I do believe that’s enough rambling from me. Go play the game and tell me how you like it!

Weapons on Wheels Done and Released and Stuff

Ralph — Fri, 18 Jun 2010 22:42:35 +0000

So that was one hell of a journey. Granted, with Weapons on Wheels being the first real game I’ve ever developed, I probably did alot of things the long and hard (twss) way.

Play it on MaxGames.com, who is the awesome sponsor.

Update: Also play it on NewGrounds and vote 5 to be awesome.

Update 2: Play it on Kongregate and 5-star it to be even awesomer.

So that’s it. Go try it out and tell me how disappointed you are in the comments!

In all seriousness, though, I learned alot when developing that game. Both in terms of code-stuff and in terms of what makes a game fun. I’ll be using all that knowledge as I develop Hero Dude, which will hopefully only take me a fraction of the time it took me to make Weapons on Wheels.

Protip – don’t go directly behind the blue car.