A Developer's Wishlist For The Next Generation of Construct

So I've been a fan of C2 for a long time, and am a paying customer. I was really excited to hear the news about the next generation of Construct, and like a lot of us here, have a few thoughts. I have NO idea if anyone at Scirra will actually read this, but here goes:

Drop the idea of naming it "Construct 3"

I think including the main version number in the product title is a big mistake! PLEASE don't call it "Construct 3". Look at what Apple did with the iPad. Remember the iPad 2? The iPad 3? Eventually they got smart and just started calling it "The iPad". People have registered domain names, youtube channels, twitch streams, online video training courses all with the term "Construct 2" in them. Now they're going to have to rebrand for Construct 3. And then 4 and then 5??? If you just call it "Construct" (and rename Construct 2 to something that sounds legacy like you did with Construct Classic when C2 was released), you'll be fine and will future proof yourself. People will naturally, casually call it "Construct 3", just as people call Unity "Unity 4" and "Unity 5".

Consider de-coupling the exporters from the main engine

I see a lot of complaints from people expressing that native/desktop exports are constantly being broken or crippled by new NodeWebkit releases. Desktop is still a VERY viable means of delivery, developers can benefit from releasing on Steam, Desura, or by direct sales. The editor shouldn't SOLELY export HTML5. HTML5 should definitely remain one of the export options, but being able to export to a truly native OpenGL app with a minimal native wrapper that just handles windowing, input and filesystem access (-ahem-...SDL...), you could easily target Windows, OSX and Linux natively. The HTML5 exporter could take the same assets and game logic and export HTML/WebGL-centric Javascript. And native mobile exporters could export games on Android and iOS. This is the way EVERY other game engine does it...it will mean more work up-front but having solid native exporters on major platforms WILL sell copies of your product.

Give us Boolean globals

Its unfortunate that global variables can only be numbers or strings. I HATE creating global numbers and using 0 and 1 for things that should just be true/false. What happens if I accidentally set that value to a 2 or 3? Since its a number that's possible, but may break the logic of my game. Maybe I'm just anal, but having global boolean variables would really brighten my day

.NET or not .NET?

I've heard that the current editor is written in .NET, and is why C2 is only available on Windows. Microsoft has recently open-sourced the .NET runtime and CLR (it's even now available on GitHub), I'd expect to see production-ready .NET desktop apps on OSX and Linux within the next few months. I know you guys have even collaborated with Microsoft a bit, perhaps you could get some assistance porting the editor to other platforms? Or maybe switching to Mono and using something cross-platform like Qt or Gtk+ for your UI toolkit...something I'm surprised you guys haven't already attempted!

Plugins Should Be Packages

You REALLY should make plugins owned by the PROJECT, not the EDITOR. Something like how NPM or NuGet works (or hell, set-up a custom repository and USE NuGet if you stay on .NET). Plugins should have a central, searchable, browseable repository for discovering and installing them, and updating the Editor should NEVER wipe them. I don't use plugins right now for that very reason and I feel like I'm missing out because of it. And for the love of God: give us a better SDK for creating plugins! The documentation is pretty much non-existent, and wading through that mess to create a simple plugin is an exercise in futility. Take a note from Unity and give us solid Plugin documentation, and give us hooks to be able to create custom UIs for our plugins.

And if you dismiss everything else I've said here, please listen to this bit of advice:

Give us more advanced script editing capabilities

You yourselves advertise on your website "No programming required!" but that's ABSOLUTELY not true: creating a game in C2 most definitely requires programming. You're just not TYPING your programs into the editor. For those of us who WANT to be able to "program" and come from other languages/engines, having the ability to type-in our events & actions would be flippin' sweet. It can be something as simple as enabling an "Advanced" setting in the preferences that switches the event sheet to just a text document where we can create functions for our events and type-in the actions ourseleves. You guys are 80% of the way there with the expression editor and code completion already in C2, just evolve it a bit further to let us also DEFINE those events and actions from within code. It would make it easier to share code snippets (right now you have to take a screenshot of your event sheet and share it...), it would be so much faster from a workflow perspective (the number of clicks required to simply assign a variable or move a sprite is frustrating), and it would open-up Construct to things you guys never thought possible. Honestly, I think that Construct 2 sometimes gets dismissed by some as a serious game development tool because you're "just clicking and dragging". If you could build your events and actions yourself in an actual script file (if you choose), I think you'd attract more attention from the "hardcore" developer set.

C#/.NET scripting would be awesome, TypeScript would be a wise choice if you stick with HTML5 exclusively, or at a minimum: a Lua API for scripting.

That's all, I'll get off my soapbox now. Keep up the good work, I can't wait to see what you guys have in store for the future!

Even if scripting worked like copying events as text from CC:

+ Bullet: On collision between Bullet and Enemy

-> Enemy: Subtract Bullet.Value('Damage') from 'Health'

-> Bullet: Destroy

+ Explosion: [negated] Explosion: Is on-screen

-> Explosion: Destroy

+ Function: On function "BulletCasing"

+ System: Shell.Count Lower than 200

-> Player: Spawn object Shell on layer "Map" (image point "4")

-> Shell: Set animation frame to 2

-> Shell: Change motion angle to (Player.Angle - 90) + random(60) - random(60) degrees (limit:360)

-> Shell: Set speed : 200 - random(100) + random(100)

-> Shell: Set 'Age' to 2

-> Shell: Set width to 8

-> Shell: Set height to 3

I like the Idea of simply calling it "Construct" and plugin packages.

... global booleans should be in C2 long time ago.

I heart this post. Honest, Well said, and thought out.

I too dig the just 'Construct' name. Makes a lot more sense.

+1000 on global booleans

Colloquially Unity 2,3,4,5 are just called Unity. Same goes for UDK which they are on to four. I suspect when Construct get's to 3/4 people will just call it Construct. However C2 exist to separate from C.Classic. That's because C2 is a major engine update from C++ to JS.

I suspect that internally the exporters are probably de-coupled already. Your post count is 3 so I suspect you have been lurking. But C2 was going to support native Windows first, and a poll people voted HTML. For whatever reason it's only JS. But I will point out that the problem with exporting isn't the exporting. It's that all the Plugins are written in HTML5 JS, and not generic JS. I suspect if the plugins where written in V8 JS and used an abstraction layer for rendering, audio, asset loading so on so forth. Then JS could be compiled to CLI and that could then be compiled to other systems. However since the Plugins are embeded and reliant on HTML Browser features(Browser XML, WebSocket, WebAudio....) that there is just no way to support other platforforms without breaking the one set of plugins flow. Personally I'm up for platform independence, and then let othr programmers do all the other platform exports. But I gave up that request 2 years ago

I'm pushing for the new IDE to be written in JS for NW.js.

I'd like the option too for Plugins to be in packages. That way CAPX will also carry the required plugins. So that if your getting a CAPX from another. The plugins put into the CAPX/Plugin folder go with it. We will see.

I think you missed the JS SDK to write your own plugins. If your talking about writing code in files. I did that. I wrote a behaviour that let's you attach code object/file to an Object. Works 90% great. I just haven't figured out how to get the file to be compiled by the JIT ... I think the files may need manual insertion. I plan to present this plugin to Ashley when it's more feature ready.....

....

though I'm kinda liking the C#/Java compile idea to JS. I can dig that. Heavier types language to reduce errors. That would kinda awesome.

Great post — Ashley has made it pretty clear that scripting will not be available. Hopefully with the new editor plugin system the community could add that type of functionality? Love the entire post though -- for construct to shine it needs to continue growing.

Thanks for all the replies, guys. I've gone back and read the Construct 3 blog post carefully and it seems like it will in fact just be an overhaul of the editor and not the underlying engine itself. So several of my requested features won't be applicable (and also it looks like they're stuck on the unfortunate "Construct 3" naming convention).

Oh well, one can dream, right? Twinsonian here's hoping that the editor plugin system is comprehensive and we get good documentation this time around because adding support for text-based scripting will be first on my list

Thanks for all the replies, guys. I've gone back and read the Construct 3 blog post carefully and it seems like it will in fact just be an overhaul of the editor and not the underlying engine itself. So several of my requested features won't be applicable (and also it looks like they're stuck on the unfortunate "Construct 3" naming convention).

Oh well, one can dream, right? Twinsonian here's hoping that the editor plugin system is comprehensive and we get good documentation this time around because adding support for text-based scripting will be first on my list

I kind of made up my own scripting using behaviors and variables and my own events logic. It works well.

+1 to global booleans, God yes. I know it's easy enough to just use zeroes and ones, but it feels 'messy' somehow...

Also some sort of folder or other organisational system for global variables would be nice, I can end up with extremely long lists to wade through every time I need to change one. The option to switch to a text-based editor and do "Find and replace"-type actions would also be amazing.

Built-in extensions and improvements to existing behaviours would be nice too. Just making semi-decent AI can be quite a hassle: I know doing it yourself gives you more control, but there are certain AI behaviours (eg flocking, wandering, swarming, avoiding obstacles without glitching/popping around everywhere) that are common to a lot of games and it would be handy to have built-in. Some sort of MoveTo+ (super fast dynamic pathfinding edition) would be a dream come true for me.

Basically put R0J0hound and RexRainbow on the payroll, you won't regret it

Basically put R0J0hound and RexRainbow on the payroll, you won't regret it

THIS!!!