next »

[sandcrab]

Hah!  It certainly isn't!  xD

Looking up Solid is giving me all manner of exciting new possibilities, thanks!

[sandcrab]

Here's another one.   Now I want to make one object follow directly over another object.  This would be totally easy (just set the follower's coordinates to the same as the followee's!) except I don't know the ID of the object I want to follow!

More specifically, the mouse cursor is followed by oCrosshair and when it collides with an oEnemy an oLockOn should appear over the oEnemy's origin and follow the enemy as long as the collision remains "true."  Well, that's what I want to have happen, anyway...

Thanks

[Derek]

The collision_* functions, instance_place(), and instance_position() should all return the id of the instance in question.  So does instance_create().

[Aaron P]

Hey...

I have a GM question. I'm working on a movement system that allows the player to move a controlled object between 4 Quadrants using the Q,A,W, and S keys. The system works pretty much the way I want it to as written, but I'm running into an issue where when I press three keys at the same time, the player is warped off screen. How can I prevent this from happening? Here is the code.

Code:

//Warp to Quad 1
if keyboard_check_pressed(ord ('Q'))
{
    if shipQuad = 2
    {
        x -= 240;
    }
    if shipQuad = 3
    {
        y -= 240;
    }
    if shipQuad = 4
    {
        x -= 240;
        y -= 240;
    }
}
//Warp to Quad 2
if keyboard_check_pressed(ord ('W'))
{
    if shipQuad = 1
    {
        x += 240;
    }
    if shipQuad = 3
    {
        x += 240;
        y -= 240;
    }
    if shipQuad = 4
    {
        y -= 240;
    }
}
//Warp to Quad 3
if keyboard_check_pressed(ord ('A'))
{
    if shipQuad = 1
    {
        y += 240;
    }
    if shipQuad = 2
    {
        x -= 240;
        y += 240;
    }
    if shipQuad = 4
    {
        x -= 240;
    }
}
//Warp to Quad 4
if keyboard_check_pressed(ord ('S'))
{
    if shipQuad = 1
    {
        x += 240;
        y += 240;
    }
    if shipQuad = 2
    {
        y += 240;
    }
    if shipQuad = 3
    {
        x += 240;
    }
}

To help explain the code:

The screen is 480 pixels long. The system is set to move the object 240 pixels along whatever necessary axis depending on which quadarant of the screen the player is on in order to land them in the target quadarant.

So...how can I handle this three key issue?

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

You could try using 'else' so that only one key can be pressed at once. Alternatively, use 'else' on only the opposite keys, so that you can't press q and s at once or w and a at once.

[sandcrab]

Ah, my lack of maths!

I have the direction of a target via point_direction, and I want to aim a missile at it that gradually homes in on it.  It's very easy to just set the missile's direction to match the target's, but I want to increment it in steps of the variable turnSpeed.  The problem is determining which way to turn, especially when turning to the right tends to produce negative numbers!

I also suspect that when that missile's direction gets close to the target's direction, the missile is going to start to waver back and forth as it is unable to actually match the exact direction that it wants because it is turning in large increments.  I don't know if that will be a jarring effect or not, but it'd be cool to pre-empt it...

Thanks again guys

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

Use the direction difference formula, which I posted here: http://studioeres.com/games/category/tags/game-maker

2. Difference Between Directions
Finding the difference between two directions (Game Maker uses a wrapping 360 degree direction system) is common enough that I've used it in every game I've made for it, yet Game Maker gives you no easy way to find that out. So here's what I use; the two arguments are simply the two directions to find the difference between:
var ret_result;
ret_result = abs((argument0 mod 360) - (argument1 mod 360));
if (ret_result > 180)
ret_result = 360 - ret_result;
return ret_result;

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

Once you know the difference between two directions, you can then use the sign of that direction to determine which way to go. I believe there's a function to get the sign of a value, perhaps it's just sign().

[sandcrab]

It's slowly occurring to me that maybe I am trying to do something very difficult, the best I seem to be able to do is get a missile moving in a circle, or (strangely) away from the intended target.  I can get the difference between the two directions, but I don't know what to do with it now that I have it. 

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

It's not difficult. As I said, take the sign. Let's say you want to move a missile 3 degrees toward its intended direction every step. You use the direction distance formula, use sign() or whatever function it is that takes the sign, multiply by 3, and then add that to its current direction.

[sandcrab]

Thanks for your patience with me!  But I'm still at a loss on this.  Here's my code, it isn't exactly the same as yours, I didn't bother with the script and just put it directly into the step code for now, and I didn't bother with the sign function either, thinking that it's better to use the methods that I understand first and I can clean it up later. I believe it should be doing the same thing, but it isn't giving the desired effect.

Code:

if (instance_exists(oLockOn)) 
    {
    targetDirection = point_direction(x,y,oLockOn.x,oLockOn.y); 
    
    diff = abs( ((direction + 360) mod 360) - ((targetDirection + 360) mod 360) );

    if (diff > 180) diff = 360 - diff;
    
    if (diff > 0)
        {
        direction += turnSpeed;
        if (direction > 360) direction -= 360;
        }
    if (diff < 0)
        {
        direction -= turnSpeed;
        if (direction < 0) direction += 360;
        }

   

The modifications to direction after I add/subtract the turnSpeed are to keep it from slipping out of the 0-359 range, though I suppose with the mod in the difference formula it doesn't really matter, right?

This produces missiles that turn in circles endlessly.  A particular line bothers me, and that's "if (diff > 180) diff = 360 - diff;" shouldn't it ALWAYS return a positive because of this line?  if I change it to "if (diff > 180) diff -= 360; then I can get a negative value, and then my missiles go in a partial circle and turn AWAY from the target.  What is going on?

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

You might be right there. Finding the difference between two directions when the directions "wrap" around 360 is actually very tricky, because it depends what kind of result you want: do you want the number of degrees between the two angles (which is what my script was intended for) or the signed difference between them -- I suspect you'd have to use a different script. You can try removing the if (diff > 180) line and removing the abs() and see if that helps, but I suspect it'd still have problems. This is a lot easier for me to conceptualize with radians, it's a pity GM uses degrees. Perhaps what you could try is removing the (diff > 180) line and replacing diff > 0 / diff < 0 with diff > 180 / diff < 180

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

Conceptually, it's like this: you can find the difference in degrees between two angles, but you can't know if that difference goes to the right or to the left as easily. Imagine a direction of 359 and a direction of 1. Is the difference 358 or 2? It's both. The script I had was designed to always give you the lesser of those two values -- it'd return 2 rather than 358.

[Ataraxia]

Thanks so much for these tutorials Derek! I've been wanting to learn programming for years but always found it boring because every beginners tutorial starts with lame math stuff rather than the actual creation of something. Then I moved on to XNA which was pretty sweet because I actually got to make things while learning, and then I realized the shear amount of learning I'd have to undergo in order to get even the basic framework of a game up and running. Then bam, I run into your tutorials and Game Maker. My programming skills have leveled up exponentially and I'm having a blast the entire time.

I've taken what I've learned here, added a basic particle system to the game, made a parallax starfield, and added in some basic enemy AI. This is the awesome.

Thanks again! And thank you to everyone who has been helping out in this thread, I've learned a lot from you as well!

[Kegluneq]

So Derek, any plans to release part IV after Spelunky v1.0 releases?

[Lon Lon Rabbit]

Thanks a lot for these tutorials, very helpful.

I followed tutorials 1 and 2 then this one closely up until setting/scrolling views.

I've run into the following issue when the game runs; the right arrow key seems to stop working once the ship passes the x coordinate which was the far right hand edge of the game's starting view (hope that makes sense). I can no longer move the ship to the right (forward) past that point, but the screen pushes it further when it catches up and I can still move up/down/left.

I've checked over everything I've done and can't figure out what I might have done wrong; does anyone have any idea?

Thanks.

EDIT: Guess I hadn't followed along as closely as I thought! Problem solved...

[Ataraxia]

I've got a small problem I hope someone could help me with. It involves collision detection. I've laid out collision detection between the players bullets and an enemy exactely how Derek did in the tutorial. Sometimes bullets will pass directly through an enemy without the collision being detected.

For example, I have a row of enemies laid out horizontally, every so often a bullet will pass through all the enemies in the row and collide with the last one. Is this a problem with the way Game Maker handles collisions or am I doing something wrong. I'll gladly post my code if you need it.

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

That's a common problem. The reason it happens is that if the speed of the bullet is high enough, it can jump right over its target. The easiest way to fix it is to lower the speed of the bullet, or increase the size (the bounding box, not necessarily the graphic) of the bullet. The preferred way to fix it is to check not only the bullet's location, but a line between the bullet's current and its previous location, using the collision_line() function.

[Ataraxia]

Thanks Paul, I will give that a try when I get home from work. I'm going to go with the collision_line() method because I like the bullet speed where it's at.

[Ataraxia]

Okay, first, sorry for the double post.

Here's what I came up with for hit detection. It's placed in the bullets step event.

Code:

//Hurt Enemy and EnemyHitFlash
enemy = collision_line(self.x,self.y,self.xprevious,self.yprevious,oEnemy,1,1)
if (enemy > 0)
{
enemy.hp -= 1;
instance_destroy();
enemy.image_blend = enemy.hitblend;
enemy.hitblendtime = 1;
}

This makes collision detection even more hit and miss, parden the pun. Any idea what I'm doing wrong?