001 Physics

Discussion pertaining to resources, stories/characters and gameplay ideas in this forum dedicated to games that are just a faint glow.
Forum rules
Do not create a topic offering to produce resources. Click here for the reason.

Please use above resources section of site so everyone can have access to the resources you create.
User avatar
Mr.Numbers
001 Support
 
Joined: Wed Feb 28, 2007 1:50 am
Location: Alberta, Canada

001 Physics

Postby Mr.Numbers » Fri May 22, 2015 9:37 pm

Rather than posting these randomly throughout the forums, may as well make a topic showing some nifty little physic-y things I've made using 001.

How most of my stuff works is based on 4 variables. 2 variables that holds the X/Y Velocity, then another 2 holding the X/Y Force that is to be applied. For instance, in the example below I have a constantly increasing Y force (Gravity), a force that constantly moves the X/Y force to 0,0 (Drag) and X/Y Force simulation via mouse clicks. There are zones on each side of the map that multiply either the X or Y forces by -0.8, which reverses the movement direction (Or in other words, bouncing) as well as "Absorbs" some of the force causing the ball to slow down after each bounce.
There is also a Y value check to ensure that once the ball is "Resting" on the floor, that gravity is no longer applied until the ball is in the air. There is also a force being applied when the ball is on the ground slowing it down faster, aka "Friction".

This is done purely in a top-down map, to ensure 001 isn't affecting the outcome in any way.

Image
I AM THE ALL MIGHTY SCRIPTING MASTER
Please do not PM me with Engine 001 related questions, rather post on the forums. ;)

User avatar
Gamerdude
001 Support
 
Joined: Wed Dec 12, 2007 8:56 pm
Location: Australia

Re: 001 Physics

Postby Gamerdude » Fri May 22, 2015 11:22 pm

Wow, that's really smooth. Nice work man.
Image
Image

User avatar
SBG
001 Subscriber
 
Joined: Thu Jun 17, 2010 8:37 pm
Location: merca

Re: 001 Physics

Postby SBG » Sat May 23, 2015 11:27 am

Top down huh? So you've basically made your own gravity system using only X and Y coordinates? That's pretty sweet! Would love to see this applied to a 3D environment.

User avatar
AnvilHouse
001 Support
 
Joined: Mon Mar 04, 2013 1:19 am
Location: Wisconsin, USA

Re: 001 Physics

Postby AnvilHouse » Sat May 23, 2015 11:30 am

SBG wrote:Top down huh? So you've basically made your own gravity system using only X and Y coordinates? That's pretty sweet! Would love to see this applied to a 3D environment.


001 Sports you say? :lol:
Image Image Image

https://www.patreon.com/Anvilhouse ...yes...I am on Patreon!


-The store is under construction-
All items are guaranteed to work with 001 ;)

User avatar
Mr.Numbers
001 Support
 
Joined: Wed Feb 28, 2007 1:50 am
Location: Alberta, Canada

Re: 001 Physics

Postby Mr.Numbers » Sat May 23, 2015 11:42 am

Gravity is actually the easiest part :P All it does is add a constant value (In this case 0.05) every 0.01 seconds to the "Y Force" variable.

If I were to disable gravity, and add some actor-to-actor collision, could easily make a pool table :P The entire system is pretty customizable that way as everything is stored in actor variables.

Image


Script if anyones interested:
Image
I AM THE ALL MIGHTY SCRIPTING MASTER
Please do not PM me with Engine 001 related questions, rather post on the forums. ;)

User avatar
Kilatorian
001 Support
 
Joined: Sat Oct 18, 2014 12:11 am
Location: Planet Earth

Re: 001 Physics

Postby Kilatorian » Sat May 23, 2015 12:34 pm

I do something similar, except it's in the front view and I use the built in actor acceleration for the friction against surfaces and I intentionally don't add drag. I've been trying to figure out a way to optimize this, as right now I just have a while timer that constantly keeps track of the actors x,z velocity and use a collided with solid trigger that works like your zones do. It just feels unnecessary to constantly keep track of so many actors velocities.

Would it be more efficient to just have 4 When triggers with collision checks to set the previous velocity right before impact? Or is there some magical way to get the actors impact velocity from within the collided with solid trigger?


It would be cool to calculate mass into the equation. You could also check to see what tile set it hit, so each one could have a different amount of bounce absorption.

User avatar
Mr.Numbers
001 Support
 
Joined: Wed Feb 28, 2007 1:50 am
Location: Alberta, Canada

Re: 001 Physics

Postby Mr.Numbers » Sat May 23, 2015 12:42 pm

I'm not entirely too sure, I used zones simply because it was the quickest and probably most memory efficient way for the time being :P I used zones for my Bounce! game as well, again, for simplicity sake - although they were fancy zones that automatically calculated the side the ball was hitting, and reacted accordingly. (Thus, making them super quick to add to a map)

Now we all knew that this was going to happen, but its a party in 001!


NOTE: When the balls hits the bottom corners there is a zone that flings them in the air to agitate them more, otherwise its not really as exciting :P


EDIT: Re-read you post, I'm highly against using any collision checks as the trigger for a when trigger. When triggers check EVERY frame, so it would cause some considerable lag.
If you keep track of the velocities in an X/Y fashion, in the "Collided with solid" trigger just use those X/Y values, as that will then tell you how fast the actor is moving AND which direction it is moving when it collided. Chances are, if the actor collided when moving in a down right fashion, it either hit a wall on the right or the ground, which you can then apply a left or upwards force (Depending on the surface) to slow the actor down.

Of course, the above wouldn't work if whatever its colliding with is moving, as it could move into the object.
If that is the case, you can run 4 collision checks inside the "Collided with solid" moving the actor up, down, left and right 1 pixel to determine where its hitting (U, D, L, R, UL, UR, DL, DR) and then act accordingly. You may want to run more than 1 pixel based on the speed the actor is moving, the faster its moving the farther its likely to get pushed into the wall.

I could have completely misread your post of course. :P
Image
I AM THE ALL MIGHTY SCRIPTING MASTER
Please do not PM me with Engine 001 related questions, rather post on the forums. ;)

User avatar
Danny
001 Forum Master
 
Joined: Tue Jul 12, 2011 7:14 am

Re: 001 Physics

Postby Danny » Sat May 23, 2015 2:18 pm

Thanks for sharing this! Is something i wanted to know how to do for a longggg time. Nice one Numbers :D

User avatar
Kilatorian
001 Support
 
Joined: Sat Oct 18, 2014 12:11 am
Location: Planet Earth

Re: 001 Physics

Postby Kilatorian » Sat May 23, 2015 9:08 pm

Yeah, you answered my question about the When triggers. I basically do it the way you just explained with the 4 collision checks. On every actor I have a while timer that runs at .1 and all it does is store the actors velocity.x,velocity.z to my actors custom velocityx and velocityz variables. I'm also using the built in gravity and it works great.

I was just looking for a way to not keep track of the velocity. See the collided with solid trigger sets the velocity to 0 so you can't just set the actors velocity.x to it's current velocity.x * -.8, which would be ideal. I wonder if the actors velocity upon impact is stored anywhere, or could be, and I could just request a 'velocity upon impact' use value that could just be used with the collided triggers. If that makes sense.

User avatar
Mr.Numbers
001 Support
 
Joined: Wed Feb 28, 2007 1:50 am
Location: Alberta, Canada

Re: 001 Physics

Postby Mr.Numbers » Sun Jun 28, 2015 11:06 pm

Ahh, thats where our scripts heavily differ. In my case, I don't use ANY of the default 001's forces or gravity, for me, the velocity is stored in an actor variable. That way, when it does collide with something the value hasn't changed yet.

What you could do is store the current velocity x/y in an actor variable using your already set 0.1 while trigger, then access it inside the collided with solid trigger. As long as you don't use any delays inside the collided with solid trigger, in theory, the velocity wont reset to 0 by the time the collided with solid trigger plays.


EDIT:
A little concept of something I'm working on. I completely re-worked my bouncing physics in an attempt to simplify things a little. (Reworked as in different and less code than the one used in "Ball Bouncer")
Only down-side is it seems it doesn't always like corners, it still needs some optimization. Probably will have to add in some velocity-math shinanigans to make the detection better at higher speeds (They sometimes rarely fall through blocks)
Image
I AM THE ALL MIGHTY SCRIPTING MASTER
Please do not PM me with Engine 001 related questions, rather post on the forums. ;)

Next

Return to Resource, Story and Level Design

Who is online

Users browsing this forum: No registered users

cron