Tuesday, December 09, 2008

Flash Tutorial: Part 5 of 21

Classes

Today we're going to talk about classes. Don't worry, we're still talking about Flash... and while you can program Flash like you do C++, we won't, and instead we'll use "class" as something we make up. So what's our definition of class?

Well of course it's similar to a C++ class. A class is a group of functions and methods and properties that are common and often used when dealing with a specific subject. So for example, we could have a Particle Class, Enemy Class, Item Class, and so on. Then the specifics of that class (a specific enemy for example) will "kinda" inherit these methods from the class. But we we're not going to deal with inheritance, and we will kinda define a constructor but you don't have to look at it that way.

We're going to make this lesson pretty brief... actually, what I mean to say is, I'm not going to write a lot, and a lot of the lesson will be you trying out different things, and reading code to see if you can understand it.

Today we're going to cover the Particle Class in detail, and then a little bit about the Enemy Class and the Item Class.

Particle Class

What is a particle? A particle is a piece of graphic that is made, and then it usually travels in some direction, and then it dies. So it could be a fireball, or a rocket, a glitter, an explosion, and more. So to figure out what the Particle Class should look like, we need to figure out what a particle generally does.

All or most particles are created dynamically; most of them travel in a direction; and most of them die. Some of them might change colours, or accelerate, or rotate along their path, or create other particles, or attempt to hit the player or enemies.

So particles have this kind of life cycle:
(0 - initialize)
1 - come to life
2 - live
3 - die
And sometimes, it has death animation, so it might have
4 - death animation
5 - die for real

Perhaps there's also birth animation, but we won't deal with it now. If you really want, you can do that later.

Once again, like we did on the first lesson, we'll use less-efficient methods right now. I might not even teach you the more efficient method.

Anyways, you should already have a particle. You know which one? That's right, the bullet. The bullet is a particle. Make a copy of the bullet movieclip in your library, and call it "particle_class".

The bullet is a good start. On the first frame, it probably already has something like

var xSpeed;
var ySpeed;

And on the second frame you have something like

stop();

this.onEnterFrame = function()
{
        _x+=xSpeed;
        _y+=ySpeed;
        //(and then you have some boundary conditions)
}

And you already have a constructor, or the thing that "constructs" it: the CreateBullet function.

So first, you want to be able to make particles... so copy the CreateBullet function, and call it createParticle, or whatever you like. Give the proper linkage to the particle_class object. Also, in the function, include parameters about the origin of the particle, because it's unlikely that all particles will be things that come out of your body.

Now, remove the boundary condition, or cut and paste it into a temporary place, because chances are, the boundary condition wouldn't be used in all particles.

Okay... so let's do this and test this in steps. For now, we'll make particles when we make bullets, so instead of calling CreateBullet, call CreateParticle. Remember to update parameters as necessary.

Test 1: Test to make sure it still works. It won't have the boundary conditions, but the rest should be okay.

Now, if you already changed your player to have that "graphic" movieclip, the next step shouldn't be too hard. You want to make it so that when you fire a bullet, it will randomly fire either a blue bullet or a red bullet. They will both behave the same way, except one is blue and one is red.

Here's the code I want you to put in, and if you remember your previous lessons, you'll be able to apply it quite easily.

var particleType = 1+random(2);

newbie tip: random(2) will choose a random integer, either 0 or 1. random(1) will always return 0, I think random(0) also returns 0, and so on. So in this case, particleType will receive a value of either 1 or 2.

this variable can be anywhere.. ideally, in the end, this will be a variable you pass into the CreateParticle function.

On Frame 1 of the particle, you'll want another variable... if you want. Something like

var particleType;

In your particle class, move the onEnterFrame frame to frame 3, and on frame 2, you'll need something like

graphic.gotoAndStop(particleType);

Test 2: Try it now. If done properly, you'll get the desired result of randomly shooting red bullets and randomly shooting blue bullets.

Now, go into the graphic of your particle, and you should have 2 frames. Make a new layer, and put actionscript in each of the two frames:

function EveryFrame()
{        trace("whee");
}

Actually, for one frame, put trace("whee");
and in the other frame, put trace("homunculus");

And... can you predict the next step?




In your particle, in your onEnterFrame, alter it so it looks something like

_x+=xSpeed;
_y+=ySpeed;
graphic.EveryFrame();

Test 3: Run the program. If done right... well, you should know by now what it means.

Change the everyframe's to something more practical. NOTE this:

function EveryFrame()
{        _parent._y++;
}

You have to use _parent, or else you're just modifying the graphic, and not the actual position of the particle.

And thus, if you want you can get back the boundary condition:

function EveryFrame()
{        if (_parent._x > 640)
        {        removeMovieClip(_parent);
        }
//and so on
}

protip: I recommend keeping certain particles separate from the particle class, including bullets. If you have enemies checking for bullets the way I have it, you'd rather have the enemy check for 1-10 bullets rather than 1-200 particles. But for now, keep it so that when you press Space, a particle appears rather than a bullet.

protip 2: For testing purposes, feel free to add more frames wherever necessary in the particle class. Later when you want to make it functionally better and also look better, you can change things around.

Challenge 1: Make a new particle that's like an explosion... you can do this in several ways, but I want a circular, yellowish-orange object that grows bigger and fades, and then disappears.

Challenge 2: Make it so that when you fire a red bullet, an explosion appears by the bullet. Do not modify moveTimer or globalcode for this. You may need to use Protip 2 above, as well as make a new function.

Challenge 3: This is probably easier than Challenge 2, but make it so that when you fire a blue bullet, it leaves a trail of explosions. Also, for the blue bullet, make sure it has a death condition so you can get rid of it.

protip 3: For particles, I usually have the x,y spot in the center of the particle, rather than the top left as I do with most of my other objects. Generally, if an object rotates, it's easier if the x,y is in the center.

protip 4: One of the things that keep the game from massively slowing down is the proper removal of movieclips, or in this case, particles. Make sure objects remove themselves properly. If you experience massive slowdown, one cause might be improper movieclip removal.

Challenge 4: If you got Challenge 2, you can probably do this one. Make it when the red bullet dies, it creates an explosion where the bullet is.

http://www.baomon.com/blog/particle_sample_0004.swf

This was a sample project I put together that shows how my particle class works. Note it has many more variables than your particle class.

particle_tutorial_flash8.fla

Here is the FLA - it should be openable in whatever flash you have. Note that if you run it, you'll probably get some errors, but you can see most of the programming - check the globalcode, and check the particle_class.

Enemy Class

enemy_tutorial_flash8.fla

This is an example of the enemy class that I'm using in my current game. Note if you run the program, nothing should happen, but you should still try to understand what the code does. I omitted one enemy, that guy from MM3 that throws the ball and you can only hit him when his eye is open, because his code is somewhat unique and different. For a basic lesson, having additional code for one enemy could be confusing.

That said, this enemy class is a good starting point but it might not be good enough for your game - maybe you have a lot of guys that are "different" like the green MM3 guy.

Note how the "extra" variables are dealt with in this Enemy Class as opposed to the Particle Class. Part of it is personal preference, part of it is how enemies are coded into the game as opposed to particles.

Item Class

Challenge: Create an item class.

What's an item? An item is an object your player can get, like a piece of food to recover health, or a gold piece to add to your inventory. What it does is it is put on the map (usually programmed by the programmer, or have an enemy drop it), and it stays there and waits to be touched by the player. Some items disappear after some time of nothing happening.

Challenge 2: Have it so that when the game starts and you start moving around, 3 different items appear on the map, each of which do something different.

Brain Logic Challenge Time

Here are a series of challenges that will help you learn some concepts and useful things in programming. After this Brain Logic Challenge, you'll learn something useful. It might be frustrating while you try to learn it, but afterwards you'll feel good and you'll have something useful.

Final Challenge Result: Create a game where you have a turret, and you can move the mouse around, and then when you press space, a bullet will fly out of the turret and travel toward the mouse cursor.

Task 1: Make a new project. Put a dot at 200,200 and call it "turret". Put another dot at 400,300 and call it "enemy". Make it so that when you run the project, it will trace("the project is running");

Challenge 1: Make it trace the x distance between the two objects.
Challenge 2: Make it trace the y distance between the two objects.
Challenge 3: Make it trace the diagonal distance between the two objects. Positive or negative, doesn't matter.

Task 2: Make a button, click on it, and open up the actionscript window. Note that this window is different than the timeline actionscript. Type this:

NOTE: when you edit the button below, the autocode will help you out. I can't put "left-arrow SPACE right-arrow" in html so I can't write it. You can do it yourself.

on (keyPress "")
{        trace("space is being pressed");
}

Run the project, and hope it works.

Task 3: Move the code into the button, so that when you press Space, all that trace happens.

Task 4: Instead of using the enemy, we're going to use the mouse now. So references to the enemy's x and y are now replaced with

_root._xmouse
and
_root._ymouse

protip: In your actual game, you might use _root.main._xmouse, or whatever.

Test the project. Move the mouse around, and hope it works.

Task 5: Put a nose on your turret.

Challenge 4: Make it so when you press Space, the turret rotates so that it points to your mouse cursor.

This challenge might be tough, or easy. You may need Math.Sin, Math.Cos, Math.PI, and if statements. Also I hope you remember how to convert from radians to degrees.

Challenge 5: Make it so that when you press Space, a bullet is created and it travels toward the mouse cursor, at 12 pixels per frame.

And you're done!

And now you know so much about Flash.

In the lessons to come: Arrays, more about user inputs, color, preloader, user interface, a little bit about sounds and graphics, and artists

0 Comments:

Post a Comment

<< Home