Objects outside the layout

This forum is currently in read-only mode.
From the Asset Store
Welcome! I-Spy (Hidden objects) is an educational puzzle that is more than just seek-and-find activities.
  • Are objects being placed outside the layout included at runtime? I mean are they being ran too just like objects inside the layout? And what happens if I destroy an object at runtime, will I still be able to create the same object at runtime using some events? This has just been bothering so yeah... Just wanna quicky know about it.

  • Yes to both.

    The layout itself is just an easy way to visualize things inside a box so to speak, and handy for removing unwanted stuff that go outside of it (if you choose to) but otherwise it's no different to area's beyond its boundaries, and unless you tell it to kill them if they go outside, you can use the space to store things you need, without them cluttering up the layout box itself.

  • Just tick the "Destroy on startup" attribute on any objects you don't want hanging around at startup. You will still be able to create other instances of them no problem.

    It might seem cluttered having things hanging around in the layout like that, but they have to exist somewhere. Perhaps in C2 there can be an "Object library" or something that you can store objects in and just pull them out as needed, instead of sticking everything in the layout (I am feature requesting this )

  • Just tick the "Destroy on startup" attribute on any objects you don't want hanging around at startup. You will still be able to create other instances of them no problem.

    It might seem ccluttered having things hanging around in the layout like that, but they have to exist somewhere. Perhaps in C2 there can be an "Object library" or something that you can store objects in and just pull them out as needed, instead of sticking everything in the layout (I am feature requesting this )

    Cluttering the layout box means objects sitting there inside the white part, when they can just as easily sit outside it as there is NO distinction between white layout box and gray layout void beyond the use of kill outside layout commands (you can confirm that with the devs, I checked). Cluttering is the correct term used in development for anything within a player area that isn't required at that point in time (such as storage, as many games, even recent ones, use storage rather than load when needed), in the early days, space was at a premium so clutter was kept in small area's the player couldn't access (often seen in games such as Doom, unconnected black boxes containing a couple of enemies, would also result in enemy noises being heard at strange times). In layouts case they can be kept outside in the void as space is unlimited (without getting into the 32bit precision issue the further out you go from zero point, because it's too early and I'm still on my first coffee).

  • It doesn't really matter if Doom has hidden objects existing off the game world map. That game is a million years old and is a really bad example. And just because they do it doesn't mean it's efficient.

    In my opinion a better solution for Construct 2 would be to have an asset library where all of your objects existed and didn't have to be sitting on the layout in the first place. The object bar could be refitted to perform this duty. You could just keep objects there if you didn't need them in the layout. Game Maker does this, and so does Unity, and it's not only easier to manage your assets but it just makes more logical sense. (And just to be clear I'm not saying it should be a global asset library or anything, it should still function on a layout-by-layout basis for the purpose of loading and unloading resources at runtime.)

    Sure, it's not really a big deal to check "Destroy on startup" or make events to destroy objects outside the layout, but it's not exactly intuitive or user friendly as evidenced by this thread and others. This isn't the first time there has been confusion about this issue.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Sounds like a good idea deadeye - I don't think we can change Construct 1 but I think in C2 we will let you have objects in the object bar with no instances actually placed on a layout.

  • Hmm at the moment, I'm just putting every object there is in my game in one layout, and just call them if they are needed in other layouts using non layout event sheets. Would that be efficient? I was also thinking, what is more efficient in terms of making some maps, make events to create them at start up or build them in the layout?

  • Making a hidden layout with the required object instances on it is a good workaround as well. As for making maps, isn't it far easier to visually place items in the layout editor than try to come up with events to do the same? Once the objects are all created, there's no difference at all in performance. An object's an object.

  • I see, well thanks a bunch!

  • I was also thinking, what is more efficient in terms of making some maps, make events to create them at start up or build them in the layout?

    In my opinion that depends on your game. If your game is going to be really long and have a lot of levels, it might benefit you to take the time to make yourself a level editor. Then you can create your level engine to use just one layout, and load levels from your map files as needed. That might be easier for you to handle than having, say, 100 layouts or whatever.

    If you're just going to have a handful of levels then you probably don't need a level editor, and using the layout would probably be easiest.

    It's just a matter of what feels right to you I guess.

  • I think in C2 we will let you have objects in the object bar with no instances actually placed on a layout.

    Wooo!

    About efficiency, I've had to do both. In one case I needed 4 objects to always be together. If you place them individually they might not be at the right position (image point and matching angle) and doing so in the editor is slow and overkill. What I did was use one object (the most visual one) as a placement marker and then on startup destroy the other 3 instances then for each one of the markers destroy it and recreate it at the same spot. Since the other objects were in a container they spawn as well (that saved 3 actions) and then you gotta place each one of them.

    So yeah, sometimes you'll have to place them with events. Most of the time, not.

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