Reducing size of formulas / Cleaner Codes

0 favourites
  • 5 posts
From the Asset Store
Cleanse the rain drops and save the sea from pollution!
  • I have two important points for reducing formulas sizes.

    In 90% of the time I find myself treating the X and the Y of objects in the same manner. In 90% of the time both parts of the formula (X and Y) get the same treatment.

    When calculating the distance, for example, I get this:

    Distance(ThisObject.X, ThisObeject.Y, ThatObject.X, ThatObject.Y)

    I was wondering whether an introduction of a special word will help the code look more simple/clean/nice. The word can be one of these:

    • Point
    • Location
    • Position

    This will turn the previous line to something like this:

    Distance(ThisObject.Point, ThatObject.Point)

    In more complicated formulas this idea make them even cleaner.


    Angle(Touch.X,Touch.Y, Head.X,Head.Y)-Angle(StartX,StartY,Head.X, Head.Y)

    Will turn into this:

    Angle(Touch.Point, Head.Point)-Angle(Start.Point,Head.Point)

    It looks more elegant.

    This addition will also show the attribute "Point" in Object Expression. Instead of just X and Y, we'll have "Point". Wish to set position of one object to follow another? Simply set it to follow Object.Point or Object.Position

    People who still need the inner X,Y separation can always use the regular X,Y reference as we do these days.

    The second point I wish to bring up is - Function library. I was thinking it would be cool if people can share their functions with the community by saving/loading functions. This will help bring more power to current creations by using other's functions.

    I already suggested this for objects so why not for functions.

    Such Functions library will reduce formulas and turn the code into something fun.

    The families (Great feature!) made the code cleaner. Hopefully these two points will contribute as well.

  • Distance(ThisObject.X, ThisObeject.Y, ThatObject.X, ThatObject.Y)

    Distance(ThisObject.Point, ThatObject.Point)

    Distance(ThisObject, ThatObject)

    Last one looks cleanter, IMHO.

    If the expression can extract X and Y out of the object, it looks cleaner than the "point" alternative and avoids creating yet another construct.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • How about instead of this.object we use self.x for picked?

    Its more specific, and already implemented. :P

    Ok yeah some arrays as variables would be nice, but that's probably way down on the list.

  • Fimbul: You're right of course. the Distance example you wrote about does look cleaner and it will be great to have such Function.

    But I was talking about a less specific solution. When you wish to compare the locations of two objects you won't ask:

    Does (ThisObject == ThatObject). such question doesn't make sense. What atribute of these Object you wish to compare?

    Instead you want to ask:

    Does (ThisObject.Location == ThatObject.Location)

    The same goes with other C2 activities. Removing the .Point or .Location is cool but does present a too specific solution.

    The solution I offered will simply add more flexibility and simplicity to most cases. Cases in which you wish to refer to the (x,y) as one unit.

    newt: This would be great. My point was to offer Self.Point or Self.Location as a more elegant way of referring to (x,y) as 1 entity (In addition to x and y as we have today)

    Hope I made my Point clear... :)

  • It's a good idea but very tricky to fit in to the expression parser and expression system, and the workarounds are perfectly reasonable and practical, so this is something it's more likely we'd push back to C3.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)