With just a little bit of time, we will create something like this:

Let’s go!

We need 6 buttons: 2 function buttons (Load – to load our leaderboard, Send – to send the score)and 4 buttons to filter the score: daily/weekly/monthly/all

We also need 3 columns (Text fields) to output name/score/date of players.

Main code:

1. initialization function

   initBoardfunction 
   initBoard():void{
   	MochiServices.connect("MochiGameID", root);// connecting to MochiServices
   	MochiScores.setBoardID("LeaderboardID"); // set the board ID to the leaderboard you wish to work
   withbtnDaily.addEventListener(MouseEvent.CLICK, showLeaderboard_d);
   btnWeekly.addEventListener(MouseEvent.CLICK, showLeaderboard_w);
   btnMonthly.addEventListener(MouseEvent.CLICK, showLeaderboard_m);
   btnAll.addEventListener(MouseEvent.CLICK, showLeaderboard_a); 
    
   btnLoad.addEventListener(MouseEvent.CLICK, loadLeaderboard);
   btnSend.addEventListener(MouseEvent.CLICK, sendScore);}

2. request is a list of score: onScoresReceived – callback function that gets the scoresfunction

   loadLeaderboard(e:MouseEvent):void
    
   {
   MochiScores.requestList(this, onScoresReceived);// request the scores and send them to the onScoresReceived method in this object or class}
    
   //description onScoresReceived functionfunction onScoresReceived (args:Object):void{
   if (args.scores != null) {
   allScores = MochiScores.scoresArrayToObjects(args.scores);
   showScore(allScores, 0, 15);
   /*
   * showScore(scores:Object, typeTop:int = 0, countPlaces:int = 10):void
   * @scores - array of objects whose keys are derived from cols
   * @typeTop - values:
   * 		0 : alltime score
   * 		1 : monthly score
   * 		2 : weekly score
   * 		3 : daily score
   * @countPlaces - number of scores. show top 15 players for example
   */
   } else {
   if (args.error) trace("Error: " + args.errorCode);	}}

3. implementation of the showScore function:

   function showScore(scores:Object, typeTop:int = 0, countPlaces:int = 10):void
   {
   var scoresOb:Object;
   var place:int = 1;
   txt_name.text="";
   txt_score.text="";
   txt_date.text="";
   for (var i = 0; i < countPlaces; i++) {
   switch(typeTop) {
   case 0: scoresOb = scores.alltime[i]; break;
   case 1: scoresOb = scores.monthly[i]; break;
   case 2: scoresOb = scores.weekly[i]; break;
   case 3: scoresOb = scores.daily[i]; break;
   }
   if (scoresOb) {
   txt_name.appendText(place++ + " " + scoresOb.name + '\n');
   txt_score.appendText(scoresOb.score + '\n');
   txt_date.appendText(showDate(scoresOb.timestamp) + '\n');
   }
   }
   }

4. function to display the correct date, for users :)

   function showDate(date:Object):String
   {
   var myDate:Date = new Date(date);
   var arMonths:Array = new Array("January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December");
   return (arMonths[myDate.getMonth()] + " " + myDate.getDate() + ", " + myDate.getFullYear());
   }

5. to send the score

   function sendScore(e:MouseEvent):void{
   var score:int = 300;
   var name:String = "Typenamehere"
   MochiScores.submit(score, name, this, SubmitComplete);
   }
   function SubmitComplete(ok:Boolean):void{
   if (ok){
   trace("Scores submitted!");
   }else{
   trace("Error");
   }
   }

That’s it. Here, I’ve described how to create a simple leaderboard. With this is simple leaderboard we can also add the current rank of the player, country flags, and a scroll bar…but I’ll save that for another tutorial :)

Download the source here

© uNik for MochiLand, 2012. | 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 Development, Front Page, MochiLand Topics, Random, Tutorials.

FGS 2012 Advisory Board Interview Series

This is part four in a series of interviews of the Flash Gaming Summit 2012 Advisory Board. This is your chance to get to know the folks who determine the content of Flash Gaming Summit, getting their thoughts on both the conference and the games industry in general. This week’s Advisory Board interview features Simon Lachance, co-founder of Berzerk Studio. Berzerk Studio is a highly successful game studio creating games for both online and mobile platforms.

For more information on Flash Gaming Summit, including passes, speaking, or award show nomination information please visit the conference website.

Introduce yourself- who are you, how big is your team, and how do you participate in the Flash games industry?

I’m Simon Lachance, co-founder of Berzerk Studio.  We’re a team of 7, (3 coders, 3 artists, 1 Game designer/Artist) making Flash games since the end of 2008. We have made over ten games up to this point, and recently launched our own Flash games portal.

What did you do before?

We, the 3 co-founders of Berzerk Studio, were working at the same Flash game company.  We always had the dream to start on our own, make games that we like and create a cool brand.  So we decided to quit our jobs and go full indie.

How did you first get into the Flash games industry? Tell us about your path.

As mentioned above, we were already working for another Flash Games company before Berzerk Studio.  That’s where we learned how to make a game from scratch.  After we founded Berzerk Studio, I was looking up “how to sell games” on the Internet (how to make a living out of it).  Our very first idea was to make a game on XNA and publish it on Xbox.  We had done a prototype of a Flash game ported on XNA that worked very well,  but we decided that it would have been too risky to start among the big ones.  Our strength was Flash games, and the XNA prototype would have taken too much time to make.

So back then, we did something hard but necessary-  we threw the 6-months-production-XNA-prototype in the garbage, and started another smaller game for the Flash market.  Our strategy was to create small but high quality games for the Flash market, build a reputation, a fanbase, and a brand to be able to sell on future console games.   That’s when we found Flash Game License (FGL).  Chris Hughes saw our prototype and contacted us, since then they really helped us monetize our games. You should really go see these guys if you want to know more on how to sell games and live from it.

What has been your proudest moment since joining the Flash gaming community?

It was when I went to Flash Gaming Summit (FGS) 2011. I’ve met a lot of cool people there- developers, publishers, portal owner etc. We exchanged a lot of great information on the games business. But the proudest moment was when I discovered that half of the people I’ve met knew Berzerk Studio and the Berzerk brand. There were literally people making the Berzerker’s scream from our intro in front of me saying “That’s the best intro ever!” I have never been so proud of our team.

What was the biggest challenge for Berzerk Studio in the early going? How does that compare to the challenges you face today?

I’d say the biggest challenge is monetizing your games. We knew how to make games, but to monetize them was something we had to learn. You have to make decisions when producing the games to make sure they sell well. The biggest challenge when you’re alone with no money to make a living, is time. You always have to scope small to make more games instead of risking to make a big game that won’t sell. Sometimes you have a really cool idea, but the time needed to create it is too long so you just have to leave it or save it for the sequel.

Describe the climate as a game developer today in terms of technology and monetization opportunity. How does it compare to being a game developer 2-3 years ago?

The biggest difference now is that you can think of porting your games on the mobile market.  The mobile market is way bigger than it was 2-3 years ago,  so it’s always best to think of a game that can be ported on the mobile market if the game does well on the web.  We chose Unity to port our games on iPhone and Android, which is a very strong technology that allows us now to port any of our games in 4 days.

What is it that you love the MOST about the Flash games industry?

It’s a very fast market.  You need to pump out games quickly, and it’s fairly easy to make a game that’ll be played millions of times all around the world.  It’s a very strong distribution tool for your brand.  An average Berzerk game gets 8-12 million plays,  sometimes 25 million.  That’s a lot of people that are exposed to your brand.

What do you like the least?

I’d say that it’s hard to make everybody happy.  Some players will want to tear it down, saying bad things about it. If your game is good,  people will ask for a sequel, NOW. If it’s bad, you’ll get tons of angry emails telling you what you did wrong.

How has the industry changed since you fist joined?

It’s pretty much the same.  You need a sponsor to distribute your games, it goes on thousands of portals and you start again. As said earlier, the biggest difference now for us is that we try to reach the mobile games market for games that worked well on web.

The theme for FGS 2012 is “Maximize Your Game”. How do you think Flash game developers are maximizing their games today? What could they be doing better / differently?

There’s a lot of ways to monetize your games.  Micro-transactions are one of them,  but knowing what and when to sell is a science. It’s important not to piss people off before they even play the game.  We have also found that translating our games in many languages is a really good thing to do, so you can reach new local markets.

Where do you see the Flash games industry going? What’s in store for the future?

Free small games will always be there.  It’s a great distribution tool for ads or showcasing your brand. I can’t see it going away anytime soon. Although, with Stage3D and the mobile market growing up, Flash games might finally have an impact on the mobile market.

What part of Flash Gaming Summit do you enjoy or look forward to the most?

Meeting people! Shaking hands and discussing business is my #1 plan at FGS.  If I have time, I’d also want to hop on stage to share my experiences, but there’s so many things going on here at Berzerk that I may not be able to!

In your opinion, why should people come out to FGS 2012? What should they expect?

“Maximize your games” pretty much sums it up.  Increasing revenue for each of your games is what you want, if you want to make games full-time and continue improving your games.

Thanks Simon, see you at FGS 2012!

© Colin Cupp 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, Front Page, Games Industry, Industry News, Mochi Media Announcements, MochiLand Topics, Publisher Feed.

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 | 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, 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.

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 | 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, Developer Spotlight, Flash Development, Front Page, Game Design, MochiLand Topics, Tutorials.

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 | 3 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.

The Mochi community event “All About Ads” has come and gone, thanks to everyone for stopping by! We hope it was informational, if not at least a little bit entertaining. If you missed it don’t worry- we have some wrap-up information for you! You can watch the recorded presentation, check out the questions from attendees, and/or view the slides below. Enjoy!

Watch The Recorded Event

Click here to watch the recorded session!

Supplemental Materials

• Ad terminology definitions
• Sales process chart

Post-Presentation Questions (answered in the recording)

These questions were asked, and answered, at the end of the presentation:

• TV is separated in different segments in this chart as opposed to internet, doesn’t that create an unfair comparison?
• How big was the impact of refusing low quality ads on revenue?
• What about ad revenue in INDIA?
• What is the minimum budget for advertising on the Mochi platform outside of the self-servce platform? Is there a video ad requirement?
• Is it possible to implement all Mochi ad products so that mochi can decide which one would be best for my game and disable some dynamically ?
• Do you have information about games that switched the ad type and how it impacted the revenue / players opinions ?
• Could you provide some information about AdBlock / NoScript and whether it makes sense to disable the game if the ad could not be displayed ? #2 Do you plan to allow LiveUpdates without Ad Integration ?
• Is it possible for a developer to refuse a required time limit ad?
• How can we take advantage of all Ad types?
• You mention hacking quite often, could you provide more information about incidents ?
• Any new formats planned for this year?
• Could you discuss what the differences are in terms of displaying ads across multiple mochi ad formats (pre-roll, interlevel, clickaway) for direct buyers vs self-serve? Are there any differences? Are self-serve only displayed in certain places? Is it all 100% randomized based on bid/ad buyer rates? Etc. If I’m currently running a campaign on self-serve, what is my benefit to moving to a direct buy campaign?

View The Slides

© Colin Cupp 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, Flash Development, Mochi Media Announcements, MochiLand Topics.

I am happy to announce the official release of the new Mochi Achievements API!

Mochi Achievements API Summary

Flash game developers can now implement a completely customizable achievements system in your games that is free, flexible, and easy to use. The Mochi Achievements API also gives developers the flexibility of 2 toaster sizes (toaster = achievements pop-up) and 9 toaster placement options so that your achievements system looks and feels the way you want it to.

Speaking of look and feel, there is no Mochi Media branding in the default UI, and we encourage developers to implement your own UI (using the Mochi Achievements calls) for a more seamless game integration. The default UI comes with an achievements list, toasters, and graphics for the locked and unlocked states of your achievements (but you can easily customize the “unlocked state” graphics in the default UI).

We have also included a points system (points related to the achievements, developer-determined) complete with progress bars. Your players can view their points and achievements progress as they’re earned/unlocked.

Who Should Use Mochi Achievements?

Developers:

• If you don’t have the time or desire to create your own achievements system, but would love to have a quality solution that gives you control.
• If you are looking for a solution you can completely customize, either with your own branding or even a sponsor’s branding- you can be as creative as you want to be.

Publishers:

• Take advantage of the Mochi Publisher Bridge for site-specific achievements, getting more value out of your community and your players.
• You can request that developers implement Mochi Achievements with your branding for sponsorships and site-locks.

Mochi Achievements Examples

Flying Candy, Papa’s Taco Mia!, big LITTLE plagiary 3, and Flood Runner 3 are all examples of games that are using Mochi Achievements in different ways to “achieve” the same goal. Check out the two example games below to see the contrast between the default UI and what can be done with a custom UI.

The first example is big LITTLE plagiary 3, which uses the default UI. The second game is Papa’s Taco Mia, which is using custom UI created by the developer along with the Mochi Achievements calls. Note that the default UI has no branding, while the customized UI can be made to look however you want it to (including sponsor branding).

big LITTLE plagiary 3 Achievements List (default UI)

big LITTLE plagiary 3: Achievement Unlocked (default UI)

Papa’s Taco Mia: Achievement Unlocked (developer customized UI)

Papa’s Taco Mia: Achievements List (developer customized UI)

What Makes A Good Achievement?

Most game creators would agree that achievements make games more engaging and encourage players to stick around (increase replays). But how do you know if you are making a good achievements system? Here are a few resources we thought were interesting on the subject:

• Extra Credits
• The Cake is not a lie, pt.1
• Achievements 101 by Greg McClanahan

Want to try it out? Here’s how!

1. Download the latest version of the Mochi API
2. Once you have the latest API, log in to your developer dashboard
3. Select the game to which you would like to add achievements
4. Select “Achievements” in the left-hand menu
5. You should now see the information to create and edit achievements.

This new tool is a direct result of the community giving us product feedback- you wanted it, we thought it made sense, so we made it. Let us know what other products and features you would like us to work on by visiting our product feedback forums.

Be sure to let us know what you think about Mochi Achievements- we want your feedback! :)

© Colin Cupp for MochiLand, 2011. | Permalink | 3 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, Industry News, Mochi Media Announcements.

Introduction

Papa’s Taco Mia! is the third game in our series of hands-on cooking sims, with Papa Louie expanding his restaurant empire and branching out into the taco business.  The original time-management game in the series launched way back in 2007, and since then we hadn’t seen very many restaurant-themed games, which had us wondering if there was still an audience for the multitasking and hands-on gameplay found in the original Papa’s Pizzeria.

When we decided to step back into the series and develop a sequel, we wanted to add a number of additions that fans had requested over the years, and to avoid making the game seem like only a “deluxe” version of the original we branched out with a new food and new mechanics with 2010’s Papa’s Burgeria.  There was a great response to the new game and the fans were clearly still there, so soon after Papa’s Burgeria had spread virally we started thinking of where else we could go with the series.

We felt there were still a number of improvements we could make to the overall structure for these types of games, and by switching to new food items we could keep each game fresh and unique with brand-new mechanics, without feeling like a recycled version of the previous game.

With Papa’s Taco Mia, we decided to focus on tacos as the theme of the new game, which would bring a number of new cooking and building mechanics that would be very different from the previous games.  During development, there were a number of things that really helped shape the game into one that fits well with the others in the series, and often times improve upon them.  We also had a number of struggles and difficulties during development, though by pushing through these rough patches and learning from them we were able to craft an even better experience for the players.

What Went Right:

1. Checking the Suggestion Box

Before starting on Papa’s Taco Mia, we spent a lot of time reading up on players’ suggestions from playing the first two games.  We had a number of new ideas to spice up this game, but we also wanted to address any popular requests that seemed to come up a lot from the fans.  There were a few key features that we implemented based on player suggestions which we feel added a great extra layer to the game.

With Burgeria we finally added the much-requested feature of spending tips to buy things in the game, but players then started to argue that they shouldn’t have to spend THEIR hard-earned tips to make Papa Louie’s restaurant run better!  With Papa’s Taco Mia, we added a new weekly Pay Day where the player earns a sum of money to spend towards upgrades, which also adds something more to look forward to over the long term.  Some players had also commented that earning new customers wasn’t quite enough of a reward for leveling up in rank, so one of things we added to improve on this is a raise in the player’s wages every time they level up, so they can earn more on each Pay Day for doing so well.

Since Papa’s Pizzeria, we’ve received a lot of complaints about the process of taking orders and giving orders taking too long.  We’ve always thought that time spent with the customer is part of the whole multitasking challenge, but we wanted to address those complaints by tying it in with the customers leveling up with stars and Customer Awards.  Now when a customer earns a bronze, silver, or gold Award, they’ll also place and receive orders quicker than before, so you get an extra bonus for doing well with each customer.

2. Added Variety with Closers and Food Critic

In previous games, there hadn’t been a lot of variety over the course of a single day – different customers may come in, but serving the last customer of the day is not that different from serving the first, aside from it possibly being more hectic.  The customers who arrive on a specific day also haven’t made much difference in the gameplay, unless the player is trying to earn Customer Awards.  In Papa’s Taco Mia, we wanted to keep the familiar aspect of serving a series of customers, but also to add a twist where serving a certain customer might have higher stakes than the others.

To change things up, each workday ends with the arrival of a Closer – a sort of mini-boss for each day that is much harder to please, and who uses a different grading scale when receiving their tacos.  These Closer customers also use a different system for visiting the taco shop:  Each of the Closers will only visit once a week, so it’s even more of a challenge to earn stars and Awards for them, since players won’t see them as often.

To add even more variety (and a helpful tip bonus), we introduced the Food Critic as a Closer customer, who orders something completely different every time he visits.  If he’s happy with his taco, he awards the player with a Blue Ribbon, which is displayed in the lobby for three days and prompts any other customers to give higher tips.  These two changes to the customer system add more variety to the gameplay throughout the day and across multiple days, without straying too far from the familiar arrival of customers.

3. Solving the Mechanic “Hooks” for the Game

With each game in the series, we try to center the gameplay on the type of food being served, and come up with ways to turn that food’s preparation into enjoyable game mechanics.  There were a variety of challenges in coming up with both the cooking and building phases for serving tacos, and lots of refining that went into getting the mechanics just right to capture the feel of the series.

All of games in the series have a cooking phase in its preparation, and up until now the way to add variation to orders was by cooking food for different lengths – making a burger well-done in Burgeria, or cooking a pizza for a brief time in the Pizzeria to lightly bake.  With tacos though, people don’t order their ground beef well-done or rare, so we needed a different hook for the cooking phase that made sense for preparing tacos.  We first decided that we would have multiple kinds of meats that would form the basis of customers’ orders.  This added variation to the preparation of an order, but wouldn’t make much difference to the cooking phase if preparing beef was no different than preparing chicken.  To capture that aspect of cooking variation from the other games, we decided that the preparation of each meat would be made of similar components (cutting and flipping), but would require different timing for each meat type.

We went through a wide variety of mechanics and visual cues for this type of gameplay to work and make sense to the player.  Since we couldn’t rely on doing one “action” in that station at the halfway point of preparing a meat (like flipping burgers when half-finished), we realized we needed to prompt players on when to perform certain actions based on the meat.  In our early versions, the circular timer around each pan would complete an entire circle before prompting to flip, and would then complete an entire circle again before prompting to cut, which made it difficult to visually gauge how far along an order was.  Instead, we changed the pan timer to represent a full cooking time, and placed red and blue markers along that timer as visual cues when an action would be required.  Since these actions were important to the overall preparation, we also added bubbles prompting players on which action is required at each point.  There were some missteps along the way with cooking preparation (see our notes on this in the “What Went Wrong” section), but we kept fine-tuning the process until it worked well as a mechanic.

We knew from the start that we would have a lot of challenges with adding toppings to tacos.  We needed a topping system that lent itself to the food, and in this case it didn’t make sense to be placing individual tomatoes and pieces of lettuce on a taco.  What we needed was something closer to a particle system, which could pour bits of toppings onto a taco and have those cascade and form mounds on top of one another.  There were also two other important facets to dealing with dynamic, fluid toppings like these:  It would need to run fast without causing a performance drain on the game, and we would also need to come up with a scoring system that could make some sense out of all of the layers and mounds of food particles.

We spent a lot of time on tech demos for the system, trying to squeeze the best performance out of it so it didn’t bog down with hundreds of chunks filling a taco.  Once the solid foods were working, we spent time adapting the system for fluids like hot sauce and sour cream, which needed a different rendering system so they didn’t look like a bunch of separate blobs.  We fine-tuned each topping type so guacamole would have different speeds and stickiness than beans or rice, and so sauces like sour cream could look and act thicker than others like mild sauce.  In the end, we had a topping system that made sense for the food, and which felt like how you naturally prepare a taco.

4. Easter Eggs Turning into Strategy

One of our minor goals was to improve the cosmetics in areas like the “Start of the Day” scene.  While we didn’t anticipate any effects on gameplay, we wanted to add a bit of life to the outside shot of the shop that players see before each day.  To make things seem livelier, we added a few customers walking up or passing by, and decided to use the first and second customers who visit that day so it related to who walks in.

A happy accident occurred during playtesting when we noticed we were actually using these “Easter Eggs” during the opening scene to our advantage while playing the game.  Once we had started learning all of the customers’ meat preferences, after we saw the first or second customer in the opening scene we would quickly jump to the Grill Station and get their meat cooking before they even arrived!  This was a great benefit to actually learning customers’ orders, since it could give you that added advantage at the start of the day.  It also helped us nail down the most important aspect of a customer’s order, which we struggled with when planning the unlockable topping system.

5. Looking forward to unlockable toppings and achievements

In the earlier games, we struggled with the feeling of monotony over the course of multiple days, and didn’t feel that unlocking new customers was quite enough of a change in gameplay or a big enough reward for sticking around.  With Papa’s Taco Mia, we sought to remedy that with toppings and ingredients that would gradually unlock while playing.  This was especially helpful for this game, which may have felt overwhelming if all of the meats and taco shells were present and being ordered from the start.  We also made sure that once a new topping or ingredient was unlocked, someone would arrive within the next two customers to order that new item, so it felt like the possibilities were expanding and that the newly-acquired item would be useful.

On top of these unlockables near the start of the game, we noticed that some players would play for long periods of time (racking up hundreds of in-game days), and we wanted to add some long-term rewards for these players as well.  An achievements system was added to the game with 60 badges rewarding players for a variety of accomplishments, including serving a number of tacos in hard shells, earning blue ribbons from the Food Critic, getting 100% in certain stations, and buying upgrades from the shop.  With unlockable toppings, long-term achievements, new customers, and Customer Awards, players now have a variety of short-term and long-term goals to work towards in the game.

What Went Wrong:

1. Rethinking the Grill

One of our biggest issues during development was the gameplay surrounding the Grill Station.  In our original plan, meats would be scooped and poured onto tacos just like every other topping, except you wouldn’t have an unlimited supply of the meats.  Instead, you would cook up large batches of beef and chicken early in the day, and you could get a few orders worth of meat from each batch until the bin was empty and you needed to cook more.

It made sense on paper, especially since that’s how taco shops often prep their meats, but after we built up the system and did some playtesting we realized it was making the game feel off-balance.  While playing through a work day, we noticed we could get our cooking out of the way early and rarely return to the Grilling Station, so most of our time was spent taking orders and topping tacos.  Without needing much prep time for tacos, the gameplay started feeling more like an assembly line and less about multitasking and keeping track of multiple orders at once.  Even worse, you couldn’t really do anything until you cooked all of your meats and filled the bins, so every day started with a couple minutes of waiting around and orders piling up that you couldn’t start.

One of the main factors in the multitasking of our previous games was a certain part of an order’s preparation that took a while to complete – waiting for pizzas or burgers or cook – which would encourage players to multitask and work on a different order while waiting for something to finish.  We had that with this cooking mechanic, but the key difference was that the meats weren’t a part of a specific order – it was just busy work before you could get on with the real gameplay.

To keep players coming back to grill, we tried making the “batches” of meat fill fewer and fewer tacos, and it soon became clear that we needed that one-to-one connection between an individual order and its preparation.  We scrapped the original idea of stocking bins with the cooked meats, and instead went with an entire pan of meat going into each order.  Without a bin to pour the meat into, we were faced with new questions on how to transfer the meat between stations, until we decided to put all of the taco shells right on the stove and pour directly into them from the pans.

It caused a lot of hang-ups in our schedule and involved a lot of rethinking and redesigning, but in the end we had captured that feel of hectic multitasking again.  This design change really helped the gameplay feel like it was constantly moving forward, instead of starting each day with a long wait at the grill.

2. How do you pronounce that?

We’re notoriously bad at coming up with titles for our games, but we thought we’d have an easy time with this one.  “Papa’s Pizzeria” was a natural choice for the original game, and for the sequel we tried to build on that familiarity with the somewhat-goofy “Papa’s Burgeria”.   For the new game we originally decided on “Papa’s Taqueria”, since taco shops occasionally go by that name, and we had that matching “-ia” at the end of the title.

The more we looked at the title though, the more we realized how awkward it could be for players.  A good amount of our regular fans are from Spanish-speaking countries, so we liked having the authentic Spanish word “taqueria” in the title.  The problem is that the word is rarely used in English (unlike the familiar “pizzeria”), and unless you frequent a lot of taquerias you may not see the root word “taco” in the name, especially with the spelling change adding a “Q” in the middle.

We were actually hung up on the title for a few weeks, trying to find something similar to the earlier titles so it felt like it was part of the series, without confusing a chunk of our fans with awkward spellings.  We tried different suffixes and even going with a phonetic spelling, though it was hard to guess how to pronounce “Tacoria” when reading it out loud, and it sounded more like a fantasy kingdom than a restaurant.

In the end, we came up with “Papa’s Taco Mia!” – making sure “taco” was clear in the title, trying to evoke the feel of “Mama Mia!”, and also getting it pretty close to matching with the other games’ titles.

3. Customers and their Toppings

When we decided to gradually unlock toppings as you play through the game, we realized we’d have some issues with how customers ordered their food.  In the previous games, the customers always order the same thing every time they visit, to help players become familiar with each customer’s individual order and feel that each customer is unique.  In this case though, a customer might normally want to order a steak taco with peppers before either of those items is available, so we had to decide exactly how we’d handle substitutions or missing toppings.

We first attempted to have the earlier customers always order what would in theory by unlocked by the point they first visited.  This worked out fine at the start, but two main problems came up with using this system:   First, when these customers show up again later in the game, we ended up with a bunch of orders that were only variations of beef, lettuce, and tomatoes, which got a little boring.  Second, when we finally unlock peppers as a topping, we don’t have anyone who wants it on a taco!  We’d need to quickly unlock more customers that would also want these newly-unlocked toppings, and it also got a little boring with five new customers in a row all wanting those new peppers and steak on their tacos.

To fix these issues, we created a more dynamic order system, where customers would have a list of ideal toppings they wanted, and would only ask for them if they were available.  This way, while a bunch of your customers might want onions, they’ll skip that topping when placing orders until you have it unlocked – and then we also have a larger pool of customers who can order newly-unlocked toppings.

Once we planned out this new system, we knew that we wanted customers’ requests to always be additive instead of replacing things – for example, Franco will originally order lettuce on his taco, then later add onions to the lettuce, instead of outright replacing the lettuce with onions.  We had two challenges again with this plan – how to handle meats and taco shells.  We obviously couldn’t ignore the taco shell if the type they want isn’t unlocked, and we didn’t want to serve meatless tacos which would cut an entire station out of the preparation.  At the same time, we knew we’d have some issues with mentally connecting a customer to their usual order if that usual order keeps changing drastically.

After trying a handful of possible solutions, we realized that the meat was the most important part of the taco that needed to relate to each customer.  It’s the main ingredient of the taco, and it’s the first thing you need to prep for an order.  It helped a lot to know that if you just took Wally’s order, he’s always going to want chicken, so you can plan what to put on the grill without having to pay too close of attention to the order ticket yet – and this especially helps if you use the outdoor Easter Eggs to get a jump-start on your day like we mentioned earlier.  To make sure customers didn’t change their meat orders, we had to carefully plan the unlocking sequence so someone didn’t visit before their meat was available (though we couldn’t get around this with the Closers who visit on a set schedule).  We’d still be stuck with customers flip-flopping on what kind of taco shell they want, but at least once their desired shell is available they’ll stick with that from now on.

4. Papa’s Coffee Shop

We had no idea if people would still be interested in cooking-sim games after Papa’s Pizzeria, so after we launched Papa’s Burgeria and saw there was still a demand for games like these, we started thinking of other directions to go with gameplay.  Before working on Papa’s Taco Mia, we had actually started making a very different cooking-sim game:  Papa was going to open his own coffee shop.

We didn’t get very far into development before we were faced with a mountain of problems.  We had a lot of trouble finding the right gameplay hook with coffee preparation, and it was hard to distill coffee-making into a multitasking process instead of just being a linear assembly line.  A lot of the same problems we had with Taco Mia’s grill were present in the coffee shop – how do we slow down the preparation to encourage multitasking, and keep it a hands-off process so you have time to move to another station?  Should you really brew a fresh batch of coffee for each cup?  Should you wait for pots of coffee to brew each morning before doing anything?  Aside from gameplay challenges, the color palette for ingredients was also pretty drab with browns and whites (coffee, cocoa, caramel, foam…) so it didn’t look very fun or interesting either.

The deciding factor was when we noticed that we weren’t getting the same vibe we got from the earlier games – there was never a moment of “that looks so good, I could really go for a coffee right now”.  We ultimately decided to scrap the coffee shop and switch gears to something else.  Tacos were on our earlier list of possibilities; though we had originally put it aside because of the challenges with creating pourable toppings and fluid sauces.  In the end, it was much easier to visualize and plan out the gameplay with taco-building, and despite the challenges it ended up being a much more enjoyable game to work on.

5. Struggle with Pouring Mechanics

After we ironed out the technical issues with pourable toppings and fluid sauces, we had some trouble deciding on the best way to actually pour those toppings into the tacos.  The first method we tried was a “click-and-scribble” mechanic:  You would first click on a bin of toppings, and the scooper would attach itself to the mouse as you moved around the screen.  You would then hold down the mouse button as you scribbled above the taco, pouring the bits out while you were “pressing” and dragging the scooper.

It felt a little odd when the scooper would attach itself to the mouse, as it wasn’t a mechanic we had used previously in the series – in Papa’s Pizzeria, you had to click-and-drag a pepperoni from the bin and release to place it on the pizza, and in Papa’s Burgeria you had to click-and-drag a pickle from the shelf and release above the burger to drop it.  It also didn’t match the mechanics elsewhere in Papa’s Taco Mia, where you use drag-and-release mechanic for moving pans, tickets, and the grill utensils.

The method that we finally used in the game is instead a “drag-then-wiggle” mechanic:  You click and drag from a topping bin to above the taco (just like toppings in the other games), and when you release the button you then move the mouse left and right to pour that topping evenly across the taco.  We went back and forth between these two mechanics a lot during development and had a rough time deciding on what felt the most natural.  There may still be a moment of confusion with toppings pouring out seemingly uncontrollably when you release that mouse button, but it stays closer in line with the rest of the mechanics of the game and the series – and after your first try or two the pouring feels natural.

Conclusion

On top of a great new topping system (which opens up possibilities for future games in the series), we were able to add many new features to give the game even greater depth than the previous ones, and add more variety and excitement for players.  Though we had a few difficulties during development, by looking at the problems and discovering the core of each issue, we were able to really hone in on what makes a game work within the “Papa’s” series.

© Flipline Studios 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, Developer Spotlight, Flash Development, Front Page, Game Design, MochiLand Topics.

Download Alternativa 3D 8.

This tutorial consist of these parts:
- move the car with keyboard controls
- follow the car with the camera

The final app will look like this:

(*requires Flash Player with Molehill)

To understand the car’s movement let’s do a little bit of math. I’ve got inspired by this tutorial and this one. But anyway, there is no rocket science involved. Just a simple trigonometric functions and that’s great, because anyone can do it easily.

Speed / Acceleration

When you press UP key, you add acceleration to the speed. When DOWN key, you subtract acceleration from the speed. When none of them is pressed, you slow down by multiplying actual speed by 0.96 – note it can be whatever, depends on how fast or slow you want to slow down.

// don't allow to speed up more than maximum speed
if (accelerate && speed0.3) {
		speed*=0.96;
	} else {
		speed=0;
	}
}

Steering / Rotation

When we press LEFT or RIGHT key, we turn the car by Math.PI/40 radians (4.5 degrees). Again, pass number that fits you best.

if (turn_left) {
	steering += Math.PI/40;
}
if (turn_right) {
	steering -= Math.PI/40;
}

You will also find that the solution above is not exactly correct, because we can turn the car even when standing on place with zero speed. To fix that, we will multiply the angle by speed/speedMax (a number between 0-1). Now it will behave correctly

if (turn_left) {
	steering += Math.PI/40*(speed/speedMax);
}
if (turn_right) {
	steering -= Math.PI/40*(speed/speedMax);
}

When we are done with speed and acceleration, we can apply it to our car. To calculate the real position of the car, we have to use a simple trigonometric functions – sine and cosine. Note that we know only speed (vector magnitude) and steering (angle, rotation of the car).

By the definition of the sine and the cosine, we are able to calculate the position (X and Y) of the car from the angle and speed.

car.rotationZ = -steering;
 
car.x += speed*Math.sin(steering);
car.y += speed*Math.cos(steering);

Let’s have a look what we have achieved so far:

(source code here)

Camera that follows the car

To add a so called “follow camera”, we have to do one simple thing – keep it behind the car in a specific distance, again by using trigonometric functions.

camera.x = car.x + Math.sin(car.rotationZ)*cameraDistance;
camera.y = car.y - Math.cos(car.rotationZ)*cameraDistance;
camera.rotationZ = car.rotationZ+Math.PI; // Math.PI = 180 deg

Right now, we have a camera, that follows the car. Try the demo here (source). But as you see, it feels very hard to play. So we add a little bit of smoothing interpolation to make the game smoother to play.

var targetX:Number = car.x + Math.sin(car.rotationZ)*cameraDistance;
var targetY:Number = car.y - Math.cos(car.rotationZ)*cameraDistance;
var targetZRotation:Number = car.rotationZ+Math.PI;
 
camera.x -= (camera.x - targetX)*.2;
camera.y -= (camera.y - targetY)*.2;
camera.rotationZ -= (camera.rotationZ - targetZRotation)*.2;

Now it feels much better. Try the final app here.

You will have also tons of questions, like adding slipping, physics, collisions, etc. Well – next time ;)

Source

Download the source code

The complete source code looks like this:

package
{
	import alternativa.engine3d.core.Camera3D;
	import alternativa.engine3d.core.Object3D;
	import alternativa.engine3d.core.Resource;
	import alternativa.engine3d.core.View;
	import alternativa.engine3d.materials.FillMaterial;
	import alternativa.engine3d.materials.TextureMaterial;
	import alternativa.engine3d.primitives.Box;
	import alternativa.engine3d.resources.TextureResource;
 
	import flash.display.Sprite;
	import flash.display.Stage3D;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.display3D.textures.Texture;
	import flash.events.Event;
	import flash.events.KeyboardEvent;
	import flash.geom.Point;
	import flash.ui.Keyboard;
 
	[SWF(width="800", height="600", frameRate="30")]
	public class CarWithFollowCamera extends Sprite
	{
		private var rootContainer:Object3D = new Object3D();
 
		private var camera:Camera3D;
		private var stage3D:Stage3D;
 
		private var speed:Number = 0
		private var steering:Number = 0
 
		private var accelerate:Boolean;
		private var brake:Boolean;
		private var turn_left:Boolean;
		private var turn_right:Boolean;
 
		private var cameraDistance:Number = 800;
 
		[Embed(source="sand.jpg")]
		private var texture:Class;
 
		private var car:Object3D;
		private var carBody:Box;
		private var carFront:Box;
 
		public function CarWithFollowCamera()
		{
			stage.align = StageAlign.TOP_LEFT;
			stage.scaleMode = StageScaleMode.NO_SCALE;
 
			// CAMERA
			camera = new Camera3D(0.1, 10000);
			camera.view = new View(stage.stageWidth, stage.stageHeight);
			addChild(camera.view);
 
			// init camera settings
			camera.rotationX = deg2rad(70);
			//camera.y = -300;
			camera.rotationZ = Math.PI;
			camera.z = -400;
 
			rootContainer.addChild(camera);
 
			// CAR
			car = new Object3D();
			// car body
			carBody = new Box(200,300,100);
			var material:FillMaterial = new FillMaterial(0xFFFF00, 0.8);
			carBody.setMaterialToAllSurfaces(material);
			carBody.y = -200;
			car.addChild(carBody);
			// car front
			carFront = new Box(200,100,100);
			carFront.setMaterialToAllSurfaces(new FillMaterial(0xFFFF00,.9));
			car.addChild(carFront);		
 
			car.z = -50;
			rootContainer.addChild(car);
 
			// MAP
			generateRandomMapOfCubes()
 
			// INIT Stage3D
			stage3D = stage.stage3Ds[0];
			stage3D.addEventListener(Event.CONTEXT3D_CREATE, onContextCreate);
			stage3D.requestContext3D();
 
		}
 
		public function followCarWithCamera():void{
 
			// Simple smoothing
			var targetX:Number = car.x + Math.sin(car.rotationZ)*cameraDistance;
			var targetY:Number = car.y - Math.cos(car.rotationZ)*cameraDistance;
			var targetZRotation:Number = car.rotationZ+Math.PI;
 
			camera.x -= (camera.x - targetX)*.2;
			camera.y -= (camera.y - targetY)*.2;
			camera.rotationZ -= (camera.rotationZ - targetZRotation)*.2;
 
		}
 
		private function loop(event:Event):void{
 
			if (accelerate && speed<100) { 				speed+=2; 				 			}else if (brake) { 				speed-=2; 			}else{ 				if (Math.abs(speed)>0.3) {
					speed*=0.96;
				} else {
					speed=0;
				}
			}
 
			if (turn_left) {
				steering += Math.PI/40*(speed/100);
			}
			if (turn_right) {
				steering -= Math.PI/40*(speed/100);
			}
 
			car.rotationZ = -steering
 
			car.x += speed*Math.sin(steering);
			car.y += speed*Math.cos(steering);
 
			followCarWithCamera();
 
			camera.render(stage3D);
		}
 
		public function onKeyDown(e:KeyboardEvent):void {
			if (e.keyCode==38) {
				accelerate=true;
			}
			if (e.keyCode==40) {
				brake=true;
			}
			if (e.keyCode==37) {
				turn_left=true;
			}
			if (e.keyCode==39) {
				turn_right=true;
			}
		}
		public function onKeyUp(e:KeyboardEvent):void {
			if (e.keyCode==38) {
				accelerate=false;
			}
			if (e.keyCode==40) {
				brake=false;
			}
			if (e.keyCode==37) {
				turn_left=false;
			}
			if (e.keyCode==39) {
				turn_right=false;
			}
		}
 
		// HELPER METHODS // not important to study them
 
		protected function onContextCreate(event:Event):void
		{
			for each(var resource:Resource in rootContainer.getResources(true)){
				resource.upload(stage3D.context3D);
 
			}
 
			stage.addEventListener(Event.ENTER_FRAME, loop);
 
			stage.addEventListener(KeyboardEvent.KEY_DOWN, onKeyDown);
			stage.addEventListener(KeyboardEvent.KEY_UP, onKeyUp);
 
		}
 
		public function generateRandomMapOfCubes():void{
 
			var ground:Box = new Box(10000,10000,1);
			ground.setMaterialToAllSurfaces(new FillMaterial(0xCCCCCC,0.3));
			rootContainer.addChild(ground);
 
			for(var i:uint = 0;i<30;i++){
				var height:Number = Math.random()*700+200;
				var b:Box = new Box(Math.random()*700+200,Math.random()*700+200,height);
				b.setMaterialToAllSurfaces(new FillMaterial(0xCCCCCC,0.5));
 
				b.z = -height/2;
				b.x = 5000-Math.random()*10000;
				b.y = 5000-Math.random()*10000;
 
				rootContainer.addChild(b);
 
			}
		}
 
		public function rad2deg(radnum:Number):Number{
			return radnum*180/Math.PI;
		}
 
		public function deg2rad(degnum:Number):Number{
			return degnum*Math.PI/180;
		}
	}
}

© TomKrcha for MochiLand, 2011. | Permalink | 5 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, MochiLand Topics, Tutorials.