99Instances2Go's Forum Posts

  • Maybe this needs a new perspective. Roguelike today is not Rogue from 1980.

    Roguelike today (i think) is in the first place BIG MAPS. And all the other things perceived as typical roguelike are just solutions to be able to offer BIG MAPS.

    Procedural (random) generation is way more easy then storing big maps in arrays. Ever tried to make an array that can represent a big map ? You will be surprised by the limits. Random (seeded) is an endless mathematical world that can be calculated on the fly and therefor does not need to be stored anywhere. Not in memory, not in the designs.

    With procedural generation there is not need to design each little corner in a big map.

    Procedural generation is the way to go when it is about 'only render what you see'.

    It is tilebased, because tiles prune probability's.

    Permadeath is just a solution to the problem that rises with storing all progress.

  • endless runner & reposition one object behind the other if theyre outside the screen

    Endless means that those objects start outside the screen (on 1 side) and move off screen (on the other side) ?

    Do they flip each pass ? Or is it a 1 time operation ?

  • I dont under stand the 'Pick All',

    currently it picks all and the sets LocalX and Y to the instance with IID=zero

  • Loopindex("x") * 20 = relative to LocalX

    ... means it should be ... LocalX + Loopindex("x")

    The conditon = System > Pick overlapping point > with ... x = LocalX + Loopindex("x") and y = LocalY + Loopindex("y")

  • Not sure how you exactly create/destroy them.

    tmntppn's example works perfect because event 9 is actual a new 'root event'

    If you create and destroy in the same event, and if you 'pick' those that you want to destroy in that same event, then you might suffer from that 'unable to pick newly created objects before the next 'root event' thingy.

    You have 2 options.

    1/ Or, do not create the one that you initially want to destroy.

    2/ Or. Destroy in a new root level.

    For method 1, you need 2 local variables. Initiate them before the loop that creates things.

    1 local that you give a random variable in the range 0 to 3. 0 = top ... and so on.

    1 local variable that gets a random index, in the range depending on if you make a horizontal or a vertical row.

    Now, if loop index it matching the random index and if that first random is matching top,left,right or left ... do not create that block.

    For method 2, you can do exactly what tmntppn suggested. A new root event.

    Pick all blocks with 'pos' = choose("left","right","top","bottom")

    Pick a random from that picklist, destroy it.

    Another problem that i see is this. You might be using a loop to create more then 1 of those 'rooms'. (also a gamble). So you have ...

    Loop for x rooms

    __Loop for up

    __Loop for down

    __Loop for right

    __Loop for left

    Now you cant escape the 'room loop' to a new root level to destroy as you want. I can imagine.

    Then i suggest to just not create them.

    Here is an updated version of tmntppn's example for method 2 (destroy in new root level event)

    https://www.dropbox.com/s/quj1lilua3ve4 ... .capx?dl=0

  • 1/

    There is a Flip Layout Effect.

    https://www.dropbox.com/s/2340wxi9fcbs4 ... ut.fx?dl=0

    2/

    You can set the Height of a Sprite to negative.

    3/

    You can clone a Sprite in Classic.

    The 'Picture Editor' for that cloned sprite has a Flip tool (icon in the top bar)

    The erase tool can erase with soft edges (Hardness = zero), so you can draw out that coastline.

    Most links to 3th party effects are dead, i suppose.

    A subtle 'warp' could give just enough illusion of water.

    4/

    Using the 'Image Manipulator'

    Add 2 sprites, 1 'source', 1 'destination'.

    Add the 'Image Manipulator' object to the layout (that is faceless)

    Now, by instance ....

    Under a 'Start of layout' ...

    Add the action ImageManipulator > action > Copy image from sprite 'source'.

    Under a 'every x ticks'

    Add the actions

    ImageManipulator > action > Apply any effect

    ImageManipulator > Copy image TO Sprite 'destination'

    That is the basic setup. But it is hard (for me it is) to get it really working, because the ImageManipulator takes 1 tick for its manipulations.

    5/

    There is a Flip effect in the effects.

    6/

    You can use any of previous mentioned methods on sprites added to an 'off-screen' Layout. Use Flip effect on that layout. And bring it onscreen with the Layout plugin.

    x/

    Here is the manual for Classic:

    https://www.dropbox.com/s/1c4cdzwycsbju ... s.rar?dl=0

    Should bring you a lot more the right direction then i can provide to you.

    Hope added enough 'presence' to my nose, after sticking it a bit 'thoughtless' in this topic.

  • 'each object' = objectA

    'another object' = objectB

    'next to it' means (i think) from all objects that are some distance away, the most close one

    Add behavior Line-of-sight to objectA

    Give it the range that you want

    System > For each objectA

    (objectA) Has LOS to object (objectB)

    (objectB) pick nearest(objectA.x objectA.y)

    ____ System > compare 2 values ... compare the instance variables

    ______________act

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Add 'else' in 29, 30 & 31.

  • This topic is so confusing. Bobbyneal100, can you clarify if this is about Classic or C2 ? Plz.

  • I have a few things to say. If that is ok, without been called a pain.

    https://www.dropbox.com/s/3rkurb2i4y2u3 ... .capx?dl=0

    1/ The property 'rotation speed' in the pathfinding behavior is rather slow. Since it has to rotate 180 degrees before it is able to move at all, it has a very slow start. The property 'Rotation object' is set to 'no', so, it seems like nothing is happening. In reality, the behavior is lining up with 180 degrees at the given 'rotation speed'.

    I rotated that object 180 degrees in the layout, so you can see the difference. Now it dont have to rotate before moving.

    2/ That generated obstacle map is ready the next tick. Not in the same tick as you use that regenerate action. So, you have to wait till the next tick before initiating that 'find path' action.

    To do this, one possibility is (since one expects the events to run top-down) to use a boolean and place a pathfinding action in an event that checks that boolean above the event that contains the regeneration action.

    Now you would think ...

    This tick ....

    Boolean is true ? ... find path (gets skipped, because boolean is not yet true)

    On enter pressed ... regenerate and set boolean

    Next tick

    Boolean is true ? ... find path (it runs now because the boolean is now true) And it will find a path that accounts for the obstacles -, because the obstacle map is build in the previous tick.

    But that is not what going to happen at all. The 'on keys pressed' is a trigger. And keyboard triggers happen (once) at the start of a tick. So, the 'On enter pressed' will happen before the 'Boolean is true ?', yet the ''On enter pressed' event is in the event list placed after the 'Boolean is true ?'

    Lesson: Be very careful with triggers when the logic depends on the order of the events.

    That is why i changed the trigger to a non-trigger in my example.

  • Oh ? Okay dude.

  • Gosh, a 2.5D isometric platformer. You really dont pick the most easy thing to do. As you know, this is a 2D engine.

    I made a example once, a year ago. It is not using projection. You might be better off looking at the tutorials for 'isometric projection' first. But here goes :

    tunepunk

    Working isometric platform model.

    https://drive.google.com/open?id=0B1SSu ... mtWVnc1cDg

    Using R0J0hound 's behavior.

    behavior-isometric_t153967

    I am PRETTY suprised with how nice this behavior does the Z sort & handles the Z-moving.

    The layout is in layers, to easely build a level. On runtime it corrects for the layer offsets and brings all objects to 1 layer. Another awwsome plus for this behavior.

  • This is a totally useless interface and not spared from bugs, but it might help you.

    https://www.dropbox.com/s/zx0ushyal1klp ... .capx?dl=0