WIP Traitor Trouble
-
@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..