Weapon Alpha

[TheShyGuy]

You could do it based on his velocity. Then, just use a bit of trig to determine the image_angle.

For example:

image_angle = inverseCosine(velocity.x / velocity.length).

Actually, it may be better to use the inverse of tangent and use the velocities X and Y component so that the rotation works for any direction.

[Valo]

You could do it based on his velocity. Then, just use a bit of trig to determine the image_angle.

For example:

image_angle = inverseCosine(velocity.x / velocity.length).

Actually, it may be better to use the inverse of tangent and use the velocities X and Y component so that the rotation works for any direction.

Ah but thats my secret, I am almost physically incapable of math.

[TheShyGuy]

Ah ok. I'll work out the exact details tomorrow after I do some testing. Though, I suggest reading up on some trigonometry and maybe even the concept of vectors. Math requires time, hard work and practice, but you don't have to stress about memorizing anything. Just go at your own pace.

If you're looking for some specifics:

For trig:

right angled triangles
Hypotenuse is the non axis aligned side (the slanted side)
sine (sin) = opposite / hypotenuse (S = O/H --> SOH)
cos (cosine) = adjacent / hypotenuse (C = A/H --> CAH)
tangent (tan) = opposite / adjacent  (T = O/A --> TOA)
SOH-CAH-TOA
square(A) + square(B) = Square(Hypotenuse)

For Vectors:

addition of vectors graphically
subtraction of vectors graphically
length (magnitude, denoted by |a|)
direction

normalized means that the vector has a length of 1 which is very useful for directions and aiming
multiplying a vector by a scalar (a real number like x = 5, the domain is (-infinity, +infinity))
creating a vector from an angle
getting an angle from the components of a vector
dot product (scalar product) of two vectors which is very useful for things like projecting and determining the magnitude of which two vectors are in the same direction.
dot(a,b) = |a||b|cos@, where a and b are vectors, and @ is the angle between them
dot product = 0 means that the vectors are perpendicular
dot product = 1 when both vectors are normalized means that the vectors are in the exact same direction
dot product = -1 when the vectors are parallel but are in opposite direction
cross product of two vectors gives a perpendicular vector, provided that the two vectors are not parallel
cross product = 0 (zero vector) means that the vectors are parallel

I'm not suggesting that you learn how to do any of these by hand or memorize anything. I'm just suggesting to learn the general concepts so that you can use them for your games. For example, "dot(a,b) = 0" means that the vectors are perpendicular or "aimDirection = normalize(targetPosition - playerPosition)", or "missilePosition += speed * forwardDirection".

Since you're also a spriter, you can use the concept of dot products for determining how much light a surface has. In basic light shaders, graphics programmers use "lightMagnitude = dot(lightDirection, surfaceNormal)". For spriting, it means that the amount of light a surface has is equivalent to figuring out how much the light direction vector and the surface normal direction are facing eachother. When I messed with spriting, thinking of shading like this made things much easier since you're more aware of and visualizing the sprite as a composition of many 3D surfaces.

[Valo]

.

..

...

Yeah...I'm going to call it a night.

[Struggleton!]

.

..

...

Yeah...I'm going to call it a night.

This project from what I've seen has had so much work and effort put into it, that it's crazy dude! I really hope this pans out to be a full on game that everyone'll enjoy Looks great!

[Mat(Nerah)]

.

..

...

Yeah...I'm going to call it a night.

What I would do is make the scarf a separate object, and then attach it to the player. So that when you apply say "image_angle" it is not relative to the player.
I am gonna be calling it a night myself, but tomorrow If I have time I could make an example.

This made me laugh really hard though. xD

[Valo]

.

..

...

Yeah...I'm going to call it a night.

What I would do is make the scarf a separate object, and then attach it to the player. So that when you apply say "image_angle" it is not relative to the player.
I am gonna be calling it a night myself, but tomorrow If I have time I could make an example.

This made me laugh really hard though. xD

Thats what i was trying to do... It does have to call upon the player at some point tho so it knows when to point where....but i messed up a bit and it changed the players angle...rather than its own...

[TheShyGuy]

I apologize for the wait. Does this look like something you want? It's only based on the player's velocity. The red line is the player's velocity and the green rectangle is the cape. The code is as simple as

imageAngle = radtodeg(arctan2(velocity.y, velocity.x)) + 180

http://docs.yoyogames.com/source/dadiosp...ctan2.html

[Valo]

I apologize for the wait. Does this look like something you want? It's only based on the player's velocity. The red line is the player's velocity and the green rectangle is the cape. The code is as simple as

imageAngle = radtodeg(arctan2(velocity.y, velocity.x))  + 180

http://docs.yoyogames.com/source/dadiosp...ctan2.html

yeah thats essentially what i'm trying to do! I'll give that a read, thanks!

[Silversea]

You could make the scarf a separate object, but really I'd try and avoid that the best you can personally. The solution above looks fine as far as I can tell.

[Valo]

You could make the scarf a separate object, but really I'd try and avoid that the best you can personally. The solution above looks fine as far as I can tell.

it is a separate object, it is easier to set it to animate independently that way.

[Valo]

I decided to put the scarf on hold for now, it doesnt really work right at the moment and in honesty it IS just a visual flourish so it can wait a bit.
...Its a start. Current idea is to rig flying to the same overheat meter the beam uses, albeit with less effect so it doesnt fill as fast. But this does mean flight and combat must be balanced by the players skill, since you can not reliably do both at the same time.  I also need to figure a way to have you ease into the movement speeds, not just instantly begin with a movespeed of 3 even if you turn right around.  

Currently the flying is activated by jumping a 3rd time after your second jump, the jump which i still havent made proper new frames for...  Stopping flight is currently cancelled by jumping again while flying. I initially wanted to have flight cancel automatically if you touch the floor, but im beginning to decide against that for various level design reasons.

[StarSock64]

I really like your color choices for this project. They look lively and don't suffer from the weird aversion to primary colors that I feel a lot of indie games have. Maybe that's just my taste, but it makes it easier for me to take your project seriously instead of feeling like it's just some B-list game.

I think the little ship part looks like a lot of fun to just be in, before touching the controller even comes into account. That's a quality of a lot of older games that I always found admirable.

The other backgrounds remind me of ZX-meets-Sega. The yellow in the city really works

In short, I like your graphics a lot

[Valo]

y'know, ive never messed with particles before. Figured i'd try. I'm going to try to get damage/knockback coded this weekend, hopefully that wont snowball into a broken engine like last time!

[Silversea]

Particles are fun, but the default particle system isn't great at least on GM8, easier to make your own for sprite-based particles especially.

The common problem I have with knockback coding is forgetting to check collisions and ending up going through walls. Easily solved but makes for fun glitches in testing...