next »

[Ataraxia]

Sandcrab,

I just wrote a quick little game to test whether motion_add would work. And it did (unless what you mean by bounce and what I mean by bounce are different)! I just made it add double the players current speed in the direction the wall is facing. Here is the code I have in the step event of the object that bounces:

Code:

if (!place_free(x+hspeed+1, y))
    {
    motion_add(180,hspeed * 2)    
    }

I apologize, in my last post I said that motion_add should add half the players speed, I was wrong, it needs to add a speed greater than the palyers current speed. Let me know if that helps.

I think the reason your not seeing immediate effect with motion_add() is because your using small speed values in the calculation. So it adds a small vector to the vector of your players current motion. Now if you make the speed a large amount you'll see that it instantly takes effect because your adding a larger vector to the vector of your players current motion.

Also, to make your bounce code not affect your landing code, make it so the bounce code will only take place if landed = false. If you catch my drift

[sandcrab]

Ahh, you are completely right, that works almost perfectly!  I had also thought of another solution, to simply reverse hspeed on impact, though to my eye, it seems that your motion_add solution works better, though I don't really understand why.  If I add twice my current speed to the opposite direction (180 degrees), shouldn't I head in the opposite direction?  The result is what I want (like if I'm moving up, I bounce off, but maintain upward movement), but I don't see why I come out facing the correct way?

Now that I really start thinking about this I'm really confused:  I was wrong when I said the opposite direction, because it's adding the constant direction 180, right?  Because this works with collisions to both the right and left, something I wasn't expecting!

I did the same thing for vertical collisions:

Code:

    if (!place_free(x, y+vspeed+1))
        {
        //vspeed = -vspeed;
        motion_add(180,vspeed * 2);

But it doesn't work, the player pushes through whatever surface he's against, and I don't really understand why.  It does work with the vspeed = -vspeed, commented out above, so I did find a workable solution, at least, and it works with just the two statements, one for vertical and one for horizontal (though it seems to me that it should need one for all four directions).

Lack of understanding aside, there's one more problem, it now does the same unpredictable bouncing that the bounce function does.  I was thinking it was because sometimes when colliding with the wall horizontally, it somehow gets to the vertical check first, and bounces me up or down instead of left or right.  It happens on vertical checks too.  Any idea there?

Thanks for the help!

[Ataraxia]

The reason that the motion_add method works so good is because it takes both your vertical speed and horizontal speed into account. So I think the reason you are getting the unpredictable bouncing is because you have hspeed= -hspeed in your code. Take that out because the motion_add function takes care of that for you on its own. Actually now that I think about it I shouldn't have even used hspeed in the code I used. You should just use speed. This will give you the most realistic bounce, I think. But with the code I wrote you'd have to have four separate wall objects. Here they are with the direction that should be used in motion_add for each (leftwall 0, topwall 270, rightwall 180, bottomwall 90)

The simplest way is to just use the move_bounce_solid in a collision event. So I don't qutie understand why that didn't work out for you. Could you post what your code was when you used that. All it should have been was:

Code:

if landed = false && other.object_index = 'yourwallobject'
move_bounce_solid(0)

Placed in the collision event of your player. That would make your ship bounce when it hits a wall. Anyways, let me know how you make out!

[sandcrab]

Oh wow, what a waste of time this has been. xD  Using bounce gets the same effect, which I have illustrated here:



and I'd still like to know what the solution to the problem would be, but I've been using move_bounce_solid(false) because I'm limiting the environment to right-angle blocks only, and I didn't think I needed the advanced collision.  It turns out if I just do move_bounce_solid(true) (which I just now tried after trying everything else and having written a rather extensive post detailing my efforts) then it does exactly what I want. 

It feels like a real cheap way out after trying to work around it for so long, though!

[Ataraxia]

Hahaha, I hear yah!! I've been finding out that game maker can be fairly quirky at times. Anyways, I'm glad you got it all worked out.

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

Oh wow, what a waste of time this has been. xD  Using bounce gets the same effect, which I have illustrated here:



and I'd still like to know what the solution to the problem would be, but I've been using move_bounce_solid(false) because I'm limiting the environment to right-angle blocks only, and I didn't think I needed the advanced collision.  It turns out if I just do move_bounce_solid(true) (which I just now tried after trying everything else and having written a rather extensive post detailing my efforts) then it does exactly what I want. 

It feels like a real cheap way out after trying to work around it for so long, though!

I imagine you'd find the direction of the wall and then bounce in that direction. I.e. if the wall is to the left or the right, reverse hspeed. If the wall is above or below, reverse vspeed.

[sandcrab]

That worked (in fact just reversing hspeed regardless of what wall I hit works just as well) and I tried using that method for both vertical (with vspeed) and horizontal collisions, but at steep angles it sometimes thinks that it should bounce the wrong way, ie, use both vertical AND horizontal.  move_bounce_solid(false) produced the same result, but (true) (for the advanced bounce) took care of it. 

My current problem is still the jittering, though I've managed to narrow it down to "sinking into the ground," and something I was doing that prevents the sinking from occurring is what was causing the jittering.  I deleted everything and started from scratch with a character and a floor object, as demonstrated in this thread I found over here (every other basic tutorial I found used drag and drop), so I could at least confirm that nothing else I was doing (like the bouncing) was interfering. 

Code:

if (vspeed > 10) vspeed = 10;

if (!place_meeting(x, y+vspeed+1, oBlock))
    {
    gravity = 0.5;
    }
    else 
        {
        //y = (instance_place(x, y+vspeed+1, oBlock)).bbox_top-(bbox_bottom-y);
        gravity = 0;
        vspeed = 0;
        }
        
if (keyboard_check(ord('U')))
    y -= 100;

There is no other code in the game at all!  The code I commented out is what causes the jittering, but without it he just sinks into the ground a few pixels.  Pressing the U key allows me to watch my my failure over and over again!  There's no collision event in this model (the full version has (among other differences) the bounce code in a separate collision event, but the landing-on-the-ground code gets the same result).

I posted the question over at http://gamemaker.wikicomplete.info (where I found the code in the first place) and no one will even touch it!

[sandcrab]

I turns out my problem was Precise Collision Detection!

Because I based everything off these tutorials, my collision objects were not really walls at all but large X's that I planned to put over tiles later, and I don't remember if Derek was having us turn off Precise Collision Detection when we made our sprites, but it turns out that it's probably a good idea to do it.  My character was sliding into the X, although I have to say it wasn't an especially convincing "slide." 

Chalk another one up to game maker settings I failed to notice?

[Ataraxia]

Oh that would make sense! It would make sense to turn precise collision checking off for your wall, but you should probably leave it on for your players sprite. It all depends on the type of game you're making. I'll just explain the difference between the two and that should help you understand when to use it and when not to. With precision collision checking enabled on a sprite, collisions are checked on a per pixel basis, for example, you'll want you're player sprite to have this on a bullet hell style shootemup. When not using precise collision checking, the game checks collisions on a bounding box. So if you were to use this on your player sprite in a bullet hell style shootemup it may look like the player dodged a bullet but the bullet will collide with the bounding box! Hope that makes sense, lol.

[sandcrab]

Yes I am already familiar with the difference. I just didn't realize that the bounding boxes which were set right there in front of me (I edited them myself in some cases) on the sprite menus weren't being used!

Also most shooters (bullet hell or otherwise) use a very small hit box in the middle of the ship, so more likely it looks like you got hit but really you didn't!  Per pixel collision is not commonly used there, especially if the ship is ornate with a lot of fins and stuff.

[Tibato]

Hey, there, just thought I'd throw in my two cents and ask some questions.

The thing I'm most proud of, even though I'm sure it's how everyone does this, is coming up with an item drop system. Essentially, I decided I wanted to have four items, and for there to be a 33% chance for an item to drop when an enemy dies. One (health) is dropped 50% of the time. The next (bombs) are dropped 25%. Third (weapon upgrade) is dropped 15% of the time. And the last (Invincibility) is dropped 10% of the time. So the way I decided to do it is to give each enemy a dropCounter variable created at 0. Each step, it goes up. If it's at 59, it resets on the next step. When the enemy is destroyed, the dropCounter is checked. On 10 of the numbers (evenly spaced), it drops health. on 5 (evenly spaced and different from the health ones) it drops a bomb. On three it drops a weapon, and on two it drops invulnerability. This way, I can simulate randomness pretty effectively.

I do have a question, though. I want my ship to be able to launch a bomb that goes off and has an expanding radius. I want enemies to be destroyed only within that radius. Can this be done with one sprite and one object? I can see maybe making a script that says "Kill things in this radius at this time, in this radius at this time," etc., but that seems like it would be kind of a pain to line up the timing with the animation. Also, while I'm thinking about it, how would I say "Kill everything in a circular radius of this size?" That seems sort of difficult to me.

Thanks so much for these tutorials, I'm having a blast!

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

That sounds like a weirdly complex way of doing something that can just be done with random(). Why would you simulate randomness in that way instead of just using the random() function?

[Tibato]

'Cause I wasn't sure of how to implement that and felt it would be amusing to play with it. The other thing is I wasn't sure how to say "I want this to happen randomly but only in these proportions." I have some other ideas that this might end up being a precursor to, also, but I'm not sure how to articulate them yet.

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

Let's say you want something to happen 10% of the time. You could just do something like 'if (random(1) < 0.1)', etc.

Alternatively, instead of incrementing something between 0 and 59, you could just do 'floor(random(59))', which will return an integer between 0 and 59. You could then just do exactly what you're doing with that instead.

One problem with the way you are doing it is that the player may figure out that at the end of the second the thing always does x, and at the beginning of the second the thing always does y, since the pattern would repeat every second or every two seconds (depending on your frame rate). It also just seems like a pain to code, considering you can do the same thing in a single line of code.

[Tibato]

Yeah, I recognized that the player might figure it out, but that didn't bug me. I actually toyed with the idea of crowding all the drops at the end of a cycle, so that the player would be rewarded for finding a certain rhythm. I then thought that that would be especially cool with music, if it were possible to time certain rewards in time with the music. I realize this would be an extreme pain to implement, but it's there in my head as a possibility.

Still trying to work out how to do this bomb thing . . . hm.

[William Broom]

I do have a question, though. I want my ship to be able to launch a bomb that goes off and has an expanding radius. I want enemies to be destroyed only within that radius. Can this be done with one sprite and one object? I can see maybe making a script that says "Kill things in this radius at this time, in this radius at this time," etc., but that seems like it would be kind of a pain to line up the timing with the animation. Also, while I'm thinking about it, how would I say "Kill everything in a circular radius of this size?" That seems sort of difficult to me.

To kill everything in a circular radius, do this:

with (enemy)
{
if (distance_to_point (other) < radius)
{
instance_destroy();
}
}

In case you don't know, using 'other' in this context will refer to the bomb, since the bomb is what called the 'with' statement. This code will kill everything that is within a certain distance of the bomb, which is of course, exactly the same as killing everything in a circular radius.

To make this circle expand, you could just include a bit of code that adds a certain amount to the value 'radius', every step.

However, this doesn't solve the problem of syncing it up to the animation, which could be quite annoying especially if you decide to change the animation later. What you might consider is just checking 'precise collision detection' for the explosion sprite, and then add a collision event between the explosion and the enemy to destroy the enemy. This would probably give you worse performance, but by how much I don't know.

[Kneecaps]

I have a fun Game Maker question!  I have an object in my game that rotates, but its "precise collision sprite" or whatever you want to call it does not.  Is there any way to make the collision detection rotate with the displayed sprite?

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

I'm not sure, I personally never use precise collision detection because it's so slow. Bounding box (rectangular) collision detection or circular collision detection is usually enough for what I need, and much faster.

[Kneecaps]

Many of the objects in the game are too irregular to be simplified as a few circles or rectangles.

The low amount of objects/collisions at any time keeps the performance up.

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

One workaround may be to create a bunch of collision masks and then manually change the collision mask for different directions (with whatever precision you need, for instance you could have 36 directional collision masks, each differing by 10 degrees). But that might be more work than it's worth if you have a huge amount of rotating objects.