aridale's Forum Posts

  • or families?

  • cool depending on theme Im prolly gonna give this one a shot

  • yeah I noticed this too in my first project. I found out the only way to get rid of it was point sampling or adding transparent pixels like mentioned above. That was in r85

  • I dont understand why youd want to move between layers at all. If a layer is over the main play layer then that layer should be considered to be a "not much of anything is higher into the 'sky' than this" the exception being sky/clouds etc.

    That means under pretty much every thinkable circumstance the player should always be under it, thus its on another layer.

    Same for the ground layers. The player will most likely never be below that layer so consider it that way all the time.

    Its like this:

    ------ arbitrary number of sky layers for fancy foreground effects

    ------ Top layer 1

    ------ Top layer 2

    ------ Player layer

    ------ Bottom layer 1

    ------ Bottom layer 2

    Everything in the top layers is always above the player. You dont really need 2 of em but you might have a use for 2 its possible. Those layers consist of ONLY objects the player should ALWAYS be under or behind like bridges or the high part of a wall section you dont collide with.

    The bottom layers (again you might not really need 2) is for things the player should ALWAYS be on top of, ground dirt roads etc.

    The middle Player layer is where anythin the player can overlap should be and thats the only layer your z-sorting should be needed on.

    The only time the player should change layers is for things like a bridge you can walk under and across. But that kinda complicated topdown collision doesnt have anythin to do with this

  • Yanns right instance vars are the way to go. You dont really have to make a bunch of global objects tho (unless you just need to) you can make 1 or 2 global objects that are solely for handling the task of data storage between layouts then relate whatever needed data to the new instances of the objects they belong to.

    Ive used this approach for years and ended up callin em Controller Objects

  • I look at groups sorta like functions/methods. I group events in there that would all make sense if run/used at the same time over and over.

    it helps keep things organized and stop you from repeating the same events in multiple places.

    My only issue is with the drag and drop arranging of events its a lil touchy sometimes especially when tryin to put events "over" other events. Like dragging a lower event up to a higher place. It wants to subevent the one above where Im actually tryin to put it instead of puttin it between it and one below it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think itd be great if we had a way to export event sheets so say if we wanted to save our player event sheet and use it in another project we could just export it then import it into our other project

  • the most important thing with this kind of issue is collision. The size and origin of your collisions make all the difference with this effect.

    With the zelda example you have to be aware that not ALL of link overlaps what hes "in front" of just part of him. That parts determined by how his collision is set up and where his origin is.

    Beyond that the only thing you do is make sure things higher up on the screen are at the bottom of the z order than the things lower on the screen.

    You dont even really need this effect depending on collision size to sprite size. It can be accomplished purely with layers.

    Look at the nes/snes final fantasy games as an example. All the characters fit in 1 "square" of the maps. They collide with things but can also go behind things. The parts they can go behind are on a layer above them. The things they collide with are on the same layer as them

  • compare the location of the moving object to the location of the click.

    object.x < click.x = to the left it should face right.

    object.y < click.y = to the top it should face down.

    etc. then play the right animation

  • what about for a literal foreground? can you set a layer to parallax faster than 100%?

  • nice another CV fan =D All my projects always end up CV related lol

  • I can see it bein a useful shortcut but I dont see it bein NEEDED specially with the project safety issue it would add.

    What I would like to see tho is a better connection to creating objects and setting values for those objects.

    I know you can create an object with an event and then use events to set values on it but theres no clear explanation of HOW to do that or that it even works (that Ive seen atleast) I had to just try it and hope it worked. Luckily it did =D

  • the problem is your checkin constantly and its not somethin thats gonna happen constantly. You should only check in instances where it might change and then only once as long as it doesnt change again.

  • yeah I dont have an example capx because its all built into a project that hugely over complicates it. podpathos explains it quite well tho

  • and during your knockback be sure to disable the platform behavior on the player