Update 2024: suggestions are now on GitHub
As of January 2024, we are moving our feature request platform to GitHub. This allows filing suggestions in a similar way to bug reports, and it uses the same account system.
You can find the new feature request platform on GitHub here, along with the latest guidelines and advice:
https://github.com/Scirra/Construct-feature-requests
Please note we plan to continue to reset all suggestions every year.
Also note the old suggestions platform based on aha.io will be shut down in the near future. We will continue to maintain its existing content up until March 1st 2024. At any time beyond that the old service may be shut down. Be sure to preserve any content you want from the old platforms by that date.
Previous post for archival reasons only
Want to submit a suggestion for Construct? Start here.
We like collecting suggestions from our users, as it's a good source of ideas and people can vote on the suggestions they like best, helping to indicate which suggestions are the most popular in our community. However please take note of the following requirements and caveats.
Background
From 2017-2021, we ran a public suggestions platform for Construct. This worked well for a while. However over the years it collected so many suggestions it represented a truly insurmountable amount of work for our small team. Even just administrating all the submissions became a lot of work. Further, for some older ideas it was no longer clear that they were still necessary or that lots of people still wanted them. This also led to some disappointment as ideas could sometimes seemingly get lost in the pile.
Consequently we've decided to run a suggestions platform, but start over with a new suggestions list once a year. This avoids an insurmountable amount of work building up and ensures the suggestions stay fresh and relevant. We archive the old suggestion lists so we can still refer back to them.
Previously we issued a limited number of votes for all users. For 2023, as an experiment, we are going to try allowing an unlimited number of votes for all users. Please see the notice above though: be aware that if you plan to spend hours voting on hundreds of suggestions, it is likely we will only be able to complete a small number of them, due to our limited resources.
Guidelines on posting suggestions
Please register an account on the suggestions platform using the same username you have on the forum, if you don't have one already.
Please search to see if your suggestion has already been posted before submitting a new one. Duplicate suggestions will needlessly split votes and make your idea look less popular than it really is.
In order to make sure suggestions are useful and realistic, we also have requirements for posting suggestions. With bug reports we have required information to make sure we can help you and avoid clogging up the issue tracker with loads of reports that are impossible to do anything about. Similarly we have requirements which must be met in order for us to consider suggestions. Every suggestion must include the following:
- A comprehensive description: this should be at least a paragraph and detail 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.
- It solves a real problem: ideally the suggestion should make something possible that was previously impossible. Otherwise ideally it makes something that was previously very difficult significantly easier. If it's not clear that either is the case - especially if it's adding a second way to do something that's already possible - it will likely be declined.
- It covers alternatives and workarounds and explains why they are not sufficient and why the proposed feature is necessary. If it seems reasonable that you could use some other combination of features, even if it takes a bit of extra work, the suggestion will likely be declined.
- It includes the reasoning why the idea is important. It should answer the question: "With our limited resources, why should we implement this idea and not another one?".
Please 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 decline 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 user's claims about how easy they think they will be.
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 post official responses to highly-voted ideas, subject to available time and resources. However we are not stating a specific vote count at which we will provide a suggestion: we've already seen ballot-stuffing happening on the old platform, and it seems likely any specific threshold would encourage ballot-stuffing in order to force an official response.
We do not guarantee implementation of features
Even if an idea is the top voted one, that does not guarantee we will implement it. Voted-on features are highly subject to hype and imagination ignoring the real-world constraints of engineering and practicality. 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.
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 - blindly jumping in to it could easily 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 very 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 easily in a day or less (although sometimes even small changes can become unexpectedly complicated, as mentioned previously). 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.
The suggestions platform
If you're happy with all the above, and accept the requirements and understand our policies such as when and how we respond, you can find the suggestion platform here:
https://github.com/Scirra/Construct-feature-requests
Happy suggesting!
Archived suggestions platforms
Note archived suggestions platforms are no longer actively monitored or reviewed. These will be shut down after March 1st 2024.
construct3.ideas.aha.io - archived suggestions posted 2017-2021
construct3-21h2.ideas.aha.io - archived suggestions posted mid-2021 to end of 2022
construct23.ideas.aha.io - archived suggestions posted through 2023