WIP Traitor Trouble
-
I’m thinking you will need less maths if you are using sprites, since you get collision and stuff like that “for free”. Both collision with other sprites and areas which you can define in your map, like walls...
-
The atan2() function will convert x and y (from the analogue stick, for example, or from the x and y difference between player and computer controlled sprite locations) to an angle. So you can keep that in a bullet.angle property. To convert that back to x and y movement, you can use the sincos() function. It might seem odd, converting and deconverting every time, and it is totally unnecessary and wasteful from the computer’s point of view, but for most people, thinking about angles and speeds is easier than the other way. It makes stuff like spread shot powerups and homing missiles dead easy :)
-
@toxibunny
I've tried the Atan2 and was able to get the rotation of my Sprite right when I pressed shoot.
But I need to convert the angle to movement like you said. But I still don't understand all that.
After I've pressed the shoot button, which is a function that spawns my bullet sprite
Function shoot()
BulletSprite = Createsprite()
Setspriteposition(BulletSprite,)
Setspriterotation(BulletSprite, and my complicated formula... Atan2)Return void
I want my Sprite to move in a fixed direction and stop and dissappear if it hits a wall how do I do that? You said something about the sincos().
I just need help for the movement part. For the despawning I would need a separate function but that's no matter
-
@Mechanical you can use removesprite when it hits a wall,you could modify my shoot program to fire in different directions
by modding the sprite direction using the right joystick and clamp to hold the direction if thats what your after. i'l try and modify my program to help you if you like. -
@waldron tell me more about the clamp please. Sounds like right the thing I'm after.
I use my right control stick to Aim, the angle between player and cursor is the path the projectile should fly
-
@Mechanical if you set up rotation values with your right stick and assign them clamp positions should work, il try and update my program later. set your sprite bullet direction to your target.x target.y position.
-
To use sincos() to move your sprite, it’d be something like
if bulletsprite then bulletsprite.pos += sincos(bulletsprite.angle)*bulletsprite.speed endif
In your main loop. So, if there is a bullet, it adds the x and y vector result from the sincos(angle) to the x and y vector that’s the sprite position, with a speed setting you can tweak.This is all very simple and off the top if my head, and it will only work for that one specifically named bullet. In real life, you’ll probably want to keep all your bullets in an array or something, then loop through the array. Have a function called ‘movebullets’ with that formula in that you pass your entire array to. Something like that.
-
@waldron sadly because I didn't know how to rotate sprites in the past my game is made out of colored circles being player sprites because of the symmetry :D its a left stick controlling the player and a right stick controlling the cursor which I aim with. But rotating sprites with the atan2 function would be cool as well. I even considered animating every Sprite direction but that's future stuff.
Right now I need an Algorithm that is capable of firing multiple Bullets,
rendering them all whith each one's own direction.
Despawning when hit a wall or player.I even need to watch out for self hitting if the bullet spawns inside the player
@toxibunny You mentioned Arrays before, and I opened a new discussion about arrays on Coding-Advanced.
We should settle on how I can manage all the data the bullets would need so I can build a structure. -
@Mechanical to be honest you should only have to fire on your target so while moving your target the direction of bullets when fired should do the trick, iv got a test program il share later if i get a chance
-
“ Right now I need an Algorithm that is capable of firing multiple Bullets,
rendering them all whith each one's own direction.
Despawning when hit a wall or player.”You have an array you keep your multiple bullets in, which are stored as structs.
Now what you need are functions that do the things you want. Split it up into simple manageable things, and preferably stuff that can be used for other things than just bullets. Then put those functions inside another function just for your bullets. For example:
function calculateVelocity(thing) thing.velocity = sincos(thing.angle)*thing.speed return void function move(thing) thing.location += thing.velocity SetSpriteLocation(thing,thing.location) Return void function collidedWithEnemy(thing, EnemyList) Int CurrentEnemy Int EnemyHit = 0 Int NumberOfEnemies = len(EnemyList) For CurrentEnemy = 0 to NumberOfEnemies loop If thing.pos == enemylist[CurrentEnemy].pos then EnemyHit = CurrentEnemy Endif Repeat Return EnemyHit function DoBullets(bulletlist) Int CurrentBullet int NumberOfBullets = len(bulletlist) For CurrentBullet = 0 to NumberOfBullets loop bullet = bulletlist[CurrentBullet] CalculateVelocity(bullet) Move(bullet) If CollidedWithEnemy(bullet,enemylist) != 0 then DestroySprite(bullet) Endif Repeat Return void
Again, just typing off the top of my head, and that will absolutely not work the way you want it the way it is (if it works at all) - there’s no sprite rotation in there for starters (though I hope now you can see how to put it in), and the collision doesn’t use Fuze’s cool built-in collision box system, and that DestroySprite() probably doesn’t belong there, but see how I split the problem up into parts and then put them back together? I think that’s probably a good way to go. I think it’s also good to keep your function inputs as consistent as possible - they all take the whole struct and then work from that, instead of one function taking a position vector and another taking something else and another taking something else. It helps me to do it that way, anyway. And you can reuse your smaller more generic functions for other stuff.
This is not the only way to do it - and it’s almost definitely not the best (see the recent discussion in the discord about ‘linked lists’ for a much much smarter way), but that’s what I got.
-
Hello good to be back.
I've come across a sad development. The interpreter clearly supports only 4 Players with a full controller.
Either 4 with 2 sticks or 8 with just a single Joycon is possible so I have thought it must be possible to get a convenient controls layout for just a single Joycon.
And here it gets complicated. I have written my controls so everyone has 2 Sticks and 2 Cursors. I could map the Player Sprite to the direction buttons and have the cursor use the stick.
But then I have only 4 buttons left.
Changing and selecting weapons would be absolutely inconvenient having to press either L or R switching through them...
And shooting would be problematic as well, should I have the Joycon horizontally or vertically? Questions over questions
-
Joycon horizontally, aim with orientation. 1 button to cycle through weapons, 1 to aim lock, 1 to fire.
Alternative, just fire towards movement direction, hold one button to strafe.
-
@toxibunny you mean the orientation like with the build in compass?
So implementations of the joycon hardware could be a good solution. I could tilt the controller to move a Sprite or aim...What hardware does a joycon use or which of these can we actually use in Fuze? Like Gyro sensor IR cam and so on
-
https://fuzearena.com/help/view/controls
Bottom of the page, orientation and velocity are the motion stuff. If you just use orientation[controller number].x and then atan2() it and multiply the angle by 3 or 4, that should get you something somewhat usable, I think.
The IR cam isn’t available at the moment though.
-
Everything you would expected is available on each Joycon, either joined or split, except the IR (as @toxibunny said) and the two little SR / SL buttons (when split). The reason the little buttons are not enabled has been explained elsewhere but in a nutshell, it was decided not to support them at this time.
-
Let's think about the controls again,
We have the Gyro sensor and the velocity sensor. Both are innovative and not often used in games very well or accurate.
Zelda Botw was a good counter example tho.If i recap what you said @Martin
Then a joycon has one stick 4 action buttons and 2 trigger buttons, that's itI could try to map some movement inputs like the wii had
-
How do I adress a certain Value of
the orientation or velocity of a joycon?By example:
Velocity of joycon left is stored in c.velocity[0]
I can print that, and it gives four values
{0,0,0,0}Im trying to make a Sprite move with movement. This way I could make the player aim by hand holding the
Joycon vertically.How do I adress just a single axis of the sensor in an if statement?
and
what is the fourth value? It seems to never changeI think this would feel much more intuitive than sticking to 2 Joycons.
-
@Mechanical OK so there is a type in Fuze called a vector which has 4 possible fields { .x, .y, .z and .w }. They are not always all used by things but they are always present and default to 0.
-
@Mechanical if you download the ‘improved joycon test’ program from the big share thread, it’ll show you what is happening with the numbers when you twist the joycon around. The numbers go from -1 to 1 just like the analogue sticks, and can probably be used similarly in your case (atan2 to get an angle maybe?) Be aware though, that proper recalibration only seems to be possible by docking/undocking or disconnecting/reconnecting the joycon. I think you’ll be able to get some sort of usable aiming working though if you try a few things out..