Should the GameSalad team fix the friction attribute?

stevej

In physics, the value that defines the friction of an object is called the coefficient of friction (COF), and is generally between 0 (very slippery) and 1 (very sticky). You can easily find the COF of different materials on the web. In GameSalad, the COF is set via the Physics->Friction attribute. However, there is a bug that causes the value to be scaled smaller than it should be, so that a COF of 1 matches a Physics->Friction value of 50.

The question is: should we fix the Physics->Friction value so that you can use real COF values?

The up side to doing this is that it makes it easier to understand how the physics values work, and to reference real COF values. The down side is it will break a lot of games until they have their attributes adjusted. We can mitigate that a bit by auto-adjusting the attribute of old games when they are loaded into creator, but if a game sets the friction value in a behavior, the game maker would have to modify their game.

Hopscotch

Making a game "feel" right has little to do with real world physics.

I always play with values until I am happy. The game world scale is so diverse from game to game that even the units of measure in Box2D have never had any useful or predictable relevance to a game at hand.

Friction in particular has not really been a problem, to me.

Although I voted no, I am all for a fix if it brings it in line with the rest of the physics attributes, without messing up existing games.

Moik

Full disclosure: I don't have any physics-based games planned or in progress, so I'm not really one of the people this is going to harm. I've only voted Yes as I feel it would be a necessity before 'going big' on Steam.

Is it possible to make a stand-alone batch converter or some kind? Or a project importer? I do cringe a little when I think of anyone having to burn already budgetted hours to rebuild and retest physics. If there was some kind of change which meant I needed to rebuild tables I would probably be demanding compensation.

The_Gamesalad_Guru

@Hopscotch said:
Making a game "feel" right has little to do with real world physics.

I always play with values until I am happy. The game world scale is so diverse from game to game that even the units of measure in Box2D have never had any useful or predictable relevance to a game at hand.

Friction in particular has not really been a problem, to me.

Although I voted no, I am all for a fix if it brings it in line with the rest of the physics attributes, without messing up existing games.

I completely agree here. After my testing I found most of the physics stuff doesn't quite comply with the real world math. I don't think many people would use the real world math as it can be complex. I would save those fixes for when you have a creator version that may not be backwards compatable. I'm sure this day must come at some point.

iamcartez

No thanks.

Hopscotch

@iamcartez said:
No thanks.

Are you trying to tell us that each of your grains in "Salt and Pepper" are an instance actor?

RossmanBrothersGames

Rather see time spent elsewhere, and friction has worked fine for me. Most users I assume just play with it till they get the right results. Not sure how many people are aware of COF values

MentalDonkeyGames

@RossmanBrothersGames said:
Rather see time spent elsewhere, and friction has worked fine for me. Most users I assume just play with it till they get the right results. Not sure how many people are aware of COF values

This is exactly what i think.

Armelline

Somehow I missed this post. I agree with the general sentiment - it works, time is better spent elsewhere, and breaking old games is bad when the benefit is so small. When you come across a new feature or change that is worth breaking old games for, then add this change in then, as people will be having to make changes to their old games anyway at that point.

Lovejoy

Nope

Armelline

@Moik said:
Full disclosure: I don't have any physics-based games planned or in progress, so I'm not really one of the people this is going to harm. I've only voted Yes as I feel it would be a necessity before 'going big' on Steam.

Is it possible to make a stand-alone batch converter or some kind? Or a project importer? I do cringe a little when I think of anyone having to burn already budgetted hours to rebuild and retest physics. If there was some kind of change which meant I needed to rebuild tables I would probably be demanding compensation.

It's worth noting that if GameSalad made this change people would not have to go back and make a change to every actor that uses physics. It seems they are saying that any time you've changed the physics attribute directly, they'd be automatically updating that. It would be when you change friction at runtime that you'd be affected. So if you have a rule saying "If x is true then set friction to 100" etc. Very, very, very, very few games would actually need updating, and even then in a small number of places (most likely).

stevej

Looks like the nos have it. Admittedly, this bugs my OCD, but I'll have to let it go.

Armelline

@stevej said:
Looks like the nos have it. Admittedly, this bugs my OCD, but I'll have to let it go.

There are just so many other "tiny" bugs that have been around for ages that are so much more important (though admittedly that list has been shortened A LOT in recent months).

Off the top of my head:

• Project image not sticking.
• Move To overshooting.
• Un-closable dashboard.
• Multitouch essentially broken (okay that's not a "tiny" one)
• Particle startup
• Rotation not resetting at 360
• Loading wheel position/background
• Booleans in tables.
• Needing to retype values with commas.

Actually, that list was really hard to come up with. The amount of longstanding bugs quashed in recent months is really very impressive.

And I only know of one surefire way to crash the app now! I've had maybe 2 unexpected crashes in the past month. That isn't appreciated anywhere near enough!

BigDave

never experienced a problem with that so I would also say no. Don't touch it.

But you can move some actors from a moveable layer to a none scrollable a couple of times. I had around 3-4 crashes doing this today and also the last weeks. Rather hunt down that small things and make the formatting of images and sounds easier, with folders.

MentalDonkeyGames

@Armelline said:

• Move To overshooting.

This is so annoying! There has been multiple times that the "Move to" would´ve been the perfect behavior to use, but because it´s broken i always have to find a workaround...

• Multitouch essentially broken (okay that's not a "tiny" one)

I´m curious. How is the multitouch broken? i haven´t noticed any issues with my projects.
(although i´ve only used it up to 2 touches)

Armelline

@NipaDidIt said:

• Multitouch essentially broken (okay that's not a "tiny" one)

I´m curious. How is the multitouch broken? i haven´t noticed any issues with my projects.
(although i´ve only used it up to 2 touches)

http://bugs.gamesalad.com/show_bug.cgi?id=1245

Essentially, the problem is if you place two touches close enough together (in time), things will go wrong. Guru and I tested it pretty extensively, independently at first and then together, and we couldn't find a way to avoid the problem. I've not found a single multitouch implementation that doesn't fall victim to it. Luckily the problem is very rarely encountered, though!