GameSalad

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Should the GameSalad team fix the friction attribute?

stevejstevej Posts: 435Key Master, Head Chef, Member, PRO GameSalad Employee
edited November 2015 in GameSalad Kitchen

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.

Should the GameSalad team fix the friction attribute? 33 votes

yes
36%
kolaboAlchimiaStudioscrazycam99GSAnimatorMoikRainbrosvafurlogixJadonxpHghostdapack90@gmail.comSEMAarturosanz 12 votes
no
63%
quantumsheepArmellineChunkypixels[Deleted User]The_Gamesalad_GuruBraydon_SFXEireStudiosvikinggrishlockneomanSocksBigDaveiamcartezHopscotchRossmanBrothersGamesapp_sauceNicrisfreneticzLovejoyMentalDonkeyGames 21 votes

Comments

  • HopscotchHopscotch Posts: 2,782Member, PRO
    no

    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.

  • MoikMoik Posts: 257Member, PRO
    yes

    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_GuruThe_Gamesalad_Guru Posts: 9,913Member
    no

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

  • iamcarteziamcartez Houston, TexasPosts: 648Member
  • HopscotchHopscotch Posts: 2,782Member, PRO
    no

    @iamcartez said:
    No thanks. :)

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

  • no

    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

  • MentalDonkeyGamesMentalDonkeyGames Posts: 1,276Member
    no

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

    Mental Donkey Games
    Website - Facebook - Twitter

  • ArmellineArmelline Posts: 4,777Member, PRO
    edited November 2015
    no

    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.

  • LovejoyLovejoy Posts: 2,078Member
    no

    Nope

    Fortuna Infortuna Forti Una

  • ArmellineArmelline Posts: 4,777Member, PRO
    edited November 2015
    no

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

  • stevejstevej Posts: 435Key Master, Head Chef, Member, PRO GameSalad Employee

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

  • ArmellineArmelline Posts: 4,777Member, PRO
    edited November 2015
    no

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

  • BigDaveBigDave Posts: 2,239Member
    edited November 2015
    no

    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.

  • MentalDonkeyGamesMentalDonkeyGames Posts: 1,276Member
    no

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

    Mental Donkey Games
    Website - Facebook - Twitter

  • ArmellineArmelline Posts: 4,777Member, PRO
    no

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

Sign In or Register to comment.