brushfe's Recent Forum Activity

  • It's so great you bring this up! The typewriter plugin is exactly the kind of thing C3 should do so well. It's something so many types of 2d games use in different ways, but it is missing some essential features.

    I'd added my thoughts on what's vital in this post:

    construct3-21h2.ideas.aha.io/ideas/C321H2-I-38

  • Sure thing! The important thing to remember about Event Sheets is that they're processed over and over, from top to bottom, in a never-ending loop (and dozens of loops per second).

    In your screenshot, for example, if the user is holding "down", the event in the red box is triggered every tick. Meaning around 60 times per second, the "crouch" animation is being played - from the beginning of the animation, which is why you're seeing it stuck on the first frame.

    In the screenshot below, you can see the "Duck" animation only starts playing if it's not playing already. So the user can hold the down key as long as they want, but the "Duck" animation will only play once, and play all the way through.

    Let me know if this answers your question!

  • This is great! The concept is awesome and the levels are really cool — they feel like Super Mario World levels in a pinball game.

    I really want to spend more time with this and finish it!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think you can simplify your events to have more dependencies, rather than a series of individual events.

    If you use what arrow key is being held down as the main condition, you can modify the actions a little easier.

    For example, below, you can see if the right arrow is being held down, we first check if the command key is held down, and then set the animation accordingly.

  • It looks like you're starting the animation over every tick.

    Your code says "Every tick, if down is pressed, start playing the crouch animation at frame 0."

    I think you only want to play the animation if it's not already playing. Try adding an "is not playing crouch" to your sub-event next to "is on floor".

  • That may be because pathfinding -> find path is one of the "asynchronous" actions.

    I believe these few special actions are designed a little differently. Calculating a path can take anywhere from one tick to five seconds depending on the layout, CPU speed, etc, so it needs to run in parallel or the program will hang until it's done. Each sprite looking for a path may take different times to find its path, or the same time.

    So it basically has a "for each Sprite" built into it. The timer trigger does not, like most triggers. So on a tick where multiple identical timers go off, your single timer trigger will be considered enabled, and it'll go off a single time.

    If all this is true, you should always use a "for each" condition on synchronous actions (like timer). Try putting a "for each sprites" condition on your timer trigger and see what happens.

  • There are much smarter folks on here than I, but I think conditions will pick a random instance from all possible objects that meet its criteria.

    So using For Each is a great way to ensure that every object that either triggered the condition or meets the condition are picked for the subsequent actions.

    I use the Browser log as an quick way to see what's getting triggered, especially when a function gets called. You can also put browser logs inside for/repeat loops, if you want to track what's being done within each loop. It's a really handy tool!

  • If I understand your question right, you can test this (and many situations like it) easily using the browser object.

    Try adding the browser object to your project. Then add the action Browser -> Log to your "on path found" trigger, and just log something like "path found“.

    Finally, run your project in a web browser and press F12 and view the console. You'll see it will have logged "path found" for every time that condition triggered.

    It's a quick way to test if your code is running as intended. In this case, my hunch is you'll need a "for each -> enemies" condition to your "on pathfinding path found" trigger, but this test should tell you for sure.

  • The problem is the same, looking backward or forward. Whatever time was spent, or will be spent, developing Animate could've been spent on C3.

    The expectation isn't that 10 years of features get quick action. We've all been told that Scirra's a small team, and that new features and improvements take time, and that's true. But now, any progress will take even more time—in exchange for an animation program.

    A chance for significant ROI is good for Scirra, and it's fun to experiment. But for people paying for C3 every month, excited and hoping for more C3, you have to understand why this will be problematic. We're getting less dev time on C3 and funding a gamble many won't use.

    But maybe we've got that wrong? If you can show people how this won't affect C3 in any way, as you said, I think it would go a long way.

  • Just a clarifying question - is all that code supposed to be part of the function "GoToNextLevel"? Or is it meant to run every tick?

    It looks like it's running every tick, because it's not a subevent of the function. But it seems like you want that code to only run when the function is called?

  • How many features in the suggestion platform will now be put off indefinitely because they now choose to focus on timeline / animation improvements, which will no doubt now get priority, of which may not even make it into C3 because their not "game related"?

    I really love C3 and the team behind it, but sadly I feel the same way, so far anyway. No matter how "manageable" the workload, the focus on C3 is still split. Even 10% of time away from C3 is tough to imagine, when there's enough ideas for C3 improvement to fill 300% of the time available.

    At best, it seems like compromise is inevitable: the features that affect both C3 and Animate will naturally become a way to make "both" sides happy, and show that there's no slowdown on C3 updates.

    One small thing about the forum update— it's a bit unfair to say "I am not aware of anyone who complained during that time that our usual rate of work had slowed down". I think most/all have assumed the team has been 100% focused on C3 the entire time, so of course there'd be no complaints. Had you asked last summer how users would feel if you spent even 10% of the dev time on a new animation product, you certainly would've heard those complaints.

    The list of mandatory features for Animate is already well outlined and a huge amount of effort or time. Adding my feature suggestion for Animate feels a bit moot considering the core work to be done.

    I suppose I'm still wondering — genuinely, not rhetorically — how does a small team for C3 not get smaller tackling this workload?

  • Glad it worked out!

brushfe's avatar

brushfe

Member since 21 Jul, 2013

Twitter
brushfe has 2 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • RTFM Read the fabulous manual
  • x10
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x3
    Lightning Draw First person to up-vote a new Construct 3 release
  • x2
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

21/44
How to earn trophies