dop2000's Forum Posts

  • Please share the working link to your capx

  • You don't need an array, you can do this with instance variables.

    Add "isUnlocked" and "isSelected" instance variables to your character sprite/family.

    In "Team Edit" menu display only characters that have isUnlocked=true

    When player clicks a character, toggle isSelected variable.

    To keep track of how many characters are selected, you can use a counter variable, or you can pick all characters with isSelected=true and use expression character.PickedCount to get the number of picked instances.

  • If you've never tested your game on mobile, I strongly suggest you use WiFi preview before actually building the mobile app:

    https://www.scirra.com/tutorials/247/ho ... al-network

    If everything is fine with the preview, you can use Cocoon.io or PhoneGap to build the APK.

    Just search this forum, there are lots of manuals how to do it, here is the most recent post:

    tutorial-build-signed-apk-in-android-studio-phonegap-build_t196001

  • You don't need arrays..

    You can use a simple variable MenuSelected (which stores a number id or a text tag of the button) and, say, a function that will set "Blink" animation for the selected item and "default" for others.

    On button Up pressed -> 
   set MenuSelected to Max(1, MenuSelected-1)
   Call Function UpdateMenuButtons()

On button Down pressed -> 
   set MenuSelected to Min(4, MenuSelected+1)
   Call Function UpdateMenuButtons()

On Function UpdateMenuButtons
   MenuButton -> Set animation to "Default"
   Pick MenuButton with id=MenuSelected -> Set animation to "Blink"
[/code:3dllbdl8]

If you prefer working with string tags, this expression may be handy to minimize the number of events:  
(condition ? result_if_true : result_if_false)

.....set MenuSelected to (MenuSelected="controls" ? "start" : (MenuSelected="start" ? "continue" : (MenuSelected="continue" ? "story" : "controls")))

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Your first "On collision with waypoint" event picks one waypoint. You can't just pick another waypoint in the same event or its sub-events.

    Try adding "System -> Pick All waypoint" before "Waypoint pick instance with UID" sub-event.

    If this doesn't help, then move this sub-event to a function.

    Something like this:

    ... Call Function MoveToWaypoint(Enemy.UID, Enemy.MyNextWaypoint)

On Function MoveToWaypoint
  Enemy pick instance with UID= Function.Param(0)
    Waypoint pick instance with UID = Function.Param(1)
         Enemy Find path to (waypoint.x, waypoint.y)
[/code:1twtbp6e]

  • You don't have to tag Ashley

    This sprite must be a member of a family and this behavior is probably defined on the family.

  • justintime0185 your link is broken, try posting it without the "https://" part

  • Here is the result of 10 seconds of googling <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    Subscribe to Construct videos now

    https://www.scirra.com/tutorials/4777/h ... background

    viewtopic.php?t=63134&start=0

    best-way-for-infinite-scrolling-background_t99686

    https://www.scirra.com/tutorials/309/cr ... s-textures

  • You should not use Physics together with any other movement behavior like Platform or Bullet.

    It is recommended that Physics objects are only moved with physics actions (apply force, impulse etc) and only interact with other physics objects.

    As for the issue with object not sleeping, I had a similar post a few days ago and R0J0hound recommended to use Chipmunk behavior:

    Chipmunk objects go to sleep much easier. So you can try it instead of the built-in Physics.

  • The nature of the game makes it very hard to maintain consistent and predictable difficulty.

    Again, think of Candy Crush Saga - when new candies are generated, I can prevent them from forming groups with existing candies, thus increasing the difficulty. Or I can force them to form groups, making the game easier. But I can't do this all the time, or it will become too obvious.

    Also, I can't predict player's moves. Player can make a clever or very lucky move, match lots and lots of candies and score lots of points.

    I am gradually increasing difficulty as the player progresses through levels by introducing more obstacles/enemies and adding more tasks to complete. But the amount of points player can score in each level is still greatly depends on random generator...

  • In some of my match 3 demos, instead of creating a swipe directional recognition, I used a single touch trigger.

    You mean when there is only one possible match at that location?

    Otherwise it can actually be frustrating for players if they want to swipe right and the game swipes left instead.

  • So when the NPC reaches the location (water) it doesn't stop and continues to walk?

    There is probably something wrong with your code, it's hard to tell without seeing it.

    Maybe you are interfering with the sequence of pathfinding events somehow, for example calling "find path" repeatedly while NPC is still moving or something like that.

    For priority you can add some kind of ImportanceFactor. Say, for thirst set it to 1, for food 0.8, for tv 0.3

    Then to determine which action NPC should take, divide each instance variable by ImportanceFactor, for example:

    hunger=3 / 0.8 = 3.75

    thirst=3 / 1 = 3

    tv=2 / 0.3 = 6.66

    So the NPC should go drink first.

  • I'm creating a puzzle game with 200+ levels.

    It's based on Match 3 concept, but the gameplay is completely different.

    For the purposes of this post, imagine it's a variation of Candy Crash Saga. (although it's not )

    There is a lot of randomness in the game and levels are generated randomly, so the final score for each level depends not just on player's skill but also very much on luck.

    Besides, players can use magical gems during the game which can significantly increase the score in each level.

    Basically what I'm saying is that scores in each of individual levels are not that important, as they can vary a lot and don't represent payer's skill.

    This and the large number of levels makes me think that making 200 online leaderboards (one for each level) is probably not a good idea.

    But I still want the players to be able to compete with each other.

    I'm thinking of several ideas:

    1. Pick just one score - the highest of all levels. The problem is that some levels are much easier than others, so again, this will not be an accurate way to measure the skill.

    2. Cumulative score of all levels (sum of all scores). The problem here is that a less skilled player who finished 150 levels will have a larger cumulative score than an expert who finished only 50.

    3. Average score. It's the most accurate method to measure the skill, but the average score is very inert, it will be hard for players to improve it.

    4. Total number of stars. At the end of each level I'm awarding 1,2 or 3 stars. This method has the same disadvantage as #2

    5. Break 200 levels into chapters. Have a separate leaderboard with cumulative score for each chapter. My levels are grouped by 10, this makes 20 chapters and leaderboards - still quite a lot...

    What should I choose?

    I don't play many mobile games, so maybe a better solution is already invented, I just don't know about it?

  • Main article:

    https://www.polygon.com/2017/9/2/162471 ... er-secrets

    The original twitter thread is very long but also very educational. Here are a few tweets that caught my eye:

    [quote:3srgzcc0]In games with nitro/boost mode, the actual speed increase is often small, hidden by the FOV pull + psychological sensation of being "faster"

    In Bioshock if you would have taken your last pt of dmg you instead were invuln for abt 1-2 sec so you get more "barely survived" moments.

    The thugs in Arkham Asylum will avoid doing 180' turns at all costs to allow you to feel stealthy and sneak up behind them.

    The Suikoden's world map is made to not frustrate players. If players walk in a straight line, less enemies will appear, bc they're clearly trying to go SOMEWHERE and don't want towaste time. If players zig-zag around, more enemies will attack, to help them grind.

    In Stellaris, we use 'tit-for-tat' mechanics to make the computer feel more human. For example: If you insult an AI-controlled empire... they usually insult you back, and grabbing space near them will make them prioritize taking systems it thinks will annoy you.

    In Bloodborne, if you're reloading your weapon your character's collisions are temporarily disabled to give you a safe reload period.

    Small enemy colliders on 2D platformers for that feeling of *Just* dodging them.

    In Infamous, if you fire and your crosshair just tracked across an enemy, we'd retroactively make it so you fired at the exact right moment. Makes it feel like your aim is better than it really is, without the usual auto-aim effect of "the game is aiming for me".

    Peggle had a hidden "luck" variable that was cranked up for the first few levels that made the ball bounce in the most beneficial angle.

    Would be interesting to hear from Construct developers - what secret mechanics do you have in your games? <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • Using a boolean variable seems like a good solution.

    On every tick -> call Function.ProcessOne()

Function ProcessOne()
   Pick Family where isProcessed=false
       Pick random Family instance -> do something with it, set Family.isProcessed=true
   Else
       Pick All -> Family set isProcessed=false
       call Function.ProcessOne()
[/code:bv3nyqfd]

There is nothing in this code that could affect performance, it should work very fast. Function will be called recursively only once in many ticks.