Skip to content

A place to submit feature requests and suggestions for Construct.

Notifications You must be signed in to change notification settings

Scirra/Construct-feature-requests

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

12 Commits
 
 
 
 

Repository files navigation

Construct feature requests

This is where we handle feature request and suggestion submissions for Construct 3 and Construct Animate.

Note

We routinely get far more suggestions than we could possibly implement. We would do all your ideas if we could! However the sheer volume of ideas and our limited resources means we can only complete a small number of ideas. Please do not be disappointed if we don't act on your suggestion. It does not mean we don't like your idea. It is more likely just because we are inundated with such an extraordinary number of suggestions that it is impossible for us to do them all!

Read these guidelines or your suggestion will not be considered

There are several reasons your suggestion may end up not being considered, or closed. Please follow these guidelines to make sure the team considers your request.

Always follow the guidelines, every time

Please always fill out all the fields of the suggestion form, every time, no matter how obvious you think your suggestion is. Often suggestions are not as clear as you think and if the team do not understand what you mean, your suggestion will not be implemented. Clear communication is essential when making a suggestion.

Search to see if your suggestion has already been posted

Before submitting a new suggestion, please search to see if the same suggestion has already been posted. Duplicate suggestions will needlessly split votes and make your idea look less popular than it really is.

Voting on suggestions

You can vote on other suggestions to show your support for it. Add a "thumbs up" reaction to the suggestion to add your vote to it. This can be done by clicking the smiley face icon at the end of the original post, and selecting the "thumbs up" icon.

suggestion-vote

Please note: other reactions may not be counted. This view is what we look at for the most-voted suggestions, which only counts "thumbs up" reactions. Please use this method of voting rather than adding a "me too!" or "+1" comment, which does not count as a vote, and can interfere with any following discussion about the suggestion.

Suggestions are cleared every year

Every year in January all existing suggestions will be archived, and the suggestions list will restart from scratch. This is to ensure suggestions remain relevant to the modern use of Construct, and avoids the suggestion list becoming so long it becomes ineffective. If your suggestion is archived and you still care about it, you'll need to resubmit it.

Only describe one suggestion per post

Posting multiple suggestions is difficult to manage: it can mix very easy and very difficult ideas; it's not clear which people are voting on; and we only have one status to apply for the entire post. If you describe multiple features anyway, we will either close the suggestion, or update its status according to any one suggestion in the post, at our discretion.

Please do not try to claim your idea is simple or easy to do

Users are often not aware of the technical complexities of their ideas and so can't easily judge if something is really a minor suggestion or not. We even struggle with this ourselves: as described in the blog post The unexpected complications of minor features, seemingly trivial suggestions can end up running in to unforeseen complications and spiralling in to weeks of difficult work. Therefore our policy is to treat all suggestions on the same basis and disregard claims about how easy it will be.

Guidelines on posting suggestions

In order to make sure suggestions are useful and realistic, we also have requirements for posting suggestions. Your submissions should include all of the following to be considered.

Summary

This should be a brief summary of your suggestion. It should include a problem statement as well, where relevant: what problem are you having which this suggestion is intended to solve? This should also be a real-world problem, and not something theoretical or anticipated.

Possible alternatives and workarounds

If your suggestion appears to already be possible in some other way, it won't be considered. Please consider how else your goal could be achieved when using existing features. List any available options, and explain why they are insufficient and so a new feature is necessary.

Proposed solution

Describe precisely how your suggestion would actually look and work. Screenshots of mock-ups can also be helpful. If the description is merely a sentence saying something vague like "make a feature to handle enemy AI", it will be declined as it's impossible to act on a suggestion that vague. Also this should not refer to other software, e.g. "make a feature like software XYZ" or "make an official version of third-party addon XYZ": it's not always clear to us how other things really work or that it's even a good idea to implement them the same way in Construct, so similarly these types of suggestions will be declined. Make sure you describe how the entire feature actually works in the context of Construct.

Why is this idea important?

A good suggestion should answer the question "With our limited resources, why should we implement this idea and not another one?". The team gets far, far more suggestions than we could possibly implement. Explaining why you think your idea is important and should be worked on ahead of all the other suggestions we get helps you make the case for why your suggestion should be implemented, and helps our team prioritise suggestions.

Notes on feasibility

Working on a large and complex software project involves many complicated technical considerations, most of which are probably not obvious to users. Here are some further reasons suggestions may be declined.

  • They're simply too massive a change to the product to be feasible. For example adding support to "make 3D games like Crysis" could amount to an entirely new product. There are huge risks to taking on a project like this, and blindly jumping in to it could even ruin the company.
  • They are not technically feasible. For example a user may ask for a plugin to allow X-ray vision through the phone camera. Unfortunately that's simply not possible. In other cases it may be just about possible, but infeasible due to the sheer complexity or amount of work involved. This isn't always obvious to someone who doesn't have to do the actual engineering involved.
  • It breaks backwards compatibility. For example a user may suggest a completely new and different way for the Families feature to work. Even if it's a brilliant idea, it would likely break thousands of existing projects that already rely on the feature working the way it already does. Users whose projects break between Construct versions rightly get upset, so we strive to ensure compatibility between Construct updates. Ideas which would obviously break this are not something we can really do in practice. We can in some cases add a parallel feature and try to phase out the old one, but this is technically complicated, and confusing to users who wonder why there are two options and which one they're meant to use.

Another factor in reviewing suggestions is how much work it involves. Some ideas are useful and can be added relatively quickly. However other ideas will clearly involve months of work and have long-term maintenance implications too. We will be much more stringent when reviewing such large ideas, since they are far more costly and risky to work on, and working on big long-term projects also precludes working on a larger number of smaller suggestions (the opportunity cost). In other words, the bigger the scope of the suggestion, the less likely it is to be implemented.

Responses to suggestions

Please note we do not guarantee that Scirra will respond to suggestions. The reason for this is that this alone would be a huge amount of work for our small team with already limited resources. Even providing a short response can involve a lot of work, involving things like assessing the technical feasibility across a large and complex codebase. Further, staff comments can easily expand in to extended discussions about what the suggestion really meant or the merits of different approaches, taking up even more time (especially across hundreds of suggestions). Therefore our policy is that we do not guarantee any responses at all.

We will make a best-effort attempt to respond to highly-voted ideas, subject to available time and resources.

We do not guarantee implementation of features

Even if an idea is the top voted one, that does not guarantee we will implement it. For all the reasons given here, suggestions may be infeasible, inadequately explained, or risky, no matter how many votes it receives. There are also several other ways we prioritise what to work on, including what we see happening with support requests, bug reports, forum posts, common questions and problems, opportunities created by new technologies, usage statistics, our own business goals, and more. The aim here is just to collect feedback, and the suggestions platform is just another one of several ways that we get feedback from users.

Community guidelines

Feature requests are subject to our Forum & Community guidelines. Significant or repeated violations of our community guidelines may result in your suggestion being closed or moderation action such as bans.

Get started

Thanks for reading our guidelines! You can get started by visiting the Issues section where feature requests are submitted. To submit a new suggestion, first check for an existing suggestion, then click the New issue button and by Feature request, click Get started.

About

A place to submit feature requests and suggestions for Construct.

Resources

Stars

Watchers

Forks