Ideas for Construct 2's future
Occasionally we're asked what our roadmap for the future is. The reason we don't publish one regularly is often our plans change internally. The technology landscape is changing faster than ever, and we neither want to break promises nor rigidly hold ourselves to a long-term plan if we feel the best thing to do is to react accordingly. Despite this we've occasionally posted 'roadmap' blog posts in the past, but it's been a while!
So here are a few of our ideas for the future. As above, I'd caveat that these are not necessarily promises and we may change our plans - they're just possibilities we're considering for the future. Here are a few ideas for the future, roughly in order of short term to long term (again, not a definite order!).
Tilemap support
We knew tilemaps were a top feature request, but I must admit to being a little surprised by the hugely positive response to the newly introduced Tilemap features in r149! (Note if you stick to stable releases, Tilemaps are currently only supported in the beta releases - they'll come through to a stable release soon.)
Obviously this feature is enormously important to many users, so we want to take the time to get our tilemap support really robust and flexible. The latest beta update r150 adds more tilemap features and we'll keep going over the next few beta releases, hopefully covering something for tile collisions, a few editing improvements, better integration with Tiled, and perhaps a new Tile Movement behavior to complement the Tilemap plugin.
New Arcade
This is a little overdue, but hopefully we'll also soon be launching a new version of the Scirra Arcade. We'll cover this more in a future blog post when we launch, but we're aiming to remove many of the current limitations and make it a great first place to publish your games online!
Real-time online multiplayer
By quite a large margin, the very top feature request for a long while has been real-time online multiplayer. While we already support WebSockets, they don't quite cut it for demanding real-time games like shooters for two reasons.
Firstly, WebSockets can only use TCP transmission. TCP guarantees in-order delivery, and will commonly hold up all packets while retransmitting a dropped packet. This is exactly the opposite of what you want in a real-time multiplayer game. Typically the game will be sending object positions every frame or so, and if a packet is lost, it doesn't matter much - a newer update will come very soon, and the game can interpolate over the gap. TCP however will dutifully hold up all transmission while it exhaustively ensures that each and every packet definitely arrives at its destination in the correct order. This is fine for games with a more relaxed pace like a turn-based strategy, but can make shooters totally unplayable. The usual alternative is to use UDP which will ignore dropped packets, which provides a vastly better real-time experience for games. WebSockets cannot use UDP, so there needs to be a different solution.
Secondly, WebSocket based games need to connect to a server. Typically the server must be programmed via traditional means. Since Construct 2 is aimed at eliminating the need for traditional programming, this isn't a good fit. If you want to make a multiplayer game, you still need coding skills to create a server that understands your game. It would be better if either the server could be made in Construct 2, or if no server was necessary.
Fortunately, a new web standard is in development that solves both of these problems: WebRTC!
WebRTC allows for peer-to-peer audio/video calls and data channels. For a game the data channels are the most interesting and useful, especially since they can use UDP transmission. (Strictly speaking they use SCTP, but it provides the same features, and I think current implementations also send SCTP over UDP anyway.) Since it is also a peer-to-peer based protocol, you can either make a server using Construct 2 (simply acting as a special peer running in a browser on a server), or assign a player to be a host and run a multiplayer game without a server (although players often don't have such good connections as servers, which might limit the size of the games).
We think these are tremendously exciting developments and we're keen to provide an answer to the demand for multiplayer gaming in Construct 2 using WebRTC. Browser support is currently limited to Chrome and Firefox only (but including the mobile browsers). We are optimistic other browsers will adopt it in future. Even if it takes some time, Chrome and Firefox cover enough users to make this a pretty exciting feature.
Improved Android exporting
Publishing apps on iOS and Android typically involves using "non-browser" (or "domless") wrappers. (Most other mobile platforms have great built-in browsers.) While they can work well, they have some limitations and issues which can sometimes cause problems for Construct 2 games. We've been actively looking for better solutions, and we think we'll have something pretty cool to show for a much improved Android exporter in the near future. We'll cover it in more detail at the time in another blog post. Stay tuned!
We'd like to also improve the situation on iOS, but Apple have strict limitations on their platform combined with poor native app browser technology, so there's not a whole lot that can be done. iOS app support will have to continue to come from non-browser wrappers for the time being, and we hope Apple improve their technology in a future version of iOS so we can provide something better.
Modularity
Another top feature request is features to make re-usable components of games, such as plugins or behaviors made in events. This is going to be a complicated feature to implement and will probably require various architectural changes, and take some time to develop. We do plan to address this eventually, but with finite resources and lots of other useful, interesting and quicker projects, we think this is something we'll approach in the long term.
Cross-platform editor
We hear regularly from users asking about Mac and Linux support for the editor itself. We are well aware of the fact the editor runs on Windows only and that this is inconvenient for the many non-Windows users out there. This was originally due to a few factors: it is simpler and quicker to develop, allowing us to release on a quicker cycle; we have a lot of prior Windows development experience, which helped us when we were first launching; and there are only so many hours in a day, and we have limited resources. We agree it is important to look to having the editor on other platforms in the future. However Construct 2 is a large and sophisticated piece of software, and porting it is probably going to take a long time, and may slow down the current release cycle while we divert resources to it. Despite this it is something we're seeing as increasingly necessary and hope to address eventually.
To The Future!
Construct 2 is still less than three years old. There's still a whole lot of exciting stuff to work on, and the web platform is still bringing out amazing new features like WebRTC which open up significant new possibilities. I'm confident over the next year or two we'll be able to keep up the rate of progress and improvement - and that there are exciting times ahead!