In this tutorial, you will learn:

• Basic for loop usage
• Basic array usage
• How to find the distance between two points
• How to use Math.atan2() to have MovieClips follow each other
• How to fire projectiles
• How to split a velocity vector into two perpendicular lines using sine and cosine
• How to create objects from custom classes

Introduction

When learning Actionscript, or any programming language for that matter, I find it best to create specific engines that employ a variety of techniques and functions. This way, you are not only learning how to use these features, but you are also experiencing a pragmatic use for them. In this tutorial we will be creating a class for an ally AI that will locate the enemy nearest it, chase it, and shoot it. This is used in just about any game where there are characters not controlled by the player. Take, for example, a tower defense game. The towers created do not simply attack any enemy they want. They usually attack the closest. However, there are some games where you can choose to have them attack the quickest enemy, or the one with the most health, or whatever it may be. But for now let’s concentrate on distance.

Now, what if there are three allies (let’s call them followers for now) and two enemies, one of which is really far away? The tutorial you are about to read is designed so that rather than all three followers clustering up on the closest enemy, two will attack it and the third will set off for the far one. Furthermore, what happens when a third enemy is spawned when all this is going on? Well, rather than the follower by itself (which may be closer) going out to attack it, one of the two that are attacking the same enemy will leave and target the newfound enemy. This optimizes the strategy of the followers so no enemy is left alone while there is a surplus of followers elsewhere.

Rather than just talking about what we’re going to do, let’s actually do it. Sometimes I prefer to just see the source code and play around with it rather than just following a tutorial. If you want, you may download a heavily-commented copy of all the code down below. Without further ado, let’s begin the tutorial.

Download Source

Step 1: Setting Up the MovieClips

There are three MovieClips essential to this tutorial. First, we need the followers and the enemies. We also need some sort of projectile or bullet for the followers to shoot. For the sake of example, I am programming this tutorial in a way that the user can create followers and enemies by clicking buttons at the bottom of the stage. So now we’re up to five MovieClips. Name them Bee, EnemyBee, Ball, BeeButton, and EnemyButton. Below are my five MovieClips in their respective order:

When saving each as a symbol, be sure to check the “Export for Actionscript” box and keep the class name the same.

Step 2: The Arrays

Now that we have our MovieClips, we need a place to store them. Open up the Main Timeline’s Actions Panel (F9) and input the following code:

var beeArray=[];
 
var eArray=[];
 
var ballArray=[];

What’s happening here is we are creating three arrays to store our objects: one for all the bees (followers), one for all the enemies, and one for all the balls being shot. These arrays are going to be accessed a ton of times throughout the tutorial, so if you need to brush up on any of the arrays basics be sure to check out this tutorial

Step 3: The Enemies

The enemies are much easier to program, so we’ll start with them first. Create a new custom class called EnemyBee (or whatever necessary to match the name of your enemy MovieClip) and start off with the following code:

package {
 
import flash.display.MovieClip;
 
import flash.events.*;
 
public class EnemyBee extends MovieClip {
 
private var r:Object;
 
private var angle:Number;
 
private var rot:Number;
 
private var health:int=1;
 
private var speedX:Number;
 
private var speedY:Number;
 
private var dist:Number;
 
private var reload:int=50; //reload timer for shooting (don't worry about this for now)
 
public var isTarget:int;
 
public function EnemyBee() {
 
addEventListener(Event.ADDED_TO_STAGE, beginClass);
 
}
 
private function beginClass(event:Event):void {
 
r=MovieClip(root);
 
addEventListener(Event.ENTER_FRAME, eFrame);
 
r.eArray.push(this);
 
this.x=stage.stageWidth+this.width;
 
this.y=Math.random()*400+20;
 
var h:Number=Math.random()*stage.stageHeight;
 
angle=Math.atan2(h-this.y,-this.x);
 
this.speedX=Math.cos(angle)*2;
 
this.speedY=Math.sin(angle)*2;
 
this.rotation=angle/(Math.PI/180);
 
rot=Math.random()*4;
 
}
 
private function eFrame(event:Event):void {
 
}
 
}
 
}

Now this is a lot of code all at once so let’s go through it line by line. Lines 6-13 declare variables which are more or less self-explanatory. The main one to note here is the public variable isTarget. This variable isn’t accessed at all by EnemyBee, but from the followers. It is used to tell how many bees are following the EnemyBee. But let’s move on for now.

In the beginClass function, line 20 places EnemyBee inside eArray (on the Main Timeline) through the use of r (the root of the MovieClip). Below, the initial x and y coordinates are set to be just off the right side of the stage anywhere from the top to the bottom. Variable h is the destination of EnemyBee and, using Math.random(), is different every time. The next line uses a function called Math.atan2(). Most of you trigonometry aficionados know that the atan2 function, being a variant of the arctangent function, returns the angle (in radians) between the positive x axis of a plane and the point constructed by the given coordinates. For now, all you need to know are the parameters. They are as follows:

Math.atan2(destinationY-this.y , destinationX-this.x);

It seems strange, but just remember the y comes first. By using the atan2 function we now know the angle between the point EnemyBee is going for (in this case h) and itself. But how do we make it so that our object moves towards it? That’s where the sine and cosine lines come in. By taking the cosine of the angle we can find the horizontal speed the object must take. Similarly, we can use sine to find the vertical speed. You can replace the 2 at the end of each line with a larger or smaller number to increase or decrease the speed (respectively). Finally, we rotate the object to face its target once again using angle, and then assign rot (the rotational speed) a random number from 0-3.99999 (this is used later on).

Now we can edit the eFrame function. So within the brackets, place this code:

this.x+=this.speedX;
 
if (this.health>0) {
 
this.y+=this.speedY;
 
if (this.x+this.width/2<0) {
 
r.eArray.splice(r.eArray.indexOf(this),1);
 
removeMe();
 
}
 
} else {
 
if (r.eArray.indexOf(this)>=0) {
 
r.eArray.splice(r.eArray.indexOf(this),1);
 
}
 
this.rotation+=5+rot;
 
this.y+=3+(3-rot/2);
 
if (this.y-this.width>;stage.stageHeight) {
 
removeMe();
 
}
 
}

First, the object moves horizontally. Next, if its health is greater than zero (meaning it is not dead) it will also move vertically and if it manages to survive the followers and go offstage to the left, remove itself from eArray, and then call the removeMe() function which we will declare in a little bit. In case EnemyBee IS defeated, however, it will first check to see if its index in eArray is at least 0. A useful fact about arrays is that “if” an object isn’t in the array at all, its index is -1. Through this “if statement” we are effectively checking to see if EnemyBee is in eArray so we don’t accidentally remove it twice (that would result in an error). The next few lines are pretty much self-explanatory.

The last piece of code for EnemyBee is the removeMe() function. Here it is:

private function removeMe():void {
 
removeEventListener(Event.ENTER_FRAME, eFrame);
 
r.removeChild(this);
 
}

This last part is easy. First the event listener is removed, and then the object itself is deleted. That’s all we need for EnemyBee. Now we can start the hard stuff! (:

Step 4: The Followers

Now it’s time to get to the heart of the tutorial: creating the followers. Create a new custom class for your followers (in this case it’s called Bee), and input this code:

package {
 	import flash.display.MovieClip;
 	import flash.events.*;
 
 	public class Bee extends MovieClip {
  	private var r:Object;
  	private var c;
  	private var max:Number=Number.MAX_VALUE;
  	private var speedX:Number;
  	private var speedY:Number;
  	private var speed:Number=2;
  	private var angle:Number;
  	private var reload:int=50;
  	public function Bee() {
   	addEventListener(Event.ADDED_TO_STAGE, beginClass);
  	}
  	private function beginClass(event:Event):void {
   	r=MovieClip(root);
   	addEventListener(Event.ENTER_FRAME, eFrame);
   	r.beeArray.push(this);
   	x=275;
   	y=245;
  	}
  	private function eFrame(event:Event):void {
  	}
 	}
}
}

You’ve seen all this code already in EnemyBee so I’m not going to explain it all again. The only exceptions are c (which will be explained in a bit) and Number.MAX_VALUE, which can simply be thought of as infinity.

There’s a lot of code in the eFrame event, so let’s do it all in pieces. First, we need this:

if (r.eArray.length!=0) {
 
//paste all the following code here
 
}

This line of code tells us if there are any enemies on stage or not. Without it, we would get errors. Within the brackets, place this first bunch of code:

if (r.eArray.indexOf(c)<0) { //if c is NOT in eArray...
 
for (var i:int=0; i<;r.eArray.length; i++) { //for every object in eArray...
 
var obj=r.eArray[i]; //assign address of object to obj
 
var distX:Number=this.x-obj.x; //horizontal distance between self and obj (the enemy)
 
var distY:Number=this.y-obj.y; //vertical distance between self and obj (the enemy)
 
var dist:Number=(distX*distX+distY*distY); //overall distance using distance formula
 
if (dist<max&&obj.isTarget==0) { //if distance < max and obj has no followers...
 
max=dist; //assign distance to max (the new shorst distance)
 
c=obj; //assign address of object currently being tested in c
 
}
 
}
 
if (r.eArray.indexOf(c)>=0) { //if c is in eArray...
 
c.isTarget++; //tell c (EnemyBee) that one more bee is following it
 
} else { //if c is NOT in eArray...
 
max=Number.MAX_VALUE; //reset max to maximum value
 
for (var j:int=0; j<r.eArray.length; j++) { //for every object in eArray...
 
obj=r.eArray[j]; //assign address of object to obj
 
distX=this.x-obj.x; //horizontal distance between self and obj (the enemy)
 
distY=this.y-obj.y; //vertical distance between self and obj (the enemy)
 
dist=(distX*distX+distY*distY); //overall distance using distance formuala
 
if (dist<max) { //if distance is closer than max...
 
max=dist; //assign distance to max (the new shortest distance)
 
c=obj; //assign address of object currently being tested in c
 
}
 
}
 
c.isTarget++; //tell c (EnemyBee) that one more bee is following it
 
}
 
}

It can get a little confusing at this point, so I included plenty of comments. The variable c is used to hold the address of the closest enemy (hence it’s name). First we check to see if it is not in the array (meaning the closest enemy has not been determined). We use a for loop to iterate through all the enemies in eArray. If you’re new to loops, you can read up on them here.

Next we instantiate four variables: a placeholder for the object being tested, the horizontal distance, the vertical distance, and the total distance. Just in case you are wondering, the distance formula is as follows:

Now that we know the distance of the object being checked, we must see if it is closer than the previous. Recall that max was equal to Number.MAX_VALUE, so it is greater than anything we could compare it to. So the first instance to be checked will definitely be closer, and the if statement will be true. Therefore, max is set to the distance between itself and the enemy being tested (the new shortest distance), and obj is stored in c. All that happened for the first enemy in eArray. Now go through it again for the second enemy. The second enemy is stored in obj, just like the first, and the distance is established. However, instead of max being equal to the highest value, it is equal to the distance of the previous enemy. If the distance between the bee and the enemy being tested is shorter than that of the first enemy, max is lowered again to match the distance and the enemy is stored in c. If not, the loop skips over this and goes on to test the next enemy. This process continues for every enemy in the array. Logically, the value of max by the time all of the enemies are done being tested will be equal to the shortest distance, and c will hold the address for the corresponding enemy.

Note that with the if statement, Bee only looks for enemies that have isTarget==0. In plain English, that means it only takes enemies that are not being followed into consideration. This way we don’t have that surplus of followers in one section and a non-followed enemy elsewhere like we previously discussed. However, there is the case that every enemy is already being followed. The if statement right after the for loop checks to see if a closest enemy (with no followers) has been found. If so, it increases the value of isTarget on the enemy (amount of followers). If not, another for loop extremely similar to the previous is carried out. The only difference is the if statement:

if (dist<max) {

Instead of checking to be sure the enemy being tested has no followers, it just looks for the closest. I found this to be the best design, but you might have another use for it. This code is very easy to customize. Say you wanted locate the enemy with the least amount of followers. You could simply substitute the if statement for this:

if (obj.isTarget<max) {
 
max=obj.isTarget;
 
c=obj;
 
}

All right we’re getting closer to finishing this up. One more loop:

max=Number.MAX_VALUE; //reset max to maximum value
 
if (r.eArray.length>=r.beeArray.length&&c.isTarget>1) { //if c has other followers...
 
c.isTarget--; //tell c it has one fewer follower
 
for (var l:int=0; l<r.eArray.length; l++) { //for every object in eArray...
 
obj=r.eArray[l]; //assign address of object to obj
 
distX=this.x-obj.x; //horizontal distance between self and obj (the enemy)
 
distY=this.y-obj.y; //vertical distance between self and obj (the enemy)
 
dist=(distX*distX+distY*distY); //overall distance using distance formula
 
if (dist<max&&obj.isTarget==0) { //if distance < max and obj has no followers...
 
max=dist; //assign distance to max (the new shortest distance)
 
c=obj; //assign address of object currently being tested in c
 
}
 
}
 
c.isTarget++; //tell c (EnemyBee) that one more bee is following it
 
max=Number.MAX_VALUE; //reset max to maximum value
 
}

Okay so after doing two loops almost exactly like this one, no explanation should be necessary. However, a brief discourse on the logic behind it should help. The only thing different here than the first loop is that it is only executed when there are more enemies than followers and the enemy the bee is following has at least one other follower. You may be asking yourself why I chose to create three loops that are almost identical instead of simply making a function called several times with slightly different arguments. Well, I think it’s easier to retain the information if you see it several times. Plus, a tutorial is never complete unless something is left up to you to figure out yourself.

All right, now that the difficult part is out of the way, we can move on to actually moving the bee. The code below immediately follows the if statement above:

angle=Math.atan2(c.y-this.y,c.x-this.x); //angle between self and closest enemy
 
speedX=Math.cos(angle)*speed; //find horizontal speed according to angle
 
speedY=Math.sin(angle)*speed; //find vertical speed according to angle
 
rotation=angle/(Math.PI/180); //rotate to face enemy
 
distX=this.x-c.x; //horizontal distance between self and closest enemy
 
distY=this.y-c.y; //vertical distance between self and closest enemy
 
dist=(distX*distX+distY*distY); //overall distance using distance formula
 
if (dist<=100) { //if distance is less than or equal to 100...
 
speed=-.1; //slow down
 
if (speed<0) { //if speed is less than 0...
 
speed=0; //keep speed at 0
 
}
 
} else { //if distance is greater than 100...
 
speed+=.1; //speed up
 
if (speed>2) { //if speed is greater than 2...
 
speed=2; //keep speed at 2
 
}
 
}
 
this.x+=speedX; //move horizontally
 
this.y+=speedY; //move vertically

This is very similar to the motion employed in the EnemyBee class and shouldn’t be too difficult at all. The if and else statements are purely for aesthetic purposes so that the bee doesn’t sit directly on the enemy.

That concludes the code for the followers. Now all we need is a means to create the followers and enemies. I’m sure you will come up with plenty of ways that pertain to your game, but for the sake of convenience I just created two buttons that allow the user to spawn them. If you’d like to see the Actionscript for this, download the source code files from above.

Step 5: Shooting

Run your .swf. If you did it right, you should get something like this:

The bees follow the enemies just like we programmed them to, but they do not attack. Remember that Ball Movieclip we make at the beginning of the tutorial? Well we’re finally going to use it. Open up the custom class for Ball and type this in:

package {
 
import flash.display.MovieClip;
 
import flash.events.*;
 
public class Ball extends MovieClip {
 
private var r:Object;
 
private var c:int=15;
 
private var id2:int;
 
private var angle:Number;
 
private var speedX:Number;
 
private var speedY:Number;
 
private var speed:Number=8;
 
private var mc:Object;
 
public function Ball(id:uint) {
 
addEventListener(Event.ADDED_TO_STAGE, beginClass);
 
id2=id;
 
}
 
private function beginClass(event:Event):void {
 
r=MovieClip(root);
 
addEventListener(Event.ENTER_FRAME, eFrame);
 
mc=r.beeArray[id2]; //find which object created it
 
angle=mc.rotation*(Math.PI/180);
 
this.x=mc.x; //set x coordinate to that of bee's
 
this.y=mc.y; //set y coordinate to that of bee's
 
speedX=Math.cos(angle)*speed;
 
speedY=Math.sin(angle)*speed;
 
r.setChildIndex(this,r.getChildIndex(mc));
 
}
 
private function eFrame(event:Event):void {
 
this.x+=speedX;
 
this.y+=speedY;
 
if (c>0) {
 
c--;
 
} else {
 
this.alpha-=.1;
 
}
 
if (this.alpha<=0) {
 
removeBall();
 
}
 
}
 
public function removeBall():void {
 
removeEventListener(Event.ENTER_FRAME, eFrame);
 
r.ballArray.splice(r.ballArray.indexOf(this),1);
 
r.removeChild(this);
 
}
 
}
 
}

Basically we’re just creating an object that follows a straight line path using the rotation of the bee it’s coming from. The address of the bee is determined by the parameter id2, which we will explain it a bit. Now we have to program Bee to actually shoot the balls. In the eFrame event of Bee, right after the speedX and speedY are used, place the following code:

reload--; //lower reload timer
 
if (reload==0) { //if reload is complete...
 
reload=50; //reset reload timer to 50
 
var newBall:Ball=new Ball(r.beeArray.indexOf(this)); //create new ball
 
r.addChild(newBall); //add ball to stage
 
r.ballArray.push(newBall); //put ball in ballArray
 
}

This creates a new instance of the Ball class and places it in the corresponding array on the Main Timeline. As you can see, the argument incorporated while instantiating the new ball is the index of the bee in its array. This is then later accessed by the ball in its class to find where it should be placed on the stage and the angle it should follow:

mc=r.beeArray[id2]; //find which object created it
 
angle=mc.rotation*(Math.PI/180);
 
this.x=mc.x; //set x coordinate to that of bee's
 
this.y=mc.y; //set y coordinate to that of bee's
 
speedX=Math.cos(angle)*speed;
 
speedY=Math.sin(angle)*speed;
 
r.setChildIndex(this,r.getChildIndex(mc));

The address of the bee is found using id2 (which is equal to the argument we just mentioned) and stored in mc, which is used to set all that good stuff above. The setChildIndex() statement is used so that the ball appears below the bee, giving the illusion that it’s being shot by the bee, and not appearing right on top of it.

Okay so run your .swf again and you should see this:

Pretty good, huh? Now we just have more step: the collisions.

Step 6: The Collisions

This part is easy. Simply open up the class file for EnemyBee and, in the first line of the eFrame event, put in the following code:

for (var i:int=0; i<r.ballArray.length; i++) {
 
var mc:Object=r.ballArray[i];
 
dist=Math.abs(mc.x-this.x)+Math.abs(mc.y-this.y);
 
if (dist<;this.width/2+mc.width/2) { //if they touch...
 
health--;
 
mc.removeBall();
 
}
 
}

It’s just a for loop that iterates over every instance in the ball array and tests for a collision. You can use whatever collision-detection technique you want, but for this example the best choice is a simple circle-to-circle test. Upon each collision, the health of the bee is lowered, and the ball is removed through the function removeBall().

Well, that’s about it. Test your .swf and it should work just as my example up above did. This technique is very useful and I’m sure you’ll find plenty of ways to use it in your games. If you make something cool, I’d love to see it (: Thanks for reading!

© dannybuoncore for MochiLand, 2011. | Permalink | 2 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Developer Spotlight, Flash Development, Front Page, Game Design, MochiLand Topics.

© JonathanChung for MochiLand, 2011. | Permalink | No comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Flash Development, Game Design, MochiLand Topics, Tutorials.

This week’s Flash Game Friday winner is Prizma Puzzle Challenge by Silen Games!

Silen Games strikes again with another fantastic installment in the Prizma Puzzle series.

It has been a while since we have had a puzzle as our Flash Game Friday winner, and this game definitely fits the bill as a high-quality puzzler. There are zones. Within each zone are stages. The goal in each stage is to get to the “finish” via a route that nets you the most stars and breaks all the crystals. As you can imagine, the stages get more complicated and challenging as you advance from one level to the next, and from one stage to the next. Silen Games also added achievements to game, giving it an extra layer of interest.

Prizma Puzzle Challenges is a great puzzle game with really nice polish, game mechanics, and achievements that make a great game even better. Congratulations Silen Games!

Get To Know Silen Games

Tell me about yourself-how many people are on your team? Where are you based?

My name is Vitaliy Sidorov of Silen Games, and I’m an indie developer. Most of my games were created by me alone, but there are exceptions. Granny Strikes Back is such an exception. This particular game was a collaboration with my friend Ivan Morozov. We are both from Russia, living in remote and cold of Siberia. :)

How long have you been making games? What did you do before?

I am actually a lawyer. At first the creation of games was a hobby, but now it’s my main job. I created my first game 4 years ago, called “Safe Breaker”, which I created using the GameMaker engine. I learned Flash a year later and still use it to create games.

Q: What was your inspiration for “Prizma Puzzle Challenge”? How is this one different from your other “Prizma” puzzlers?

Prizma Puzzle was my very first game created with Flash 2.5 years ago. Prizma Puzzle Challenge is the fourth part of the series. When you compare it to the 3rd installment it’s pretty similar. I added a few new elements, such as Crystals and Crystal Breakers, which serve as doors and keys. I also added a new game mode, Challenges, which consists of light and fun levels that accent only one game element. The game became more simple but not less interesting.

What types of games do you like to create the most? What types of games do you like to play the most?

I love to create a shooters that have a lot of explosions, action, drive, and coins:)
I like to experiment with exploration & adventure games. My favorite game from childhood is “Land Stalker” for Sega Genesis. I also love the Castlevania series of games, and Metroid.

How long is your game creation cycle? What is your process?

I try to finish the game in a month, before it begins to get boring. Any development begins with the selection of the concept and prototype of the basic mechanics of the game. If the gameplay is interesting – I continue to develop. Next, I create a level editor, and then the schedule. The last thing I do is add levels and sounds, as well as tune the balance of the game.

Are there any game developers that you admire or consider “rock stars”?

I have great respect for the game designer Jason Kapalka of PopKapa. He creates a brilliant casual games. But I do not always follow his advice. For example, “Granny and Snowmen” is a fairly hardcore game and therefore isn’t as popular among the casual audience. But I think it would be great as a console game.

What is it about making a new game that you enjoy most?

I do not like to continue and create sequels. Much more interesting to create something truly new. For example the development of my last game “The Bee Way” was a lot of fun.

Do you have any hot projects you’re working on right now?

Now I am finishing work on the game Mushroom Madness 3. Part two was popular and I am sure that part three will be even better!

Thanks for answering my questions Vitaliy, and good luck with Mushroom Madness 3!

© Colin Cupp for MochiLand, 2011. | Permalink | One comment

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Flash Game Friday, Game Design, Game Showcase, MochiLand Topics, Publisher Feed.

This week’s Flash Game Friday winner is Bad Eggs Online by Rob Donkin!

You are an egg. You have weapons. Your job is to take out your enemies, which depending on the type of battle you are in could be the other team or literally every egg on the screen!

Bad Eggs Online is an awesome turn-based multiplayer shooting game that is really innovative because of the integration of some great features such as: in-game chat, achievements, level-ups, skills, custom shells, and even a terrain editor…whew, talk about a big game!

As you progress through the game, you are awarded new weapons and shell design options (so you can tell who has “rank” when you play them). You also acquire achievements, one-time use skills, and there is a store where you can buy things you haven’t yet earned. There are various combat scenarios for you to choose from, such as 3v3, 2v2, 1v1, or 1v1v1v1v1. As if that weren’t enough, the in-game chat that carries over from waiting room to the game and back again is a really nice addition. This allows for teams to talk about strategy and even use disinformation tactics!

In Bad Eggs Online, the Donkin brothers did an incredible job at making a deep and social game. The gameplay is smooth, polish is high, and the experience is great. Congratulations Donkins!

Get To Know Rob Donkin

Tell me about yourself- how many people are on your team? Where are you based?

I’ve recently started working with my brother and we made Bad Eggs Online together as a two man team with me as coder and him as artist. We both live in the UK.

How long have you been making games? What did you do before?

I’ve been making games for just over 3 years. I dragged John on board earlier this year and since then we’ve made a few games together. Learning to make games overlapped with uni for me – I couldn’t wait to finish my course so I could forget all I’d learned and start making games full time!

What was your inspiration for “Bad Eggs Online”?

It’s pretty clear that Worms provided some inspiration for us but actually we enjoyed playing an artillery game that we knew simply as ‘Bomb’ when we were kids. According to wikipedia it was in fact called Tank Wars but was also known as Bomb because that’s what the file name was. We were also very impressed by another multiplayer tank game called Shellshock Live. We were very conscious of treading in the footsteps of these great games in the same genre that had come before us so we really tried to approach it in our own unique way and come up with features and weaponry that hadn’t been done before in quite the same way.

Why multi-player? Why in-game chat? How did you build it?

I was at FGS earlier this year and sat in on a very inspiring talk by Chris Benjaminsen of Player.IO. His talk was all about how he made Everybody Edits using Player.IO and he included some great figures about how much people were spending in his game. I had been wanting to do a multiplayer game for a while but couldn’t see how it would work financially (nor did I want to spend ages learning how to go about making one). Player.IO was so well documented and easy to get to grips with (after a bit of a learning curve at the beginning) that I just decided to dive right. I’d actually prototyped an artillery game with eggs about a year earlier but had dropped it by the wayside.

In-game chat seemed like an obvious thing to include in a multiplayer game. Whilst we were building and testing the game it was clear that the trash talk was a huge part of what made the game fun. What good is smashing your opponent into oblivion if you can’t laugh in their face afterwards? We didn’t get chat right first time though. It took a bit of learning as we went to get it where it is now. We initially only had in-game chat so after a game or in the pre-game lobby you couldn’t chat to each other which was obviously a pretty silly mistake. We also then didn’t make chat persistent from lobby to game which meant that it was hard to follow a conversation. The great thing about a multiplayer game though is that if you don’t get it right first time your players will let you know and you can release an update to fix things.

Can you give us any insight into your content release schedule, and how that has impacted the game?

Although we don’t have a rigid schedule that we stick to, we’re working full time on improving the game, adding new features and additional content on a regular basis. We’ve worked hard at taking on board the feedback and suggestions from our players, keeping in touch using our forum. So we kind of play it by ear when it comes to new content and such, not to say that we don’t have stuff waiting in the wings.

We recently launched a cool new feature which we call skills. You can earn one a day and it enables you to cast little perks such as shields or teleport in the game. Sometimes these can be a real game changer and we feel it adds an interesting extra dimension that wasn’t there previously. At Halloween we added a new map and the zombie egg. We infected one of our players with the zombie and asked them to go forth and spread the outbreak by killing other players with the zombie egg. A week later there are nearly 10,000 infected players.

We also have a huge range of egg shells that people can use to play as in the game. We’re adding new ones every week with plenty more to come. Did someone say Dragon Eggs?

Any early trends or stats you can share about player behavior?

By far and away the most played game type is 1v1 (which is understandable since it is the default selection and also will make for the shortest games). The least played game mode however happens to be my personal favourite: 4 player free for all. I like this game mode because it’s as much about diplomacy as it is about skill. You have to form alliances if you want to win but you can’t trust anyone! I’m also sure that that’s why it is the least popular game mode…

Also, it’s almost worrying how addicted some players get! We don’t get to track this sort of stuff usually but on a multiplayer game where you have to create an account we can see how individual players progress. When we were making challenges for the game we put some in that we thought would be crazy high for the real addicts like get 500 kills. We’re already seeing players that have over 1000 kills which is pretty mindblowing and also fantastic to see that people have enjoyed playing so much that they keep coming back for more.

What types of games do you like to create the most? What types of games do you like to play the most?

I like making all sorts of games. I like to try and do something a bit different every time but I suppose I do always have the old fall backs of ‘something with box2d’ or a point and click adventure. Those are definitely the kinds of games that I like playing so it’s probably not too surprising that I have made a few of them myself. John and I grew up with classic point and click adventure games such as the Discworld games and Myst series so have always been inspired by those.

How long is your game creation cycle? What is your process?

It varies so wildly depending on the game. Bad Eggs has been the longest development time of all my games, partly because it was our most ambitious project so far, partly because I had to learn how to use Player.IO and partly because we’re still working on it adding new features! Generally we try to aim for about a month per game or less if possible. Bad Eggs has been about 3 months so far I think but after going into beta we let it rest for a week and made a quick little game in between (not yet released though).

We tend to plan our games as thoroughly as possible before we start making anything and use a wiki to keep track of our thoughts. Then it’s just go go go, referring back to the wiki and filling in the gaps as we go.

Are there any game developers that you admire or consider “rock stars”?

We admire a lot of developers. Independent game developers in the truest sense of the word who are making amazing games. There are a lot of talented people making flash games and we’re always impressed by the wealth of entertaining and original ideas that come out on a weekly basis. Some games that have caught our attention recently include Cyclomaniacs 2, The King’s League, BioGems (and not just because it was made by mochi! This was a really fresh spin on an exhausted genre and we were very impressed by it), Wonderputt, Last Stand: Union City, Shore Siege 2.

What is it about making a new game that you enjoy most?

Prototyping a new game is a really fun process. Coming up with the ideas that are going to make a game fun and then being able to very quickly translate that into something you can interact with is something I really love doing.

Do you have any hot projects you’re working on right now?

Bad Eggs Online is still taking up a good chunk of our time at the moment but I do have a sequel to a game I made with the artist RobotJAM in the works (Hambo 2) and we have started brainstorming our next game that may or may not involve a ninja teddy bear.
Congratulations again, looking forward to Hambo 2!

© Colin Cupp for MochiLand, 2011. | Permalink | 12 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Flash Game Friday, Game Design, Game Showcase, MochiLand Topics, Publisher Feed.

Note: This tutorial was originally written for .net magazine. I’m now allowed to publish it here, so read on and enjoy! Grab the files for download before starting!

Retro style games are becoming more popular than ever online. Commonly referred to as “8-bit” these games have pixel-art graphics and “chip tune” music that apes the consoles of old, but often have surprisingly innovative gameplay mechanics. And Flash has turned out to be the perfect tool for creating them, as hit titles like Canabalt and Fathom demonstrate.

Fathom was one of the first games built with Flixel and is a good example of what it can do.

This may seem at odds with a technology known for its vector graphics and timeline animation. But under the hood Flash is perfectly capable of pushing around large volumes of pixels which is exactly what is required. Flixel is a game framework born from a desire to create 8-bit style games. But it has evolved into a powerful way to rapidly create games in Flash. With a strong community and plug-ins available it’s the perfect choice to create our game with. In this two part series we’ll explore how Flixel works and build a retro-styled platform game in the process.

Download the tutorial files and look through the source code alongside reading the article, because for the sake of space not all of it can be included here and we’ve got a lot of ground to cover.

Getting started

For Windows users there is a guide on installing FlashDevelop with Flixel. On Mac OS X you can use Adobe Flash Builder. FlashGameDojo has a tutorial for this. Or run FlashDevelop under Parallels.

Even if you use FlashDevelop / Flash Builder already I’d still recommend following the guides so you become familiar with the Flixel package structure.

Game Design Brief

It helps to have a plan of your game before you start on it. While the plan should never restrict you from iterating your game during development, it will set a base ground on which to build. Here is a concise brief for our game:

“Player controls a chick who can run left/right and jump on platforms across a horizontally scrolling level. The environment is a lush green jungle with trees, grass, flowers and ruins to explore. There will be static and moving platforms and stars to collect. Collect enough stars and the level exit opens. Player cannot die by falling unless he hits the water. Animal baddies move around the platforms and are fatal to touch.”

From this brief we can instantly visualise how the game will look and play. This allows us to break the code structure into logical objects such as Player, Map, Star and Enemy. The artist can also create concept sketches to set the style of the game, and provide a point of reference for the pixel art.

Concept Sketches These help set a visual style for the game, introduce main characters and act as a reference for the pixel art.

It starts with FlxGame

Open Main.as from the “Part 1″ source folder:

public class Main extends FlxGame
{
public function Main()
{
super(320, 240, PlayState, 2, 60, 60);
forceDebugger = true;
}
}

FlxGame is the wrapper for your whole game, setting up Flixel in the process. The call to super sets the resolution of our game (320 x 240), the initial State (PlayState), the zoom level (2) and the frame rates (60 fps).

While 320 x 240 may seem small at a zoom level of 2 it will display at 640 x 480. The up-scaling of retro games is a common trait that helps show-off the detailed pixel art. forceDebugger enables the built-in debugger which is activated by pressing the ‘ key. This lets you view bounding boxes, collision, paths, variables, logs and save out game replays.

Your game can have only one FlxGame class, but it can have many States. States are a way to split your game into logical sections. For example a MainMenuState, a PlayState with the guts of the game and a GameOverState. Only one State can be active at a time.

Getting into a right State

States in Flixel extend FlxState and they are the guts of your game. When the State is initialised it calls the function create. This is used to construct any assets or variables the game needs. Once your game is running Flixel calls the update function every frame. In Flash terms it’s the equivalent of an Enter Frame event. Here is where you handle anything that needs to happen continuously. We’ll use it to detect collision between game objects.

Inside the create function we make two types of object: the Player sprite and some platforms.

player = new Player(32, 100);
floor = new FlxTileblock(0, 208, 320, 32);
floor.makeGraphic(320, 32, 0xff689c16);
add(player);
add(floor);

The floor variable is one such platform. Although we’ll replace it in the final game it’s a great rapid way to provide objects the player can jump on to test the physics. The objects are then added to the State, allowing Flixel to draw them when it renders the scene. It’s similar to addChild in native Flash and the order in which you add defines how they are drawn.

All player specific code is held in the Player class, represented here through the player variable. This keeps it organised and easy to re-use. Before we start that however we need to give our player some wings – quite literally – by preparing the sprite sheet.

Nutmeg The sprite sheet for the pixel hero of our game, drawn in 16 x 18 sized frames.

Flixel can automatically create reversed frames so we only draw him facing right. The first frame is an idle pose. Frames 2 and 3 are the walk cycle, and frame 4 is a hurt expression. If you are more comfortable animating inside of Flash Professional then you can create a timeline sequence as usual, export it to a SWF and use a tool such as Grant Skinner’s Zoe (http://easeljs.com/zoe.html) to convert it to a sprite sheet.

Sprites in Flixel are called FlxSprite which is what our Player extends. These differ from regular Flash Sprites in that as well as graphics data they contain extra values to allow you to easily control physics, animation, direction, collision and rotation. Inside Player.as we’ve embedded the sprite sheet:

[Embed(source = '../assets/player.png')] private var playerPNG:Class;

And then tell FlxSprite to use it:

loadGraphic(playerPNG, true, true, 16, 18, true);

This tells Flixel to chop the sheet into 16×18 frames and create reversed versions. Animation works in a similar way to Flash MovieClips.

addAnimation("walk", [0, 1, 0, 2], 10, true);

This creates a new animation sequence called “walk” which cycles through frames 0, 1, 0, 2 at a rate of 10 frames per second. The true parameter makes it loop. To play an animation you use its label:

play("walk");

What goes up must come down

Making the player sprite run and jump smoothly provides us with a great opportunity to explore ones of Flixel’s strengths: its plug-ins. Much like with WordPress and Drupal, the Flixel community release plug-ins which extend the framework further and ultimately save you time.

One such plug-in is FlxControl which is part of the Flixel Power Tools. They are included in the tutorial zips but are constantly updated, so check https://github.com/photonstorm/Flixel-Power-Tools for updates. If downloading fresh there is a Getting Started guide in the Docs folder.

The plug-in needs to be activated and assigned to our player FlxSprite:

if (FlxG.getPlugin(FlxControl) == null) {
FlxG.addPlugin(new FlxControl);
}
FlxControl.create(this, FlxControlHandler.MOVEMENT_ACCELERATES, FlxControlHandler.STOPPING_DECELERATES, 1, true, false);

The parameters tell it that we want the sprite to accelerate and decelerate. If we didn’t pick this the sprite would start and stop immediately making the experience very abrupt.

FlxControl.player1.setCursorControl(false, false, true, true);
FlxControl.player1.setJumpButton("SPACE", FlxControlHandler.KEYMODE_PRESSED, 200, FlxObject.FLOOR, 250, 200);
FlxControl.player1.setMovementSpeed(400, 0, 100, 200, 400, 0);
FlxControl.player1.setGravity(0, 400);

This enables cursor control for the left and right keys, and sets SPACE BAR to be the jump button. The player can only jump if on the floor and will try to jump to a height of 200 pixels. setMovementSpeed allows the sprite to accelerate at 400px/sec up to top speed of 100px/sec. Modify these values to much lower or higher numbers to see the effect! Finally we set some gravity, pulling the player back down to earth. Try changing the gravity value to make the player float or drop like a lead balloon. The best thing you can do to learn about Flixel and its plug-ins is to mess around with them. You never know what might come out of it! I’ve seen whole game ideas born from what were code bugs, so it pays to experiment.

Putting it all together

Run the code at this point and you’ll see we have a cute little chick sprite who can run and leap around at will. It collides smoothly with the ground, and there’s even a platform to leap on. If you press the debug key (‘) you can watch the physics values in real-time. Click the box icon in the top right to turn on the visual outlines.

We have lift off! A running and jumping player with platforms to leap on

Granted it isn’t quite Mario, but we’re not finished just yet.

Building a Level Map with DAME

Green blocks are all well and good, but we need a proper level for the player to explore. Flixel has built-in support for Tile Maps which are an efficient and fast way to construct game levels. Tile Maps work by using Tile Set in a series of tiles aligned to a fixed-size grid. Here is the Tile Set created for our game:

The Tile Set used to draw the game map, complete with water, plants and platforms.

Each tile is 16×16 pixels in size, and you can see that some of them join together to form game objects such as the platform in the bottom right. The organisation of the Tile Set is up to you (or your artist!), but it’s sensible to leave big chunks of empty tiles should you need to insert new tiles later on in development. Tiles are separated into two types: Tiles you can collide with, and tiles you never collide with. In Flixel this is determined by the tile number and is called the Collide Index. Every tile after the index is treated as a tile you collide with. In our Tile Set you’ll see on the top row items such as flowers, bushes and shrubs. These are all non-colliding tiles, as we don’t want our player getting stuck on flowers.

With our Tile Set created we now need to design the level. To do this we use a Tile Map Editor. For this tutorial we’ll use an editor called DAME. Although the interface takes some getting used-to, the actual map view in DAME is rendered directly with Flixel so you know for sure that what you see in the editor is how it appears in game.

DAME can be downloaded from http://dambots.com/dame-editor/ and works on Windows, OS X and Linux. Create 3 map layers in DAME, one for the Sky background, one for the level itself and one for the stars which the player can collect. You can find our DAME maps by downloading the tutorial files and looking in “Nutmeg Part 2 – The Map”. With the Map Layer selected click on a tile in the Tile window and then paint with it, just like an art package:

Tile Map Editor DAME in action showing part of the level created for the game

Once you are happy with the design of your level you can export the map data to a CSV file from the File ñ Export menu.

Lights, Camera, Action

Add a new class to the project called Level1 that extends FlxGroup. This is Flixel’s way of grouping display objects together and keeps our code logical and structured. We can also check for collision against a whole group, which is significantly faster than checking every element individually. Our map is held in a local variable:

map = new FlxTilemap;
map.loadMap(new mapCSV, mapTilesPNG, 16, 16, 0, 0, 1, 31);
add(map);

loadMap takes our CSV map data exported from DAME, and an embedded Tile Set png and creates a Tile Map object which is then added to the group. The same process is repeated for the Sky background.

Back in the PlayState we add the level to the display. But before we can unleash the player we tell Flixelís camera system to follow them around and restrict the camera to the map boundary:

FlxG.camera.setBounds(0, 0, level.width, level.height);
FlxG.camera.follow(player, FlxCamera.STYLE_PLATFORMER);

The last task is to add a collision check into the PlayState update function:

FlxG.collide(player, level);

With the map loaded, the camera set and collision running we can now test the game. The chick now happily bounces around the level, landing on platforms and not colliding with flowers.

Sprinkling a little stardust

Now we’ve a pretty landscape to traverse we’ll add stars for the player to collect, and display the total collected as a score in the game. Flixel has a text function called FlxText which we use to display the score:

>

score = new FlxText(0, 0, 100);
score.scrollFactor.x = 0;
score.scrollFactor.y = 0;

The score is added at the top left of the screen and has a scrollFactor of zero. This means the text will be locked in place at the coordinates given, and not scroll around as the camera moves.

In the DAME map the Stars layer was exported to a CSV file and weíll use this map data to create Star sprites. The function parseStars in the Level1 class works by looping through the CSV map data, and for every tile it creates a new Star sprite at those coordinates. All of these sprites are added to an FlxGroup called stars. In the PlayState update function we check to see if the player is colliding with a star:

FlxG.overlap(player, level.stars, hitStar);

If a collision occurs this will call the function hitStar, passing in the two objects that collided, in this case the player and the star he hit. The star is removed from the game and the score increased:

star.kill();
FlxG.score += 1;
score.text = FlxG.score.toString() + " / " + level.totalStars.toString();

Finally the score text is updated to show them how many stars they’ve collected, and how many are left. With this one small addition we’ve now got a real playable game with an objective to collect all stars:

Reach for the stars With the stars in place our game now has a purpose - try to complete the level

In part 2 we will introduce baddies for you to avoid, sound effects, a user interface (HUD) and Game Over sequence. If you feel inspired to build your own games be sure to visit http://flixel.org which is home to a vibrant developer community. You’ll also find stacks of Flixel related tutorials at http://www.photonstorm.com along with the Flixel Power Tools plug-ins. Finally for reference to the classic games of old http://www.retrogamingtimes.com is well worth a visit.

The following 2 parts were the “box-outs” that appeared in the print article. I’ve included them here because they’re interesting :)

Adam Saltsman talks about why he created Flixel

I guess it was around 7 years ago that I tried to make a little “game engine”, something that would allow me to make Super NES style games. It just seemed like a fun thing to do. After a few abortive attempts in C++ / Python / Java I finally settled on AS3. It was the pixel-level stuff in it that really interested me. However I’d grown very cautious about “engine building” and not actually making any games. So I stuck with AS3 and created game after game, and noticed which patterns evolved. The games kept getting more complex, and re-used code from previous projects, and eventually those parts I was seeing in every project got moved to their own folder. I think a lot (if not most) developers have a similar folder somewhere, just a pile of “really handy” code.

Originally this was just for me, something I’d use to sketch new game designs in. But it wasn’t long before I thought that with a little polish here and there I might be able to release it publicly. Turns out it needed a lot of polish (and still does), but I really like where it’s going. Lately I have been thinking a lot about how to “make stuff that matters”, which is a very loose idea, but something I obsess over, for better or worse. I think Flixel is a cool thing. It’s not really “art” in and of itself, but it contributes to the cultural food chain, and that makes me feel like a hero.

Eventually it would be great to add official support for a physics engine like Nape, and port it over to Molehill, the hardware-accelerated Flash Player by the end of the year. I am very hesitant to ever add game-specific features to the framework, but these all seem like good general systems and will just make making games easier and more fun.

At the risk of leaving out something awesome I would say the following games are shining examples of Flixel in action:

Canabalt
Station 38
Tuper Tario Tros
Cat Astro Phi

Cat Astro Phi Designed to look, sound and feel like a Gameboy Classic title it's a good example of what Flixel is capable of.

Pushing Pixels

Mastering the style of pixel art

Professional pixel artist Ilija Melentijevic explains how he created the artwork for Nutmeg:

Pixel art is a time-consuming but rewarding approach to creating game graphics. If you have little screen space such as on a mobile device, or are simply looking for that charm and precision it offers, then itís worth making the extra effort. Also, it’s incredibly fun!

It’s a good idea to start from the big picture. First make a mock-up of a game scene, defining the style, colours, characters, etc. Once you have such solid foundation it’s easy to turn it into actual game assets. Your art must fit and enhance the game, not just look nice on its own, so make sure everything reads well and speaks to the player in a consistent way. In a busy shooter, use colours to separate bullets from power-ups, or to make the foreground objects pop out. Immersion is a priority in any game, and understanding what’s going on plays a big part in this. Fire up your favourite games and look how the pros do it.

There are a number of tools you can use and they vary widely. Some people even use Microsoft Paint! Many professionals use Photoshop and it certainly gets the job done, but I prefer a dedicated pixel-oriented program. Closest to the industry standard is Cosmigo Promotion which boasts an impressive set of features and will look familiar to Photoshop users. My personal favourite is the 100% free GraFX2. Currently it lacks animation, but otherwise provides for an unparalleled workflow and ease of use.

Make sure you join an active pixel art community that will provide both feedback and motivation. PixelJoint lets you comment, rate and vote on other people’s work, submit your own, and even take part in weekly challenges, perhaps the best way to hone your skills.

For a less casual approach consider Pixelation, a community focused on pushing the medium forward. Here you’ll find discussions on theory, game art analysis, collaborations and more. Many masters of the form frequent the forum, so it’s a great place to post your work to get some constructive critique.

View Ilija’s artwork at http://www.photonstorm.com/topics/art

GraFX2 A lightweight and free (as in free beer) pixel-pushing program for Windows, Mac and Linux

© Photon Storm for MochiLand, 2011. | Permalink | 7 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Developer Spotlight, Flash Development, Front Page, Game Design, MochiLand Topics, Tutorials.

So many games have been released, that it seems like everything has been done. But sometimes all it takes is a little tweaking on an old idea to create a new one.

Problem: There are thousands of Flash games out there on the web and it’s tough to make your game stand out from the rest.

Solution: Make your game unique.

Before I get into the meat of this post, I’d like to say I’m glad to be writing again. The last few months of summer were spent researching in the environmental science field. Flash was put aside as I immersed myself into something new. But I’ve been drawn back into the Flash community temporarily, and expect to pop up again from time to time. Without further introduction, let’s get into a few ways to put a new spin on an old genre.

1. Reverse Roles

If you’re looking for an easy way to make your game unique, try putting the player into a new, unconventional role.

In my game Whack A Mole: Revenge, I had gamers playing as the moles, trying to avoid the computer’s incoming hammers. It was a simple idea, but it made my game stand out. You could apply this concept to nearly any genre. In a tower defense game, have the player send waves of enemies instead of defending with towers. In an adventure game, have the player build a map that will stop the adventurer.

Here are some common role reversal ideas:

• Side-kick/Hero
• Player/Enemy
• Good/Evil
• Follower/Leader
• Player/Level Builder

Those are just a few ideas to get you started. Be creative with it!

2. Mix Genres

As high school chemistry teaches us, a great way to make something new is to mix two different things together.

The same concept can be applied to your game development. Mix up the objectives of one genre with the gameplay elements of another. Or perhaps mix the time period of one genre with the time period of another.

3. Introduce a New Game Element

While our the first two suggestions can completely change the way a game is played, this third suggestion merely adds upon the genre. Think of it like the toppings on your ice cream. You don’t need them to enjoy the ice cream, but they can make it better.

A new gameplay element could be anything from a simple mini-game (a fighting mode in a football game, i.e. Blitz) to a complex chat system which allows you to control your squadmates in a shooting/strategy game.

4. When in Doubt, Add Features

If you went through all these tips and still can’t think of any new game ideas you’re excited about, don’t fret just yet. Perhaps there are some features you can add to make your game more unique than the rest.

For example, most pong games are too simple to have an upgrades store. Maybe you could add upgrades and achievements into your pong game to make it something new and interesting. Or maybe you want to make a shooting game. How about adding a custom gun creator, complete with design elements, shot type, damage and more?

Wrapping it up

There are many ways to take an old genre’s gameplay and turn it into a game that is new and interesting. It takes creativity though, so don’t be afraid to think outside the box. Get messy if you have to. Just don’t forget to get feedback before you start developing. Sometimes what’s awesome to you might be completely wacky to others.

When have you developed a game that was unique and different? Tell us about it in the comments.

Photo Credit: thephotographymuse

© freelanceflashgames for MochiLand, 2011. | Permalink | 12 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Front Page, Game Design, MochiLand Topics.

What Is Mochi London?

Mochi London has been held for 3 consecutive years now as a community-driven Flash game developer meetup averaging 8-12 attendees, and has traditionally resulted in open conversations with regards to Flash game development. Ernesto Quezada and myself have been to every single one, with Ernesto serving as the organizer the past two years. Well things changed in 2011 after Ernesto and I had a little conversation- we wanted this year to be bigger and better than before!

Who Are We?

I’ll start off with myself! My name is Chris Jeffrey, I’m a Games Developer based in the United Kingdom. I primarily develop on the Flash platform, however as of late I’ve also started porting games over to iOS & Android platforms as well. I’ve been using Flash for around 5 years in total and developed games casually for approximately 3 of those years.

However! More recently I’ve actually made a bold move and actually left my job to go full-time indie, so I’m really looking forward to having the chance to devote all of my time to development. Apparently the content I throw out can be somewhat successful, ranging from 4-8m impressions in their life cycle, but if you want to know more and hear me blabber on, head over to chris-jeff.com, where I dribble in the form of blog posts! You can also find me on Twitter.

Ernesto Quezada is a Games Developer/Publisher from El Salvador. He started using Flash in version 4 back in the late 90′s. In 2002 he moved to London. After learning a bit of English, in 2005 he went on to get his Masters degree in Digital Media at the London Metropolitan University. Even though he’s been working professionally as a Flash developer since 2006, his graphic design background still stops him from moving completely to the dark side so he’s still a bit scared of the command line which, anyway, he uses at work on a daily basis. He’s created about 30 games in the past 10 years (and has drank a lot of tequila on the way…). Check out his portal over at games-garden.com.

First meet up in 2008

Why London?

Exactly! It’s what I ask myself. Personally, Mochi Newcastle seemed much more appealing (I live in Newcastle). Honestly though London is a great place and we thought it would be a more convenient location for the majority of people, plus it has the added tourist incentive for people to see the sights and such. Previous Mochi London meetups have generally been with developers in and around the London area, so we didn’t feel a need for our 4th event to be anywhere else!

The Venue

Ernesto, the London local (and official Mochi London tour guide) received a really good tip on this one. After he checked it out and shared pictures of it with the rest of us, we knew right away that this was the right place. Plus, the venue itself was relatively close to a tube station and a pub. Perfect, right? The inside was just right for the crowd we’d anticipated, it seated everyone pretty comfortably without people being too cramped or too spread out. Kings College London also catered the event, which meant that we didn’t have to get catering from another vendor.

So a big thanks to Mochi with helping us out with the venue, food, & beverages for the event! :)

The line for lunch! Nom.

First Steps

We started to discuss potential ideas of ramping up the meetup and getting it to a level where we could potentially attract more attendees than just the regular handful. We toyed with the idea of getting sponsors and going down that route of making it more of an official conference than just a meet up, but that whole idea didn’t really appeal to us, we wanted a more official meet up, however still cater to the whole idea of it being by developers for developers. We settled on the idea that it would be best to get Mochi Media directly involved, especially since this was coming directly from their community! However, we still wanted to keep the whole conference style and not just sitting in a pub, so we threw ideas around about getting a venue and speakers and making a whole day out of it.
We were moving in a different direction from the typical meetups, a direction that I was really excited about! That said, we still liked the idea of our pub meetup (Being from Newcastle I guess maybe?) So we ended up including the pub portion as well and made it a two day event to keep with Mochi London tradition.

Merlin Gore - Importance of personal branding - As you can see, I'm all branded, Huzah!

Speakers

Once we had the idea locked down, it was time to get the event pumped with solid content that would get the Flash games community excited about the event! For some, this can be a pretty daunting and time consuming experience- trying to get quality speakers with content people actually want is no easy task. My approach: I kept it real simple and just thought of what I’d want to hear! Sounds a little egocentric, but I’m an indie developer and I know exactly what I’d want to hear and from who- so why not get them to speak!? Makes sense, right?

Day 1 schedule! - Look how far we've come!

We ended up with a pretty strong line up of speakers, with content that covers a wide variety of topics within the Flash games industry. Perfect in my eyes!

• Iain Lobb (freelance Flash / ActionScript developer)
• Stuart Allen (creator of Gravitee Wars)
• Martine Spaans (Ubisoft, formerly of SPIL Games)
• Michael Hudson & Steven Gurevitz (CodeHeads / 2002 studios)
• Merlin Gore (Flash developer, FlashGameLicense.com)
• Mike Jones (Platform Evangelist, Adobe Systems)
• Colin Cupp & Ryan Nichols (Mochi Media)

Day of the Event!

A few of us kicked off the day a little earlier in order to get set up and also to ensure that everything was in proper working order. Registration opened at 9:00am and it wasn’t long after that when we started to see people arrive! Personally I felt really great when people started flooding in, as beating 8 attendees for a community event is a milestone for Mochi London ;). And they didn’t stop- we ended up with about 50+ people eager for the antics that the day would bring, in the form of presentations of course.

Mochi London 2011 - All the happy faces :)

I honestly feel the day couldn’t have gone any better, unless we actually went to Nando’s afterwards (inside joke and my personal obsession)!! All the speakers were started on-time and covered their topics extremely well. Questions were asked by engaged attendees, and they received some really in-depth responses. There were moments when the conversation moved from the presenters out to the audience, which was exactly the type of attendee interaction we were hoping for. Overall, the whole day was really informative and went exactly to plan (minus Nando’s, not fair!).

Day Two

The day that consisted of drinks and random chats about Flash game development, experiences and stat sharing! Exactly what Mochi London started off as, so this couldn’t go wrong at all! We totally kept up with tradition and met up at the Montagu Pyke pub which is where the first meet up was held! It’s a nice, open venue with a solid Sunday roast…and it’s reasonably priced!

We met up at 8pm and finished at around 10:30pm, then  went on the hunt for food! Of course, I suggested Nando’s (As always!), however we missed it by around 5 minutes, I’m not sure what I’ve done, but karma wasn’t on my side for that day! Or the day before…

Closing Thoughts

I personally thought the whole event went to plan- in fact, it couldn’t have gone any better as far as I’m concerned! This was a great step for Mochi London. We’re definitely going to be preparing for Mochi London 2012 due to the popularity of this year’s event! My hope is to be able to take it up another notch with more quality speakers who have a strong presence in the Flash games industry, as well as keeping the event as fun and informative as possible. In the end, Mochi London is all about the community.

So on that note, Mochi London 2012 anyone?!

Robinson and his heroic efforts at manning the reception booth, thanks Robinson!

I’d love to hear thoughts and ideas for next year, we want to make it even better! Feel free to contact me!

I’d also like to thank everyone involved in making Mochi London 2011 what is was on the day! From the Mochi Media team, to the speakers, and most importantly to the attendees who turned up- thanks everyone!

Presentations? We Have Presentations!

Check out the presentation slides from the speakers of Mochi London 2011

Mobile Gaming: Is It The Future? by Michael Hudson and Steven Gurevitz

View more presentations from mochimedia

Gravitee Wars Post Mortem by Stuart Allen of FunkyPear

View more presentations from mochimedia

Player Behaviour by Martine Spaans

View more presentations from mochimedia

Game Design for Game Developers by Iain Lobb

View more presentations from mochimedia

The Importance of Personal Branding by Merlin Gore

View more presentations from mochimedia

What's New At Mochi! by Colin Cupp and Ryan Nichols

View more presentations from mochimedia

Mochi London 2011

View more presentations from Mike Jones

Pictures!

Check out the pictures on Mochi’s phototstream to see pictures taken throughout the weekend!

Videos

I’ll be sharing the videos of the speakers in a later post as we’ve got to get all the footage in one place and edit a bit (as it’s recorded from a tablet). So keep an eye out! :)

 
Thanks for reading!

© ChrisJeff for MochiLand, 2011. | Permalink | 6 comments

Add to del.icio.us

Search blogs linking this post with Technorati

Want more on these topics ? Browse the archive of posts filed under Developer Feed, Flash Development, Front Page, Game Design, Games Industry, Mochi Media Announcements, MochiLand Topics, Publisher Feed.

Introduction

BioGems is Mochi Media’s first in-house game, which can be found in the Mochi Media games catalog. It’s a puzzle battle game in which space pets fight to protect their planet. By matching gems on a board, the player gets his pet to attack the opponent, defend itself for a while, regenerate some health or energy, or fill up its Rage meter.

Building a Team

My name is Dominique Ferland and I’m the game designer of BioGems. Before I joined Mochi, I worked on console games for about 4 years in Montreal. My title was never clear – something of a mix between an artist and a game designer. Growing tired of large-scale projects, I started making games in my spare time. The last game I made is the gamer trivia title, Geek Mind, which put me on Jameson’s radar for a Mochi in-house title. As soon as Jameson made an offer for me to start a development team and make fun games, I said goodbye to my old job!

CEO and co-founder of everything Mochi, Jameson Hsu is the best boss in the world. His vision for games is pretty simple – making awesome games he’d love to play. As we shared our love for games and discussed our game ideas, it was clear that we’d make a good creative team. As you’ll see in this post-mortem, Jameson’s input in the design and in the production really helped keep BioGems simple and super fun.

As Jameson and I were developing our puzzle game idea, we realized we would need a super programmer to join the team – that’s when Jameson found Nico Tuason, Master of Flash. Based in the Philippines, Nico has been making games and other Flash projects for years. He really impressed us with his little indie gems, Desert Moon and SolarMax, which really showcased his creative programming skills. Each time he’d add something to the game, it would be super polished, animated and tweaked to perfection. And he’s just an awesome dude.

Brian McBrearty, musical genius, joined in a bit later in development to add all the bleeps and bloops, the loud gem explosions and the awesome music. He did it all with such ease and awesomeness that it was kind of scary. Brian has designed sound and music for tons of films, games and other media – check out his blog for all that craziness.

Enough about us, let’s talk about the game!

Game, Set, Match-3

Since our brand new team was creating our first game together, our instinct was to make something small, manageable and simple. We’d take basic gameplay that we all knew and loved and just see if we could make it quickly. We actually had many basic game prototypes created around well-known game types with generic art and no polish at all. We soon realized that these were just boring, uninspired clones so I had a new task – making these interesting with a fresh theme and clever twists to the gameplay, something to make us stand out from the crowd.

I pitched 3 game ideas, on which I had carte blanche for theme and looks. The first was a quirky cooking-themed Puzzle Bobble clone, the second an Indiana Jones-style archeology-themed Puzzle Fighter, and the last one was a mad scientist battle Bejeweled game. Here are the pictures I sent to Jameson, along with the pitch for the third idea.

Food Bubbles & Spelunquest, 2 not-so-good ideas

The very first mock screen for BioGems

For the moment, the board consists of colored gems that contain little organisms that look like basic monsters. The player gathers these miniature monsters, then mixes them up to create monsters with many different effects. For example, I’d need 6 yellow gems (skeletons) and 6 blue gems (octopi) to activate the Skeltopus (or something!), which either deals damage to the other player or has some special effect. Every time a power activates, a little image of the activated monster would appear with its name and its effect. For example, I gathered red and green and used “Phoenix”, and a cool-looking cartoony phoenix would appear with “PHOENIX: Deal X damage and play an extra turn after this one”.

Characters would be stylish scientists (yes, I will make them cool), with different pre-selected sets of monsters.

We opted to work on the third idea, which I would refer to as Science Quest – a pretty lame name now that I think about it! The player would play as a scientist battling his peers with science, merging together mutated animal genes to create monstrous things to attack the opponent. The board was populated with gems, each imprinted with little creature types, as well as viruses and money.

How gameplay won over theme

As weeks passed by, Jameson and I exchanged ideas and tweaked the game via e-mail. We kept a short design document detailing the game’s systems, abilities and characters, which was very useful to keep the scope of the game under control and as a starting point for our soon-to-join programmer. The game changed a lot during pre-production – here’s a short history of how we dumped science for sci-fi pets!

The original title banner

The name BioGems appeared quite early in the process. I just sent this e-mail to Jameson, who approved right away! It sure is catchier than Science Quest!

“Since the players will be mixing up gems that contain some sort of genetic material for creatures, I thought of GeneGems or BioGem as the game’s name… What do you think? “

As an artist, user interface designer and game designer, I like putting together mock screens of the game I have in mind as early as possible. These fake screens make me ask myself a few questions. Does this look like a game I would play? Would a player understand the game right away? Is there a major design problem that couldn’t be seen in a design document, maybe with space, clutter, or colors?

A first iteration I never showed anyone before!

As the game evolves, I keep modifying the mock-ups until they become the actual interface design files. It’s a very useful tool to discuss gameplay with teammates since almost every aspect of the game is shown in the screens.

Squares turn into bubbles, energy bars are clearer, and life bars evolve

Even at this early state, you can see RPG elements start to appear. We all agreed that collecting money, buying upgrades and customizing your character would give the player a nice feeling of progression. Now we realize it’s a lot of work to code, but ultimately was totally worth it!

Placeholder portraits for scientists based on Spock and Futurama’s Zoidberg.The “Special” bar would eventually become the Rage Meter!

The original design, similar to the great Puzzle Quest, had lots of resource gathering. The player would need to match and collect different types of cells before they could use the wide variety of special abilities. Many turns would be spent collecting instead of fighting – it seemed a bit boring, so we switched to a more direct approach. Matching gems of a certain type now instantly triggers an action, making battles more intense. It also removed the extra layer of complexity in the many special abilities. A casual player would get confused with too many different effects and conditions, plus programming all of the abilities would overwhelm our very small team of one guy!

Bubbles turn into gems and the timer appears.
The energy bar also makes its first appearance, then named “Special”.

When we ditched the different resources, we were exposed to a huge challenge – giving each gem type an action and making sure the player would understand it quickly and clearly. At that point, matching bird gems would restore life, matching beast gems would raise energy… It really didn’t make any sense, so we replaced animals with clear icons. The icons on the gems and whether to put text on them or not were the toughest interface design issues we ran into.

Placeholder art for monsters – I used Pikachu and Dragon Quest’s slime temporarily, to see how much space pet monsters would take.
The timer is refined, bar’s colors are tweaked and text appears on the gems.

Now that the animals weren’t on the board anymore, the scientist battle idea was pretty much run into the ground. For a while, we made it so that scientists would each have a pet to battle with, Pokemon-style, using the gems to command it. It felt a bit off, and when I got to writing and designing the introduction and cut-scenes with the scientists I just cut them off completely, leaving only the pets, fighting on their own. It made for a much simpler story to tell through comic book cut-scenes – no need to explain the relationship between scientist and pet, why they’re using them, and so on. The minimal science-fiction story I wrote was simple enough to tell quickly and without text – there are space invaders, and you must fight them!

The final gems are finally here, along with the Rage Meter.

Monster Gallery

At first, when I was thinking about the battling pets, I sketched a bunch of weird monsters. None were really that exciting and creating a group that would fit well together seemed like a huge challenge – until Jameson suggested making them animals. Everything clicked when I put a space suit on a cute, bad-ass bear. I went on to design the enemy space suit and the rest of the cast was pretty easy to complete. The bear was originally supposed to be a playable character, but we opted for classic house pets as playable characters, and tougher animals for the enemies. Here’s a somewhat chronological gallery of the character design for BioGems!

The animation team did a wonderful job with BioGems’ characters. I wrote short descriptions of each character’s animations in a spreadsheet format and sent it over. We began with one character at a time, to establish a good style and create a template for the rest of the cast. The spreadsheet sent to the animators looked something like this:

They sent us Flash files showcasing all animations on a single page, then we’d comment and ask for some changes. When we were satisfied with the first few characters, we gave the green light for all 12 characters and added each one to the game as soon as possible – seeing the game come to life in such a fantastic fashion was such a motivation boost!

Precioussss

The look of the gems evolved slowly. Jameson asked for objects that looked more like precious gems or diamonds, while I was worried about clarity. We showed a bunch of different gem designs to people around us, eventually settling on the current icons without labels.

The very first set was quite square! The over-detailed images inside the squares looked terrible on the board.

The bubbly second set, which looked okay but lacked any 3d-ness. Icons were also hard to see.

Simplified creature icons are imprinted on these octogonal stones. I still love those icons, but they really were detrimental to gameplay.

Creatures are replaced with icons. A test with text on the gems helps understand the gameplay, but really messes up the board’s readability. The stones still don’t look like precious gems, so we change them in the next iteration.

The last look is created from gems, emeralds and diamonds. We change the icons again to something even clearer and we add the amazing rainbow black hole.

It’s a Small World

Now that the main gameplay seemed pretty solid, we had to design a single-player experience around it. The player would progress through a series of enemies until he defeated the last boss. I came up with two completely different models. Terrified by the complexity of the somewhat larger second model, Jameson gave the green light to the linear model. I was kind of frustrated at first, but this was totally the right call – the game would never have seen the light of day in that crazy over-sized model!

The simple model is pretty straightforward, like old school arcade fighting games.

I really wanted to give the player more choices in where to go, what to do – but it was too much work!

The crazy thing is, there was a third model – an actual turn-based strategy game, complete with resource gathering, territorial control, micro-management, and all that jazz! I would show you the model, but it doesn’t even fit in a web browser!

Controlling the scope of the game is very hard to do. Even the game as it is now was a bit too ambitious for our team size and our schedule – Nico was a bit overwhelmed by all the features we kept adding, while Jameson and I were struggling with making everything user friendly. Even a basic world map and upgrade system such as ours requires a lot of testing and balancing, so I’m really glad we kept the game small.

Using the hivemind

Alternating between game design and art kept development fresh for me, doing a bunch of different tasks every week. Nico was now coding the match-3 gameplay super fast, adding layers of polish early, programming menus, doing smooth transitions between screens, while I was designing the world map, creating the shop and polishing the interface. The whole team met in San Francisco for 2 weeks during GDC 2011, and being in the same room with everyone was the most effective time working on BioGems. There was a strong synergy between us, since all team members were so excited about the game coming together at last. While I was almost done with my tasks, Nico was working 12 hour days tying it all together and adding tons of polish. Nico made sure we had daily BioGems builds to dig through to find bugs and balance difficulty.

As soon as we had a playable ladder of opponents, we had a bunch of friends and co-workers test the game’s usability. The lovely employees over at the Mochi offices in San Francisco provided us with much needed insight. Having worked on the game for so long, we were comfortable with the gameplay and the interface, but testers had a rough time understanding what was happening on screen. Here are a few things we fixed thanks to testing.

Confusing icons

The red gem, which fills up your Rage Meter, originally had a skull icon. Some hardcore gamer testers got confused – in a similar title, Puzzle Quest, the main way to damage your opponent is by matching skulls. We decided to change it to a fire icon, which makes more sense anyway!

Cues for player action were missing