We're introducing a new platform for suggesting features and ideas for Construct 3, and voting on them. This will help us collect information on the most-wanted features and guide our development. However please note the caveats below, particularly that we do not guarantee features will be implemented, even if they are the top-voted ideas. The goal is just to collect feedback, which should help guide our development of Construct 3.
How it works
Please register an account using the same username you have on the forum. (I'm afraid we're too busy to do any account integration right now - so you'll need to register separately.) You can then submit a feature idea or suggestion.
Please look for existing ideas before submitting a new one. If you file a duplicate suggestion, you'll just split the votes and make it look less popular than it really is. This will also help keep the list concise and organised.
Please be as comprehensive as possible when making a suggestion. Sometimes users just throw out an idea like "add a button that does X". My usual first thought is "why?". A good suggestion has the following qualities:
- It is clearly described and well thought out.
- It solves a real problem. Ideally it makes something possible that was previously impossible. Otherwise ideally it makes something that was previously very difficult significantly easier.
- It includes the reasoning why the idea is important. It answers 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, which means there is no appropriate status to use if some are implemented and others are not. If you describe multiple suggestions in one post anyway, we will mark the suggestion according to any one suggestion in the post (e.g. "shipped" if any one got shipped, "already exists" if any one already exists, etc) at our discretion, which may not be what you want - so please only describe one suggestion.
Vote wisely
Each user gets 25 votes to distribute to the existing submissions. You can place up to 3 votes on a single idea. So you can more highly vote ideas which are more important to you, or add a single vote to ideas which are nice but less important. The vote limit is intentional: we don't want everyone voting for everything, we want you to focus on just the most-wanted things. Please cast your votes wisely - don't vote for infeasible or implausible ideas.
This system is probably biased towards older ideas, since they've had longer to collect votes. Remember you can also re-cast your votes at any time if you change your mind or would prefer to prioritise something else.
It's much more likely that quick, simple or easy suggestions will be implemented. Also, once ideas are shipped, you get your votes back to use on new ideas. So to get results I'd suggest focusing votes on the quick/simple/easy suggestions and moving your votes around as they get returned. Otherwise you could end up leaving all your votes invested huge uncertain or long-term projects, which could leave you waiting a long time for results.
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. For example it's easy to see "make 3D games like Crysis" being the top voted idea, but there are a broad range of technical, practical and business reasons we are not planning on doing that. We will, however, endeavour to provide official responses to top-voted ideas. If we decline them, we'll do our best to provide a clear description of why.
How we decide on the feasibility of features
Working on a large software project is very complex, and there are a great many factors which go in to deciding what to do next. Most of these are probably not obvious to users. Please don't be disappointed if we decline an idea. We'll try to explain why, but here's a general run down of some of the reasons we might turn down ideas.
- They're simply too massive a change to the product to be feasible. For example adding support to "make 3D games like Crysis" would amount to an entirely new product, and completely distract us from what Construct does best. The business risks to this kind of jump are enormous: blindly jumping in to such a project 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.
- There are other more important ideas. This is also known as opportunity cost. We have limited time and resources, and can only implement a finite number of suggestions. If idea A is good, but idea B is simply amazing, and we can only do one, we will likely choose idea B. This does not mean idea A is bad, it just means we picked the thing that would make the biggest difference to the most users.
- It's not clear why the idea is important. It's important to write a clear and compelling suggestion. However if we're left puzzled as to what the point of the feature is, we probably won't do it. For example suggesting "make a button that closes all windows" would just leave me wondering "why?". However suggesting "make a button that closes all windows so I can see more of the start page on startup" is a more compelling idea.
- It's too vague. Sometimes people suggest ideas like "make a dialog that allows us to configure enemy AI!". When you actually have to write code to implement an idea, you need to know exactly how it works, and what the precise mechanisms are. If that's not covered in the suggestion and it's not obvious how it would actually work, we won't be able to implement it. There's also a high chance that if we did try to implement it anyway, it would not actually do what you wanted it to, because it wasn't clear how you actually wanted it to work.
- We may simply be too busy. There are a great many jobs to be done in a software company, ranging from re-architecting the codebase and fixing bugs, to accounting and managing. We may not be able to do a feature if we are busy with other tasks, but we'll try to at least indicate if we like the idea.
Another factor in reviewing suggestions is how much work it involves. Some ideas are useful and can be added in literally 10 minutes. Those are easy enough to implement. However other ideas are essentially proposals for a 6-month engineering project. We will be much more stringent when reviewing such large ideas, since they are very costly to work on.
Risks of allowing feature voting
In the past we've allowed voting on features, and it did not always work out very well. For example we used to run polls about which feature to implement. Multiplayer was consistently voted as the top feature request with a huge majority, even with clear caveats that the feature would likely be difficult to use in practice due to the nature of networking. We spent several months developing it while putting all other features on hold. In the end, as far as we can tell, very few people actually use it in practice. In this case we think those voting for it imagined it as being better than it would actually be in practice - hype, in other words - and it probably would have been better to work on something else. This is also why we are are trying to be clear in adding the caveat that we won't necessarily implement everything that is voted for. It's not actually always a good idea to simply pick the top-voted idea and implement it.
On the other hand, there's the risk if we don't implement a highly-voted idea, that users become upset. In particular we are worried about people making statements like "Scirra don't listen to their customers - they're ignoring this feature even though everyone wants it". If that kind of thing happens a lot, we will probably just shut down the suggestion platform. Our full reasoning why we might decline ideas is explained in detail above. However we will try to provide an official response to all popular ideas, including the rationale for declining any ideas, or just whether we think we might eventually do it in future, even if not soon.
The suggestions platform
If you're happy with all that, and accept that we may not implement top-voted feature ideas, you can find the suggestion system here:
https://construct3.ideas.aha.io/
Happy suggesting!