next »

[William Broom]

Also, I was able to get a little Grace Period going after I spawn the ship back in, but there's no visual indicator.  I suppose that (pardon my non-code language):

Code:

if grace exists, create a blinking ship on top of regular ship's current location;

and I can certainly manage that, provided "blinking" means it is flashing to a visible color--if I make it go transparent, you'll still see the solid ship underneath and the effect would be invisible!  It might be cooler to do it as a visible color, but then I won't have learned anything!  I want to make it blink the traditional way, with the ship flashing transparent briefly.  How can we accomplish this? 

I suspect once we know how to do that, it wouldn't be hard to modify it to add animations for other events, like tilting the ship as it moves up and down?

Ummm... can't you just change the sprite index?

[sandcrab]

That sounds wonderful, but please tell me how? 

[Derek]

If you give the ship a Draw Event, you can make it blink easily:

Code: (Draw Event)

if (blinkCount > 0) blinkCount -= 1;
else
{
   blink = not blink;
   blinkCount = 2;
}

if (blink)
{
    draw_sprite(sprite_index, image_index, x, y);
}

When objects have Draw Events, they don't draw automatically.  You have to call draw_sprite, or nothing will appear.

[___]

I think its draw_sprite(sprite_index, image_index, x, y)

[sandcrab]

Phew, that seems to be it, I was kinda driving myself crazy trying to figure out how to make "sprite_draw" do anything.    Is it possible to tell it to draw more than one "subimg" to make something animate?  If that were the case, I could easily create any number of animations by piecing together sprites out of oPlayerShip in different sequences (including a blinking one using a blank frame), but I have a feeling it's not going to be that simple?

Anyway, draw_sprite is working but that Boolean business is totally losing me.  What is happening there, and what variables do I need to define to make it work?

[Derek]

Whoops, sorry - aside from the draw_sprite mix-up, I also forgot to set "blinkCount = 2;" in that else statement.  That should work, I tested it this time.

All it's doing is toggling the blink variable every 2 steps.  You can define those booleans somewhere in the Create Event:

Code: (Create Event)

blink = false;
blinkCount = 2;

[ஒழுக்கின்மை (Paul Eres)]

An easy way to do this is with 'mod', also known as the % operator. I usually have a global variable called 'steps' which increases by 1 each game cycle / each frame of animation. Just use global.steps += 1; in the controller step event.

Then, whenever you want to do something every n frames, you can do something like this:

Code:

if (global.steps mod 5 == 0) {stuff}

That stuff will occur every 5 steps.

You can also do something like:

Code:

if (global.steps mod 30 <= 10) {stuff}

That stuff will occur one third of the time, ten times every second grouped into a third of a second (assuming 30 fps / a room speed of 30). This may be useful for slower blinking items or whatever (since blinking every step can be epilepticly fast).

So in general having a global variable that is incremented every step is pretty useful.

[sandcrab]

Thanks, I'll fiddle with both of these.

[sandcrab]

I have made a cool enemy that releases more enemies!  It sits at the bottom of the screen and enemies fly straight up out of it.  Then I made another version that releases enemies that move down the screen instead of up!  But I thought, wouldn't it be way cooler if it were actually releasing the SAME enemy, and depending on which generator released it, the new enemy would move up or down accordingly?  My code, however, is flaw'ed:

Code:

// release oFodder

if (ejectCounter = 0)
{
    instance_create(x, y, oFodder);
    oFodder.setDir = -1;
    ejectCounter = ejectDelay;  
}
ejectCounter -= 1;

oFodder.setDir is a positive or negative 1 (depending on the generator) which oFodder's movement rate is multiplied against to reverse direction.  I naively believed that this would effect the instance of oFodder that was just generated, but obviously that didn't work.  Is it possible to instance_create(x, y, (oFodder with setDir = -1))?  Or should I go back to the two different enemies plan?

[William Broom]

I believe you want to do something like this:

Code:

spawn = instance_create (x,y,oFodder);
spawn.setDir = -1;

This works because although instance_create performs an action (creating an instance) it also returns a value (the id of the instance it has just created). So in this case it is setting the variable 'spawn' to be the id of the newly created oFodder. Then, directly after that, it sets the spawn's values to whatever you want. The next time you create an enemy in this way, the spawn variable will be overwritten with the id of the new enemy.

One thing to bear in mind when doing this is that the oFodder's Create event will trigger as soon as it is created, then it will come back to the code that created it and pick up where it left off. Not paying attention to this order of actions has left me with some confusing bugs in the past.

[sandcrab]

Awesome, thanks again

[JackBread]

Hey, how do I get enemies to move and fire? Thanks in advance.

[William Broom]

That's a pretty broad question. The movement thing depends on how you want your enemies to move. But for basic up-and-down movement, you should probably give them a variable called 'ymomentum' and then add to the step event:

Code:

y += ymomentum;

Then if your ymomentum is positive, the enemy will move down, or if it is negative it will move up. Doing the same thing with an 'xmomentum' variable will give you the barest bones of a standard movement system.
But you also want your enemy to be able to detect when he is nearing the edges of the screen, and change his ymomentum to avoid leaving the playing area. If the screen scroll up and down, then you'll probably want to make him check against the edges of the screen (view_yview[0] is a constant variable representing the y value at the top-left corner of view

• ). When the enemy sees he is too close to the edge of the screen, he will change his ymomentum accordingly.

As for shooting, the basic idea is that you create a 'bullet' object with similar properties of xmomentum and ymomentum. Then when you make the bullet, you set one or both of its momentum values high so that it will move fast. When you fire the the bullet is up to you. You may want to make it fire at regular intervals (using an alarm that resets itself) or at semi-random intervals (make the alarm reset itself to a semi-random number such as '50+random(50)' which will produce a random number between 50 and 100.)

This is just an overview sort of thing because I don't know exactly how much you already know. If there's anything you don't understand and want to have explained in more detail, just ask.

[sandcrab]

I made a very simple enemy that I based primarily off of Derek's code.  There's probably a better way to do a lot of this, but I was working with what I had.   If you're really stuck for a moving enemy, this might at least give you something to start with (it goes in the enemy's step event).

Code:

//move around a bit

x -= 2;

if (movetimer < 10)
    {
    movetimer += 1;
    y -= 1;
    }
    else
    {
        movetimer +=1;
        y += 1;
        if movetimer > 29
        {
            movetimer = -10;
        }
    }

Basically, this enemy moves toward the left side of the screen at all times as it wiggles up and down based on the variable "movetimer."

I've poked around looking at GM's commands for making bullets (it's atually get one specifically for making bullets!) but I created some bullet-like projectiles by simply setting the following in the creation event:

Code:

direction = random(360);
speed = 5;

This almost seems too easy!  The speed command means it moves at the specified speed, and direction sets a direction in 360 degrees.  I used random(x) to create a random direction here, but you can set it to any direction you want (for instance, the bullets the ship in the tutorial fires would be set to 0).  point_direction(x1,y1,x2,y2) returns the relative direction (in degrees) of a coordinate to another, so you could aim at specific things with that.

[sandcrab]

And one for me!  I've started a new game based on what I've learned here and want to expand it out a bit.  How do I make a game that has a flow like this:

title screen
level
level
level
(etc)

I know there are plenty of room commands (room_goto() looks helpful), but where should I put them?

[Soulliard]

In the menu, it should be in a key press event or mouse event, depending on the interface.

For moving from one level to another, it should be in whatever event would signal the end of the level. If you need to get from point A to point B, it should be in a collision event with a (possibly invisible) object that marks the level's end. It could also be in a destroy event if the object is to defeat a boss, or in an alarm event if the object is to simply survive for a set amount of time.

[JackBread]

Thanks, William. That helped a lot. 
Now, how do I make it move the opposite direction when it hits an object?

[William Broom]

Thanks, William. That helped a lot. 
Now, how do I make it move the opposite direction when it hits an object?

Do something like this, in your step event:

Code:

if (place_meeting (x,y+ymomentum,wall))
{
ymomentum = -5; //or whatever speed you normally have it move at
}

This will check directly below the enemy and turn it around if there is a wall there. You need to make sure that you have a single wall object, which is named wall so that the enemy can detect it. If you want different sizes and shapes of wall, just make them, and set their parent to 'wall'. This way they will all function as walls.

You use the place_meeting function because rather than checking at the exact point specified, it checks an area based on the size and shape of the object itself. Much better for checking collisions, for obvious reasons.

However this code on its own will only make the ship turn around if it hits a wall below it. To do it from above as well, just copy and paste the code but change all the minus signs into pluses. If you want it to check against walls to either side as well, just copy it again but change all the y's to x's.

[sandcrab]

I've made some enemy characters who move around the screen and are supposed to change direction when they bump into something, but sometimes (too frequently for my liking!) they get stuck in a wall and jitter around for a while until they pass through it.  Currently, the collision code looks like this:

Code:

direction += 90;

This should make them turn 90 degrees, but typically it actually turns them all the way around, I assume because it is getting two collisions in before it actually comes away from the wall.  Setting it to 180 causes it to just go straight through the wall like it wasn't even there!

Thanks

[salade]

is your wall object on solid? if it is, then your enemy should only have one collision, and then automatically be placed to a position where it does not hit the wall. if you are using place_meeting, you may have to do this manually (x = xprevious;).