Some Construct 3 QOL suggestions for your consideration

1 favourites
  • 7 posts
From the Asset Store
Casino? money? who knows? but the target is the same!
  • Not seeing any rules against this so I hope it's OK, but I'm looking for support / discussion on some of these ideas. I feel like some of these are essential and would appreciate more demand to try and get them implemented sooner. Thanks!

    Editor Improvements

    1. Option to hide unused objects in inspector/debug view
    2. Hotkeys to flip objects and rotate in layout view
    3. Lock and hide all layers via shortcuts

    Hierarchy

    1. Play animation from random frame
    2. Sibling relationship for Hierarchy
    3. Hierarchy inherit opacity and visibility from the parent:
    4. Edit hierarchy relationships at runtime:

    Tilemap

    1. On tile created event
    2. Disable all tile collisions on tilemap
    3. Background brightness for Tilemaps, similar to the Sprite Editor
  • I do like the idea of hiding unused objects in the debug view.

    Top of my list would be a 'crop images project-wide' option on export.

  • I do like the idea of hiding unused objects in the debug view.

    Top of my list would be a 'crop images project-wide' option on export.

    I have 536 object types so far. I seriously must spend at least 30 minutes a day just scrolling down the debugger.

    Export crop would be very very helpful! I don't see an entry for it. I can put one in if you're not planning to?

  • Option to hide unused objects in inspector/debug view

    Yes! There are several existing similar ideas, you can vote for them:

    construct3.ideas.aha.io/ideas/C3-I-1591

    construct3.ideas.aha.io/ideas/C3-I-1382

    construct3.ideas.aha.io/ideas/C3-I-950

    construct3.ideas.aha.io/ideas/C3-I-1442

    Sibling relationship for Hierarchy

    Edit hierarchy relationships at runtime

    Isn't this already implemented?

    On tile created event

    I don't think this is needed. Also, since tilemaps can have many thousands or even millions of tiles, this event can be bad for performance.

    Background brightness for Tilemaps, similar to the Sprite Editor

    Not sure what you mean, what background brightness?

    crop images project-wide

    Why would you need to crop images on export? To remove unused transparent space? I think bulk-resizing all imaged in the project is a bad idea. This can potentially break lots of things in the game - collisions, image points, tilemaps, tiled backgrounds, effects etc.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • dop2000

    Thanks for the other links, I voted for some. (First one was mine).

    On tile created wouldn't be used for every single tile, just specific ones. So ideally it wouldn't affect performance too much. Unless that check would increase performance usage? Like I detailed on the page, it'd be great for animated tiles, multi-layered objects, and spawning other sheets with tilemaps. It's pretty cumbersome switching back and forth between workflows so to be able to do this would increase tilemap usability a lot.

    This is what I mean by dark/light background view in tilemap view. It already exists in the animation editor. If you have an image with the same color as the background it's impossible to see.

    A couple of reasons to crop images. Some things like tiled images can have tearing if the sprites don't have white space. Removing transparent edges (past a 1x border) would reduce the image size and improve memory / performance usage. It shouldn't break anything image points and hotspots shouldn't be changed. Tile BGs and tilemaps would have to be excluded from the crop.

  • Oh, I didn't realize that each suggestion in your original post is a link.

    Yeah, inverting background color for tilemap toolbar seems like a useful feature.

    As for cropping images on export - still think it's a very bad idea. There are lots of situations where extra transparent space in sprites is added deliberately - for example to enlarge a clickable/touchable area of a small button, or to modify the shape of a character's hitbox. Cropping images will change collision polygons and will break the game in this case. You can also have events that rely on certain sprite dimensions, for example, to create a scrolling background, or events that check BBox* properties of sprites.

    I understand that you are proposing that the feature to crop images will be an optional checkbox. But many people will still unknowingly click it without realizing that the exported game may behave differently than in preview, or contain bugs, or become completely broken.

  • It's all perspective right, I would argue that if beginners are not thinking about optimal spritesheet composition then they will run into trouble sooner rather than later with performance.

    So the checkbox would 1.) Serves as a reminder to think about it

    and 2.) Give better performance for those beginners not relying on the sprite itself for collisions.

    But that is beside the point really. Whatever gives us the ability to work faster - I am down for. Project-wide cropping would save thousands of clicks over a bigger project and that means more time developing.

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