lionz's Forum Posts

  • Hello!

    First you will need to track the animations clicked if you have not done this already i.e. global variable starts at 0, when correct animation is clicked add 1 to variable.

    When global variable is 2 (all animations clicked) > use system go to layout 2. (explained in General section here: https://www.scirra.com/manual/125/system-actions)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are lots of ways you can do it. This is another way : https://dl.dropboxusercontent.com/u/495 ... rols2.capx

    Here you assign player 1 a character and set the anims corresponding to the character and player 1 always has the same controls.

  • There might be but I do it this way, especially for the controls. I don't see any reason to look any deeper into it because the premade behaviour handles everything.

  • Yeah under pathfinding behaviour if you disable Diagonals then they should just use those angles.

  • I would take the for each EnemyCntrl out of the nested loop and have a separate event, on EnemyCntrl created > set type to random (0,2) but that's just me.

  • Yeah we can do that, I just wanted to make sure the layout scale was good enough. Put the green bit on its own layer that scales. Everything else put it on a layer with scale rate set to 0 and it will be unaffected when you use layout scale.

  • Does system layout scale work or are you looking for something else? I'm no artist so you might be looking for something specific.

  • When I'm doing controls it's as simple as that : https://dl.dropboxusercontent.com/u/495 ... trols.capx

    I also added a character select so you'd see how I would start with the basics of picking a character.

    You don't use families for this but I've added the two events underneath to show how you could use families, i.e. when any character's health is 0 then destroy, this saves you from typing out when wizards health is 0 then destroy, when knights health is 0 then destroy.

    The setup of the controls is really based around how your game works. If player 1 selects wizard, the wizard will spawn OK but which controls are they using, is it always the same set of controls for player 1 and player 2? It's easy to set up with player IDs.

    Regarding the last question, that's for you to decide I guess? You said it was local co-op so I guess the controls are set to certain buttons.

  • It's because you're using conditions for objects that haven't been created yet. I would use a global variable to block the players from buzzing.

    https://dl.dropboxusercontent.com/u/495 ... wedit.capx

  • Sorry every tick might make it smoother, how does that look? I just slowed it down so you could see the zoom.

  • I answered an identical question to this here :

    The 'Persist' behaviour will work for allowing objects to remain in the same state they were before, including instance variables etc.

  • In its basic form, every 0.1 seconds > set layout scale to layoutscale-0.05 would zoom it out slowly. So it's layout scale basically to scale things up or down and make it appear as though you are zooming in/out.

  • I would just set up 4 lots of controls and if 1, use control set 1, if 2, use control set 2 etc, where 1, 2 are just player IDs. Whether the players are separate objects or 4 instances of the same object you can still assign a player ID or maybe even use UID. Families are not going to work here because you're trying to apply controls to different things within the same family instead of all but it's fine as you don't really need them. Families will be useful though for cutting down on the events for taking damage and the gameplay things you listed etc

  • Yeah plus you'll want it to be nearest playerunit that isn't already being overlapped right?

    It would normally be - for each enemy sprite > find path to nearest player unit - but since you want it to do checks for if the player has been targeted...

    In its basic form, when an enemy unit overlaps a player, or 'has reached destination' in the pathfinding you could toggle a player instance boolean 'isTargeted'.

    Then when you run -for each enemy sprite > find path to nearest player unit - add a condition under for each enemy sprite that player is not targeted (isTargeted set false).

    Of course this is getting out of simple mode now as you will have enemies moving to a player as its destination before it is set to isTargeted so you will need to be either running this check every so often to find a new destination or use the 'destination failed' event on pathfinding.

    If you want a specific number of enemies to reach that destination instead of just one, you could have the isTargeted as a number and add 1 every time an enemy gets there and when it hits 6 or whatever the total is then it doesnt become a destination anymore. You'll just have to build it a bit at a time to get what you eventually want.

  • Because the walk keys can be pressed when in mid air you need an inverted 'is jumping' condition on the walk events to block out the animation change. If you do want to move left and right when in mid air though you'll have to split out the walk animation and simulate press left/right actions.