Thursday, January 22, 2015

Main.as or Document Class (AS3) Part 2

As promised we're going to go over keyboard inputs now.

The point behind the Document Class (DC) is to basically control everything that goes on in your game/program/whatever.  Unless you have a mouse-only game you will always need the keyboard.  As the keyboard is static in the sense that it's always the same you can go ahead and use the same setup for every program.  The work is long and boring initially, but you only have to do it once, so it's worth it.

1.  Set up your variables.

public var kLeft:Boolean;//37
public var kRight:Boolean;//39
public var kUp:Boolean;//38
public var kDown:Boolean;//40

I'm only doing these for as an example.  You can add all the keys if you wish.  We set these Booleans up because we only care if a key is pressed down or not.  We don't care what the functionality is.  That can be handled in the other Classes, not our Main.as.

2.  Call the keyboardEvent listeners.

 stage.addEventListener(KeyboardEvent.KEY_DOWN, keysDown, false, 0, true);
 stage.addEventListener(KeyboardEvent.KEY_UP, keysUp, false, 0, true);

This calls to see if a key is pressed down or is released up.  Make sure you add that "stage." beforehand as it won't work otherwise.

3.  Handle key presses.

 public function keysDown(ke:KeyboardEvent) : void
 {
  if(ke.keyCode == 37)
  {
   kLeft = true;
  }
 
  if(ke.keyCode == 39)
  {
   kRight = true;
  }
  
  if(ke.keyCode == 38)
  {
   kUp = true;
  }
  
  if(ke.keyCode == 40)
  {
   kDown = true;
  }
 }
 
 public function keysUp(ke:KeyboardEvent) : void
 {
  if(ke.keyCode == 37)
  {
   kLeft = false;
  }
  
  if(ke.keyCode == 39)
  {
   kRight = false;
  }
  
  if(ke.keyCode == 38)
  {
   kUp = false;
  }
  
  if(ke.keyCode == 40)
  {
   kDown = false;
  }
 }

What is this sorcery?!  Well it's quite simple, actually.  From the previous step we call constantly to see if a key is pressed or released.  When it's pressed we check the keyboard input (ke) and check it against whichever key want want to process (keycode == "n").  Don't know the keycode number?  No problem.  You can check the Interwebs with a Google search or just go here:  http://www.dakmm.com/?p=272.  Don't worry, I'm not affiliated with them.  I just have that bookmarked.  You can also do the arduous task of finding the keycodes yourself by simply tracing out the keycode in the keysDown to look something like this:

 public function keysDown(ke:KeyboardEvent) : void
 {
  trace(ke.keyCode);
 }

Now, when you run the program you can just press a key and it should trace out what keycode it corresponds to.

So in the keysDown function we set the corresponding Boolean to true, so if we press the down arrow then kDown is true.  And in the keysUp function we do the reverse, so if we release the down arrow, kDown is false.

Now because we already setup the whole Main.instance thingy from the last part we can access the key presses from anywhere.

3.  As an example, let's say we created a Hero.as Class which of course allows us to use a Hero.  We could create an update function that constantly checks to see which keys are being pressed.  Here's the whole sheband:

package  
{
/*
 An Amazing Coding Product of Benjamin Floyd
 
 If you got this, even by trickery, feel free to use it.
 
 A tip-o-the-hat would be nice though.
*/

import flash.events.Event;
import flash.display.MovieClip;

public class Hero extends MovieClip
{
 public function Hero() 
 {
  addEventListener(Event.ADDED_TO_STAGE, init, false, 0, true);
 }

 public function init(e:Event = null) : void
 {
  removeEventListener(Event.ADDED_TO_STAGE, init);

  addEventListener(Event.ENTER_FRAME, update, false, 0, true);
 }
 
 public function update(e:Event = null) : void
 {
  if(Main.instance.kLeft)
  {
   x -= 1;
  }
  else if(Main.instance.kRight)
  {
   x += 1;
  }
  
  if(Main.instance.kUp)
   {
   y -= 1;
  }
  else if(Main.instance.kDown)
  {
   y += 1;
  }
 }
}
}

If you run it as is, then you can move your little Hero all along the place.

And that's it.  All you had to do was see if a key was  pressed and you could add any functionality you wanted to go along with it.

4.  Of course writing out Main.instance every single time you want to access the DC is stupid and annoying so you can simply add a variable to replace all that typing like so:

 public var ROOT:Object;

Now, we need to make sure the ROOT is initialized so in our init function place the following:
   
 ROOT = Main.instance;

Now anywhere you have "Main.instance." just replace it with "ROOT." and you can easily access your DC.

That's pretty awesome, right?

Well, thanks for reading.  I hope you learned something from it.  Join me next time when I talk about some other stuff in regards to programming in ActionScript 3.0!

You have to update before you update.  Thanks, Windows.
Here's a screenshot I took last night.  Steam has been crashing my computer when it tries to load so I looked up why.  It said to make sure Windows is up to date.  So I went to update and realized I hadn't updated since the last time I was using this blog, about 1.5 years ago (in case you're wondering I don't update because my computer will almost always crash after an update; I have real good luck that way).  Anyway, I thought this was funny and wanted to share.

Wednesday, January 21, 2015

Main.as or Document Class (AS3) Part 1

Something that I've found to be vitally important in writing ActionScript 3 is accessing the Document Class from other classes and packages.  And the beauty is that once you make your Main.as you will need only a bit of time to adapt it for your other projects.

Keep in mind that my Main.as is constantly changing, mostly because I keep thinking of stuff to add that I know I'll always need.

Here's a bit of code to start us off:

public class Main extends Sprite 
{
 public static var instance:Object;
 public function Main() 
 {
  addEventListener(Event.ADDED_TO_STAGE, init, false, 0, true);
 }
 public function init(e:Event = null) : void
 {
  removeEventListener(Event.ADDED_TO_STAGE, init);
   
  instance = this;
 }
}

So what does this mean and do?

My understanding is that this is called a Simpleton (after re-reading I realized it's Singleton, but I left that in because it's funny). But whether or not that's correct, what this does is allows us access to the Main.as at all times from anywhere in the program.  Of course with what we have written so far, this doesn't mean much, so let's add some important info that would need to be accessed in most, if not all, Classes:


 public const SW:int = 512;
 public const SH:int = 288;
  
 public const SWH:int = SW / 2;
 public const SHH:int = SH / 2;
  
 public var TS:int = 16;
 public var TSH:Number = TS / 2;


In this section we have the stage width (SW) stage height (SH) and half of both of those (SWH/SHH). These are the dimensions of the screen and it makes it a lot easier to access than typing in:

        stage.stageWidth

We also have in there the tile size (TS) and half of the tile size (TSH). Because TS is set to 16 and our stage dimensions are 512 x 288 we have a 16:9 screen ratio to work in.

Do you understand yet why this Main.as is important?  Here's an example:

I have a plumber who has to check collisions with the environment.  In order to do so I need to find out if he's going to collide with a Block or if he's just falling through air.  In order to find out if he's hitting said Block I need to know where the nearest Block is.  Since the map has already been laid out (in this example it has, we'll get to that for real later) we know that all tiles are lined up by the TS that we have established in our Main.as.  So from the plumber's Class we can access Main.instance.TS to find out if the plumber bashes his head on a Block or just goes through air.

If this makes sense to you, you might be wondering why you don't just put in "16" instead of calling out to Main.as.  If it's a simple program, you're right, there's probably not much reason to do this.  But let's say you wanted one level where everything was giant except the plumber.  You could then easily change Main.TS to 64.  You wouldn't have to go back in to the plumber Class or the enemy Class or whatever other class needs to know the tile size to change it all.  You have to type in one number on one Class to change the way the plumber will interact with the level.  That's pretty cool, right?

Well, that's it for now.  I hope you enjoyed this little insight into what I'm learning and doing.  Next time I'll talk some more about the Document Class and how setting up the keyboard controls in Main.as makes life much easier down the road.

Here's a picture to go along with all these boring words:

http://www.gigs4gags.com/funny-programming/

Tuesday, January 20, 2015

Necro Blog

Hmm.  It's been a long time friend of mine.  If we were to go by the numbers according to years it's been 2 years since I last did anything website/blog related.  In actual time it's been 1 year and 4 months.  It's not too late to revive this blog.  As long as I'm alive, it's never too late.

Lately, I've been creating a Tile-Based 2D Engine in Flash, or more accurately with ActionScript 3.0.  I've created multiple variations because I just don't know what to do.  I'm getting better, my code is getting smaller, and I'm learning the value of Object Oriented Programming (OOP).

I started writing a tutorial and only wrote it as I programmed it, because I know most tutorials have so many errors that it never compiles.  But I got too carried away and stopped writing the tutorial and only wrote code.

I started to implement the engine into an actual game, but my focus kept shifting.  Did I want to do a Mario-like platformer or a Zelda-like top-ish down game?  Both, I found.  And the code is similar up to a certain point.  When it got to that certain point I realized that if I knew how to make things OOP then I wouldn't have to write all this code again.  So I went back and refactored the crap out of everything.

So I'm at a crossroads of sorts.  I got my engine up and running for a Zelda-like to the point that I have tile-based collisions with the map and some other Maths based collisions with everything else.  It's incredibly awesome.  I feel incredibly awesome for having written it without the need for a tutorial to look up (I've written it so many damn times I should know it by heart).  But where do I go from here?

I thought about writing a full tutorial of what I've done.  But my goal is not necessarily to be a teacher, but to make games.  So, while writing this blog, I've decided to finish a game.  I don't know when it'll be done.  I don't know if it will be good.  But I know that I will finish it.  It's not a New Year's Resolution or some such as I don't know anyone who has ever kept one.  This is a promise to myself and a promise to my wife who has been very tolerant of my lax attitude about pursing my dream.  This game will be finished by the end of April if not sooner.  I have a plan for it.

The first step is to basically turn this into a devblog.  I'll be sharing what I think is awesome as well as just providing some insights that I've gleaned in my foray into programming.

Peace out and here's hoping to a productive gaming year!




Just because pictures are awesome and I mentioned Mario earlier on, here's a really cool picture.  I don't know the source (and I saved it so long ago I don't remember where I got it) so if anyone knows the creator send me a line so I can give proper credit.