See the section on transparency in Using 3D in Construct.
If you run in to any problems please file an issue following all the guidelines: https://github.com/Scirra/Construct-3-bugs
In Construct, by default 2D games still use a perspective projection. Notice as you use Z elevation to move something further away, it gets smaller. Orthographic projections are more useful with 3D cameras oriented at an angle, e.g. for an isometric perspective. Take a look at the 'Orthographic projection' demo project which shows this.
It seems to be working fine for me in r263. It's hard to help without more information or a bug report.
That looks similar to an orthographic projection with the 3D camera pointing up instead of diagonally, so maybe you could use that?
Gravity is just a force. You could turn off gravity and apply a different amount of force to different objects.
What do you think is missing exactly?
I think GameMaker have something like at least 5x as many staff and the backing of a billion-dollar corporation. We did not even exist a decade ago. If we had similar resources we could do far more. But I think we're doing really well despite that, and there are still lots of big advantages to Construct, like JavaScript being a much faster and more powerful programming language! Also let me know when Yoyo Games start blogging about their weaknesses 😛
You might be interested in this thread which shows Construct out-performing GameMaker with an independent benchmark that's more focused on the overall engine. Small and simple benchmarks ought to be doable in the free edition of Construct, so you shouldn't need to purchase to run some benchmarks.
There are a few options already for integrating code and events, such as callFunction to jump from JS to event sheet, and script blocks/actions to jump from event sheets back to JS. What would better integration look like to you?
If the graphics driver is the problem, a native engine will still run in to issues with that. It could even crash or glitch even worse. Unfortunately drivers are notoriously poor quality. Changing to different technologies isn't a silver bullet that fixes everything.
We've done a ton of work to optimise event blocks already - I've written some past blogs covering work done on that (e.g. compiling expressions to JS). We've done so much that it's probably quite difficult to make any significant further improvements.
The blog post covers several major disadvantages of using a custom programming language. The benefits of JavaScript are so big I think it's clear it outweighs any benefits there may be of a custom language.
I'm not sure why you seem think this is some kind of gotcha - I know console support is missing in Construct and that our choice to focus on HTML5 is a reason that it's difficult to support consoles. My point is just there are actually plenty of people out there who are focused on other platforms like mobile, and aren't planning on publishing to console. For example how many Android game designers do you think are thinking of porting their work to Xbox One? I doubt it's many, as it's such a different form factor and market. Console support may be very important to some, but it isn't everything to everyone. And it's not like the fact it's missing negates all the benefits of JavaScript pointed out in this post for people who publish to those platforms.
Construct does excel at the no-programming block system and that's a big focus of the product. But part of the point of adding JavaScript coding is to expand the scope of the product to include programming. And the point of the post is to highlight that if you're interested in that, JavaScript has many strengths that make it a great choice.
Do you have any actual benchmarks? The benchmark in the post shows JavaScript outperforming YYC, which uses native code, by over 5x.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.