Help Needed for game - beginner

P

philly85

Guest
Hi there I just finished the space rocks tutorial doing GML.

I have an idea for a game but unsure what I need to use or pay attention to.


Ill try explain it as simple as I can

Basically I want a ball to follow either left or right when the keyboard is pressed left or right
When space bar is pressed I then want it to let the ball be thrown (front facing) onto an object in front of it and IF it collides (maybe a 50/50 chance coded that it will collide) with the certain item (in front of it) then I want it to bounce back to the user (they have to click to "catch" the ball) to be given another chance to throw the ball.

Is that doable? or am I best off making it a side view to throw the ball because I imagine the collision mask would have to be precise

Basically image standing on the side of the road facing the opposite way and throwing a ball at the kerb and if it hits the edge of the kerb the ball will come back to you and you will win a point

Thanks for any help.
 
Yes this is doable! The concept actually seems very cool to me! Basically you would need to set up the angles with a function like point_direction and then if it collides with the curb and bounces back you can create an invisible tile layer that acts as the start where the player originally threw the ball or something like that and if it collides with that and the player presses the catching key then the ball will be caught and so on.
 
P

philly85

Guest
Hi there thansk its basially a british game people play as children in the summer to pass the time haha, is there any example or tutorials for those functions and instances that might help me please?

Thanks
 
P

philly85

Guest
Just to get it correct in my head it would need to be coded like...

IF keyboard press = vk-LEFT then ball.obj will move
IF keyboard press = vk-RIGHT then ball.obj will move

IF keyboard press = vk-SPACE then ball.obj will move towards curb_edge_obj
IF ball.obj COLLIDES with curb_edge_obj then...
ELSEIF destroy ball.obj

This is where my knowledge vanishes haha

But basically needs to BOUNCE BACK

IF user clicks the ball.obj during this bounceback event then they regain control and win a point
ELSEIF user misses the ball then DESTROY and will be happy to leave it at that for the beginning.

Does this make sense? lol
 
P

ParodyKnaveBob

Guest
Howdy, philly, and welcome to the GMC. $:^ J

Sounds like you've broken down the logic pretty well, there. Whether you do this in DnD™ or GML, you can pretty much just follow your own wishes. Either chunk all that into a Step Event and tweak from there, which I do not recommend, or use all the different events available to you, like so:

Create Event
GML:
is_clickable = false;
Keyboard Left Event
move left

Keyboard Right Event
move right

Keyboard Spacebar Pressed Event
move up

Collide (Curb Object) Event
GML:
if (choose(true, false)) {
bounce DnD/function (check the manual if this is what you lack)
GML:
    is_clickable = true;
}
Mouse Left Button Pressed Event
GML:
if (is_clickable) {
    instance_destroy();
}
Outside Room Event
destroy

Naturally, all that can be improved upon, but those're the basics of what you said translated almost word-for-word into game logic. Perhaps you merely need to take more tutorials to see how brain-desires turn into programming-logic? $:^ J

I hope this helps!
 
Last edited by a moderator:

TheouAegis

Member

I like the idea of doing it head-on more than from the side. But in terms of ease of programming, doing it top view from the side is definitely easier. Would it be as fun? *shrug* Personally, I would program it with a power gauge & maybe a spin gauge like you would see in a typical golf or bowling video game not on the Wii. Oh, and I would have the ball follow the mouse, not the keyboard necessarily. Whatever. But you would want the height of the ball on the screen to be a factor, as well as the power of the player's throw to be a factor. The power meter is the classic method for handling the power of a throw, but alternatives in the past have been the speed of a controller (e.g. trackball rotation speed, or mouse speed). Ball spin isn't much of a factor in kerby, but it's something I'm sure some child has had to deal with in the game at some point in history. LOL

If you were doing a head-on version, you would need to factor in z depth. That means you would need to learn how to code with 3D concepts. You don't necessarily need render in 3D, although arguably it might make things easier, but even a 2d-rendered game would need 3D concepts. I mean, your proposal could be made on an Amstrad.

If you did head on perspective, you would need a variable (z would be a good name) to keep track of how far from the curb (sorry, US spelling here) the ball is. That would be a good variable to randomize slightly as well. Rather than having a 50/50 chance to hit the curb, you can simply have a bunch of a variables with slight random variations to them which would still take away a little bit of the control of the player, but not so much that they would ever feel cheated. Because let's face it, if you are running after a ball and real life, you are not going to be throwing from the exact same position time after time. If you are a human, you are not going to be throwing with the exact same power time after time. However, that does not mean your position or power are randomly decided, they are decided based on your particular actions. Anyway, you would need a variable for the power meter. And you would also need a height map for the curb, although this could just be a simple algorithm for calculating the height of the curb rather than an actual array of values.

You don't really need any trigonometry for this unless you did decide to add spin. At its most basic core, you just need the height of the ball, the z depth of the ball, the velocity of the mouse or the power meter level, and gravity. Using elementary physics: the z depth would change based on power level or mouse vertical velocity. The vertical velocity of the ball would increase by gravity every step, causing the ball to fall faster. You can either add spin to the ball based on the horizontal velocity of the mouse, or you could utilize the horizontal velocity of the mouse to modify the vertical velocity of the ball, such as if the mouse veers left or right, you add that horizontal velocity to the vertical velocity of the ball. Then every step after the ball has been released you add the vertical velocity of the ball to its y coordinate, then take the z-depth and use that to find the height of the curb, then compare that value to the height of the ball. If the height of the ball is greater than the height of the curb, you know the ball has hit the curb, or maybe the sidewalk, or maybe the road. The z depth will let you know if at the time of hitting the curb the ball was actually still in the road, or overshot onto the sidewalk, or hit the curb exactly. Handling the bounce back is a whole other story. Again, you could use the horizontal velocity of the mouse when the ball was thrown determine which direction the ball will bounce back. For example, if the player accidentally swipes the mouse toward the right a teensy bit, the ball will bounce back to the right a little bit; if the player swipes the mouse toward the left by a lot, the ball could bounce back to the left by a lot more. Up to you.

Velocity, in case you don't know, is the change in position over time. So a vertical velocity is the change in y values over a particular time and a horizontal velocity is a change in x values over time. Thus the velocity of the mouse would be the change in mouse_x or mouse_y over time. personally, the way I would handle the time is wait for the player to click the mouse button and save the current position of the mouse to two variables (oldmouse_x and oldmouse_y). Then every step if the mouse button is down check if mouse_y is greater than oldmouse_y; if it is, set oldmouse_y to mouse_y and oldmouse_x to mouse_x; else if mouse_y is less than oldmouse_y, set an alarm to room_speed/4 (quarter second, might need to tweak this though). In the alarm event, subtract mouse_y from oldmouse_y and mouse_x from oldmouse_x to find the distances the mouse traveled within that time window, then divide those distances by room_speed/4 and you now have your vectors for the mouse movement.
 
P

philly85

Guest
Thank you all so much for the help.

I guess I have two choices for throwing , power bar and click which would get boring if the user figures out the correct power needed to hit the kerb they will find it boring maybe.

The other option is the click hold and flick forwards to throw, which seems so random that they might be like "screw this too difficult" haha. I am going to try later to code something veyr basic to see how it comes along. If I can get the ball to hit the kerb and come back to me first off I will have the very basic concept down if that makes sense.
 
P

philly85

Guest
I think I will design a ball and a line to start with and see how I get on with collsion and what happens when it hits the line, strip it bare visually
 

TheouAegis

Member
Regarding mouse deviation, you can downplay it by varying degrees by multiplying the measurements by fractional amounts. For example, if you make it rebound left or right based on the mouse's horizontal velocity, multiplying the velocity by 2 would make the ball veer off more sharply, but multiplying it by 3/5 would make it veer off less so.

In regards to things being too predictable or too random, there are ways to tackle it. Regarding the idea i had about letting the player catch the ball at different times to affect the distance from the curb, scale the ball's sprite slightly. But as for the power meter being too predictable, ues that is a significant drawback of power meters, but they are still used to this dau for a reason. Incrementing the meter by 1 each step is pretty fast at 60fps, but the larger your power meter, the slower it will appear to fill. Incrementing by more than 1 will mitigate this, as will multiplying it or dividing it. Another trick is to force the player to multitask, distracting them from the meter. Making the meter sparkly and distracting sometimes works. Another trick (mostly against beginners) is to multiply the meter by cos() or sin() to make it increment at different speeds. Or you could randomize the speed it increments or the position it starts at.
 

woods

Member
having that meter fill and hitting the button at "the right time" is harder than it looks sometimes.. i remember plenty of times playing random golf game on the nes or ps1 etc.. getting that third click just right can be a pain.. if the meter fill speed changes or if the target sweetspot is small (ball is in the rough so the sweet spot is only a handful of pixels wide vs on the fairway with a much larger target area)

just a thought ;o)
 

TheouAegis

Member
having that meter fill and hitting the button at "the right time" is harder than it looks sometimes.. i remember plenty of times playing random golf game on the nes or ps1 etc.. getting that third click just right can be a pain.. if the meter fill speed changes or if the target sweetspot is small (ball is in the rough so the sweet spot is only a handful of pixels wide vs on the fairway with a much larger target area)

just a thought ;o)
I suck at Golf. lol That power meter was deceptive! Although again, golf is a great game to use a power meter in because there is one giant variable present in nearly every single golf game, even the simplest ones. And that is, wind. As soon as you add even one random element into the variables, the power meter becomes less predictable. And with the NES being an 8-bit system, you have 256° of wind direction to play with, and if you divide it up into eight sprites for the arrow to show the player where the wind is blowing, that is still 32° of variance that the player will not be able to see. and then you factor in the fact that the power meter only increments in certain amounts, the wind is very likely to throw the trajectory of the ball off.
 
Top