TheInstance's Forum Posts

  • Did you solve this ? and how ?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • To align the animation of the Ghost with the direction its moving.

    Just add an action that sets the animation to the variable 'way_to_go'.

    And just between the lines, notice that you can move every tree of events, well those that start with a "always" base, on any place in the events sheet.

    It should not matter.

  • AI stands for Artificial intelligence.

    Wah! you say ? i dont use that ?

    Oh sure you do. Construct is not at the point yet to implement Multiplayer.

    So all your games are puzzles or the player fights against enemys that you create.

    Every, Any, Each enemy is driven by AI. Simple or complicated. But its AI.

    We have a saying, roughtly translated: Pictures say so much more then words.

    So Allow me to trow you in a commercial.

    http://nl.youtube.com/watch?v=AYC8fTv2jp4

    There are 3 messages that i would like to give by this.

    Level 1 message:

    KEEP ON WALKING !!!

    If you at first do not are succesfull in the creation of your game. Dont give up.

    Bring it to the forum is you feel completely stuck.

    But keep on walking.

    level 2 message:

    Do you see how hard it is to take the Android as a machine ?

    The player will do the same towards the enemys you create for him/her.

    They are not machine in the players eyes, middle in the fire of the battle,

    and you should try not to let them act as machines.

    level 3 message:

    Its easy to make the Enemys smarter then the player.

    Its easy to make the Enemys this dumb, that they are beatable in a blink of an eye.

    Its not so easy to make make the Enemys in a way that they are beatable, but only after a BAttle.

    But rule number one is: the Enemys can NOT be smarter, faster, better then the player.

  • I think you guys scared Ashley by evoluating the Box in to the Circle.

    If you look at the Box. Then you will see its missing some properties. Also its missing some actions and conditions compared to a sprite driven object.

    To me it looks like it was meant as another faceless object. And this object was meant to be used as "help object". As a sensor. As a way to mark locations. As .... uhh ... so many things.

    I think (well assume) that it got its face (the borders) more by accident.

    But now it has a face, everyone refers to it to ask for similar but in a circle form.

    I would rather have an object with a surface driven by math. So i can make a 5 sides, a 6 sides, and yes also a 4 sides and a circle by one object by just giving it the number of sides in a property. Also, this can not be the Box object. The Box has, i think a different use, it has to be simple and fast. The object i am asking for should have the same properties, actions and conditions as a sprite driven object.

    hope you see what i mean.

  • Its midnight here, time to go to bed, so i did't read the "read me" yet, nor did i walked to trough the events.

    But Dude, i am pretty amazed by the game when its running. This is done VERY nice.

  • Now look back at the events 8, 9, 10 and 11. Where we sense by overlap conditions.

    Lets change those. First browser a second in the system objects conditions.

    And notice the "Object overlaps point" condition. This is what we gonna use.

    No more setting image points too. But its good that you know how to set those. And how to use those. So do not forget that.

    ok .. double click the U overlaps Blue condition to change it.

    Click back till you are in step1 of the wizard.

    Step1: base object = system object.

    Step2: condition = "Object overlaps point"

    Step3: parameters : the object = Blue (the family we call the walls with)

    now X will be an expression. We will point to the x where we positioned the Sensors in last post.

    But Where is the X coordinate of the sensor ? without using the sensor ?

    Well, the maze is a 40 by 40 grid. Our octopus is in the middle of that grid. So the distance from a maze edge to the Octopus middle point (its X and Y point) is half the 40. Simply 20.

    Lets Add 2 pixels to have a save and never failing Overlap Detection.

    So X for the up "sensor" = Octopus.X

    and Y is Octopus.Y - 22

    there ! The sensor objects are eliminated by this. But you need more imagination to see whats happening, and even more to debug if you run into problems.

    But, its certainly faster and more CPU friendly.

    so ...

    point x gets the value Octopus.X

    point y gets the value Octopus.Y -22

    click finish.

    do the same for R overlaps blue.

    Xpoint in the parameters is now Octopus.X + 22

    Ypoint = Octopus.Y

    For D this will be

    Xpoint = Octopus.X

    Ypoint = Octopus.Y + 22

    For L this will be

    Xpoint = Octopus.X - 22

    Ypoint = Octopus.Y

    Now go to the layout editor.

    Delete the objects U, R D and L

    they will be deleted from the events sheet too

    meaning, you will have a few empty always events.

    You can delete those.

    And run all.

    NEVER DELETE OBJECTS BEFORE YOU CHANGED THE EVENTS !!

    (hope daddy smiles after this post)

  • This is the second time that i write all this. Why ?

    Well i did yesterday, but then, while writing, i asked myself,

    can i do this without sensors in the form of objects.

    And the answer is yes. We can. Realizing this i closed it all out without posting.

    But then, i hate to leave unfinished things behind. Thats my dads fault. He taught me. Finish what you started.

    Now i have to add a post explaining how to do this all without sensors in the form of objects.

    But i better finish this first. Its more *visual* and easier to explain, and easier to make the bridge to not using objects anyway.

    So here goes. Pick up the last cap that i posted as start layout.

    I skinned this layout down from another project that i worked on. I noticed i forgot to clean up some things. Like the global variables. Bring up the global variables, and clean all the present variables. I am sorry ?

    Now explore the layout that i left you. There is a maze, and i gave some little secrets about that maze in previous post. All Members of the maze are part of the Family "Blue". You can see that in the properties. Event can call Objects by there Family name. Very handy.

    There is the Ghost01, which has already a few private variables added.

    There is the Octopus that we will move. Add 2 Private variables to it.

    Xstep, number, 0

    Ystep, number, 0

    There are 4 objects: U, R, D and L.

    Scale them to 12 by 12.

    Change there collision methods to bounding

    Add 4 image points to the Octopus. Instructions how to in a previous post.

    Name them U, R, D and L. Use respectively the 8, 6, 2 and 1 keys on your numeric to positions the points.

    Go to the events editor. First we snap the sensors to the Octopus. Giving the beast tentacles.

    Add a System: Start of layout condition to the empty sheet. Thats easier now then later.

    For me the events sheet looks weird without one. It marks for me the start of a sheet.

    Add a system : always condition.

    Add a sub condition system: always.

    (as i explained earlier, the first always we will replace with a flow condition, once we build this module in a complete game))

    add 4 actions to this sub event

    U Set position to object 0ctopus 0 (image point "U")

    R Set position to object 0ctopus 0 (image point "R")

    D Set position to object 0ctopus 0 (image point "D")

    L Set position to object 0ctopus 0 (image point "L")

    As you can see. Although we dont use the sprites of the objects in the game, they will go invisible,

    good thumbnails extracted from those sprites make the events very readable.

    You can run this to check if you snapped up to up, right to right and so on.

    Next event will move the Octopus.

    Add another "always" sub to an "always" event to the sheet.

    add 2 actions to the sub "always"

    0ctopus Set X to .X + 0ctopus.Value('Xstep')

    0ctopus Set Y to .Y + 0ctopus.Value('Ystep')

    It is not moving yet, but it will do so soon.

    There will be no key inputs. The Ghost01 has to move all by itself.

    Add a new always condition.

    First we do the Overlap detections, to sense if the Octopus can go in a certain direction ...

    or that there is a wall sitting in the way.

    We can call all the wall objects by the Family name "Blue"

    We also need a way to memorize the results. In a next step we will partly randomly choose a direction, partly force a direction not blocked by a wall. I will use a String for that, and at same time introduce basic string operations.

    Add a sub event containing an "always" to the last event.

    First we will reset the string.

    The action will be:

    Ghost01 Set 'Possible_Ways' to ""

    Possible_ways is a private variable carried by Ghost01. "" stands for an empty string.

    Now lets find out all "Possible_ways" the Octopus can go.

    If object U overlaps Blue, then that way (upwards) the Octopus can not go.

    But we need the the directions that it CAN go. Just invert the Overlap Conditions.

    Add a second sub event with the condition

    U overlaps Blue (inverted)

    Add an action to this

    Ghost01 Set 'Possible_Ways' to Ghost01.Value('Possible_Ways') + "U"

    (set value)

    Copy this sub tree for R, D and L. And change objects in the conditions, and the strings in the actions.

    U: overlaps Blue (inverted)

    Ghost01Set 'Possible_Ways' to Ghost01.Value('Possible_Ways') + "U"

    R: overlaps Blue (inverted)

    Ghost01Set 'Possible_Ways' to Ghost01.Value('Possible_Ways') + "R"

    D: overlaps Blue (inverted)

    Ghost01Set 'Possible_Ways' to Ghost01.Value('Possible_Ways') + "D"

    L: overlaps Blue (inverted)

    Ghost01Set 'Possible_Ways' to Ghost01.Value('Possible_Ways') + "L"

    What is all this doing ?

    It resets the variable Ghost01.Value('Possible_Ways')

    then it will add the letter "U" to the variable, which stands for upwards, if that direction is free from walls.

    Same for R, D and L.

    In other words, if there are no walls in the Left and Right directions, the variable Ghost01.Value('Possible_Ways') will hold the value "RL"

    Note that you can, due the way we build the events structure, easily collapse every starting "always". Or invert it to keep it from running for debugging purpose. There is a "toggle event" in the ribbon, but for me inverting an "always" is easier, because there as contextual menu.

    Al we have to do now is to decide which of the two possible directions we will go.

    We will do this in a few conditions. But first lest make a 2 Global flow variables to guide those conditions.

    Skip, numeric, 0

    So_Many, numeric, 0

    Make a new "always" event.

    Add a sub "always' to it. Add an action to it to reset the variable Skip.

    System: Always

    System Set global variable 'Skip' to 0

    Add another action to set the variable So_Many to the length of the variable Ghost01.Value('Possible_Ways')

    System: Always

    System Set global variable 'Skip' to 0

    System Set global variable 'So_Many' to len(Ghost01 0 .Value('Possible_Ways'))

    The length of 'Possible_Ways' is holding important info for us.

    When the length = 1, then there is only 1 way to go, thats the way we have to let it go.

    When the length = 2, and the way we are already going is still a possible way, then we will prefer to keep going the way we was going already.

    When the length > 2, we will choose randomly, but with preferring the way it was going already, if this way is still a possible way.

    This means that we also have to store the direction that we are going, before choosing another direction, in a variable. But that we do a little later in the events. Yet we will use it now.

    This variable will be Current_way as private variable present in the Ghost01 object.

    OK lets start this.

    add a second sub event. Compare a global variable. Compare skip if its zero.

    Add a second condition to this. Compare if So_many = 1

    We store the actual way that we go in Ghost01's private variable Way_to_go

    so the first action to this will be setting Way_to_go to Possible_Ways

    the second action will tell the other conditions that we found a solutions. Its like a "dont bother, we know already".

    There for we set Skip to 1.

    This whole sub event looks like:

    System: Is global variable 'Skip' Equal to 0

    System: Is global variable 'So_Many' Equal to 1

    Ghost01 Set 'Way_to_go' to Ghost01.Value('Possible_Ways')

    System Set global variable 'Skip' to 1

    You can copy this sub event tree, and just lazy edit the condition.

    The comparing 'Skip' stays the same.

    Comparing 'So_Many' will be against 2.

    Add another condition to find out if the direction we are already moving is still possible.

    To do this we will use the system expression "Find in string" put into the first value of a system condition "Compare", and compared as greater then the value 0

    The sub event will look like:

    System: Is global variable 'Skip' Equal to 0

    System: Is global variable 'So_Many' Equal to 2

    System: find( Ghost01 0 .Value('Possible_Ways'), Ghost01 1 .Value('Current_way')) Greater than 0

    Find(string, string to find) , returns the position of the string we are looking in the string that we are researching. It will return a value higher then zero, if the string is found.

    In our case, when the direction that we are going (Current_way) is present in the open ways string ('Possible_Ways'), then thats still the direction to move.

    So the action will be, set the Way_we_go to Current_way,

    and set skip to 1 because this is what we decided to do under those conditions.

    the total event tree looks like this.

    System: Is global variable 'Skip' Equal to 0

    System: Is global variable 'So_Many' Equal to 2

    System: find( Ghost01.Value('Possible_Ways'), Ghost01.Value('Current_way')) Greater than 0

    Ghost01,Set 'Way_to_go' to Ghost01 0 .Value('Current_way')

    System Set global variable 'Skip' to 1

    You can copy this tree to lazy edit it.

    the Skip condition stays.

    So_many we compare against > 2

    The find condition stays.

    the action will add Current_way to Possible ways. In other words. This directions will be twice in the whole string. So when we randomly choose from the available directions , this direction has more chance to be chosen. At same time we update So_many to the new lenght.

    Skip will not be changed.

    Whole tree looks like.

    System: Is global variable 'Skip' Equal to 0

    System: Is global variable 'So_Many' Greater than 2

    System: find( Ghost01.Value('Possible_Ways'), Ghost01.Value('Current_way')) Greater than 0

    Ghost01Set 'Possible_Ways' to Ghost01.Value('Possible_Ways') + Ghost01.Value('Current_way')

    SystemSet global variable 'So_Many' to len(Ghost01 0 .Value('Possible_Ways'))

    You can copy this tree to lazy edit.

    But all we keep in the conditions is the skip condition.

    meaning, if there is no solution yet, lets randomly choose.

    We will use the system expression "get middle substring"

    as mid(String, Start, Count)

    string in this = Possible_ways

    start = random (the length) + 1 .. because random in construct starts from zero

    Count = 1

    mid( Ghost01.Value('Possible_Ways'),

    random(global('So_Many')) + 1

    ,1)

    this tree looks like:

    System: Is global variable 'Skip' Equal to 0

    Ghost01Set 'Way_to_go' to mid(Ghost01.Value('Possible_Ways'), random(global('So_Many')) + 1 ,1)

    This is the final decision, so we will also set Current_Way to the same direction. Add a sub "always"

    System: Always

    Ghost01Set 'Current_way' to Ghost01 0 .Value('Way_to_go')

    Now we covered all possible Direction changes. Our little Ghost starts to look smart.

    Now all we have to do is translate U, R, D and L in to X and Y values.

    Add a totally new "Always" event.

    Add a sub event to this, compare the "Way_to_go" to the "U", and set the Xstep and Ystep variables according.

    Add 3 sub events for the other directions.

    This tree looks like:

    System: Always

    Ghost01: 24 Value 'Way_to_go' Equal to "U"

    0ctopusSet 'Xstep' to 0

    0ctopusSet 'Ystep' to -2

    Ghost01: 24 Value 'Way_to_go' Equal to "R"

    0ctopusSet 'Xstep' to 2

    0ctopusSet 'Ystep' to 0

    Ghost01: 24 Value 'Way_to_go' Equal to "D"

    0ctopusSet 'Xstep' to 0

    0ctopusSet 'Ystep' to 2

    Ghost01: 24 Value 'Way_to_go' Equal to "L"

    0ctopusSet 'Xstep' to -2

    0ctopusSet 'Ystep' to 0

    Now all we have to do is limit the Direction changes to the grid.

    Locate the base "always" of the event that changes the directions. (should be line 12)

    and change the always to a condition that checks if Octopus X is on the grid.

    add a condition that checks if Octopus Y is on the grid.

    Event will look like this:

    System: 0ctopus 0 .X Equal to (round(0ctopus 1 .X /32)) * 32

    System: 0ctopus 0 .Y Equal to (round(0ctopus 1 .Y /32)) * 32

    The grid it has to move on is 32.

    Round will round a number to the nearest integer, like 2,2 will be 2 and 2,7 will be 3

    All points on the grid you can divide by 32 and the result will be an interger.

    Now set the position of Gost01 to Octopus, up to you to choose where in the events.

    The Whole events sheet looks Very simple when collapsed. Add some comments, and its very readable. Very Clean and logic too.

    <img src="http://usera.imagecave.com/j0h/octupus/01limit.jpg">

    Uncollapsed it looks.

    <img src="http://usera.imagecave.com/j0h/octupus/02limit.jpg">

    <img src="http://usera.imagecave.com/j0h/octupus/03limit.jpg">

    <img src="http://usera.imagecave.com/j0h/octupus/04limit.jpg">

    This method is very visual, very friendly to debug.

    But i am sure not the most CPU friendly aproach.

    Of course you will set the sensors invisible, and also mister Octopus.

    But still.

    Next post a small adjustment to do it without actual objects as sensors.

  • Drop down menu just 2 pixels on the left of the home menu.

    Minimize ribbon.

  • I dont think i understand the question. If i run the enemy layout, the only one containing a bird. That bird is animating fine in there.

    I am not sure if its supposed to be in there at same time as the Wizard trowing things at the player.

    Your Events are not easy to read for me.

    But, it looks like the bird is avoiding itself ?

    System: Always

    BirdSet height to BirdFace 0 .Height

    BirdSet width to BirdFace 0 .Width

    BirdFaceSet position to object Bird 0 (image point 0)

    BirdAvoid moving over Bird 0

    This why it stays at a negative y ?

    Excuse me if read your events wrong.

  • here is the .cap that i will use as starting layout in the next post.

    First notice The DOUBLE grid in the maze.

    The octopus object is 40 by 40.

    And moving it around in the layout shows that the maze has a 40 grid.

    But now.

    Set the layouts grid on 32 by 32.

    Click the "toggle grid" to make it objects snap.

    And you notice that the objects that make up the grid are place on a 32 by 32 grid.

    This makes the ghost that we gonna move over the grid also move by a 32 by 32 grid.

    40 is bigger then 32. This on purpose. It will allow us to use Overlap detections,

    in stead of Collision detections.

    This gives us more control, and closer to black and white decisions.

    The sensors will never be on a place where 1 pixel can make the difference between the object being stuck or moving fine.

    You should always use the Box object as sensor. Because it is a very fast detection object. But this will make the .cap in this *tutorial* less readable. This .cap dont need to be fast. It needs to be illustrative. Thats why there are 4 sprites U, R, D and L.

    But that will be clear at the end of all this.

    If i am able to finish this today.

  • ....

  • I introduced you to the Zombie sensor, to the Ghost sensor,

    next is the Octopus sensor.

    <img src="http://www.rijnvos.nl/foto/octopus.jpg">

    It dont look scary ! at all. So relax. Its simple too.

    An octopus will reach out its tentacles and sense its environment.

    But we need a point to attach the different tentacles.

    Thats why here a brief tutorial on how to make Image Points.

    Its in this .cap. Just run it.

    http://www.mediafire.com/?lutyjtg4jby

    One day Ashley will give us the condition "on Collision on image point (x)",

    till then we will go with attaching tentacle sensors to image points.

    But thats is for next post.

  • Your time to answer questions will come. Dont hurry. It will be sooner then you think now. Just keep asking. And realize that you are asking our questions and those from people that did't make a "log in name".

  • ^5

    Now lets encourage the poeple that are working on it. I saw in an other post, some one started a "reference". Wich pleases me very much.

    Can i encourage you to start something ?

    I just keep writing my ideas down and down. In the best english i can (lol me).

    Currently i am building the whole sensor story, i dont know if you noticed,

    and yes without explaining every step, wich dont feel well.

    I have no idea how long the pictures will be up though.

    After "the Zombie", the "Ghost", i just need a name for a Sensor build out of 4 sensors. Once i got that name i continue. I cant without naming things.

    Dude i had hell when i started with construct. No documentation. Not much help. And only wanted to make a Tetris for my girl that does not speed up in levels.

    Adventialy i made it in game maker 7, the free limited version.

    Then i came back to brag, i have to admid that. But also to notice that there was a new version in short time that (with some work arounds) allowed me to make it in construct. Now some versions further, i could (and should) remake it without ANY workarround.

    At the moment Construct bites my ass, and i cant let it go.

    Things move faster then you can write them down. But yes maybe now is the time to start documenting, this why i allready started, good or bad, its a start. Can only gain more users, more ideas, more flows, more Construct.

    And i do have the feeling things are having a good turn. When i asked about containers. Ashley used exact the words, the terms and the way i explained things. And that was a big sign to keep gooin.

  • Thats well explained Daddy.