calminthenight's Forum Posts

  • ROJO I was intrigued by the OP's question and I've been working on a similar principle to what you described. I think using a built in movement behaviour to handle the movement when the object is not in orbit is probably the way to go. For when the object is being influenced by the planet I've built a custom orbit behaviour where both the force of the object and the opposing force of the player input determines the velocity of the object, which subsequently determines the speed at which the object enters/exits an orbit. It's not ready to add here yet but if you have any other input I would be interested to see other peoples takes on the problem.

  • I used a counter and state variables and it works fine.

    See a demo project here: 1drv.ms/u/s!AkmrWgxeuxlKhIcUT00GLzS3UjKMDA

  • How are you looking to handle objects that approach straight on at speed? In reality these objects would never be pulled into orbit. Are you looking to force all objects to enter an orbit if they are slowed down enough?

  • Do you want to share your project file? It would make it easier for us to see what you are trying to do and provide help.

    You should be able to use the timer behaviour along with some variables to make this work. You could also use the every 'X seconds' action.

    You could have a boolean variable called "controlswitch" and then use every X seconds toggle "controlswitch".

    Then you would have an event that says if "controlswitch" is true, set the controls active for your first character and inactive for second, and another event that says if "controlswitch" is false, set the controls active for your second character and inactive for first.

  • You could have as many or as few as you like. You could define each bottom goomba with a number and use events to determine which ones get certain amounts of top goombas at start. Then if you expand the falling section as I mentioned you could theoretically continue upwards in numbers indefinitely.

    So: pick goomba bot with 1 child (then add the fall amount)

    pick goomba bot with 2 (add fall amounts)

    3 add amounts and so on

  • It would be much simpler to continue with the original system and just add more top goombas at start. Then in the second section continue with the events you used to extend it to a 4 stack (based on child count). There will be no performance detriment to adding more events in there and the current system is not inefficient.

  • Might be similar to the issue that I've had for a while now. It seems that if I open a project and attempt to preview it will be black. If use worker is on it will remain black, if not it will hang for a bit then load. The workaround is to switch use worker off then run the preview once. After that you can turn it back on if you like and it works normally

  • Were your audio files imported in the WebM format?

  • Yep. I just had it set to work with three but using what you added you can scale it. I like the updated pick condition, not sure why I didn't think of that :) If you look at my last link again, you'll see I also removed the need for the Ypos variable and changed some of the set Y expressions from +100 to Imagepoint(1).

  • Here you go final version which is much neater 1drv.ms/u/s!AkmrWgxeuxlKhIcOwK5zIeRyJyPc2A

    Hope your project goes well :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've just had a look at it again and there are a few unnecessary things in there. Let me clean it up and I'll post it again later today. It was late last night :)

  • It looks for the distance between image point 1 on the bottom goomba, which is at the top of the sprite, and image point 0 on the top goomba which is at the bottom of the sprite. So they should be overlapping each other or separated by 1px based on the other rules. I had to implement this as there were problems with the pick condition when another goomba stack was overlapping on the horizontal. I've tested this system and can't get it to break.

    EDIT: Also I just noticed that in the add child action for that section the inherit Y option should be selected. It still works without it because of the other rules though but might add a layer of safety by adding it

  • I suspect if you wanted to continue using the current method that you could add an instance variable to the stack of enemies, something like "is on slope" then use that as a condition with something like:

    If enemy is on slope & not falling & has enemy at offset below then set enemy.Y to enemybelow.Y-100.

    EDIT: I ended up playing around with the Scene Graph tools for a bit of fun and have come up with a much more robust system. Any goombas on top of the bottom goomba automatically inherit the bottom goombas movements. This means they can travel in any direction. When a bottom goomba is destroyed, the next goomba falls to the ground and becomes the bottom goomba, which then adds any above goombas as children of it.

    1drv.ms/u/s!AkmrWgxeuxlKhIcNlIeglSsUumgCDg

  • It would be easier if you posted your project file. Without knowing the rest of the mechanics it makes it a bit of a guessing game. There's a lot of ways to do it and a lot of things that could interfere.

  • No Worries.

    Yes the overlap at offset checks for an overlapping object at a specific distance. You could use any number within the size of the object to be checked here to find an overlap. Here I'm using it to check if a goomba is seeing another goomba or the ground directly beneath it.

    The goombas are 100x100px so that's why the formula has the current position of the goomba +100. On the Y axis, + is down with 0 being at the top of the screen.

    Lerp is a way of smoothly interpolating between two numbers at a given rate, so we are asking it to move from the current Y position of the object (self.Y) to a predefined position which is the original Y position of the object+100px on the Y axis (self.Ypos"instance variable"+100px), and we are asking it to do it at a rate of (dt*10). dt is Delta Time which is based on the frame rate. You could also use any number between 0 and 1 instead of using dt to determine the speed.

    So the *10 isn't correlated to the offset of 10, it's just the speed that I chose.