[Feature Request][Answered][Denied][C3] Blank Object

It's not a really a need but having this really in a game engine does makes sense.

Design:

A Blank Object is just like a tiled background / sprite that isn't visible on export / preview but visible on edittime. It has no image or graphical content. You can change it's opacity / color / angle / and other basic properties. But again, it isn't really drawn on screen or anything. It is just there for behaviors.

Purpose / Use:

• Main Purpose : As a behavior box! For example:
• As a Camera Box
• As a Solid Box
• As a Jumpthru Box
• As a Platformer Box
• For Calculations from Point A to B without using any graphic memory.
• There are many more but you get the point.

This is just like a Rectangular Box Tool, Line Tool or Ellipse Tool but not necessarily a line tool or ellipse tool. A Rectangular alike Box Tool is fine.

Why need this:

Point 1:

It's really doesn't have any performance impact or anything but it just seems right having this. Especially for beginners.

I remember the time that I didn't use a Behavior Box on my first game, I was a fool. I used the Graphic Sprite for the behaviors and

i experience several glitches and at first I thought it was the code. So after 8 months developing my game, i realized my very big mistake.

I should have separated the behaviors from the graphic sprite. I actually knew about it, but I thought the glitch was just by chance and could only

happen on bad use of events.

My point is that if we have this kind of feature intended for this purpose. Then there will be less beginner mistakes.

Point 2:

It's kind of like a bad practice to use graphic memory for something that isn't even going to be shown like behavior boxes or solid grounds. And in some cases. there are beginners that can make a very inefficient mistake. How do I know? Well it's because I myself made the same mistake.

Some of the possible mistakes that can happen with beginners and can be avoided with this feature:

1) Making a solid ground . Some beginners make a mistake when making a solid ground. Some make a single black colored sprite that sizes (1000,8), (8,1000) or any size that covers the part that is intended to make solid. This makes a huge impact on performance. Imagine the size! But this is unlikely to happen though .

2)But making a sprite that has a size of (128x128) with a single black color for a behavior box. Now, this is likely to happen. There is now a little wasted graphic memory.

3)Adding the solid behavior to the ground using connected separate sprites that are adjacent to each other. Now this one has a bug with IntelXDK that produces seams with solid behavior sprites adjacent to each other. So if any beginner does this without testing on IntelXDK first. Then it's game over . Time to redesign the game.

4) Making a single black colored tiled background as a solid ground. Now there are cases when a beginner fills the default (250x250) tiled background with a black color without resizing it to (1x1) or (2x2) first. Then there will be a little bit wasted resource.

I'm not saying it is a need, responsibility or a negligence of construct 2. As a matter of fact it is only optional for Construct 2 considering it's design and it is the beginners fault that they didn't read the manual if those mentioned above happened to them considering all the tutorials and documentation provided. But having this feature will make adding behaviors more comfortable for the users.

But I got to admit though, this will make a huge change on Construct 2/3 tutorials about adding behaviors.

Ashley , I hope you consider this feature request . But it's also okay if you implement this later on C3.

Dunno if I'm missing something but wouldn't you get the same deal out of creating a sprite object and setting it to invisible? Shows up in the editor, can hold instance variables aplenty, and being invisible won't show up or consume any resources during runtime. Well maybe except for a bit of gfx memory but if you set to sprite to something like a 4x4 res image it won't make any practical difference. Right?

ErekT - As I mentioned yes it won't consume as much but it is still dependent on the image size but as I also mentioned it is still using graphics memory regardless if it's invisible, sized (0, 0) as long as it is pre-loaded on start of layout.

It's not a need but as I said, using memory for non-visual purpose is kind of wasting resources even if it is only a little bit. And as I also mentioned above without this feature there are chances of producing beginner mistakes relating to behavior boxes.

If you read the whole thing you'll know my point.

Invisible, opposed to 0 opacity, is not drawn, so it has no impact on graphics memory.

I don't think this feature is necessary at all. All you have to do is provide an online newcomers FAQ which outline common mistakes made by rookies which can updated by users themselves so the small C2 team not need to bother about it.

Heck, links to basic game programming concepts might be good as well.

Invisible, opposed to 0 opacity, is not drawn, so it has no impact on graphics memory.

I think he means the texture is both downloaded and loaded, even if not drawn.

I think it would make sense to have a non texture object with collision polygons being applied, semantically speaking, but it should have a placeholder image in editor so we can interact with it.

I don't really agree with this suggestion - you can just make a sprite with a 1x1 texture and it uses an utterly negligable amount of memory. A 1024x1024 texture is 1,048,576 pixels, literally over a million times larger. There is no reason at all to concern yourself with such a tiny amount of memory.

Also, construct is a lot easier than a lot of other tools, but there is no getting around the fact that some learning is required, and making a whole new object just to keep people from having to understand basic stuff like texture sizes would just hold them back as developers.

In addition, I find it useful at times to make behavioral objects visible sometimes anyway - if someone decided they wanted to do that later, would they have to convert their object back to a sprite? It's just needlessly convoluted when it's almost exactly the same as a sprite.

In CC we had a box object. It was quite useful as it had lines as well as fill options.

As I recall someone made one for C2, but it lacked a webgl counterpart.

If you are looking for something that works as a dummy object without a texture, that would works, if we had one.

Yann made a polygon plug, however it had issues with performance.

I made that "box" plugin when C2 was at very early beta stage - Image editor was only able to load images (no drawing tools) and that was the only reason for it. Also to speed up test and prototypes - it was faster to add "something" with a sprite functionality than trying to find and load some images from hdd.

shinkan

I miss that plug.

I don't see any reason not to just use a Sprite. A small image e.g. 32x32 uses 4kb of memory which is totally negligible. So there doesn't need to be any new feature for this.

Well, it was worth a shot.

shinkan

I miss that plug.

I miss it too sometimes to be honest.

Having a simple solid box with adjustable (size/color) stroke around it can really make some awesome stuff... Unfortunately I'm a webgl moron and still can't figure out how to do it... After all these years...

Still more than I got going on....