Algodoo

@lokyinng I've updated the description to hopefully explain things more clearly.

If anyone wonders why it's called Smashy Ball Testing, it's because I got totally mixed up on which scene to edit and upload and ended up uploading the wrong one. I tried to change the name back but it didn't work and I don't know why.

@CatTheFat all my scripts are free to use. For a general overview of how the scripts on this scene work:
- The players each have a health value which is synchronized with a public variable and when the health changes the damage / heal ring around the player will light up when it detects the change in the health value. If a player runs out of health, it will either be teleported to the spawn point and get a life removed or disappear completely if there are no more lives left.
- The lives you see at the top of the screen are just objects that will despawn when the life number for whichever player they are representing drop below a certain point. For example, the 3rd life circle for player 1 will despawn when the amount of lives for player 1 drops below 3.
- For boost mode and heavy mode, I created a system where there are two variables, one for the current state and one for the "cooldown". When you use boost mode, the current state will go from 0 to 1 and the cooldown will start slowly counting to 1. The power for boost or heavy mode is calculated based on the difference between the current state and the cooldown. This means that when the cooldown reaches one, there will be no difference between the current state and cooldown and the power will be 0.
- The particle effects are fairly simple. I basically just spawned each particle with all of its properties initialized along with a postStep to control it over time and delete it when it's used up its lifespan.
- Some of the objects will take into account the angle (e.normal) and impact force (e.soundgain) during a collision (saws, forcefields, player collisions) and use that data to spawn particles going in a certain direction. The saws will spawn spark particles going outward from the collision point, the forcefields will spawn sparks going outward from the center, players will calculate the damage based on the impact force and their current mass, etc.
- The camera movement is calculated based on an actual circle attached to springs which you can find above the arena. When the camera gets "shoved" in a certain direction, that circle will get its velocity set in that direction and the camera will be offset by the circle's position relative to its resting position.

Sorry for answering so late, I get no notifications when someone posts a comment on one of my scenes.

@CatTheFat This is awesome! I replied to your comment on Smashy Ball by the way. I don't get any notifications when someone comments so I have to check it for new comments occasionally.

@CatTheFat the division was kinda complicated. I can't remember the exact equation but basically, for each of the small boxes, it calculates an offset from the center of the big box based on the amount of division, the width of the big box, and the X and Y index of the small box (two nested FOR loops are used to construct a grid of small boxes, one for the X and one for the Y index in the grid); then it calculates the size of the small box with a simple <big box size> / <amount of division>, sets the angle of the small box to the angle of the big box, does a linear transformation (common thing in game engines that handles everything like location, rotation, and scaling) to figure out where the small box would be if the big box is rotated, and finally clones the velocity and angular velocity of the big box to the small box. The whole thing is kinda complicated and requires a lot of math (As mentioned in one of the scrolling tips, 3Blue1Brown is a very good resource for all things math.)
The impact is pretty simple, there is a variable named soundGain on the event object of onCollide which is the total impact force of the collision. The only thing extra I did for the collision damage was multiply the force by 1 / player density. This means that if two players collide mid-air, the one that has less density (if player one is using boost mode and player two is using heavy mode, then that means player one) will take more damage from the collision.

ANNOUNCEMENT: I have recently gotten a better PC (For a long time I used an Intel NUC i3 potato) and have started learning Unity for good. My current project is to recreate this game in Unity (and also fix the 50 million issues with this version like balancing the damage system and fixing lots of other random bugs etc). I'll try to post my Unity version publically when it's in a playable state and I will include a link to it here.

PS. wow i actually did something i said i was going to do in the future

ANNOUNCEMENT: My Unity remake is now mostly playable and is avalaible from a public GitHub repository at https://github.com/XVNexus/brutalsky. So far I have remade the damage system, movement system, graphics, and controls, and the new controls are a lot easier to use for limited keyboards (no numpad usage, less keys required so less key rollover issues (if you press too many keys at the same time some don't get detected, like my keyboard), and should still work fine for ergonomic keyboards with a split down the middle (like mine))