Algodoo

the game it too hard to play burh

@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.

THIS IS SO NICE CAN! CAN YOU PLEASE TELL HOW THOSE SCRIPTS WORK? PLS PLS PLS

Can I use some scripts?
Please answer. Love your work.
-CatTheFat

@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.

Oh its no problem, sorry I am kinda late to respond too, I was sleeping.. so I understood some scripts by looking into them... so I am still wondering about how the devision works. Its becouse I know that it isnt rigged, I thought it could only work with boxes. but I put the scripts in anything and it still worked. also how does the "impact" works? I played areound with the scripts and made a little game! I put the scripts that makes the cam "shacke" into a nuke. That made some fun moments.. anyways, I dont know how to devide an objects size. is it using the nurmal devide commands?
Love your work
-CatTheFat

well can you make the control is wasd and arrow keys pls

the orange one is not working

@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))