[UPDATE 3.5]Angry Square

[HippoSocks]

I don't quite think its the size of the sprites changing, but if you watch when you go up, and hit the top of the window, its somewhat okay, but then as soon as you go left or right the sprite changes and causes a crash..

I can't be sure of it just yet, as I'm still half asleep from spending 8 hours debugging stuff till 3 in the morning..

EDIT: From trying stuff out with the release, it's making me believe that it has something to do with the clamping the sprite to the window on the y axis.

If anyone can travel left and right on the top and bottoms of the screen and tell me if it crashes for them, Then I can work out if it is clamping or not..

A fix I could do is add some walls around the window, but the only thing i dislike about that idea, is there is less playing room..

[LuX]

Simple but great game idea you have there. I see a lot of potential in it to add over time since it fits the style chili teaches us games.

Seems toddfather is pretty excited about your game.

[HippoSocks]

Thanks for the comment LuX, I'm glad you like it, even though its a bit broken.

I'm thankful he was enthusiastic about my game as he help me fix a cosmetic bug that I just over looked, and gave me some helpful advice and ideas.
Without toddfather I of stopped working on a actual game, and slowed down what I'm learning dramatically.

I'm glad so many people have been kind towards it, Its giving me a drive to keep learning.

I had a gander through the forums earlier, and I tried out one of your games, may I ask how you get the movement like the bullets move in your Square Demo you posted a while back?

I would appreciate it as having sprites limited to 8 directions kind of sucks, and it would help me add new features to this game, I believe vectors would be a way forward but I think there might be another method?

[LuX]

There's a couple of ways to calculate it. The one I'm using calculates the sine and cosine translation of a distance and angle, and then a couple more calculations to make it work properly.

The easier way would be to calculate the x and y difference to the target point, and normalize it using the distance to the target. Eg. launch point is ( 0, 0 ), target is ( 10, 5 ), distance is roughly 10, let say. the speed would be 1, so there's 10/1 steps to the target = 10 steps. now divide the x and y difference by 10 and you have the amounts you need to add each frame.

[HippoSocks]

That's put me in a state of confusion..

So I take starting x, y and target x, y.
Calculate the difference then normalize it, then distance divide speed.
Then divide x and y by steps.

That would leave me with how much to add each frame.

Would the result be a float then ?
Plus I normalizing kinda got me stumped, I tried looking what it is up, but found nothing useful or that explains it well enough..

But thanks for that, I'm sure with that I can work it out somehow, It's appreciated.

[LuX]

Haha, well, I don't know how far you are in maths at school, or if you have already been to school and forgot everything, but if we consider the single step difference of x and y you need to add each frame, that would be your speed vector. By normalizing a vector we are taking about setting the length of the vector to a single unit, in most cases 1, but here it would be the speed of your bullet.

The "length" of a vector would be the distance from (0, 0) to the vector value (x, y).

And yes, to get the accurate value, you would have to store the value as floats. In fact, the bullet position should be a float too, unless it isn't already.

For a more straight forward example, consider the case where you would shoot a bullet from (0, 0) towards a target at (10, 0). Here you can forget the y value.

First: the distance is obviously "10". By the bullet speed of "1" it will reach the target in 10 steps. So to get the amount the bullet needs to travel in one step you would calculate how many steps go into the distance.

If the shooting location is "(x0, y0)" the target is "(x, y)" the distance "d" and bullet speed "bS", the equation would be: xDifference: (x - x0) / (d / bS), yDifference: (y - y0) / (d / bS)

[thetoddfather]

Lux, have you ever considered doing any math/physics ... etc tutorials to suppliment the stuff chili is doing? Or could you point us to a good place where we can learn this kind of stuff in an application specific way (ie. Learn it while making games)? I missed your Square game on the forums, glad hipposocks mentioned it! You clearly have a firm grasp on complex maths and I was curious what advice you'd have for people who wish to get more up to snuff on this stuff.

I am a little confused too lol. Can you recommend any good books or tutorials online?
I would probably get it more if you stepped through the process a bit more.
Just looking at the projectiles in the game, I'm curious about why you need number of steps to the 'target' and distances and all that.
So, at leftMousedown or whatever, the game grabs mouse x,y and player x,y (source), how does it calculate the distance in order to plug that into your formula above?
And once we have xDiff / yDiff, what then? Say our goal is to simply take mouse x,y and source x,y and we want to plot the projectile along that path with a set bulletspeed of 1.0f until it leaves the screen and is destroyed. Not tracking anything.

Anyway, any help or direction would be much appreciated. Also, love the game and the Vortex Nova too! Are you still working on them??? Got something new on the go? Pretty sweet work man, you should keep going on them!

[Musi]

Don't mean to but in, just wanted to add my 2 cents. I found Khan Academy is a great site for learning math, and other things. Its what I've been using.

Here's some pseudo code showing steps to move point1 to point2, at a certain speed.

Code: Select all

// Find the X difference and Y difference.
DeltaX = x2 - x1;
DeltaY = y2 - y1;

// Use Pythagoras Theorem to find the straight line distance between the 2 points.
Distance = sqrt( ( DeltaX * DeltaX ) + ( DeltaY * DeltaY ) );

//Normalize the X and Y to make the straight line distance = 1 in the same direction.
NormalX = DeltaX / Distance;
NormalY = DeltaY / Distance;

//Multiply the normalized X and Y by the speed you want.
SpeedX = NormalX * BulletSpeed;
SpeedY = NormalY * BulletSpeed;

//Finally add that to the current position.
x1 += SpeedX;
y1 += SpeedY;

Point1 has moved the distance of "BulletSpeed" towards point 2. I think Lux's equation does the exact same but slightly differently. I suck at equations, i like small steps.

[HippoSocks]

Thanks for the reply Lux, your a great help.
As for how far I am in education though, It's not so good, the school I'm at sucks, but at least I have an education.. I leave in a few months so, It should all be fresh in my brain.

Also thanks for re explaining that, its kinda confusing at first, but the more I run it through my mind, it starts to make a small bit more sense..

I do agree with toddfather, you are quite experienced with maths, I wish I was..
I have always had a liking towards maths, but the only problem is I don't have anyone who can teach me it in a way that I would actually learn it.

I think I'm also stuck at the same step as him as well, I don't quite know what to do with the s

If you could point to a book online or some tutorials it would help me as well, and I'm sure it'd help.
But I have the feeling you studied it for some sort of qualification.

EDIT: Musi posted at the same time as me

I'll check out the site in a bit, thanks for the mention.
Also thanks for that quick example, it's quite handy to see it in that form, it does look quite similar to Lux's equation. Maybe a small difference, but same concept either way, I believe.

[LuX]

Can't really think of a book or tutorials to suggest. The page Musi shared is what I had in mind, even tho I've used it just once.

@toddfather
Haven't though about making tutorials, but a lot of people have asked about some ways to calculate things like update bullets and movement etc. Maybe if I find some time I can make a quick tutorial, video or text, about how I do most of the math part. Not like I write a new equation every time I need to calculate something, I have some math functions done and then it's simply putting stuff together.

I hope Musi's post made things a bit clearer. The only difference is, he fist normalizes, then multiplies to get the correct speed, where I go straight for the speed.

About me being a genius in math, if I compare myself with others in my class I'm more like average or so. I'm better at solving problems, maybe it's that, that makes me find solutions rather than actually being great. I think I've written a couple of posts about this.