Top Down camera gun system?

[lusty lily]

Sorry if this is way too broad kinda new to this whole studio thing, but I wanted to make a top-down camera-style gun system where you shoot from where your cursor (and body) are looking. Any Idea how this could be done. I am aware this is a bit ambitious for a first-time game. Here is what I have so far

[sullen ledge]

There are 2 ways of doing it and it depends on your camera.

If your character is always in the center of the screen (not recommended as it doesn’t look as good as a slower tracking camera (I’ll try to show a video about this later)
But then you can just base the position based on the mouse position around 0.5,0.5 (scale) (or screensize.X and Y/2)

or you can use mouse.hit to get the 3d position equivalent of the mouse and use that to base the rotation/direction off of. Yet this does make it more laggy.

[lusty lily]

Yeah I did enjoy having a bit of give in the camera tracking so it delayed ever so slightly from player movements so the first option wouldn't work.

[lusty lily]

Probably gonna try to tackle it again in the morning, so take your time, appreciate any help

[sullen ledge]

https://youtu.be/FXqwunFQuao?si=BELlaPb25Gjp3CeE

yes it’s in unity and a platformer, but the constrainting come down the to the same logic.

In case he didn’t explain it, try to make the camera slowly follow the player instead of constantly snapping to the player, it will feel smoother

[sullen ledge]

Just came up with a 3rd alternative but it does involve some more math.

You will need to find a way to determine the player’s position on the screen (as sadly roblox doesn’t do it for you)

But then you can just use the first method, which would be the most performance friendly

[prisma sinew]

using mouse.hit will not impact performance in the slightest

performance literally does not matter if it's not at scale

and one mouse.hit check a frame is negligible

[lusty lily]

Admittedly, I got my camera system off a forum, but it did have a built-in delay system, which I can tweak as shown.

[sullen ledge]

Doing it for every frame can still cause some lower performing pcs to fall behind

[prisma sinew]

still no not really

[sullen ledge]

And optimisation is never a bad thing

[prisma sinew]

yes it is actually

if you waste time optimizing and make a worse game then yeah it's a bad thing

[sullen ledge]

That’s only true when you’re on a deadline

[prisma sinew]

this video is a good dive into the topic
https://www.youtube.com/watch?v=tKbV6BpH-C8&t=626s

[sullen ledge]

I’ve no haste releasing/finishing stuff. So I just micro optimise my stuff

[prisma sinew]

yeah but you aren't getting anything out of it

theres no device thats gonna seriously struggle because you decided to use mouse.hit

[sullen ledge]

Well you are, you’re learning better alternatives to use later on

[prisma sinew]

there's a point where it genuinely actually changes nothing

[sullen ledge]

Mate, I’ve owned pcs older than most of this server, there are definitely devices that will struggle with it

[prisma sinew]

i would genuinely use a 10x worse performing method if it isn't a performance critical part of the code and it made for better readability

okay but those pcs can barely run roblox in the first place

i dont think optimizing for those kinds of systems is worth it in the long run, and you're focusing on the wrong kind of optimizations anyway

[sullen ledge]

Oh no, that pc couldn’t even run windows 7 and any browser at the same time

[prisma sinew]

yeah so why would you try to optimize in the hopes that a system like that would get one more frame in a second (it really wouldnt)

[sullen ledge]

That’s up to personal preference

[prisma sinew]

thats up to good coding practice

[sullen ledge]

If it’s not up to any preference then tell me the exact ratio for performance optimisation to readability

You can’t, as it’s up to a opinion. And differs per person/team

[prisma sinew]

100% readability 0% optimization unless it actually starts affecting performance

which is pretty rarely

like oh no my gui layout call that happens once ever takes 3ms instead of 0.5ms what will i ever do

(exaggerated numbers its more like 0.01 vs 0.002)

this has derailed very far from the original topic i apologize for that lol

mouse.hit is a simple, readable, adaptable and a solution that wont matter for performace, so i think adding on the "it might be more laggy" is unhelpful and false

[lusty lily]

Both of yall make valid points, though this was supposed to be a "test the waters" kind of game, not meant to be a super high end thing, something I figured was gonna be simple enough to do, but I have just hit a roadblock when it comes to the Gun targeting

[fickle summit]

** You are now Level 1! **

[sullen ledge]

Well then this would already be contradicting. In one of my projects I’ve to sort through a few million array entrees. I would much rather just leave a few comments then spend 10 micro seconds more on 1 entree (10 micro seconds means 10 seconds/million entrees, which can easily go up to a minute on some of these arrays)

[prisma sinew]

raycasting is not sorting through a few million array entries im sorry

of course when you have to sort through millions of array objects performance is incredibly critical

[sullen ledge]

I took a different example for one of my personal projects

[prisma sinew]

that is a performance critical piece of code and my general advice does not apply there

what im saying is in most cases, as in 99% of your code, performance does not matter that much

[sullen ledge]

Then your ratio is not true. As it cannot be applied to all scenarios. Meaning it’s subjective. Which is what I said before

[prisma sinew]

like using oop and inheritence structures and stuff is "bad for performance" but it makes your code more readable and adaptable so it's a worthwile tradeoff

i said 100% readability *WHEN not writing performance critical code

i said unless it actually starts affecting performance

[sullen ledge]

Inheritence vs composition differs on case per case

[prisma sinew]

ive had code that i had to make less readable for performance reasons everyone has to do that at some point but that's also after profiling and finding what i need to direct my attention to

[sullen ledge]

It always affects performance. Sometimes it’s simply not noticeable

[prisma sinew]

before it affected performance it didnt matter because i could technically write a "faster solution" but it just slows me down in the long run

no it doesnt. if the game runs at 240fps then the game runs at 240fps

[sullen ledge]

But what do you consider noticeable? That’s up to you, making it subjective

[sullen ledge]

On what machine? Maybe for one machine it now runs 59.5 fps instead of 60.0

[prisma sinew]

this is all "maybes" and "possiblys" though

you can always optimize later

and i feel like the bottleneck isnt gonna be your mouse.hit code

[sullen ledge]

Just agree that performance vs readability is based off of subjective preferences. We both know it’s true, just don’t even try to die on this hill

[prisma sinew]

the bottleneck is gonna be your 1million array code

[sullen ledge]

Only 1 million? I said millions, I would gladly have arrays with only 1m entrees, but that would just limit me too much

[prisma sinew]

you know what i meant

[sullen ledge]

Then I can just write a half asked mergesort and call it a dat

[prisma sinew]

obviously you have to optimize code that is actually causing issues, but trying to squeeze out an extra 0.5fps when you don't even have a game yet is just misguided in my opinion

also you can run hundreds of raycasts in a single frame on modern systems before you start to run into performance issues

[sullen ledge]

I would rather spend 1 extra day at the start to optimise the rough stuff. Then having to rewrite everything as I found out that X algorithm works faster than Y. And now I’ve to rewrite all my code to support Y

[lusty lily]

I don't mean to be that person; however, the point of this was to figure out how to get a top-down shooting system to work, not optimization, I will try to keep it as optimized as I can; however it's a first game so I don't expect it to be mega optimized, stormworks taught me the hard way to be reserved when starting out

again yall both bring valid points but I'm just trying to test the waters

[sullen ledge]

1000s even, yet you need to also think about the folks with 10+ year old pcs

[prisma sinew]

on roblox its more like hundreds

i have a pretty high end system and it was starting to struggle so i had to start multithreading

[sullen ledge]

Well yes, but I was referring to the raycast stuff. With their actually optimised rays

[prisma sinew]

i would prefer to move this argument somewhere else so we can stop clogging this support thread

[sullen ledge]

Or we finish in an ultimatum, we both agree to disagree

[prisma sinew]

fair, i dont think this argument is super productive lol

we're both arguing with walls here

[sullen ledge]

Could be worse, I’ve seen forklifts operators blame the door after they came crashing through it

And a figurative wall is not as bad as a literal wall

[prisma sinew]

sorry for hijacking this thread earlier, what is the issue you have at the moment? because it seems like the code you have does what you're describing

[lusty lily]

Yeah, I didn't want to be mean, but it had nothing to do with what I was trying to do. I will consider points made by both sides in the development

[lusty lily]

no worries

objectively I want to be able to make a system that shoots projectiles where the body is facing, kinda like door kickers or empty shell

I do have something that shoot projectiles (as seen in the video) but it felt kinda jank so wanted to see what the way everyone would go about it

[prisma sinew]

the only issue i see with this is the the projectiles are handled on the server

which isnt an entirely bad thing, but it makes the projectiles feel delayed because they have to travel across the world

what i would personally do is have the projectiles handled on the client completely if it's a single player game where that doesnt matter

[lusty lily]

i would have liked to do something 3-4 player co-op

[prisma sinew]

well you can make the particles feel LESS jank by having them spawn on the client, and have the server replicate it for the other players

because if you actually play the game there will be some delay between shooting and having the bullet appear

also another thing that may feel a bit jank is that your velocity is not added to the bullet. in the video when you are moving upwards, the bullet seems like it's going the wrong way because it doesnt move up with you

[lusty lily]

That could work; do you know what the start of that path could be? Still quite green here

[prisma sinew]

well what you have currently works fine, using the forward direction of the root part (since it points towards your mouse)

i would imagine you'd eventually also have the projectile come out of your gun when you have a gun model implemented, but for now having it come out of the root part is a good enough approximation

[lusty lily]

good catch, now that you pointed that out I see it too

I also admittedly grabbed this projectile system off a tutorial video. Do you have any idea how I would adjust the velocity value to add play speed and to adjust where the projectile comes out?

[prisma sinew]

hrp.AssemblyLinearVelocity is the velocity of the player, however it seems like the projectile code. uhhh. sucks

[lusty lily]

knew it felt jank lol

[fickle summit]

** You are now Level 2! **

[prisma sinew]

so essentially the projectile code is just moving it 1 stud forward every frame using the orientation

and that is regardless of framerate, so if the game lags the projectile will move slower, which kinda sucks

[lusty lily]

I don't have much experience (most of my Lua experience comes from Stormworks) but even then, I had a sense

[prisma sinew]

also, it does not have a velocity, and is always fixed to the same speed (so you cant have different kinds of prejectiles)

if the projectile is a part, you can set projectile.AssemblyLinearVelocity and you can run the movement code based on that

you can do something like

local targetDirection = hrp.CFrame.LookVector
local targetSpeed = 200 -- studs per second
local targetVelocity = targetDirection * targetSpeed + hrp.AssemblyLinearVelocity -- Add the player velocity as well
```to get the velocity you want

[fickle summit]

** You are now Level 7! **

[prisma sinew]

also you don't even need to set a velocity value on the projectile itself, since you still have a reference to the velocity

in the heartbeat code instead of using te lookvector * 1 you can use the velocity * delta

delta is a very useful thing in coding and essentially is how long the last frame was

so if delta is 1 then you'd move everything forward by 1 second

if delta is 0.01 second you'd move everything forward by 0.01 seconds

essentially to do "meters per second" is "meters * delta"

sorry if im being confusing, i can clarify anything if you need

[lusty lily]

I mean its a skill issue on my part, trying to figure out what bits of the code I should and shouldn't be changing

[prisma sinew]

okay so all of the code that's there is fine, its just what you need to change in heartbeat and just before it

so you need to have the direction, speed, and velocity set before you connect to heartbeat

and replace the heartbeat line with RNS.Heartbeat:Connect(function(delta)

delta is an important variable that heartbeat gives you that you can use to do the multiplication with

inside of heartbeat you want to update the position, but instead of changing it by (orientation * 1) you can change it by (velocity * delta)

[lusty lily]

so replace this with that?

[prisma sinew]

no that code is fne, that's instantiating the projectile object

you still need that there, but you also want some new information, (the velocity)

and the velocity is just the direction * speed (and player velocity)

[lusty lily]

Sorry if I'm a little too uneducated about this. I assume it's something like this?

[prisma sinew]

yes

perfect, now to actually use the targetVelocity variable

the original code is taking the projectile's position, and adding (projectile.CFrame.LookVector * 1)

essentially moving it forward

instead of using the lookvector we want to use (targetVelocity * delta)

and move it with the velocity

[lusty lily]

is it just a matter or replacing lookvector with (targetVelocity * delta)?

[prisma sinew]

yeah

[lusty lily]

alr

Alr so.. this?

right uh its getting late out here so gonna turn in for the night, have a good night sorry if I have been taxing

[lusty lily]

Should state in its current form I messed something up as no projectile is firing

[lusty lily]

@prisma sinew Sorry to bother but did I do this part right or did I mess up again?

nvm went back and forth with the assistant and got here but still doesn't take into account the players velocity?

[prisma sinew]

you have to replace line 46 with

projectile.position = projectile.Position + targetvelocity * delta

[prisma sinew]

my bad i didnt capitalize Position

[lusty lily]

yeah that fixed it aside from this oddity

somehow player velocity is messing with the targeted direction

[fickle summit]

** You are now Level 3! **

[prisma sinew]

AssemblyLinearVelocity, not velocity

not sure if thatll fix it but velocity is deprecated

other than that idk what else would e wrong

[lusty lily]

Yeah, it's still a problem. My guess is the player's velocity calculation is going negative because some things are messing with it. Would it be possible to clamp it to 0-1?

[prisma sinew]

clamping it won't help, cause you want to add the player's speed

i think the root issue here is that this is happening on the server

if you move this code to the client is your issue solved?

[lusty lily]

Unfortunately my time is up gotta head to college then work, let ya know when I’m back