8 replies to this topic

[Shinryokin]

A little bit on me before we get into the problem. I've been using game maker for about 3 days now and have a huge project lined up that I am collaborating on with a friend. I have some programming experience(mostly just intro to programming and programming fundamentals in college), and I've done a bit with pixel art and designing sprites and tile sets. I am picking up game maker really fast though and have learned a ton in those 3 days. I use 8.1lite for now, will probably upgrade to pro after I've mastered a bit more of the features and start getting into programming code.

So here is my issue, I am trying to make it so once I release jump button from the character will begin to fall so I can do short hops. I have done this by setting vertical speed to zero when the jump key is release. The problem is that it continually resets the Vspeed every time so if you keep tapping the jump button the character will sort of hover. Any ideas on a better way of creating short jump? I would also like it to work with a double jump also, which I have already set up.

I have another problem with shooting, I took a tutorial from http://sandbox.yoyog.../make/tutorials on creating a platform and I used their setup for shooting. I have found out now later on in development that for some reason if I am facing left and jumping and do not release either the jump or left key I cannot shoot. This only happens for looking left while mid air, facing right works fine as well as on the ground in any direction. Can someone look at this tutorial and tell me what the issue might be?

Thank you so much!!!

[IKSB]

To solve the jumping problem, I would just say something like this:

if vspeed < 0 then vspeed = 0;

This way it will reduce the speed on release only if you are traveling upwards. This is the simplest fix I can think of.


To fix the jumping and shooting problem.... the tutorial uses a very inefficient and rough way of controlling the direction of the bullet. I have two solutions for this:

SOLUTION 1
If you want the player to be able to fire the bullet at the mouse to allow for more precise aiming, just tell the bullet it in its creation code:

direction = point_direction(x,y,mouse_x,mouse_y)
speed = 9000 (or whatever)

and then just tell the player in the press spacebar event:

instance_create(x,y,obj_bullet)

because, in this case, it doesn't matter whether the player is looking left or right. The bullet will fly at the mouse. To keep it from looking stupid, you would have to have the player constantly looking at the mouse as well.



SOLUTION 2

If you want it to fire a bullet only in the direction it is facing, the way the tutorial does it sucks. It sucks because, for most games, we don't have one static image for every time the player faces left. What if we want a separate sprite for jumping, standing, and running? We would then have to check whether the player sprite is any of these before allowing the bullet to be fired. A more efficient way of doing this is to have a variable represent the direction the player is facing and just check that.

Here's how I do it: in the create event for the player I define a variable that I usually call "me." So in this case:

me = 1;

1 = facing right, and -1 = facing left. Then, when the player walks left, I set me to -1 and when they walk right I set me to 1. So then, when you shoot the bullet:

bullet = instance_create(x,y,obj_bullet); ///now, whenever we want to control the bullet, we just refer to the temporary variable, "bullet"
if me = 1 then bullet.direction = 0 else bullet.direction = 180; ///if the player is facing right, tell the bullet to go right. If not, then the bullet goes left.
bullet.speed = over9000 /// (hahaha.... yeah.) This just says how fast the bullet goes.


BONUS TIP

Using this system of checking direction allows you to do something fun. You don't need to have two sprites for running left and running right, just keep the sprite for running right. Then, in the draw event, set the image_xscale to "me." You can either do this by telling using the draw_sprite_ext code, or by just saying:

image_xscale = me

So when it is facing right, image xscale will be 1, which is normal. Then, when it faces left, it will be -1, which is the sprite inverted: facing left! Pretty nifty stuff, I know.

If you use draw_sprite_ext, then you can just say the sprite index = sprite_index. Not very revolutionary, but I feel like it gives me more control over changing the size, transparency, and rotation of the sprite.



Sorry I got carried away, but I hope that helped!

[Shinryokin]

This is a great help, thanks a ton. One other issue I've ran into is that when I collide with a platform above me my double jump resets and I can continually jump and basically stick to the bottom of a floor. The only thing I can think of is to create a new collision object to reset on and make it 8x16 and lay it across landing platforms. That way it resets when I land on a surface but not when I hit one from below. I can see this turning into needing to create a ton of different collision tiles though.

To solve the jumping problem, I would just say something like this:

if vspeed < 0 then vspeed = 0;

This way it will reduce the speed on release only if you are traveling upwards. This is the simplest fix I can think of.


To fix the jumping and shooting problem.... the tutorial uses a very inefficient and rough way of controlling the direction of the bullet. I have two solutions for this:

SOLUTION 1
If you want the player to be able to fire the bullet at the mouse to allow for more precise aiming, just tell the bullet it in its creation code:

direction = point_direction(x,y,mouse_x,mouse_y)
speed = 9000 (or whatever)

and then just tell the player in the press spacebar event:

instance_create(x,y,obj_bullet)

because, in this case, it doesn't matter whether the player is looking left or right. The bullet will fly at the mouse. To keep it from looking stupid, you would have to have the player constantly looking at the mouse as well.



SOLUTION 2

If you want it to fire a bullet only in the direction it is facing, the way the tutorial does it sucks. It sucks because, for most games, we don't have one static image for every time the player faces left. What if we want a separate sprite for jumping, standing, and running? We would then have to check whether the player sprite is any of these before allowing the bullet to be fired. A more efficient way of doing this is to have a variable represent the direction the player is facing and just check that.

Here's how I do it: in the create event for the player I define a variable that I usually call "me." So in this case:

me = 1;

1 = facing right, and -1 = facing left. Then, when the player walks left, I set me to -1 and when they walk right I set me to 1. So then, when you shoot the bullet:

bullet = instance_create(x,y,obj_bullet); ///now, whenever we want to control the bullet, we just refer to the temporary variable, "bullet"
if me = 1 then bullet.direction = 0 else bullet.direction = 180; ///if the player is facing right, tell the bullet to go right. If not, then the bullet goes left.
bullet.speed = over9000 /// (hahaha.... yeah.) This just says how fast the bullet goes.


BONUS TIP

Using this system of checking direction allows you to do something fun. You don't need to have two sprites for running left and running right, just keep the sprite for running right. Then, in the draw event, set the image_xscale to "me." You can either do this by telling using the draw_sprite_ext code, or by just saying:

image_xscale = me

So when it is facing right, image xscale will be 1, which is normal. Then, when it faces left, it will be -1, which is the sprite inverted: facing left! Pretty nifty stuff, I know.

If you use draw_sprite_ext, then you can just say the sprite index = sprite_index. Not very revolutionary, but I feel like it gives me more control over changing the size, transparency, and rotation of the sprite.



Sorry I got carried away, but I hope that helped!

[Shinryokin]

Also I have no idea how to do the image_xscale because I know nothing really about writing in the scripts. I tried but it did not seem to like the value of me; either that or maybe there is a command I need to use before it. I am not sure, the idea of using the me variable seems awesome to me but I just can't figure out how to make it work to flip the image.

[IKSB]

The variable "me" simply needs to be a defined variable in the create event. So, if you're writing out code, it would be:

me = 1

in the create event. It probably was complaining that it was an unknown variable. As long as it's defined in the create event, it should recognize it in the rest of the code. In the draw event just pull in a code block and put in:

draw_sprite_ext(sprite_index,image_index,x,y,me,1,0,c_white,1)

It will just draw the sprite as it normally would, but would use the variable "me" as its image_xscale. If this doesn't work, I can make a quick example to show you how it works.


And as for double jumping, what you probably did was something like saying, "when the player collides with a block they can double jump again." This doesn't work because it creates the problem you had of reactivating the double jump when hitting a block from below. What you need to do is instead say, "when the player collides with a block from above then they can jump again."

How you would do this is when you collide with the block, in code, say:

if !place_free(x,y+5) then doublejump_ready = true

The "!" means "not." So what I'm saying is, if the space below me is not "free" (has no SOLID object at the point x,y+5) then I may double jump again. The y+5 is a basic, arbitrary point below the player. You may have to tweak the exact number to get it to work. With block code you would do this:

Check Empty (in the control tab, it has a blue icon with a circle in the middle)
x = 0;
y = 5;
Only Solid
(Check relative. Relative asks whether origin point is the objects x and y. So instead of x = 0 being the far left side of the map x = 0 is the objects x)

THEN put a VAR block in there. It is also in the control tab and is gray with all caps VAR on it. Say this:

variable: doublejump_ready ///just use whatever variable you were using for the double jump ability
value: true

Personally, I prefer the code as opposed to blocks. The block code quickly gets difficult to manage when you try to do more complicated things. It will be well worth your time to learn GML, which doesn't take long. I taught myself how to use it without any of the tutorials. It works much like the block code, you just have to know a few keywords and code snippits. I believe there is a PDF somewhere that has the code equivalents to every block.


This is some pretty complicated stuff you're trying for the third day in! Best of luck to you!

Edited by IKSB, 29 November 2011 - 11:47 PM.

[Shinryokin]

Awesome thank you. So now the new issue, I got him constantly doing the run motion and don't know how to tell it to switch to a new sprite for standing still. I switched the values of me to 2 and -2 for left and right standing still but it is looking at the sprite I set my character object to. I guess my question now is how to, in code, write out a swap between sprites. I really need to look up this PDF file so I can start understanding the code. I started a new prototype game to build my skills in writing code, I want to avoid block code as much as I possibly can. Thanks so much for the help, hope I am not asking too much here.

[IKSB]

The value of me never equals anything but 1 and -1. This variable exists only to check the direction the player is facing, control the direction the sprite is facing, and flip actions the player performs.

So in code, to tell it to go to a new sprite, it's really quite simple:

sprite_index = spr_newsprite

This is why using the code I gave you for draw_sprite_ext was so good, because it will now start drawing the new sprite with the xscale of "me."

If the new sprite has an animation and you want it to start at the beginning, you can also say:

{
sprite_index = spr_newsprite
image_index = 0 ///this is the step of the animation of the sprite, so 0 is the first frame
}

And if the new sprite has an animation that you want not to move, you can throw in there:

image_speed = 0; ///image speed controls how fast the animation moves and works like a percentage, with 1 being 100% and 0 being 0%. So .5 = 50%.

[Shinryokin]

Hey thanks a ton man. I think things are finally clicking for me. Last night I had an epiphany at like 2am and came in and deleted like 15 variables from my game cause I was making it way to complicated. Won't be long before I have all the motion and animation done and we can just focus on creating the levels of the game. What do you know about publishing these games? With pro edition does it remove all indication that it was made with game maker when you create the .exe and have you tried publishing a game and charging for it? We really want to make some money off our games at some point. Thanks so much for all your help.

[IKSB]

Haha, well that's the catch really... I've never actually finished a game. I mostly use GM to entertain myself to try to figure out how to do things. So I'll come up with a game design, see if I can make it, and then move on to something else.

But for marketing indie games, Steam seems like a pretty good way to go, so I would look into that.