Rate this camera out of 10?

Help and Feedback Creations Feedback
#1

So I’ve set up a camera, to be used for spectators who have died in the game. Instead of the regular spectator switching or what not, I wanted to give it some uniqueness.

I’m going to also make sure the part is invisible using transparency, this was just for debugging purposes.

Is it also a good idea? Instead of just using the regular switching to a different player shenanigans?Should I just use this instead?

10 Likes
#2

Should I use this as a spectator system or use the regular spectating systems you see in many roblox games?

I’ve my own scripts for either one so let me know.

1 Like
#3

Yes! this is a 9/10. and is this free cam?

3 Likes
#4

Basically, I sorta thought outside of the box.

This is using the regular camera system, the camera type is still the default. Custom.

The code for this script is 100 lines, and i’m glad I didn’t use tutorials. i’m proud I was able to make it :smiley:

4 Likes
#5

Proud of you! Im just a builder not a Programmer so im not the best at this.

2 Likes
#6

Thanks, i’m happy you liked it. One more question though, you don’t need to be a scripter to answer:

Would you prefer this as a spectating system, or the regular switching from player to player? What I mean is would you rather have this camera system for spectators or this?

Obviously I would make the UI look better but yeah.

1 Like
#7

I like this! Maybe a next step would be to force it first person, that way the zooming wouldn’t be awkward. You can adjust the FOV too.

Did you make this using things like LookVector (and others)? And is this more event and/or function-based, or is this entirely a looping script?

1 Like
#8

Oh yes I already know how to do this, the only reason I didn’t make the part invisible and what not was purely since its in a testing phase right now.

Good idea!

I was going to use lookvectors orginally, but I realised it was working purely just by offsetting CFrames.

And yes it’s mostly event-based, there are temporary loops to check if the player is holding down the keys instead of just a click however.

The only one script that is sorta looped is a renderstepped event that makes the part’s cframe look at the camera’s cframe, for the turning of course.

3 Likes
#9

I like the more free cam one, as you can see the all of the map so this one.

1 Like
#10

Alright great thank you.

30char

1 Like
#11

Np i hope i helped you! Have a good day!

1 Like
#12

What if you unbinded a bound .RenderStep function from within itself?

for instance:

local UIS = game:GetService("UserInputService")
local RS = game:GetService("RunService")
local W_HeldDown = true

UIS.InputEnded:Connect(function(input) -- when you let go of W, make W_HeldDown false
	if input.KeyCode == Enum.KeyCode.W then
		W_HeldDown = false
	end
end)

RS:BindToRenderStep("silly", 199, function()
	-- run code
	if W_HeldDown == false then
		RS:UnbindFromRenderStep("silly")
		end
end)

I don’t know about optimizations, but you can always use a repeat until loop as well (so it won’t run every frame, at the cost of it being more static-ey).

1 Like
#13

In my opinion, you should have both. Free cam is cool, but having to always track the player can be tiring. So why not both? I’m pretty sure I’ve seen both in one game so maybe you can look around to see if it works.

1 Like
#14

Oh no no, the script is not like this.

It originally was a renderstep loop for the holding down right mouse thing, but I realised I could use events for those aswell + debouncing.

Also the script is only enabled if the player is in the spectator team, so it’s quite optimized I’d say.

I’m pretty sure a repeat loop is more harmful on resources actually.

1 Like
#15

it’s just a freecam? ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎

1 Like
#16

Oh yeah good idea then. That makes sense.

1 Like
#17

Yep, I was just wondering it looked nice and if I should use this or the regular spectator systems.

1 Like
#18

Interesting!

Really? How so? Also if it wasn’t clear, the loop would be intended to have some waiting time in between (e.g every 0.05s (which would be once every 3 frames on 60 FPS)).

1 Like
#19

Actually, they’d probably be around the same in terms of performance.

However, the X factors are readability and smoothness. I’m pretty sure it would be slightly more smoother than a repeat, also my original code would basically be an infinite loop so I’d have to do:

repeat
until
true

Which looks worse imo rather than just an event with runservice.

1 Like
#20

This camera looks nice! I rate it 9/10! Good job on it! How long did it take to make it?

1 Like