Well... I don't like Godot.

Looks to complicated and it's all scripting.

Even though I know scripting (php, python, pascal, js, vb etc etc)

I don't want to do all scripting for a game... I want building to be visual.

That is why I considered Construct 2.... But can't invest in a stand alone I believe will disappear.

And I am not doing a subscription and get nothing for it at the end.

Tried Unity and Real... nice and powerful. But their licensing and splash screen puts me off.

You can only make games with Unreal (per license)... and Unity is going the expensive subscription too. But you can't make non games without getting enterprise license (CHA-CHING $$$$)

These big game giants are making it harder and harder for newbies to obtain... what are these people thinking??!!

I am looking for something that not only designs games, but can also do interactive content (not games) and output to html5 and standalone exe.

Well, you can't have your cake and eat it too

Nothing in life comes for free. Version 3 of Godot will have built-in nodal-based visual coding, but I think even then it is probably too much work for you.

Most Game Maker developers code with scripting as well - it is more flexible - as Havok explained too. You will not get very far without scripting in Game Maker.

If you want a drag and drop / Event Based system GoDot is not an equivalent or alternative to Construct.

They are building a flowgraph system but it looks even more complicated than the code. If you want this type of thing + 3D then both Unreal and Unity + GameFlow or Unity + Playmaker is much better imho. I've used both and got some gameplay demos out how I wanted it with realistic amounts of effort. a day or two's work with some tutorials etc.

I thought so at first too when I opened Godot the first time; until I created a first small game in it (tutorial). It may look complex, but really is not: just a different approach. For example, you want the camera to follow the player? Just parent the camera to the player. Change some camera settings, BAM! working scrolling.

The animation timeline is a huge time-saver: no need to programmatically control a lot of stuff. And the beauty of Godot's timelines: they are stackable! Anything can be animated. IK boned characters are built-in, with control over animation blending. And the 3d features obviously offer a much greater scope in possibilities.

But yes, the initial investment is much deeper - not unlike Unity (which I also tested, and I even purchased Playmaker for testing). I did not like Unity for 2d game development. I like having 3d options (like Godot), but I prefer to work in a dedicated 2d dev environment (just like Godot, Fusion, Construct).

I also think that the more complex a game becomes, the harder it will become to control in Construct. I read a number of accounts from experienced C2 developers here about how larger projects become much more difficult to maintain. Godot is more geared towards larger game development. You can tell because variables can be exposed to an object's GUI in the editor, and it is even possible to run functions while editing ("tools mode"), and of course the excellent scene-based workflow (which I think is even better than Unity).

I chose Godot because I do not like renting software, and I need good native exporters. And after trying out the visual editors in Construct and Fusion, I prefer simple scripting.

Of course, there will always be trade-offs. The initial start-up in development will take more time in Godot than Contruct, I think - but I am confident that Godot is the better choice for (semi)larger projects, and for my project.

But this is good, isn't it? At least there are so many alternatives, so everyone can make up their own minds. For me, after working for a couple of years in Visionaire Studio, I really like working with Godot. But for others who do not want to learn scripting, Construct, Fusion, of Buildbox (just checked that one out) will be a better choice. But in that case you will have to invest money. As I said, nothing comes for free.

Looks like my only alternative is GameMaker.

No, it's not. Other non-subscription options are Godot and Fusion for 2d games.

I opted for Godot, and it's more capable than either GameMaker or Fusion. I've been having a great time with it so far: the scripting is easy, the built-in 'animate all' animation timeline a gods-end, and since it is open source: free.

Godot is used and developed by an actual game studio, and you can tell. It's very efficient and organized to work with. Exporters for all major platforms, including consoles (by request and if you have a developer's license).

So if you dislike rental business models for your software, there are choices.

So... To sum it up after five pages of discussion, two camps of thought:

1) the Construct developer(s) maintain that it is due to drivers and user errors (for example badly scripted events)

2) a number of game developers who have actually made and released larger 2d desktop games in C2 on Steam, and speak from experience when they notice performance is not up to par with 'native' engines, and of whom a number have switched to other game engines for their next games.

Question to Ashley: does Scirra use their own engine to develop larger games? If not, perhaps it would be a good idea to work on at least one larger project to see for yourselves if there exist any issues.

But then why is Wii U listed? And why is Wii U listed as one of the platforms that runs "the Next Penelope"? It's misleading, if you ask me. I looked for the game to test playing on my Wii U, and it does not exist. Some people could say this is "false marketing".

I am a bit confused: on the Scirra.com website support for Wii U is listed, and "the Next Penelope" is released and running on Wii U according to the article here: scirra.com/construct2/games ... t-penelope

But when I looked for it on the web (I have a Wii U and wanted to get the game for it), I found out that the developer never released it on Wii U, although (in his words) he really intended the game to be released on Nintendo's console in the first place: pastebin.com/gkcHUSx6

Three publishers attempted to get it to run on Wii U, and it just did not work. The developer gave up on the Wii U release, and switched to Unity now, because of Nintendo support for the Switch.

So now I am wondering: why would Nintendo Wii U support be listed on Scirra's home page, and why is Wii U listed on the same website as a working platform for "the Next Penelope", when in truth this just isn't the case?

I genuinely think it's a perfectly fair deal. It's a fantastic product and it's still pretty cheap: you get all features and exporters, including a build system, for less than the cost of a build system alone (PhoneGap Build). Nobody is completely locked out of their project; it just disables some features (not even all of them; you can still edit layouts and such). We have already talked about how we plan to have a maintenance subscription to help people who just need to do light maintenance so they don't have to go for a full subscription to make changes after their subscription expires.

Hey Ashley, here is an idea: you offer a Phonegap-type build system for Construct 3. Why not allow any html/js/canvas developer out there to not only build C3 apps, but also regular html/js/canvas based projects, just like Cocoon and PhoneGap?

So in effect a Phaser developer might want to sign up for Construct 3, and use the Construct 3 build tools to upload and build their own code.

This may open up new revenue streams for you, and Construct 3 gets introduced to js developers.

I was wondering the same thing two months ago when I researched various game engines for a new semi-complex 2d game project. I tested Godot and Construct 2/3 on my two laptops.

I went with Godot, because on lower spec'd machines (i5, 4gb) the performance just wasn't that great, and native export with Godot kept the games I tried running at a nice 60fps. With NW.js and Construct 2 I could not get the same level of performance. At least, not on the older laptop. But since a fairly large part of the Steam community still runs similar level hardware, I decided against Construct.

I read through the comments of other C2 developers who have published C2 PC desktop games to Steam, and I did not really like what I read. There are some issues, it seems. My experience during testing was also that putting Construct in debug mode while running the game would slow it down much more than running games in debug mode in Godot. That really clinched the deal for me, because far more complex games would run quite smooth in debug mode on my Linux Mint work laptop, and would slow down far too much in Construct 3 and the browser.

So, yes, in my opinion the browser wrapper may work against you. But you could always increase the minimum system requirements for your game, obviously. And your work machine may be much faster than mine, which is a run-off-the-mill laptop with 8gb and intel graphics (purchased last year).

I have no experience with GameMaker - but Godot works like a charm while developing and testing on my laptop. C3 does not. Your mileage may differ.

By the way, on a side note: how is it possible that a user collects 11,242 gold medals, is 21001 days online in a row while he/she only registered 74 days ago, and has an insane 5,621,827 reputation points?

And only one post in this thread?

scirra.com/users/20170217

WackyToaster: I believe C3 must check if you own a valid license every once in a while. If, at that time, C3 cannot validate the license, C3 will no longer allow you to edit and publish your projects until you connect to the net.

Stop paying the rent, and you lose access to edit your projects. With a regular perpetual license this does not occur, and the user can always open older projects to edit and publish anew. So I kinda can see where Blurymind (and others here) is coming from when they say your C3 projects are held 'hostage' by the rental model.

Having said this, I suppose for some users a rental model works just fine for them.

As for me, I looked into Construct recently to become a new user (heard good things about version 2), but when I found out C3 will be renting only, I decided to look into Godot instead. At least with open source I can never be locked out of my own projects, no matter what. And Godot being a more capable 2d engine is only icing on the cake!

> Wed Feb 01, 2017 2:17 pm

> Most people here who use & enjoy C2 are hobbyist, myself included. I will not pay a subscription fee for C3.

>

Your sentence holds a lot of truth. More so than what most supporters of the new subscription model appear to realize.

Nice hack! This forum's security needs to up the ante

One thing that does stand out as being one of webasm's advantages: security. Since it runs binary/bytecode the browser's console window can no longer be abused to hack into a game's code that easily.

Is this correct?

The engine would have to be rewritten from the ground up, including plugs. In a different language.

It's basically the same as asking for a native export.

I read up on the subject a bit.

tinyurl.com/jy5dr2c

Seems like WebAssembly (webasm) is meant to allow C/C++ to be compiled to run in a web browser.

Newt, you are correct, it would be like asking for a native exporter level of support. That is why Unity and Godot (and other game engine) are relying on webasm: to have a relatively easy port of their native exporters!

It would be sour cherries for Scrirra to swallow when it turns out that competing game engines' native exporters ported to WebAssembly perform better than hand-written native asm javascript and canvas in the browsers.

A static language converted to webasm executes faster than javascript converted to webasm. That is saying that Construct 3's javascript is converted to webasm in the first place, which is not the case, right?

And since javascript (asm) is JIT compiled (meaning it must be parsed, typechecked, interpreted and finally compiled) it will be slower than webasm, which is parsed and then compiled. According to the linked article a 5% speedup is already the case, with future speedups expected.

The conclusion is that competing game engines will (probably) offer better performing web games with improved predictability because they have native exporters in the first place which are ported to webasm. Isn't that ironic?

Of course, in practice it will probably not make much of a difference for most games, going by what Ashley says in his article. I do suspect that it may matter for lower spec'd hardware.