Scrolling shooter help

[spider dude]

I'm making a basis side scrolling shooter game for my multimedia class and I just need a bit of help with some code.
At the moment when you hold down 'control' you shoot lazers non-stop. I want to be able have a pause between each time I fire without having to make it 'on (release)'.
If someone could enlighten me that would be awesome!

Cheers

[Freddy]

Couldn't you just make a counter for it.


if CONTROL is down
if RateOfFire is 5
shoot lasers
RateOfFire = 0
if not
RateOfFire +1

something like that maybe?

[truimagz]

honestly, I am sure your teacher is being payed quite well to teach your class, and I personally would feel much better if you asked that person.

We are definetly here to help but I personally dont do others homework.

good luck to you.

[Lui]

I'll do your homework for you! If this code works, that is >_>
Exactly like what Freddy said,


This code is for actual delay (even if you hold control)
NOTE: This is code is to be put on the actual frame, so I'm leaving it up to you to implement your code into this.

//If your fps is set to 12f/s then theres a two second delay between
//shots, just adjust it however way you please.

shotTimer = 24
shot = false;

onEnterFrame = function(){
if(Key.isDown(Key.CONTROL) && shot == false){
shot = true;
//insert shoot function here
trace ("SHOOT!");
}
if (shot == true){
shotTimer--;
}
if (shotTimer <= 0){
shot = false;
shotTimer = 24;
}
}
(Editing with next code)

This code is basically just tapping your CTRL button - no delay.

shot = false;

onEnterFrame = function(){
if(Key.isDown(Key.CONTROL) && shot == false){
shot = true;
trace ("SHOOT!");
//insert shoot function here
}
if (Key.isDown(Key.CONTROL) == false){
shot = false;
}


Tell me if anything is wrong.
YES! I BEAT MATT FROM POSTING A CODE!

[Logic]

Instead of using onEnterFrame, use a key listener. If that's too complicated, just look up the Button.onKeyDown and Button.onKeyUp methods. They should both let you solve your problem, and I would recommend the onKeyUp method.

[Lui]

You talking to me?

[Logic]

No, I'm addressing the general abuse of the onEnterFrame method. Much more specific methods exist specifically for handling key presses within the core Flash API. I recommend using key listeners for listening for keys before I recommend using frame listeners for listening for keys. Seems simple.

I'll edit my post anyway now that I've re-read it - sorry to seem insulting. My bad.

[Lui]

No problem.
Just remember that there are different ways to do something, I just pointed out one way.

[Freddy]

No, I'm addressing the general abuse of the onEnterFrame method. Much more specific methods exist specifically for handling key presses within the core Flash API. I recommend using key listeners for listening for keys before I recommend using frame listeners for listening for keys. Seems simple.

I'll edit my post anyway now that I've re-read it - sorry to seem insulting. My bad.

Seeing as I don't know how to use other types of listeners myself, I'm going to take this opportunity to make a request to you for the public...and me.

Explain to us some of the listeners or whatever that we can use and what they're for and how we could use it.
It would be for the greater good of the Flash Dev Forum and would reduce the amount of questions in that area of actionscript help.
=]

[Jonanin]

Listeners are what the name says -- they listen for certain events to happen.
Here is a short and sweet example of listening for a key to be pressed.
var myListener:Object = new Object();

// when a key is pressed, this function is called
myListener.onKeyDown = function() {
trace("HOLY #### A KEY WAS PRESSED OMGG!");
}

Key.addListener(myListener);

[magcius]

this.addListener? I think you want Key.addListener.

[Logic]

There are many kinds of listeners, but the easiest ones to use (and most commmonly implemented) are key listeners. All listeners are set up using the same structure in ActionScript 2 because there are no specific listener types; you must use the Object type. Here is the rough outline of attaching a listener to your Flash:

var myListener:Object = new Object();
// create the listener object

myListener.onEvent = listenerFunction;
// when some event "onEvent" occurs, execute the "listenerFunction" function

this.addListener(myListener);
// let the listener start to listen for the indicated event "onEvent"

A common usage is to remove the overhead of using an onEnterFrame listener to always listen for key presses. Instead, you can use something more opportune like:

// create an listeners
var keyListener:Object = new Object();

// assign the listener to an event
// DO NOT ADD PARENTHESES LIKE SHOWN HERE: onKeyDown = handlePress();
keyListener.onKeyDown = handlePress;

// attach the listener to the stage
Key.addListener(keyListener);

// define the handlePress() handler function
function handlePress()
{
// visual indication of event occurring
trace("Hey, a key was pressed");

// more specifically, the key's code was...
trace(Key.getCode());

// if you want WADS controls...
var code:Number = Key.getCode();

// A button or Left arrow key down
if (code == 65 || code == 37)
{
}

// W button or Up arrow key down
if (code == 87 || code == 38)
{
}

// D button or Right arrow key down
if (code == 68 || code == 39)
{
}

// S button or Down arrow key down
if (code == 83 || code == 40)
{
}
}

[Jonanin]

this.addListener? I think you want Key.addListener.

What? What are you talking about?! I did use Key.addListener!

(shhh)

[Freddy]

Neat. Going to have to try this out.
But why would I go through the trouble of all this when I already use the onEnterFrame for something else.

Does it put less strain on computer or something? Or help with later programming down the line?

[Logic]

Think about it this way - the onEnterFrame event fires every frame. All of its code evaluates every frame. Why bother checking for something every frame when you can just use a listener to detect exactly when the event occurs? Also, consider if your Flash content is not meant to be run at a high FPS, like a slideshow or other multimedia application. Would you still use an onEnterFrame listener if the frame rate was something like 6 FPS? Or would you use a Mouse listener and a Key listener?

In ActionScript 3, you lose the ability to be able to use onEnterFrame to check for key presses as well. It forces you to correctly use listeners. Considering how complicated most coding is for moving a movieclip based on user input, having the code evaluate only when necessary can have huge performance gains for other aspects of the game. I know I like to do something akin to this in my ActionScript 3 programming:

- when the player is not moving (no keyboard input), set the quality to HIGH unless some complex animation is occurring. Otherwise, set it to a lower setting using an FPS detection class.

- when the player is moving, lower the quality of the Flash appropriately for the best visuals and performance. With a lot of action occurring on-screen, the player won't notice the minor decrease in quality and won't experience a decrease in performance.

Listeners let you optimize your game and often achieve better performance than onEnterFrame events allow. Consider if you have a custom cursor for your game (annoying as hell but some people use them) - would you want to update it every frame OR as often as the mouse moves? Clearly as often as the mouse moves to eliminate lag from frame rates. So instead of:

listener.onEnterFrame = mouseUpdate;

you would smartly use:

listener.onMouseMove = mouseUpdate;

Starting to understand?

[magcius]

Also, just to let you know, you do not have to have a "listener object."

By default, all MovieClips are registered to both Key and Mouse, so they can receive onKeyDown, onKeyUp, onMouseDown, onMouseUp, and onMouseMove events.

[Logic]

Core concepts of ActionScript 2 and 3 dictate that you should centralize and simplify your coding. Creating independent listeners for all instances/MovieClips goes against both of these concepts. It can be likened to adding "on (event)" statements to every instance.

[magcius]

So you are against listener functions directly on the movieclip, or not? That thought was unclear.

[Logic]

Against. Create one listener object for each kind of listening (key press, key release, mouse move, mouse click, mouse release, etc) as needed. Don't map one to each instance as it makes for messy code that is hard to debug.

[magcius]

....

That's against the core philosophy of programming.
When you make a class, you don't make a MouseListener class, you make a Player class that handles all the things that a player does. Need a mushroom? Don't make a mushroom part of the Stage class, make a Mushroom class! It's how everyone does it......

[Logic]

We have a conflict of the same concept. I always extract my handlers into core classes which I can easily update. You embed them within the classes which you can just as easily update. We both do the same thing, just differently.

####ing OOP. >_>

[truimagz]

I think what is being stated here, and is getting off track from, is that the OP should be using a key listener to listen for key presses instead of an onenterframe.

Although they can both be deleted and restarted when needed, the onenterframe is much more cpu intensive.

[arkhan]

ok..now we got a conflict..who is going to handle the speed tests to see whats the best way to do it?

[Matt]

Think about it this way - the onEnterFrame event fires every frame. All of its code evaluates every frame. Why bother checking for something every frame when you can just use a listener to detect exactly when the event occurs?
Damn! That'd fix ANY lag problem there'd be. So THAT's how they do it.
Thanks.

edit: But... How the hell would you go about using it to check for multiple hitests at once such as the for loop can do? If it can't always run the code it wont beable to hittest them all... I'm rather confused.

edit: I've been doing some tests using it and it seems rather slow on response end. Maybe that's just me but there's always a delay.

[magcius]

this.onKeyDown = function ( ) {
trace ( Key.getCode ( ) );
};


That should not have any lag at all, even when the document's frame rate is ridiculously low, like 1 or 2 fps.

[Matt]

this.onKeyDown = function ( ) {
trace ( Key.getCode ( ) );
};
That should not have any lag at all, even when the document's frame rate is ridiculously low, like 1 or 2 fps.
I did movement with it. And changing directions did lag. It wasn't instant.

[Soon to be flash master]

honestly, I am sure your teacher is being payed quite well to teach your class, and I personally would feel much better if you asked that person.

We are definetly here to help but I personally dont do others homework.

good luck to you.

I'm in the same class as him, with the same teacher. He is an art teacher, he can paint and draw but he doesnt really know anything about flash and scripting.

[magcius]

It won't redraw the screen until the next frame is there.

[truimagz]

also using listeners for movement isnt always a great idea, you wont get the same response from an enterframe.

The bottom line, is that you need to explore all possibilities before aproaching any project.

and Ideally your game will consist of only one enterframe, and everything that needs to be ran each frasme gets despatched to it, and then removed when not needed.

When I wrote my rpg engine, I was very constious of all of this during development, this is why I can run it at 1680x1050 and have multiple enemies and spells going off at once without lag.

I believe that my rpg engine at idle, meaning no player movement, the only things being looped through are the keypresses, I always put my keypresses inside my game loop for faster response.

hmmm....... maybie I'll post some code snippets to try and explain further

[Matt]

Well I'm interested.