GeometriX's Forum Posts

  • All of your questions are related, actually.

    Consider that there are two types of event conditions: triggered events and continuous events.

    Triggered events, identified by the little green arrow symbol next to them, like "on touched", happen once. As soon as the player touches the object, the actions are taken once.

    Continuous events monitor the conditions all the time (every tick, technically) to see if they are being met, and if they are, the actions take place all the time as well.

    Here's an example of the difference between the two:

    Say I have a monster, and I want to do damage to that monster every time I tap on it with the touch screen. Let's call it 50 damage. On touched object, I'd subtract 50 from its hit points. But that would require the player to tap many times, each time they do so, 50HP would be deducted. If I wanted the player to have access to a weaker continuous attack, I'd use the Is touching object action, and would perhaps deduct 5 hit points continuously (every tick) while that's happening.

    To answer your question, you would typically use every tick as its own action. Like, every tick -> set text to Monster.HitPoints.

    Trigger once is a special kind of event condition. It's a way of turning a continuous action into a triggered one - one that only activates a single time while true. You use this when you need to continuously check for something, but only want its action to take place a single time.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Tekniko's solution has nothing to do with the number of event sheets you're using. If all of your levels use the same event sheet, you need to find a way to determine what the "next layout" will be.

    Most of the time that'll be a global variable, something like CurrentLevel will do. Then, once the win conditions have been met (in your case, the collision of two objects), then run two actions, one to increment the CurrentLevel by 1, and another to Go to layout "Level"&CurrentLevel.

  • There's the C2 game Hamstar?k, which does what you want, just the other way round. I can think of a few ways to do this but none seem that practical. Perhaps gorgonzola3000 could shed some light on how he/she accomplished this effect?

  • It's possible that the platforms aren't lining up properly...

    or their collisions polygons aren't meeting...

    or the player's collision polygons aren't correct...

    or the collision polygons are changing due to changing animations or frames of animations...

    But that's just guessing, which is all we can do without having anything to go by.

    I get that you don't want to share your prized creation on an open platform, so here's a bit of advice that will solve at least that issue, if not your game's own issue: recreate just a small slice of your game that you won't mind sharing. Use the exact same events that you have in your main game, but just to test this particular issue.

    While doing so there's a 90% chance that you'll figure out where the error is occurring. If you don't, then, well you can share that capx and other people can have a look.

  • Bad English isn't a big issue; I think many of us here have become accustomed to trying to figure out what people mean :P

    Thanks, that explanation helped clear up a lot of things. I totally had your gameplay mechanisms down wrong.

    So, here's an updated capx with everything working. I changed a number of things, which I commented, to improve the workflow and the win/lose events especially. I hope my changes will make sense - they're fairly simple - but please let me know if they need any more explaining. I suggest you open your project and my updated version side-by-side and go through the changes.

    Oh, and the star rewards screen is obviously untouched. I assume you're still working on that, but it probably doesn't need to include the main event sheet, which is causing it to spawn enemies there as well.

  • It's usually a good idea to be as descriptive as possible, both in your request and in your actual project. Took me a while to figure out what your "bullet" was meant to be. You really should label your objects. What text object isn't working?

    I don't understand the logic of your game. Is it a shooting gallery type game? Surely then the bullet itself would destroy the enemy object, but instead you've set the enemy to be destroyed when the player clicks on it, which doesn't make sense.

    Also, you're setting the position of the bullet to the pistol every tick and when timer = 60. I don't understand what that timer is actually meant to do. You're using every tick actions all over the place which don't make sense.

    Come to think of it, I don't understand what your entire game is meant to do. Not to sound mean but it really is quite a mess.

  • Also, I'd recommend doing it in one event, and just set the background colour to rgb(floor(random(254)), floor(random(254)), floor(random(254))). Unless you need those individual RGB values for something else, of course.

  • I've struggled with similar issues in the past, so I get that it seems weird. The way to think of it, though, is that the actions are trying to run at the same time. Putting in that wait command effectively forces them to run independently.

    At least, that's how I see it. I'm not sure how accurate that really is.

  • I don't have the same issue (although I use Chrome), and I've shared this file a few times in the past and nobody else has reported as such, so it's possibly just your machine. Does it do this with other projects? Can you try another web browser and see if it does the same thing?

  • If you put a System -> Wait 0.0 seconds action in your first event, it should prevent that from happening.

  • Of course it won't close the actual browser (unless it's the only tab open). I was referring to it closing the current tab.

  • It should be noted that the browser->close action is buggy in node-webkit. In Windows 8 it's prone to crashing the application, and I've seen plenty of reports from Windows 7 users that it's given them issues, too.

    In actual an actual web browser, and also in CocoonJS, however, it should definitely work.

  • Laurent, I'd suggest adding an event on ball collision with the wall, drop the drag and drop, and set the ball physics bullet property to true.

  • It's funny how often this topic comes up. Here's an example that I made a while ago for someone else: example capx.

  • The platform behaviour doesn't seem to like the way you've set your ground tiles. It's getting stuck between the tiles.

    EDIT: Just saw Tekniko's response. I guess it's a combination of the two issues.

    I recommend two things: first, use the tiled background object instead of individual sprites. Then, for the actual collisions of your player on the solid ground, use a single invisible sprite that's been stretched to fit the space. It can start off as small as a few pixels either way, then just use the handles to stretch it to size.