• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

I can not make a TDS game, the player does not turn the player does not turn

S

Sevonka

Guest
I do not know what to do, I'm studying video lessons and forums on a game maker, and tried everything. My player does not turn where the mouse is looking !! Do not pay attention to sprites, this is not the main projectupload_2017-11-26_16-27-1.pngupload_2017-11-26_16-27-17.png
 
M

maratae

Guest
I do not know what to do, I'm studying video lessons and forums on a game maker, and tried everything. My player does not turn where the mouse is looking !! Do not pay attention to sprites, this is not the main projectView attachment 14608View attachment 14609
Ask yourself if you really need to use the physics engine on your game.
The physics engine is one of those things that unless you really really have a good reason to use it, don't.
Some regular functions won't work with physics at all, and although I'm not quite sure, I think the problem might be that 'direction' is one of those.
Good luck.
 

TsukaYuriko

☄️
Forum Staff
Moderator
First things first, since I'm seeing screenshots of code: How to Q&A

How to make the enemy look in the direction of my player?
You've already made something turn towards something. Now it's up to you to read the manual entry of point_direction and figure out why your code does what it does. Then, you will be able to adapt it to the new scenario without any further spoon-feeding input from the community and will actually have learned how to do something on your own! :)
 
S

Sevonka

Guest
First things first, since I'm seeing screenshots of code: How to Q&A


You've already made something turn towards something. Now it's up to you to read the manual entry of point_direction and figure out why your code does what it does. Then, you will be able to adapt it to the new scenario without any further spoon-feeding input from the community and will actually have learned how to do something on your own! :)
phy_rotation = -point_direction(x, y, obj_player.x, obj_player.y); :)
 
Last edited by a moderator:
H

Halph-Price

Guest
phy_rotation = -point_direction(x, y, obj_player.x, obj_player.y); :)
Ya, I started the game I'm working on now with working in phy, but since then realized I don't need things shifting around, and that for a first game, maybe be better to hit up that phy💩💩💩💩 later.
It's sort of antiquated and was in there for early GMS, I think, because flash games and stuff use to play with player made physystems before, but that gimmick is kind of lost.

Still, I do think it's an interesting system and a good reason to use GMS. Just look up in the manual everything for
Physics Functions
and read over everything in there, that is what GMS uses, and doesn't usually interact with other stuff, so you need to mess with friction and mass to change the movement start and go and collision distance and stuff. Once you get it working, tho, just ask yourself. "DO I ACTUALLY NEED THIS" because anything that GMS does, you cannot control and it's like relying on the mysterious process to help fix it. With speed and direction you know what's going on when and where and that's useful.

Then again collision is the biggest headache, and phy system fixes a lot of that. You're not going to find as many tutorials on how to work with the Phy system, but the ones you do, they're pretty insightful, because it takes a lot of patient to make it work, which is good if you got a lot of time.
 

Jezla

Member
Then again collision is the biggest headache, and phy system fixes a lot of that.
It doesn't really, though. It seems easier because all you have to do is place a comment in the collision event to get a collision, but when you think about it, the traditional collision system is simpler. Firstly, the physics collisions can cause problems for the inexperienced because a physics collision event fires multiple times per step, depending on the physics update speed, and then only if a force is being exerted on the fixtures. Secondly, the way the physics system works 'under the hood' is far more complex than it seems. It checks to see if the fixtures are overlapping, and if they are, and the instances are supposed to collide, then it moves the fixtures out of collision.

The traditional system is simpler in that it checks to see if the sprite/mask is overlapping. What makes it seem harder is that you have to code the reaction yourself.

Your first point is the best. If you're making a game that requires moving objects by forces or impulses, or requires a realistic physics simulation, then the physics system is appropriate. If you're making a traditional TDS or platformer, then it's not.
 

Gamerev147

Member
Don't use the physics engine!

If you're making a simple top down shooter without any special effects that require physics, you don't need to use the physics engine. By the looks of it, you'll just get confused using the physics engine.
Looking in certain directions is super easy to do in game maker. To get the player to look at the mouse, simply use:

Code:
image_angle = point_direction(x, y, mouse_x, mouse_y);
To make the enemy look at the player:

Code:
image_angle = point_direction(x, y, obj_Player.x, obj_Player.y);
Remember, all of that code is for a game NOT using the physics engine.
 
H

Halph-Price

Guest
@TsukaYuriko literally just said not to further spoonfeed
I tried to find the video I got that from, but couldn't find it so.... also no other video that was really useful.

OOPS NEVER MIND


welp...

Best resources for making a top down shooter with physics... hehehe.
 
Top