Mipey's Forum Posts

  • Imagine that conditions are filters; all objects that pass through the filter are treated as one when you apply the action to them. The "For Each Object" condition instead executes the action for each individual object that passes the filter.

    I hope that helps clear it up

  • Add the following condition to the Every 800 ms event:

    For each enemy_1

    (you'll find it in System)

    This will ensure that each enemy is evaluated instead of all at once, thus in turn each bullet will shoot off into its own direction.

    Also, get rid of the enemy_bullet1_collition. Just check for collisions between bullets and player. (The collition sprites weren't moving at all, by the way. They stayed where they were spawned.)

    You might want to move the player_bullet action to the spawning event. It is pointless to change its angle to -90 every tick, once it is already facing that angle.

  • Well, I can't tell what's making them fly straight without looking at the .cap.

  • Hm, do you have any other events or behaviors affecting the bullets?

  • Assuming that your bullets have Bullet behaviour, you can do the following:

    +Every 100 ms

    BigBadMeanGuy: Spawn Bullet

    Bullet: set angle to BigBadMeanGuy.Angle - 45 + random(90)

    They will fire randomly within the 90 degree cone in front of them.

  • Kind of. Sprites add to the overhead, it does show when you are working on a major project.

  • I hate trivial achievements, though... they are by FAR overdone. Such as: "You breathed!" or "You used your mouse!" achievement. In my opinion, achievements should be awarded for non-trivial accomplishments, such as finishing a game, doing an optional overly dragged-out side quest or stuff.

    /rant

  • Yes.

    No.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are global and private variables as well as array/hash/python options. However, I believe it would make sense to have Layout-specific variables as well. Too often I find myself using variables that pertain to the current layout only.

    These variables could be set to "persist" - remember the value after layout is closed - or "forget" - reset to the default value after the layout is closed.

    These variables would be accessible through Layout properties as well as system expressions. Perhaps local('variable') just like global('variable')?

    Should the need to retrieve other layouts' variables arise, I suppose that could be done by adding another expression: get layout variable(layout, variable) or something.

    I reckon this would be of great help. I feel such a layout-specific variable is the missing link between global and object variables.

  • Or use Python data structures. I'm going to do so for my next project.

  • Or, when in the dialog that wants you to enter expression, double-click the object to get a list of available expressions.

  • Each object has Unique ID. You can retrieve it using the Get UID expression or .UID suffix (ex. Sprite.UID).

  • ClickTeam?

    Edit: curse you, Dreadeye! I shall defeat you one of those days!

  • I see, thanks. At first it didn't work within quotes, but I've must made a subtle typo then.

    Disregard this thread, I'm stupid.

  • Hmm, then what is the difference from System.CreateByName?