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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.