Come2Play with LinkedIn Flash Game Developers Group has launched the 2nd multiplayer flash game contest, and this time with prizes totaling $10,000! Last years contest had only a handful of entries, so chances of winning the $5,000 pot for first prize this time is very high. Check out the winners games and other entries of the 1st ‘Games that Challenge the World Contest‘.

• 1st place – $5,000
• 2nd place – $3,000
• 3rd place – $1,250
• 4th place – $750

Flash games developers are welcome to join and take the pot. Create awesome head-to-head turned based multiplayer games, use come2play’s multiplayer API, submit and win! Prizes will be given out to the game which will have the best replayability both for new and return players, game design, concept and execution.

Developers keep all rights to the submitted games and even previously published games can be retrofitted to enter. Game entries does not have to be exclusive, so pre-released games are also welcome.

“So I’m interested, but only have a single player game” – Not a problem, see the developer tips on how to evolve your single player game into an interactive multiplayer game.

For complete contest info check out the official contest page.

Edit: Deadline has been extended to April 15th!

Having a SAVE feature in a project/game is one of the common things that could lead users to be more attracted and increase replay value for potentially recovering what was done in a previous visit. Using the SharedObject class in actionscript project/games is sometimes a requirement or at least a need, may it be AS1 (FP6), 2 or 3. It can be used to store valuable data like progress, settings, statistics, achievements and a lot more without dedicating storage on the server. Basically, SO or shared objects are like the browser cookies for flash, it is used to store some amount of data on the user machine, therefore it also has some limitations on its use (for security purposes really).

By reading the documentations or the livedocs, either for AS2 or AS3 (it’s really the same), you might have a gut start of what key points to remember.

• created shared objects can only be stored/retrieved on the same domain
• shared objects cannot be shared across domains, meaning a shared objects from “examplesite.com” cannot read shared objects created by another domain “mywebsite.com”
• users can disallow local storage per domain or opt-out globaly, then the object would not be saved locally
• data size to be stored is limited by which the user sets it (none, 10kb, 100kb, 1mb, 10mb, unlimited), although a dialog box can request an increase in storage if what is set is exceeded
• if the user sets a limit smaller than the shared object, the shared object would be deleted
• shared objects are stored on the user’s local machine not on the server, something shared over another machine cannot be accessed by another machine

The most essential part when using SharedObject is the SharedObject.getLocal() method, which is what we will be discussing more through out. Basically, AS1/2 and AS3 syntax haven’t really changed (although a few more rules were imposed in as3).

getLocal(name:String, localPath:String = null, secure:Boolean = false):SharedObject
[static] Returns a reference to a locally persistent shared object that is only available to the current client.

var mySo:SharedObject = SharedObject.getLocal( 'mySaveName', localPath, secure );
mySo.data.thingtoSave = myVariable; // your variables
mySo.flush(); // stores data into disk

Avoiding Known Issues

It might seem that using shared objects could be the simplest when you are only storing a couple of variables and objects like statistics or even could be the more complex when saving a game progress/state together with the players preferences. The bigger the system, more likely, the more complex your variables/objects are (same for games), and this is where possible issues during saving/loading/handling the shared objects.

Some common things to remember when using shared objects with your games:

1. Don’t use direct reference to objects and use the game’s data only not the actual game objects.
2. Use a localPath param on the getLocal() method.
3. Taking advantage of unique names for your shared object name.
4. Prompt and request for shared object size limit increase when your game needs it.

While I only have these that I can explain, you are free to share more if you have one or more. We can discuss and make the lives of other actionscript writers a little better.

Don’t use direct reference to objects and use the game’s data only not the actual game objects.

Why do I say this? Basically it is fine to store various data types such as objects and arrays on SO (shared objects), same goes for strings, numbers (int/uint), booleans and bytearray (as3). If you store references to local game objects on your shared objects, one way or another, your in for a later problem.

var mySo:SharedObject = SharedObject.getLocal( "mySaveName" );
// world.gameObject contains further objects like settings, player, etc
mySo.data.gamedata = world.gameObject;
mySo.flush();
// --

When you do something like the above, instead of storing the needed values only, you are referencing the local game object (w/c also contains references to other local game objects) in which Flash defines this as a copy of the local object but is really just a reference. Any change through out the game values/data would update the local object (which the shared object references) and Flash Player would write that into the shared object file when flush() is called or as soon as the shared object session ends – that is then swf file is closed.

The worst case here is that when you clear, reset or even delete your local game objects, the shared object which references to it will be affected and updated (as session has ended).

Also, even if don’t experience the possibility of issues when you do the above there, a problem might still arise when you load the shared object in later time. This case might not be so common but is possible to experience if loading the shared object is sloppily made. You can have inconsistent object references where the object contained within loaded shared object is conflicting, a duplicate, or not referencing the correct object.

A better and safest way of using shared objects (something like):

mySo.data.gamedata = {
  player:{
    score: world.gameObject.player.score,
    health: world.gameObject.player.health,
    currentLevel: <code>world.gameObject.player.currentLevel
  },
  settings:{
    mute: world.gameObject.settings.mute,
    quality: world.gameObject.settings.quality,
    particles: world.gameObject.settings.particles,
  }
}
/* well this is just a shortcut on containing them into objects,
 * but the point here is that score, health, currentLevel, etc
 * are all basic data types like number/int/uint, string, bool, etc</code>

Now you see that we store each valuable data only. We now transfer only the value of the variable not it’s reference. So while it’s fine to use objects and arrays on your shared objects, keeping be wary of how you do it, be careful.

You probably wouldn’t want to directly store instances of display objects, bitmapdata, functions, etc on share objects.

Use a localPath param on the getLocal() method

While passing the localPath parameter upon calling getLocal() is optional, although I would have to recommend using it by this time. In the case where you are building an independent system, prototypes, does not consider expansion/addons and will never be a part of a larger system, you can probably opt-out the localPath and never mind it.

So whats the issue of using and not using the localPath? By default, if you leave localPath by it’s default (null), it would use the the full path of the swf file (w/c includes the swf file itself) to store your shared objects.

#SharedObjects/<random code>/<domain>/<path>/<swf filename>.swf/<object name>.sol

• Windows XP and Vista:
  • For Web sites: %APPDATA%\Macromedia\Flash Player\#SharedObjects\<random code>\<domain>\<path>\<object name>.sol
  • For AIR Applications, %APPDATA%\<AIR Application Reverse Domain Name>\Local Store\#SharedObjects\<flash filename>.swf\<object name>.sol

• Mac OS X:
  • For Web sites, ~/Library/Preferences/Macromedia/Flash Player/#SharedObjects/<random code>/<domain>/<path from webserver>/<object name>.sol
  • For AIR Applications, ~/Library/Preferences/<AIR Application Name>/Local Store/#SharedObjects/<flash filename>.swf/<object name>.sol
• Linux/Unix:
  • ~/.macromedia/Flash_Player/#SharedObjects/<random id>/<domain>/<path>/<flash filename>.swf/<object name>.sol

-taken from wiki

For example, I have a swf  at http://example.com/games/uploads/supergame.swf, and when it creates a shared object (SharedObject.getLocal("supergameData");), the SO can be found at #SharedObjects/<random code>/example.com/games/uploads/supergame.swf/supergameData.sol.

While it works well and fine without the localPath parameter, there are certain sites/APIs/services that change the game’s file name by using their automated uploads, feeds, etc as the file name is used in the path. When the developer tries to upload a bug fixed build (v1.0.1), the swf might have another file name hence a problem appears where the previous build’s (v1.0.0) shared object won’t be accessible from the new build due to security reasons.

Although your shared object would be secured against any another swf so it can’t read it, by setting a localPath parameter like “/games” or simply “/”, the shared object can now be read by another swf file within the same domain. Using “/games” would make the SO accessible for any swf within the game directory, while having “/” would make it accessible from any swf within the domain.

Again from the same example but using SharedObject.getLocal("supergameData","/");, makes the SO at #SharedObjects/<random code>/example.com/supergameData.sol. This would make it not dependant on the swf’s file name.

Note: If you set a localPath in which the path doesn’t physically exists as a (sub) directory of the domain the shared object won’t be stored. Luckily with AS3 you’ll be prompted with an Error #2134 when the SharedObject can’t be created, but for AS2, you have to be well aware of this.

Taking advantage of unique names for your shared object name

This is one is something that I have just learned through experimentation and will soon incorporate on my next projects. While setting the localPath parameter to “/” makes the SO accessible to other swfs, there is also a risk that your SO name might be the same with another swf. We wouldn’t want another swf to mess up or overwrite our SO file just because it both uses general and/or generic SO names like “saveData” or “gameData“.

The ultimate tip: Since the SO names allow certain special characters like / (slash), we take advantage of that! Together with the localPath “/”, what I recommend is do a standard setup for your SO names something like:

<company/developer name>/<game name>/<data name>

var mySo:SharedObject = SharedObject.getLocal( "jaycsantos/neolithic/preferences", "/" );
// -- and/or something else like
var mySo:SharedObject = SharedObject.getLocal( "jaycsantos/neolithic/gameData1", "/" );
// --

…will store your SO at something like: #SharedObjects/<random code>/<domain>/#jaycsantos/neolithic/gameData.sol

Although I still have to confirm this with Mac OS and Linux machines. Drop me a line if you find it working with those.

Now ain’t that a little more organized than having all SO on the “/” of the domain!

Prompt and request for shared object size limit increase when your game needs it

There are cases when your shared object has a lot of data in it and it could exceed the default 100kb limit of a user. If this happens, it may cause your shared objects to be written but not read. I have read quite a few times where issues of reading/writing of share objects were resolved by prompting a request to increase local storage limit. This is where the flush() method takes it stand.

Immediately writes a locally persistent shared object to a local file.
AS3
flush(minDiskSpace:int = 0):String

minDiskSpace:int (default = 0) — The minimum disk space, in bytes, that must be allotted for this object.

AS2
flush([minDiskSpace:Number]):Object

minDiskSpace:Number [optional] – An integer specifying the number of bytes that must be allotted for this object. The default value is 0.

With AS3, the flush() method basically does the same thing as with AS2 including their parameters, the only difference made was their return values. AS3 returns a string constant but AS2 returns an object; still their purpose is the same, only the data types have changed.

var mySo:SharedObject = SharedObject.getLocal( 'mySaveName', localPath, secure  );
mySo.data.thingtoSave = myVariable; // your variables
/* stores data into disk and require 10kb of min space
 * if the allocated disk space for local storage is
 * less than 10bk which most probaly be 1kb, then it
 * would prompt a dialog box requesting for an increase
 */
var fushResult:Object = mySo.flush(10000);
trace( fushResult );

So saying simply, if you know your game’s shared object will be greater than a few kbs, you should consider using flush(minDiskSpace) with as your expect maximum size for your data. Why maximum? – think of it as your allowance. Now don’t even consider 2mb or more as an allowance if it’ll never even reach it, play your game at it’s fullest and see what is the size of the shared object using the getSize() method (as2) and the property size (as3) then add around 5-10% of it’s size for an allowance.

Conclusion

After all I have read about using SharedObject is as simple as it could be, in reality it can be a whole lot more than spinning circles for all of what you would need. Well yes, storing a string and recovering it is a piece of icing but storing a complete game state/progress is a new kind of cake to bake. Basically what I have written here are tips and suggestions that I have experienced and with what I have experimented. Either it be accurate or I know not, using SharedObjects has its own work around and is not as simple as most people have said like building a chair, while yes it is not the most complicated but it could be a big question mark on the head for someone new or not familiar to its purpose. I might even consider making a SaveManager or the like but that would be when I get to it. Well, that’s it, this one is quite long but I know it’ll help!

Other Keywords

• Working with Flash Actionscript Shared objects.
• Issues and techniques with Flash Actionscript shared objects.
• Saving data with action script using shared objects.
• Actionscript tips and tricks, shared objects.
• Shared object help, actionscript 2 & actionscript 3.
• Flash actionscript saving & loading locally.
• Flash Actionscript proper way of use when Shared Object does not work.

Some common but usually neglected things you might not want but your game might have:

• The everlasting suggestion of “avoid directly referencing _root“.
• Yellow boxes appear (on buttons/movieclips) when pressing Tab.
• Cheating by pressing Space when the yellow boxes focus on buttons/movieclips.
• Cheating by right clicking (shows the context menu, a cheat for some game genres).
• Cheating/altering game play/screens by pressing forward, back, etc from the context menu.

_root or no _root

_root ?

As you might have read a dozen or countless times, it is highly recommended to not directly call _root within the project, although using _root is not necessarily wrong. These developers come to use _root as a hack way of referencing an absolute path to their objects. If you are building an independent system, prototypes, does not consider expansion/addons and will never be a part of a larger system then it would be fine to use _root as a hacky way. But if your work is part of a larger system or the like consider having to add in various (most of the time, 3rd party) extensions, plugins, services, APIs (application programming interfaces), SDKs (software development kits), or anything similar in it’s purpose then you’ll be in for some serious headaches. Most notable of these are those that wrap your game within another swf file. You might be able to face serious issues and problems varying from sounds not playing/missing, disposition world objects, localtoGlobal/globaltoLocal miscalculations, undefined object property, sprites (movieclips) not following the expected position and behavior, wrongly positioned custom cursors and a lot more.

// somewhere in the timeline...
_root.mySuperFunction = function(){
  // doing some super things
  return 'my super function worked!';
}
 
// somewhere else in the game...
trace( _root.mySuperFunction() );
// before
  // outputs: my super  function worked!
// after some integration and browser testing...
  // outputs:         (its really has no output)
// nooooo!!! it isn't working now! but it used to work before,
// maybe this thing wrecks my game when I use it!? I didn't do anything else.

Although I won’t be discussing fixes for the issues mentioned above, we can start by doing what is recommended, to not directly reference from the _root. The most starter’s way from first look at the documentations and other sources, is using _lockroot. Basically it could prove to be a good way to fix and keep things the same but for some cases it might not be enough. For more assurance and better practice I would recommend referencing _root from a global variable or static variable from a class (most recommended).

Why do I have to use a variable? So what we reference can be dynamic – there are some cases where the _root is not technically the parent most, where it can be a specific game container or something similar, this way you don’t have to shift through using _root and updating all your codes when needed. And the sole reason is for code reusability.

// probably on frame1 before your preloader code
this._lockroot = true; // where this = root actually
this.mySuperFunction = function(){
  // doing some super things
  return 'my super function worked!';
}

// for those who do timeline coding or the like
_global.gameroot = this; // where this = root actually
 
// somewhere else through the game...
trace( _global.gameroot.mySuperFunction() ); // output: my super function worked!
// hoorah! its working well!

// and for those who use classes (highly recommended),
// simply pass it on your main class during instantiation
// to be referenced on a static variable
var maingame = new MainGame( this ); // where this = root actually
 
// on your MainGame class or the like
class MainGame{
  public static var GameRoot:MovieClip;
  // constructor
  public function MainGame( root:MovieClip) {
    GameRoot = root; // stores the root mc in static var
  }
}
 
// somewhere else through the game...
// now simply reference from static variable MainGame.GameRoot instead of _root
trace( MainGame.GameRoot.mySuperFunction() );  // output: my super function worked!

Magical Weirdness of Yellow Boxes

Yellow Box

Some games that incorporate interactive buttons (or movieclips that acts as buttons) are not wary of this feature. Basically flash has the ability to take use of tabbing on GUI, but since we are game developers there are high chances we would not want this as it might look ugly. While most games might not be affected by this feature there are certain circumstances that the game play can be cheated one way or another. Good examples are those games that use mouse interactivity using mouse over and mouse click events, where as the player can cheat things by combining tabbing, pressing space (to select) and the use of mouse. When a yellow box appears over a button its rollOver event is triggered, and when space is pressed its onPress event is, and that is where some cheating may occur on some combinations and timing. It is fairly a simple piece of code you have to declare at the beginning to disable all of the magical yellow boxes.

// probably on frame1 before your preloader code
this.tabEnabled = false; // disable tabs for the whole movieclip
this.tabChildren = false; // disables tabs for the rest movieclip's childrens

Right clicks and Context Menus

Which frame to move?

While the context menus from right clicks (control-click for Macs) on flash can’t be removed, we can modify the menus and also strip down unnecessary movie controls like forward, back, play, etc. If your game/project is AS2 powered and is not really well structured (timeline coding and uses gotoAndStop() methods ) then you might encounter glitches and frame skips once the player right clicks and select any movie controls. They could end up skipping levels to scoring indefinitely and would make things less fun and more cheating for them.

If all you want is to simplify the menu:

// probably on frame1 before your preloader code
Stage.showMenu = false;

But if you also would like to customize and add your own menus then:

// probably on frame1 before your preloader code
// instantiate a new contextmenu
var my_cm:ContextMenu = new ContextMenu();
my_cm.hideBuiltInItems(); // hides the built in items, duh
my_cm.customItems.push( new ContextMenuItem("(c) Jayc Santos", gotoJayc) ); // creates a new menu
function gotoJayc(obj, item){ getURL("http://jaycsantos.com/"); }
this.menu = my_cm; // overwrites the default menu and where this = _root (most of the time)

There are also some cases where simply right clicking would create issues for the game play and/or cheat things. A good way to determine is to use the onSelect event. You can also use the onSelect event for more customizations of your context menus (see livedocs sample).

var my_cm:ContextMenu = new ContextMenu();
function menuHandler(obj:Object, menu:ContextMenu) {
  trace( "right click context menu was invoked" );
  // do awesome things
}
my_cm.onSelect = menuHandler;
this.menu = my_cm;

Conclusion

So overall you might probably want to have something like:

// probably on frame1 before your preloader code
Stage.showMenu = false; // hides the built in items on context menu
this._lockroot = true; // locks the root, duh
this.tabEnabled = false; // disables tabs
this.tabChildren = false; // disables tabs for it's children

for timeline coders

_global.gameroot = this; // where this = root actually
//  when "this" is traced it ouputs "_level0" most of the time unless altered

and for those who use a little more OOP approach

var maingame = new MainGame( this ); // where this = root actually
 
// on your MainGame class or the like
class MainGame{
  public static var GameRoot:MovieClip;
  // constructor
  public function MainGame( root:MovieClip) {
    GameRoot = root; // stores the root mc in static var
  }
}

Now, your actionscript 2 coding life will be a little better with these in mind.

Other Keywords

• Starting flash with actionscript 2 (AS2).
• Frame 1 of actionscript 2 project/game.
• Preloader code actionscript 2 (AS2).
• Why to avoid or why not use _root/root with actionscript.
• Getting rid of yellow boxes when tabbed.
• Flash actionscript tabs.
• Flash actionscript context menus.
• Flash actionscript important points especially for games.

Plan your behavior

So I have introduced how to plan out simple AI behavior from my previous post – Cheating AI from Hardcourt – Plan it out – if you haven’t, read that one first before this.

Our next step would be writing the data charts into codes. It might look quite easy when you see the simple flow charts but remember that the AI must process this through out the game with a character’s lifespan.

What I’m about to share is simply a psuedo codish (partly actionscript syntax) of the AI’s logic. Eventually you can port it into which ever approach you are comfortable with, like OOP or the old school timeline.

Remember that this is my first published game where as I still used AS2 using prototypes and functions but I’ll discuss this in a little of close objective approach. First of we prepare a few world declarations & preparation in a quick manner.

Prepare the world

In the game world object or whichever the game’s entities reside, we’ll be having a calculateDistance method that pre-calculates distances of each of the characters then stores each of their enemies distance on an enemyDist container object.

// from the game world
 // called within the main loop
function calculateDistances() {
  // pre-calculate distances of:
  //   ball to char - store distance to the character's ballDist variable
  //   char to char - store all other character's (enemy's) distance to character's enemyDist container variable
}

The code below acts as base methods for all characters. This is primarily an advantage from inheritance whereas properties and methods of the base class is inherited by the class that extends it. Basically all the characters will be capable of methods such as moving (moveChar), getting the ball (getBall), shooting it (shoot) and punching their enemies (punch).

  // used to store the ball object also do determine if the we have the ball; set to null if we not
var myBall:Ball;
  // the distance of the ball from character in Vector2D (x, y)
var ballDist:Vector2D;
  // contains enemies distances
var enemyDist:Object;
  // assuming that 25 is the range where the character can punch it's enemies
var punchRange:Number = 25;
 
 // moves the character
function moveChar( xdir, ydir ) {
  //  xdir - move left (-1) or right (1)
  //  ydir - move up (-1) or down (1)
}
 
 // determines if we have the ball else if the ball is close & not owned (by enemy) then get it
function getBall():Object {
  //  use ballDist for the calculated distance;
  //  returns: ball object - if our char already has it
  // 	      null - if the ball is nowhere near
}
 
 // shoots the ball
function shoot() {
  // release the ball towards the ring
  // set myBall to null
}
 
 // attacks the enemy
 //  params: enemy:Object - the enemy instance to punch
function punch( enemy:BaseChar ):Boolean {
  //  returns: true - if successful hit
  //           false - else not
}

Note: for the Vector2D, some might be wondering what it is, well it is a class whose purpose is to calculate Vector operations in two dimensions.

Now we have prepared the initial methods, let’s go with the proposed coding of the flow charts.

Basic Behaviors

The AI controlled character behavior:

  // runs with the main loop for each AI character
function thinkAI(){
  var xdir = 0;
  var ydir = 0;
 
    // if we have the ball
  if ( getBall() ) {
      // then shoot it!!
    shoot();
    // if not
  }else {
      // get the direction of the ball
    xdir = ballDist.x ? ballDist.x / Math.abs( ballDist.x ) : 0;
    ydir = ballDist.y ? ballDist.y / Math.abs( ballDist.y ) : 0;
      // and move towards it
    moveChar( xdir, ydir );
  }
}

Basic Chart - Get & shoot

We used the method getBall() to determine if we have the ball or not, if so shoot it. Else, we get the distance from ballDist (which contains the distance in x & y values), have it’s polarity from it’s the absolute value and move towards it.

This is only the first chart (Basic Chart), our AI only considers that in the game world there is only the character himself and the ball, so whenever he gets the ball he shoots it immediately and repeats the process.

Expanding for more Interactions

What we do next is implement the second chart (Interactive Chart) and consider situations with the enemy and interact with it.

So improving the thinkAI() method:

function thinkAI() {
  var xdir = 0;
  var ydir = 0;
 
    // if we have the ball
  if ( getBall() ) {
      // then shoot it!!
    shoot();
    // if not,
  }else {
    var ball = GameWorld.ball;
    var dist:Vector2D;
      // check if another char has the ball, since definitely it isn't this char
    if ( ball.owner ) {
        // store the enemy who has the ball in a local var
      var targetEnemy = enemyDist[ ball.owner.id ];
        // this is the distance of the enemy char with respect to this char
      dist = targetEnemy.dist;
        // if this enemy is within punching range
      if ( dist.len < punchRange ) {
        punch( ball.owner );
          // no need to do the processes below...
        return;
      }
    } else {
      dist = ballDist;
    }
      // get the direction
    xdir = dist.x ? dist.x / Math.abs( dist.x ) : 0;
    ydir = dist.y ? dist.y / Math.abs( dist.y ) : 0;
      // and move towards it
    moveChar( xdir, ydir );
  }
}

Interactive Chart - Steal the ball

After determining that the ball is not in our character’s possession, we check if the ball is owned by another character. As it is owned, it certainly is not our character who has it as we already tested. So from the enemyDist container object (this has the pre-calculated distances of the character’s enemies) we get the enemies distance. See if the enemy is within stealing (ok, punching) range and punch if so, else move towards the enemy.

Now we have considered enemies too, if they have possession of the ball, our AI char simply goes after him and if he is within range we steal/punch.

Take note that when a character is punched he losses the ball so I also call punching stealing the ball.

Then we take this into the 2nd chart.

function thinkAI() {
  var xdir = 0;
  var ydir = 0;
 
    // if we have the ball
  if ( getBall() ) {
      // then shoot it!!
    shoot();
      // if not,
  } else {
    var ball = GameWorld.ball;
    var dist:Vector2D;
      // check if another char has the ball, since definitely it isn't this char
    if ( ball.owner ) {
        // store the enemy who has the ball in a local var
      var targetEnemy = enemyDist[ ball.owner.id ];
        // targetEnemy.dist is the distance of the enemy char with respect to this char
      dist = targetEnemy.dist;
        // if this enemy is within punching range
      if ( dist.len < punchRange ) {
        punch( ball.owner );
          // no need to do the processes below...
        return;
      }
    } else {
        // default the distance from the ball
      var dist = ballDist;
      var ds;
        // loop through enemies
      for ( c in enemyDist ) {
        ds = enemyDist[ c ].dist;
          // see if they are closer
        if ( ds.len < dist.len )
          dist = ds;
          // it seems that this enemy is already in range, no need to check the others
        if ( ds.len < punchRange )
          break;
      }
        // if this is not the ball distance then it could only be the enemy
      if ( dist != ballDist ) {
          // if this enemy is within punching range
        if ( dist.len < punchRange ) {
            // attack!!
          punch( ball.owner );
            // no need to do the processes below...
          return;
        }
      }
    }
      // get the direction
    xdir = dist.x ? dist.x / Math.abs( dist.x ) : 0;
    ydir = dist.y ? dist.y / Math.abs( dist.y ) : 0;
      // and move towards it
    moveChar( xdir, ydir );
  }
}

Interactive Chart 2 - Go offensive, attack!

What I added here is for our AI character to consider not only the ball itself and it’s possible owner, but also nearby enemies. Checking through all enemies and determining if they are close enough or within range, therefore stopping them with a punch.

You can also see clearly the advantage of pre-calculating the distances, as I used the enemy and ball distances enough to avoid recalculating them again and again when needed.

Now we have our competitive AI ready! Or not. Feeling like something is missing? Yes, its “difficulty!” Basically as you might have suspected that this AI behavior has the perfect reflex (well not so perfect really). It does what it has to depending on exact situations at the exact time on the next loop.

Example this:

Just at the same moment you grab the ball the enemy would instantly steal the ball or, simply saying, you can’t even run away, your character’s very change in position and angle is updated and read by the AI at the same time or yet exactly at the next frame therefore it knows where exactly you are same way the moment you move anywhere.

And another problem with the perfect reflex is same way we planned it, the moment the AI character grabs the ball he just shoots it at once.

For this problem, a good fix I did was based around with numbers. Yes, “numbers” will help with everything, you can imagine setting a level of intelligence for the AI and how much well it executes it’s task depends on the numbers assigned. But I’ll leave that to another post to discuss about it more…

What do you think? Play hardcourt now! to experience the AI in action.

v2 logo

I’ve had my current theme for more than half a year, and I’m currently working on the next version during leisure time. “But the current one is good, simple and plain” – Yes it is, but it lacks things that I didn’t knew yet when I first made this. Actually v1 is my first full WP template. So basically, the current theme (v1) doesn’t support wordpress widgets. Oh yes, widgets, also known as the “sidebar accessories” which are plugins that can be integrated into the sidebar.

So taking feature and content design into consideration, I decided to redesign my theme and catch up. And now presenting a sneak peak into the version changes. (also click on image below to enlarge)

v2 design

• I’ve redesigned the logo to be brighter and sharper.
• Kept the color scheme (I still like my colors) and some box styles yet made the design livelier.
• Sided with more personalized design than corporate look but still as sleek as it is.
• Widget support! And it’s not for sidebars only.
• More content/game/portfolio exposure.
• Maximized content width yet still support 1024×768 user screens.
• Removed the news section (from v1).

As of this post’s time, sliced it up into html/css then the next step is converting into a wordpress theme. Watch out, I’ll be uploading v2 in a week or three.

Hardcourt

Working with AI is a real pain, but I say, it most likely depends on what your game needs, what you want it to do. Most developers who are new would quickly ask the magical word “how?” or “how to start?”. If you haven’t had experience or good experience with AI patterns and behaviors, hear me out on how I did it with this game.

With my first game, Hardcourt, it was also my first time to encounter programming (or should I say cheating) artificial intelligence (AI). I myself didn’t have proper educational background with AI patterns and behaviors else haven’t even read anything about it when I made that game (I still had dial-up before, so no online tutorials too). With the first build of Hardcourt there were no AI so no playing with CPU, it was just a 2 player on a single PC game. After some time I decided to make it into a much complete game and had been finalized as it is now. I’ve had received good reviews with how the AI performs. It can totally beat the players up (esp with quick play, hard mode).

AI was the most troubling part as I thought; I didn’t even have an idea where to begin with. Now let me share a little knowledge on how I have dealt with this so called “artificial intelligence” and cheated my way through it. This shall be some multi-part discussion on the step by step methods when I dealt with them.

Note: Starting here, we reference the character AI (which is the CPU controlled enemies) as our player or the primary character; hence the human player will be referenced as the enemy. So don’t confuse yourselves.

Charts:

Flow charts were the first logical programming I had; it can clearly display your problem’s logic through proper data flow. So basically, what I wanted was the AI to do all the same things that a human can and would do (just the common and usual behaviors):

1. go after the ball
2. shoot
3. steal the ball
4. go offensive (attack)

… it does look simple, but where do we start?

Basic Behaviors

First thing to do is look for actions which least require external forces/object interaction but executes the aim of the game.

These steps are primarily available for those “race to finish” games where the primary aim is achieved without requiring going after opponents. This would be good for certain sports games, racing, who-is-faster, etc games. For hardcourt, since the game is basketball, the primary aim is to shoot into the hoops. So that would include going after the ball and shooting the ball.

Basic Chart - Get, move shoot

To explain the chart through words:

1. See if our character has the ball or not,
2. if not, get the ball and check again if the ball was acquired (»1)
3. else if yes, shoot the ball,
4. then check if the ball was acquired again (»1)

It’s actually a very simple loop but provides the main action required to fulfill the game’s primary purpose. Upon testing this basic behavior, the character shall go after & get the ball, shoot, do get the ball again and repeat the process.

Expanding for more Interactions

The next step is to consider the external factors. This is where the character considers the status or actions of another character. It can either be to support allies or to go after enemies depending of certain conditions.

Case: What if the enemy has possession of the ball? – Then steal the ball.

Interactive Chart - Steal the ball

From this case after knowing that the ball is not in the character’s possession we have to determine where the ball specifically is.

1. So the enemy has the ball:
2. if so, we have to steal it
3. else if not, we just go after and get the ball.
4. Either way we loop again with checking if we have the ball’s possession.

So basically we determine the ball’s condition, our character doesn’t just chase it, and he has to steal it if it’s in the enemy’s possession. In case you’re wondering why we did not consider getting the ball directly after stealing the ball is because there will chances that stealing the ball would simply fail and the enemy still has its possession.

Case: The enemy doesn’t have the ball and we don’t want the enemy to get a hold of it. – go offensive, attack!

On this next expansion, we decide to make our character more aggressive and attempt to stop the enemy to from gaining the ball.

Interactive Chart 2 - Go offensive, attack!

Now we made it clearer that for stealing the ball we attack the enemy. For this, before going after the ball, we determine if the enemy is closer than the ball is.

1. Check if enemy is closer than the ball,
2. if so, attack him
3. else if not, we go after ball first.
4. Either way we loop again with checking if we have the ball’s possession.

With this chart expansion, our AI now considers the enemy position compared to the ball’s position and determines which action to do. It might not be the wisest decision making but it would comprehend that fact that the enemy is offensive in a way.

Now our AI behavior chart is complete enough to be competitive… or at the least it does what it has to. We can even add some more like evading the enemy when taking a shot, even simply evading enemy attacks or other more complex actions/reactions from various events and circumstances. But with hardcourt, this is all that I would have needed. Although if you’ll consider more decision making for your AI with more specific situations, you’ll be making a better AI and might even be more intelligent than the human.

You want to see these behaviors in action? – analyze and see for yourself: play hardcourt now!

Cel-shading

I’ve introduce cel-shading – my personal preference on art style (and its currently the best I have ) – in a previous post Using Cel-shading. And now I have something to share on basically how to apply them in flat drawings using flash. This is based on my experience from how I started drawing it to how I do it these days.

With tools provided with flash we can achieve a cel-shaded effect in quite different ways and yet achieve similar (if not so the same) results. As for this, we’ll be using the rectangle tool, line tool and brush, but of course all with the help of the selection tool and paint bucket tool for our color fill needs.  Just remember the base rule, to have consistent light source when adding the shades.

Our sample character

I’ve prepared a hand drawn character where we will be applying shading. Now, don’t tell me that my drawing doesn’t look any good, it’s all that I can do. :-p

Rectangle Tool

First off the bat, is the rectangle tool. Why the rectangle, not the cirle? Hence the edge points will be needed to snap on other line’s edges. The rectangle tool is only good for simple shapes with not so much detail, so for this example I can only see the nose to be simple enough.

Nose - Simple shape 1. Start with a basic shape from your drawing where the shade would not be too complicated (so don’t choose the ears, unless your ears is all round and flat to begin with).	2. Select a skin color which is slightly darker to the skin color. Take note the darkness or lightness of the shade would depend on the imagined light intensity.	3. Using the rectangle tool, draw a small circle.
4. Make sure to enable snap to objects to connect points easier. Use the selection tool to drap the corner to it one of the border edges.	5. Continue dragging the corners to the borders. Then use the paint bucket tool to color fill the space created .	6. Drag the other sides to form a curve. This will be the shade for the nose curves.
7. Continue dragging the remaining sides and curve them to make the round nose appear more round.	8. Now from the point where both points meets (a corner) drag it to make a smooth curve.	9. And we have the shading for the nose.

Well it obviously took long enough just to have that shade using the rectangle tool which will prove that it isn’t that effective for this task.

Line Tool

So next we will be using the line tool. Now things would be much quicker to do hopefully compared to the above or maybe not, since we’ll be shading the whole face now (with the ears).

10. Using the line tool, create a line above the jaw then curve it a little. We will have connected lines instead of having just one so that we can have more control over the curves.	11. The reason we curved the line is so that we won’t hit the mouth lines. Now extend it just above the chin. Curve it to your liking and to follow the jaw lines.
12. Continue with creating lines and curve them to show how the face is (note: straight lines = flat faces).	13. Continue lining and curving until you close the line for the shaded part.
14. Since the ears are a little huge (okay, not little but really huge!), we won’t completely shade it. Create lines and curve them respective to how the ears are popped-out.	15. After lining and curving, we can simply use the paint bucket tool to fill the shade color.
16. When everything is looking okay (lines and curves are good enough), we have to delete all the lines (unless you’ll make them necessary).	17. And look now, we have our character shaded quite well.

Now that we have our character’s face shaded, the only thing left is the shirt.

Brush Tool

For this last one, we’ll be using the brush tool and expect this one to be the quickest of them all. Although the outcome might not be well straight and curved unlike from lines but who care anyway, we just want it to look better and do it fast. By the way I’m using my tablet but this shading can still be achieved by using a mouse.

18. With the Brush tool, we have to set the brush mode to Paint Selection.	19. Select the fill for the shirt using Selection tool.	20. With Brush mode set to Paint Selection, only the selected parts will be painted, so go on and brush the upper part of the shirt which is supposed to be shadowed from the character’s head and don’t worry about paint going off the selection, it won’t.
21. Then do the same for the part bellow the arms.	22. And also with the sleeves.	23. And do the same for the arm too. And we’re finished!

I supposed you would not like to use the rectangle tool, but I just wanted to share that since I once used it before. The line tool has it’s own purpose on certain circumstances that using the brush tool might be troubling.

Sample character with shading

So maybe now, you have an idea on how you’ll be able to cel-shade your drawings from my example here. Of course hand draw styles are not meant to be with perfect lines, curves and shades, it would all come to a matter of preference and personal style. Learning this drawing style might take a while for you to get used to but it will be well deserved when all comes to place after a lot of practice. Now, go! go! go and draw your toons…

Where are my display objects?

Before, the Stage class in AS2 is treated as a class whose properties are all static, but with AS3 the new and better Stage class is now a display object. Both making the stage class the main drawing area and where flash content is shown. Basically, just think of it as a practical stage, all actors and props are all objects on display and those who are backstage are objects which are simply not included in the stage yet.

The Stage is a singleton class whereas there can only be one instance of it (imagine watching a play where there are 2 or more stages, its just impossible). Even if you add multiple instances of display objects to the display list, the stage property of each display object still refers to the same Stage object (that goes for loaded SWF files too).

Did you know that the stage is not globally accessible – you can’t call it or reference it from anywhere (unless manually referenced in a variable of course). The simplest way to do so is to use the stage property from any of your display objects which were added to the display list.

Yes, you heard it right from “any” display object, but take note, only if it is already added to the display list. It doesn’t matter if your display object is a child of another display object or how far the display heirarchy it is, as long as it is included in the display list.

Don’t confuse yourself with “Stage” (with capital “S”) and “stage” (with small caps). “Stage” refers to the class flash.display.Stage and “stage” is it’s instance.

Just remember, from a common coding convention: classes begin with capital letters and variables don’t.

If the display object is removed or not yet added from the display list the stage property is just set to null.

Example:

Create a Square.as. The doStuff function just tries to see if the stage is available or not from its own scope.

package
{
    import flash.display.Sprite;
    import flash.display.Graphics;
 
    public class Square extends Sprite
    {
        public function Square()
        {
            // just some drawing
            graphics.lineStyle( 2, 0x666666 );
            graphics.drawCircle( 0, 0, 48 );
            x = 100;
            y = 100;
        }
        public function doStuff()
        {
            if( stage != null ) // if stage is available
            {
                trace( 'I see the stage! '+ stage );
            }
            else // stage is not available
            {
                trace( 'I am not on stage... :( ' );
            }
        }
    }
}

Now create MyStage.as and a new Flash File (actioscript 3.0) then set MyStage as your Document class (just on your properties panel).

package
{
    import flash.display.MovieClip;
 
    public class MyStage extends MovieClip
    {
 
        public function MyStage(){
 
            var square:Square = new Square(); // instanciate a Square
            square.doStuff();
 
            addChild( square ); // add the square instance into display list
            square.doStuff();
        }
 
    }
}

When you test your movie the output panel should display something like:

I am not on stage... :(
I see the stage! [object Stage]

Neat Trick: code snippet

So based on this you can have a neat little trick to determine if your display objects are on stage and added to the display list.

        public function isDisplayed():Boolean
        {
            return Boolean( stage != null );
        }

I hope you understand a little bit more with using display objects and the stage from what I have shared.

Other Keywords

• Working with Actionscript 3 Stage.
• Knowing Flash Actionscript 3 Stage.
• Stage & stage difference in actionscript 3.
• Proper use of Flash Actionscript 3 Stage.