Przemek32767's Bag o' Suggestions

Just a bunch of suggestions to make Construct 2 even more useful (not that it's not already useful <img src="smileys/smiley17.gif" border="0" align="middle">). I don't know how many of them are possible to implement, but here they are:

• Expressions to retrieve system date and time.
• An expression to retrieve current time as Unix time and expressions to convert a given date and time to Unix time and vice versa. People could find some quite creative uses for this.
• The ability to add comments to actions and not just events.
• An "ignore solids" property or behavior which would allow objects normally stopped by solids to pass through them and a similar feature for the Physics behavior.
• A condition to give an event a 1 in x chance to run (for example, if it was set to 5, an event would have a 1 in 5 (or 20%) chance to run).
• Regions - self-explanatory. They would use conditions that check for any objects or specific ones: on entered region, on left region, is in region, compare number of objects in a region.
• The ability to choose a collision mask for sprites (collision polygon, circle, bounding box) - just like the Physics behavior does.
• Simple graphic objects, like a line, a circle and a rectangle. It would be great if they could detect collisions with objects.
• An expression that returns the last key pressed on the keyboard as a string and a condition that checks for a key pressed based on that string. That would allow for customizable controls.
• The ability to take a snapshot of a part of the canvas rather than the whole canvas.
• Subscribe to Construct videos now
• The ability to style the Text object using CSS.
• The ability to change the image offset of tiled backgrounds.
• The ability to set whether the "Every x seconds" event and the "Wait" action take the timescale into account or not.

Good suggestions.

(also, I love your signature!)

egions - self-explanatory. They would use conditions that check for any objects or specific ones: on entered region, on left region, is in region, compare number of objects in a region.

This can be easily done with one TiledBG with one text variable

imple graphic objects, like a line, a circle and a rectangle. It would be great if they could detect collisions with objects

Same here, Sprite - draw line, circle or rectangle ;P

for the rest of them, they are really nice suggestion.

• A condition to give an event a 1 in x chance to run (for example, if it was set to 5, an event would have a 1 in 5 (or 20%) chance to run).

Using a condition "System: Compare two values", setting the first field to int(random(5)) and setting the second value to 4 should give exactly just that, and would even allow you to tweak the "chances" as well (int(random(5)) < 2 (2 chances on 5 to execute).

Does it really need a dedicated condition for that "trick" ?

• The ability to choose a collision mask for sprites (collision polygon, circle, bounding box) - just like the Physics behavior does.
• Simple graphic objects, like a line, a circle and a rectangle. It would be great if they could detect collisions with objects.

I believe the physics behavior still rests on the principle of collision polygon.

I mean, the resolution of the circle collision mask is still based on a fixed number of points that forms the general shape. Or so I believe, Ashley could correct me.

Also, when setting the texture of your sprite in the image editor, you can right click and "Set to bounding box".

In the same order of idea, since the implementation of drawing tools in the recent beta versions, you can fill the texture with a color, and use it as rectangle (filled) or a line.

The non filled rectangle could be an interesting addition.

Also when using the draw tools, the collision polygons are guessed, and a full filled texture is by default a bounding box.

Maybe I'm missing the point here, but I don't really see what advantage we could expect here.

• An expression that returns the last key pressed on the keyboard as a string and a condition that checks for a key pressed based on that string. That would allow for customizable controls.

I strongly second this one <img src="smileys/smiley4.gif" border="0" align="middle" />

Returned as a string or as keycode, it doesn't really matter.

Just as long as we can map keys.

And also would have conditions "on key 'keycode' pressed/down" that would be wonderful.

>

• A condition to give an event a 1 in x chance to run (for example, if it was set to 5, an event would have a 1 in 5 (or 20%) chance to run).

Does it really need a dedicated condition for that "trick" ?

I figure it would be equally as easy to add. It's trivial to do this in a plugin, but it's better if it's in the editor - this shouldn't take more than 10 minutes to add and would be cool for beginners.

As for the line, box, and circle drawing, I can see them being EXTREMELY useful for debugging - though we already have the canvas object, so this feature is pretty low priority IMO.

I greatly like the key mapping option, this is almost mandatory for a professional quality game.

As for the panel object, I can see myself using it in conjunction with inheritance layers to make cooler interfaces, though I'd prefer a whole system to support UI elements - we have so much to do with them: modal and non-modal dialogs, skinable controls (standard + the whole jQueryUI library, for instance), drag'n'drop widgets, cascading/transitioning menus... I say it calls for it's own editor.

imple graphic objects, like a line, a circle and a rectangle. It would be great if they could detect collisions with objects

In the new beta releases you can do this (well, lines and rectangles, no circles yet). Very handy!

1) I would like to be able to highlight a series of actions, and when I right click on "Add Group" the highlighted items are immediately added. It would make cleaning up code easier.

2) The ability to move global variables to another event sheet. As my game grows and I split code out to separate event sheets, I find my global variables are stuck in the sheet I created them on (since moving them deletes all the related nodes). I'm wondering if I can mess about with the XML files to do this...

An expression that returns the last key pressed on the keyboard as a string and a condition that checks for a key pressed based on that string. That would allow for customizable controls.

This is a high priority item, I feel. It's a standard of PC gaming, and especially for accessibility and disabled people's sake. Sure there's already the keycode plugin but it conflicts with Ashley's keyboard plugin.

I don't think many software developers are aware of the importance of customizable controls, as Clickteam and Construct Classic didn't have this support either (although Ashley has been getting a little bit better with the gamepad plugin at least).

Developing a game for a specific set of keys/gamepad is pretty much the worst thing you can do to a proffesional game, every person likes the controls a different way. Input is such an important part of the experience, and if you mess it up your game is going to be so much worse.

"Regions - self-explanatory. They would use conditions that check for any objects or specific ones: on entered region, on left region, is in region, compare number of objects in a region."

* I think a native "locations" layer would be awesome! *

This could save a lot of memory that would have gone to placing invisible sprites into a location (I think), and would save time for someone who would otherwise input specific x and y values into their event sheet.

"The ability to take a snapshot of a part of the canvas rather than the whole canvas."

This could be really awesome for 'action screenshots.' Basically, in an action or platform game, if you anticipate something cool to happen at a particular moment (especially in a multiplayer game), snap a shot of that area, and then create a screenshot collage or quick slideshow at the end of the game/match of potentially cool moments.

Though obviously, video capture would be even more powerful, but I expect that would be more difficult to implement.

These are all great ideas, the chance/dice idea, though as mentioned above can be done with random() and compare value, should be added in as a condition as well, as a game with a lot of "luck" based events would certainly benefit a lot and make it simpler. Most games also require atleast a few of these in my experience.

2) The ability to move global variables to another event sheet. As my game grows and I split code out to separate event sheets, I find my global variables are stuck in the sheet I created them on (since moving them deletes all the related nodes). I'm wondering if I can mess about with the XML files to do this...

boolean: You can already move the variables.

When you cut them, indeed, actions and events related to those disappear.

But once you paste them in the destination events sheet, they all reappear.

Magic !

xpressions to retrieve system date and time.

There's a plugin for that:

http://www.scirra.com/forum/plugin-system-date-and-time_topic45206.html

he ability to take a snapshot of a part of the canvas rather than the whole canvas.

The canvas object can do it with the "paste layer" action if you're not using webgl.

>

> 2) The ability to move global variables to another event sheet. As my game grows and I split code out to separate event sheets, I find my global variables are stuck in the sheet I created them on (since moving them deletes all the related nodes). I'm wondering if I can mess about with the XML files to do this...

boolean: You can already move the variables.

When you cut them, indeed, actions and events related to those disappear.

But once you paste them in the destination events sheet, they all reappear.

Magic !

You can't simple make a event sheet, calling it by "Shared Global Variables", with all yours global and import then on every "Stage Event Sheets"? I do this way and never worried about. ^^

Nice ideas, and the mapping keyboard is really the best suggestion here.

I was doing a huge system to check the last pressed and set it to the selected input command, but this way I limited the player to press only the offered keys on the list =\</p>

You can't simple make a event sheet, calling it by "Shared Global Variables", with all yours global and import then on every "Stage Event Sheets"? I do this way and never worried about. ^^

If you made event sheet filled with global variables only, You don't have to include it to any event sheets at all.

Global variables are global ;)

>

> 2) The ability to move global variables to another event sheet. As my game grows and I split code out to separate event sheets, I find my global variables are stuck in the sheet I created them on (since moving them deletes all the related nodes). I'm wondering if I can mess about with the XML files to do this...

boolean: You can already move the variables.

When you cut them, indeed, actions and events related to those disappear.

But once you paste them in the destination events sheet, they all reappear.

Magic !

Oh you're kidding me! Looks like you are correct. <img src="smileys/smiley5.gif" border="0" align="middle" />

I would like to change my feature request then that the dialogue box that says "All related events will be deleted" has the text "unless they are included back into another sheet" added <img src="smileys/smiley4.gif" border="0" align="middle" />

You can't simple make a event sheet, calling it by "Shared Global Variables", with all yours global and import then on every "Stage Event Sheets"? I do this way and never worried about.

Unfortunately I didn't think of this when I started writing my game. <img src="smileys/smiley1.gif" border="0" align="middle" />

xpressions to retrieve system date and time.

There's a plugin for that:

http://www.scirra.com/forum/plugin-system-date-and-time_topic45206.html

Oh, that's good to know. It would be awesome if it were shipped with Construct 2.

Also, I know some of my suggestions can already be done (like using variables for a random chance to trigger an event), but being able to do them without "hacks" like this would make our lives a little easier.

Thanks for your comments so far. <img src="smileys/smiley1.gif" border="0" align="middle">