Mikerbice's Forum Posts

  • 8 posts

  • I seem to have worked it out for myself.

    I set a sub event condition picking the instance of Enemy1 in the attacking state then added the required values to an array.

    Another sub event condition picks the other instances of Enemy1 (which aren't in an attacking state) and pulled the required values into its own instance variables.

    It appears to work but needs a bit of tweaking.

    Does this sound like the right way to go about it? I saw the Pick nth Instance but not sure if that'd be better.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Maybe I'm stuck on this because I'm lacking sleep but either way I feel pretty dumb right now.

    Working on a top down action game with some stealth mechanics.

    I have an enemy called Enemy1

    When it sees the player with the line of sight behaviour, it sets its own state to "Attacking" via an instance variable.

    While it's in the "Attacking" state (and the player is still within it's line of sight) it will record the players position via two other instance variables called "PlayerPositionX" & "PlayerPositionY"

    I would like Enemy1, when in range of other Enemy1 instances, to share the players position to these other instances.

    The goal is that the other instances of Enemy1 will join in attacking the player, but only once they have been alerted to the players presence.

    I'm having trouble making one instance of Enemy1 do something to another instance via the event sheet.

    How do I do that?

    Condition: Enemy1 - has Line of Sight to Enemy1
       Action: Enemy1 - Set - PlayerPositionX to Enemy1.PlayerPositionX
               Enemy1 - Set - PlayerPositionY to Enemy1.PlayerPositionY[/code:29fg396z]
Obviously doesn't work because it's just affecting itself.

Thanks in advance.

  • Seconding this. It seems that this is the way it's done, especially in isometric games.

    The bottom layer could be the trunk and the top layer the leaves. The leaves are almost always going to be higher than the character so you don't have to worry about any kind of z-ordering that way.

    I've seen the same principle used for buildings too, roofs etc.

  • Thanks, Lunatrap.

    Your attached capx is almost exactly how I've been doing it with instance variables, so that gives me confidence my thought process. Thank you also for the link to the plugin. I will have to check that out.

  • I'm also struggling with this. I could very well be wrong but this is my understanding on how it's done:

    I believe you want to use the "Rotate towards angle" action.

    You need to have a trigger that is constant until your object has reached the desired angle. In other words, this way the action is looping every tick until it you get to the desired angle.

    The "Degrees" parameter is how many degrees it'll rotate each tick and the "Angle" parameter is the desired angle.

    As a side note you'll probably want to use the delta time expression with the "Degrees" parameter so that the speed isn't linked to the frame rate.

    This does seem a bit long winded to me which makes me think I've got it wrong. If anyone has a better method I'd be interested also.

  • If I understand you correctly all you need to do is select the project root from the projects window on the right, then from the properties bar on the left set fullscreen scaling to "letterbox scale".

    There are different ways to scale or crop game and it's all explained here https://www.scirra.com/tutorials/73/supporting-multiple-screen-sizes

  • You probably want to look into procedural tilemap generation. There's lots of way to do it and the general idea can be translated fairly easily into many engines/programming languages.

    https://www.scirra.com/tutorials/1112/procedural-dungeon-generation-a-roguelike-game Seems like a good start but it doesn't use tilemaps.

    I recommend you look into how you'd code it to fully understand. Tilemaps and arrays go together really well because they both are conceptually a grid.

    Put simply, it moves across each tile in a sequence and applies actions to each tile based on a bunch of conditions you set. If you set the right conditions and actions you'll end up with what you want.

    Edit: This looks like maybe a better tutorial https://www.scirra.com/tutorials/1123/smarter-procedural-roguelike-dungeon

  • Add the "Scroll To" behaviour to whatever you want the viewport to centre on. If you add that behaviour to multiple objects it will centre the viewport on their combined centre point.

  • 8 posts