Layer filter idea

0 favourites
  • 12 posts
  • I was thinking a "Layer filter" or "Smartlayer" might be useful.

    Basically a toggle or tickbox that would hide or grey out any code that isn't relevant to your currently selected layer.

    Eg. If the background layer is selected, only code for content on the background layer and variables that that code uses are shown.

    (Using multiple event sheets is getting more and more confusing)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I don't know - what layer does the event "Start of layout - set global variable to 1" count as being on? What if an event applies to multiple layers? What if you dynamically move objects between layers at runtime, so one event actually does apply to a layer at runtime, but the editor doesn't think it does?

    Maybe you just need to use more event sheets, organise everything in to groups and includes, and use more comments. It should be possible to make well-organised events without that feature.

  • I think you're right, I didn't consider objects switching layers like that. Thanks for considering it anyway.

  • What exactly are you using layers for? I don't see the need for this without knowing your situation...

  • I found it easier to start a new event sheet for each layer as I was originally putting everything in one single event sheet and it was getting really hard to navigate.

    So one for the HUD overlay, inventory box, background, buildings, usable objects, enemies and a couple for different menus. (I know I'm forgetting a few but you get the point)

    I was imagining a cleaner version would essentially be a feature keeping it all in one sheet but dynamically show only the code relevant to the area you're working on.

    Perhaps I should have suggested a feature filtering the code that affects a single selected object rather than a whole layer.

    I think I just need to rethink the way I'm splitting things up and just need to keep track of everything on a big sheet of paper or three, but thanks anyway.

  • Perhaps I should have suggested a feature filtering the code that affects a single selected object rather than a whole layer.

    Try just typing the name of an object in to the 'Event search' box on the ribbon.

  • after using alot of approaches i found out that making good use of groups is the way to go, and keep reordering these in logical sense, and every time i start some new events, make a group, using alot of eventsheet i found i constantly jumping from eventsheet to evensheet, while now i just need to find the right group

  • D'oh! That's embarrassing.

    Thanks Ashley.

  • Thanks Vtrix. I have been using groups but I think the problem is more with designing as I go rather than getting it all out first. The groups end up overlapping each other and either contain too much to too little, then I end up with closely related code being in completely different sections. At least this has been a good learning experience. I think I better notch this up as a prototype and start over. Such a mess.

  • 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.

  • Blam, I also passed through this situation in my early days. With time you will learn how to create your code in a way that is organized and easy to follow.

    One bad thing that I used to do was reuse the same conditions for everything I could, thinking I would gain performance. I normally had just one "Every Tick" condition to run every action that was supposed to be executed always. It seemed a good strategy in that time, but as your eventsheet gets more complex it starts to become a mess.

    So don't be afraid of duplicating events to help make things more readable. If you need to duplicate an event and put it into another group just to keep similar code grouped, do so.

    It will save you lots of time in searching, understanding, and modifying your events. If it's not a loop event it's highly unlike to cause any significant impact on performance.

    Also, wherever possible try to plan your events in meaningful pieces. Start by the core things and plan how you can add further functionalities later without disrupting what you have already done. Make each functionality a new group.

    If you are uncertain of how to implement a feature do sketch programming: create a new document just to fearlessly test your ideas and discover how to get things working. Once you are sure you know how to do it, then recreate it in your official file. The recreation will normally come a lot more polished and understandable than the first trial.

    If a feature depends on other functionalities then duplicate your main file and work on top of the clone. Remember to rename the files accordingly so you can track what is official and what is a sketch. Again, once you are sure you know how to do it, then recreate it in your official file.

    I think a whole tutorial could be done about C2 good programming practices. Unfortunately I don't have enough time to do it.

  • I think your post is a pretty succinct programming practice tutorial already. Thanks! :)

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)