Though for this 2d shooter project, being 2d and all I should just be using vector2s the whole time I think?
You theoretically could, except there's a bunch of stuff that assumes a vector3 and will error if you give it a vector2 - off the top of my head, transform.position is one of them, and if you send it a vector2 it'll complain.
It'd be easy enough to make a method that takes a Vector2 input and spits out a Vector3 output to fix any of those examples though.
Thanks, this is extremely informative. A lot of what you wrote in the code sections is flying over my head but will spend time and try to parse and understand it all later when I have some time.
the only things you might not be immediately familiar with are
[serializefield] in my variables, and Oncollisionenter() having a Collider callback
[serializefield] is an attribute, that basically means the variable shows up in the unity inspector so you can mess with it outside of code, but you don't have to expose the variable as public (ie you don't need to let other scripts mess with it directly).
OnCollisionEnter is a prebuilt method (like Update() ), but it returns a pointer to the thing it collided with as a variable of type Collider, so you can access it.
One comment though, you said the way the projectile code is written is bad and you should be using 2drigidbody. The thing is that my class project using the assets they give us (including that projectile code, which they say is the most simple script included), is using 2drigidbody. Like we had a whole session on rigidbody because when we first made the ship player and put an enemy with projectiles in the projectiles would just pass through the player ship until we added 2drigidboy and definied the hitbox.
Not sure what that means because this is beyond my scope of understanding that the projectile code is setup that way along with using rigidbody for collision.
Basically, Unity is running 2 simultaneous timers; one is the rendering timer, which by default runs at 60 ticks per second and is called from Update()
The other is the Physics timer, which by default runs at... 25? ticks per second, and is called from FixedUpdate()
A rigidbody component basically just tells Unity the thing its attached to has 'physics' and it should keep an eye on it for things like collisions.
Generally you want to put anything physics related into FixedUpdate rather than Update, so Unity knows about it and is checking on the physics tick, not the rendering tick.
So if you just wanted to have like... clouds and shit flying past in the background, you could use a basic transform.position on them in the Update() loop.
Something like a bullet though, you probably want to move the rigidbody (which the simplest movement is just rigidbody.position) rather than the thing the rigidbodys attached to, and do that in FixedUpdate().
Its basically more reliable in terms of 'catching' collisions, as you can probably imagine moving stuff thats supposed to interact with each other at entirely different tick rates is kinda sketchy.
Also I want to understand what you're saying about time.delta and shmup slowdown because if I can add shmup slowdown to this with a ton of bullets/enemies that would be kind of cool.
Time.deltatime is there to give the impression of smooth framerate, even when its not, and anything in Update() is directly tied to framerate - oldschool games didn't have two different timers, they had one thread, so when that shit got busy, the whole game slowed down because the framerate was the speed the game was actually running at.
With Unity (and most modern engines I think) having rendering done separately to game logic means you get gameplay independent of framerate, so your dude moving at 10m/s at 100fps is the same 10m/s as someone else playing at 10fps, they just move each of you a different amount per frame so it averages out over a second.
For deliberate bullet time type shit, you can mess with time.timescale which will slow / speed up time itself; this will fuck with time.deltatime, but if you still need that for smoothing during bullet time or whatever, you can make your own version based on uhhhhhh time.realtimesincestartup or something, then average that out to get your own averaged time per second value.
(I only know this because the UI animations used to be linked to Time.deltatime, and if you did ez mode pause button of timescale=0 the fucking ui stopped working
)