TheInstance's Forum Posts

  • I am not saying you aproach this wrong.

    I am the one who should have said after every line i wrote in my tutorial "but i could be wrong"

    I am saying : i do not agree with you on certain things.

    Like sizing the sensor to zero is not a good general rule to give to beginners. It will not sense moving objects, and certainly not objects moved by a behavior.

    But yes its a good trick to be rememberd by more advanced users.

    I think there should be 3 things.

    1/ a beginners guide.

    This will be a long book, forcing people to start out where you want them to start out. Every step explained. It will not have a "content table"

    2/ a clean how to.

    This will be shorter. Clean and PRACTICAL. It will have a content table. And its searchable. Like how to add an event to the sheet. Add a sprite to an object. Its should work as a shoulder to lean peoples memory on.

    3/ a reference.

    Every menu, every condition, every button, every action, every expression etc ....

    Explained in 2/3 lines. Deep indexed.

    And the first thing that has to be done is "identify" the modal beginner. What do we think he/she knows when picking up construct. When i wrote that long ass guide, i had the most *dumb* user in mind, to do this i talked to myself.

    Identify the "average" user for the "how to".

    Also keep in mind that some starters come from using another program. Or even a program language. Everything this user knows is a handicap. Fresh users only have oppurtunitys. *Used* users first need to forget. So if you really want to place Construct in the market, you have to guide starters coming from another program in forgetting.

    And i go back to work.

  • General Note :

    There is a difference between by instance Photoshop and Constuct in the learning process.

    Come here an i teach you Photoshop in 2 days. Its purpose is to alter a pixel, and its "editors" to do so is rather limited. The results are are rather instantly, even if u trow some filters on a pile.

    Construct is different in this way.

    Everything you do,

    from choosing between a square sprite and a Box

    till positioning an object on a grid or slightly besides it

    using "s or 's

    everything has its place in the in the final result,

    but you can not see it with beginners eyes.

    Learning Photoop is like old school, if it dont work, you get a instant snap on the fingers.

    Learning Construct is like, if it dont work, you will be bitten in the butt much later, after you forget what exactly you have done.

    Everything depends on everything to work or not.

    I dont think i can be short in explaining something in Construct.

    Moment you start, you should be as complete as possible,

    or

    define to where you go.

    And both will bring you in writing a serious book. Just like you just did.

    And on top, there is no standard approach to things. All the people in this group are still figuring out an approach, a very personal one too at the moment.

    A lot of things work, some dont. Whats the cause ? Is it my fault ? Is it a flaw in construct ? Did i choose the right way to do this ? Is there a work around ? How will i do this in the next version ? Is it possible to write my own plug in ? Construct is not finished yet.

  • I never coded in Fusion, not in Factory. But as Far as i know, they are not oFFering 3D.

    In other words, only because you are Familiar with the F's made you decide this about this Fing ?

    Or to drive the car as it should be driven, straight Forward, to get somewhere ..

    Your decision was made before you looked ?

    Or, are there features that you mis ?

    Or, i should be blind, but, yet i see a line in F people dropping in and do a stand up commercial for the F things ?

  • Lets Give the way of using a sensor in my last post a name.

    And lets call it The Zombie Sensor.

    It works, but it is not really aware, and the AI is brought by the player hitting the arrow keys.

    Its a zombie sensor.

    The next sensor i bring to you i call The Ghost Sensor.

    (Nope Ashley, you can not upload in a reply, and i seem to annoy people when starting new posts)

    The base for the Ghost Sensor is no more then just a copy of how the behaviors keep objects from intruding solids. So basically we just code our own behavior. But since we will have more control, we are not limited to only "solids".

    Behaviors do this:

    They memorize the objects position,

    then they move the object,

    then they check if the moved object is overlapping a solid,

    if thats not true, they keep the new position of the object,

    If there is indeed an overlapping with a solid, they will move the object back to the memorized position.

    And this way, whatever shape the sprite has, the object will never be able to intrude a solid sprite.

    This we can do ourself in Events. And even very simple.

    So take up the starting layout, available in download on top of this post.

    Since we not gonna use a "8 directions", we will need the mouse&keyboard object to code our own key related movements.

    Add a new object to the layout, choose the mouse&keyboard object to add.

    Go to the Events Editor.

    There is already a "Start layout" event, let it just be there.

    Add a new event.

    step1: object = mousekeyboard

    step2: condition = on key is down

    step3: parameters = Up Arrow

    finish

    Add an action to this

    step1: self = Sensor

    step2: action = Set value

    step3: parameters: add a new private variable "sX" / set the value to 0 (zero)

    finish

    Add a second action

    step1: self = Sensor

    step2: action = Set value

    step3: parameters: add a new private variable "sY" / set the value to -2 (negative one)

    Copy the this whole event tree 3 times.

    Change the key's to right arrow, down arrow and left arrow. Change the values in the actions to.

    for right arrow

    sX = 2

    sY= 0

    for down arrow

    sX = 0

    sY = 2

    for left arrow

    sX= -2

    sY= 0

    When done with that, add a new event from the system flow "always"

    add a sub event to this from the system flow "always"

    add 2 actions to this,

    where u set the object Sensor to "its self position" + "the private variables sX and sY"

    You should know how to do this by now.

    You can run it at this moment, to check up.

    Temporal "invert the condition" that hides the Sensor in the "start layout" event.

    add a second sub event to the top "always" of this event tree.

    Make a collision that detects overlapping between the object Wall and the object Sensor.

    Add an action to this that positions the Sensor to the DVD

    (oh i forgot to rename the wall object to Wall, well then you do that)

    Copy that event. And invert the condition.

    Change the action in the copy to position the DVD to the Sensor.

    Run all.

    Thats all for the Ghost Sensor.

    Its difficult to move the DVD into the middle maze ? Ah yes to do that it needs little adjustments.

    But this type of Sensor, we will mostly use for objects moved by the computer.

    So yes, this is the base for the Ghost Sensor.

    The Events sheet should look like this.

    <img src="http://usera.imagecave.com/j0h/tick/99_result.jpg">

    note for Ashley: as you can see in my uploads i had to start this .cap over.

    Is there a bug in saving a .cap under another name ? Making them corrupt ?

  • xx

  • ...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yup Ashley,

    There is a Norm variable, and if one of conditions is met, there will be a new Norm.

    Thats is correct.

    Nope, lol, this is not gonna be a game. I am just diving and diving into "how to capture

    behaviors by events", without missing even one collision.

    Here is was looking for the optimal speed where the most of collisions made by a ball behavior get captured.

    I expected the speed to go straight up. Then i would alter the ticks to find the optimal speed, expecting the speed would stabilize when changing the time window the event is checking in.

    But i did not expect the speed to "wiggle" like this. Guess there is a Big Random part in what i try to measure.

    And i do start to realize now that there is no optimal speed where the events make the most collision detections done by a ball behavior.

    Sorry if u think i dont make sense, lol. Guess i start to write my beginners post about Ghost Sensors.

    j0h

  • Why is the balls speed not gooing straight up ?

  • ..

  • i am not "arty" but i am a video editor.

    http://video.google.nl/videoplay?docid= ... 5267468424

    This one won this years (2008) company video competition, although its low budget.

    http://video.google.nl/videoplay?docid= ... 0&q=&hl=nl

    this one was the official video for 175 year Belgium, done in 24 languages

    http://video.google.nl/videoplay?docid= ... 4&q=&hl=nl

    this i just made at home in my free time on my laptop

    http://video.google.nl/videoplay?docid= ... 6&q=&hl=nl

    done in 4 languages and low budget.

    Yes i am one of the few editors left doing everything in a production,

    video, grafics, and sound.

    at the moment i have

    1 cars TV program in Dutch every week

    1 cars TV program in French every week

    2 cars programs special for Fleet in dutch and french / month

    1 program about Trucks every 3 months

    1 item from the cars program

    http://video.google.nl/videoplay?docid= ... 7733993997

    and still do company movies during summer.

  • There is also a General Lesson to learn out of this.

    Collision detection or overlap detection by events is limited to the moment in time they "tick".

    And, on top, they are limited to Pixel coordinates.

    To refresh.

    The game runs 1 tick if it completed the whole events sheet 1 time. The time it takes to run 1 tick is of course depending on the speed of your computer and graphics card. But it will never be zero.

    Lets assume an event sheet that runs 3 times a minute on your computer. (the slowest computer ever made) Lets assume the events sheet has 5 events.

    Then one event runs every 20 seconds. (it ticks every 20 seconds) And lets assume the actions take 2 seconds to do there thing.

    If this event is made out of an Collision detection condition, then the detection will be done Every 20 seconds during 2 seconds.

    In other words, there will be no detection for 18 seconds, the remaining time the other events are ticking.

    <img src="http://usera.imagecave.com/j0h/tick/timeFrame.jpg">

    Thats 1 grid the events run in. Yes it is a time grid. Detections only get made when the event "ticks".

    The other grid events run in are the Pixels. They are always Round. Events dont know a X position of 200,457. Place an object at 200,457 in an event and it will be placed at 200.

    And the dimensions of 1 pixel is not zero. There dimensions depend on how big your screen is.

    If the resolution of your screen is 1440 by 900, and your screen is 40 cm, then one pixel is 40 cm / 1440 = 0,3 mm / or 0.0118110236 inch. And that is not zero.

    So events are limited by a time grid and by a position grid.

    Behaviors do not have this limits at all.

    In other words, an object moved by a behaviour ...

    Who's position has to be tracked by an event, ..

    Will a lot of time not be on the time grid that the event is checking on ..

    and also not on the pixel grid the event is checking on.

    Behaviors and Events RUN OUT OF SYNC.

    There is a speed where the events always will pick the object moved by a behaviour.

    How faster OR slower then this speed the object moves, how less chance the events have to pick it up.

    To see this in action.

    Scale the h1 ... h4 objects to 1 or even 2 pixels.

    Place them on the grid in the corners

    and run all.

    there, thats all for this second.

  • Starting .cap is here.

    The duck has a "8 direction" behaviour already.

    Run all

    Move the Duck with the Arrow Keys.

    But, oh man, thats a totally drunk Duck.

    Suppose we want its movement aligned with the grid for this maze ?

    Huh ?

    Lets move the paper roll aligned to the maze's grid in a quick event, to show you.

    Give the Paper object a Bullet Behavior.

    Be care full to not move the Paper,

    if you accidental did, then move it back by giving it x = 480 and y = 400 in its common properties.

    Notice the Green Box objects, named h1... h4.

    They are placed strategical on points where the Paper will change direction.

    There angles are according the direction the Paper will change to.

    And look under the Group properties, and deeper the Families properties.

    They have been given a family name Yellow.

    You can give a group of objects a Family name, to call them by there family in the events.

    Go to the Events Editor.

    Add a system flow event "always"

    Add a sub event to this ..

    step1: object = Paper

    step2: condition = Is overlapping another object

    step3: parameters: Choose Yellow as object.

    finish

    Yellow is the family name we call all the h1 ...h4 objects with.

    Add an action to this.

    step1: self = Paper

    Step2: action = set angle

    Step3: parameters: Yellow.angle

    finish

    Run All

    That paper has a nice move.

    And our duck is still drunk.

    This is then the limit of the "8 directions" ?

    Ahhhhh, not yet. But yes almost.

    Go back to the layout Editor.

    Edit its grid to 80 by 80.

    Click Toggle grid to make objects snap to the grid.

    Select the most Bottom layer.

    Add a box object. Name it Sensor

    Give it height and a width of 80

    place it somewhere on the grid, but not on a wall, and not in the middle.

    The grid will snap it to a good place.

    You can change its color and looks, but the initial values are ok for me

    Delete the "8 directions" behavior on the Duck

    Give Sensor an "8 directions" behavior.

    Go to the Events Editor

    Add a system "Always" flow condition.

    Add a sub event with a system "always" condition.

    Ad an action to this sub event.

    Step1: self = duck

    step2: action = set position to another object

    step3: parameters : choose the object Sensor

    finish

    Run all.

    Nice !

    Although, The Duck is still drunk by 1 pixel.

    And Because you see the Sensor, it is easy to move the duck, because your eye is using it as a guide.

    Go to the layout editor.

    Select the Sensor,

    Try to find its "set invisible" properties.

    Uhh, i dont know myself where it is. But

    Go to the Events editor.

    Make a new Event from the System "Start of layout" condition

    Add a sub event "always"

    Add a action to this sub event.

    Step1: self = Sensor

    Step2: Action = Set visible

    Step3: parameter = Invisible

    finish

    Move the "Start of layout" events on top of the events sheet.

    Run all

    Move the duck Around a while, and notice that its a little more difficult to push it around the corners.

    Also, and this is the end of the "8 directions" behavior.

    What if i want the duck to move in the maze but only in one direction ? With no Returns?

    What if i want the duck keep moving and let the player only alter its direction?

    Its the limit of the "8 directions".

    BUT it is the Born of the sensor principle. You just made your first Sensor.

    And believe me, once its born, it sticks on you.

  • ;;;

  • ..

  • Here is the starting .cap

    Lets forget the Square and bring in a real animated Sprite.

    Adding animation is not the subject of this post, so i already added the animations.

    You can see this when u select the Car thingy, and bring up "Animator" in the right Organizer Pane.

    There Is One animation. With 4 sub animations, for each 90� angle of the object 1 sub animation.

    When the object rotates, it will automatically play the right animation corresponding with its angle.

    So add a "8 direction" behavior to the car thingy.

    The walls are set "solid" already.

    Run all.

    Looks nice, but there are some culprits.

    The car will go stuck in the bottom corners, and sometimes stick to the top edge.

    From the last post we know that the behavior goes very well with Box shaped sprites.

    Even when they are not square like our little car is.

    Must have to do with the the way our car is sensing the walls.

    Select the car, and change its collision method properties from "per pixel" to "Bounding Box"

    Per pixel = every outer pixel will sense if it collides with a solid.

    Setting this Method on "Bounding box", will use the the pixels that make up the bounding box of the sprite to sense collision with solids.

    The bounding box has also the simple straight forward shape of the Box we used in previous post.

    To see the bounding box, select the car in the layout, and there will be drawn a square around the sprite. Thats the bounding box.

    Now its works perfect again.

    Although, the way the car moves when bounded by the upper wall is silly. The head of the beast should move a few pixels over the wall. To have at least a little 3d feeling.

    To do this, we need to make the bounding box smaller then the Sprite. But at the moment that is impossible in Construct.

    There is no option to add "collision masks" to a sprite yet also. (version .95.3)

    What now ? Stop using construct and wait till those things will be added ?

    Nopes, no way.

    The solutions is quite simple, and you will use it a LOT. Personal, for me there is no need to add "collision masks" to the program.

    Lets get it going.