I assume the new C3 runtime will be capable of exporting to WebAssembly? The trouble is that Microsoft browsers do not support WebAssembly at this point, BUT Microsoft just announced support for it in their latest Edge version (albeit behind a experimental flag):

tinyurl.com/laetjcm

It works really well. The upcoming version 3 of Godot will also support direct WebAssembly export, as explained here:

tinyurl.com/lhbq8ko

I'd be very surprised if Scirra would not support WebAssembly as an export option.

> I feel your are right: even the performance of a simple platform game (Kiwi) is very underwhelming on a i5 machine with 4gb.

>

Please provide actual benchmark numbers, otherwise this kind of statement is worthless.

My office machine can render over a quarter of a million on-screen sprites at 30 FPS in Chrome, so you can get great performance in a browser. A single actual measurement is worth more than an entire forum full of vague statements.

What is your office machine's spec, if you don't mind my curiosity? By the way, shouldn't you be testing at 60fps instead of 30fps?

Mine are:

Celeron N3050 (8GB ram, 850gb SSD and Intel graphics) laptop with Linux Mint

older Windows 7 i5fhl@1.33ghz 4GB tablet Intel HD graphics

I made certain to update all drivers to the latest ones.

I am attaching screenshots here: imgur.com/a/J3nUo

I discovered that the fps tops at 30fps for the Kiwi game on the older Windows machine (which explains the 'slow' feel), but runs at 60fps on my Mint system (vanilla browser window without inspect element active).

The frame rate is quite irregular on the whole on the old Windows machine, and stutters and yanks happen while playing. This does not happen on the Linux laptop.

Running the debugger on both machines impacts the fps a lot. A similar platform game in Godot keeps running at 60fps when the debugger is run. I also tested the profiler in Godot, and the preview keeps running at 60fps on both machines. I wanted to turn off parts of the debugger in C3, but it would not let me.

Inspect element and its fps counter causes the shooter sample game to run at 30fps, but runs at 60fps on the older Windows machine.

It's a mixed bag of results, really. I cannot benchmark without the debugger or inspect mode in Chrome, and both slow down the Kiwi game preview.

I can only say that:

+Godot runs fine throughout on both machines with or without the debugger running, while Construct 3 struggles on the older Windows machine.

+Construct 3 on my Linux Mint machine runs okay, although is not as responsive as Godot. As I said before, it takes a fraction of a second longer to register mouse clicks in Construct 3 compared to native apps. I blame Chrome here, not Construct 3.

+The debugger slows down simple games in Construct, even on the Linux machine.

+ It's hard testing Construct 3, because the sample projects are relatively simple games. I'd love to see a larger project tested.

I'll wait until the final version is out, and do some testing again then.

This argument would be more valid if 30fps was the target, possible to achieve steadily, or possible to lock a game at. With an entirely variable framerate, and with the default (and uneditable) target being 60, this doesn't really mean anything, as a performance benchmark or for what's possible to achieve in a commercial product. Wildly varying framerates, which is what we currently have to deal with any time a Construct project drops below 60, looks like absolute garbage and is a great way to get lots of complaints from anyone who purchases a game with a variable framerate. We don't live in 1996. Slowdown and frame drops aren't expected 20+ years later in 2D games.

I tend to agree. Although perhaps we are expecting too much from lower spec'd hardware and Construct 3 games running in Chrome? I don't think it is the C3's developers' fault - Chrome looks like a resource hogging beastie after my experiments on both Linux and Windows.

I see more and more complex web applications being offered lately. Let's hope Google will take note, and improve their brower's performance for demanding web apps.

Delenne - I opened Kiwi Story in C3 with Chrome Canary and it only used around 300mb of memory. It might be worth checking your browser addons, some can add a lot of extra memory usage, especially ad blockers.

I deactivated all the extensions in Chrome on my Linux Mint and Windows 7 - memory usage is now about equal on both platforms: ~450mb with the Kiwi project loaded up in Linux, ~520mb in Windows.

I have the following extensions on both platforms: Adblock Plus, and the Google applications (Docs, Sheets, Slides).

Much better now than the ~800-900mb on Windows.

When I preview the Kiwi game, memory usages goes through the roof again: an additional ~200mb is used for the preview window in Chrome!!! (Linux and Windows).

My view is that Chrome is a memory hog, and needlessly gobbles up memory, and that is bad news for anyone building a web app with Chrome as a foundation.

Not an ideal situation but we are beating a dead horse here.

C3 runs in the browser, with all the benefits that brings, but also with it comes all the negatives. i.e Construct 3 won't be as fast in performance as Fusion 2.5-3 , GameMakerStudio 2, GameSalad, Stencyl, Unity.

The question one should ask what is fast enough for your specific game you are trying to make. I think for most it will be fine. I really hope so. I like Construct and got along with it better than the other applications. However bad performance is obviously a deal-breaker if your game doesn't run well on a platform even though you did optimize it etc.

I feel your are right: even the performance of a simple platform game (Kiwi) is very underwhelming on a i5 machine with 4gb. Needless to say Godot runs smooth even when in preview mode on the same machine. And I tested by far more complex projects in Godot on the i5 machine.

My advice for now: stay away from Construct 3 if your intention is to create action games that must also run smooth on lower spec'd machines. And it worries me that the performance of such a simple game like Kiwi is lacking on a i5 4gb spec.

Note: I could not test the exported version of Kiwi, because C3 does not allow me to export the game. I would be surprised if it made any difference, though. Ashley: maybe it is a good idea to allow export of the demo games, so users may get a better idea of published game performance? Or is a published version of Kiwi available online?

I just read Ashley's new blog posting about Construct 3's memory usage. He seems to be happy with Constructs memory footprint?

Perhaps I am comparing apples with oranges, but... I loaded up Fusion 2.5 (Windows 7) and Godot (Linux Mint) out of curiosity, and compared memory footprints.

Linux Mint (harder to measure, I loaded each application and compared the difference in memory usage before and after loading)

Godot + platform demo game loaded up: ~135mb (game level visible in editor)

Chrome + Construct 3 + Kiwi project loaded up: ~600mb (game level visible in editor)

Windows Process Explorer

Fusion 2.5 + 39mb project loaded up: private bytes: ~72mb, working set: ~127mb (game level visible in editor)

Godot + ~180mb project loaded up: private bytes: ~308mb, working set: ~187mb (game level visible in editor)

Chrome + Construct 3 + Kiwi project loaded up: private bytes: ~890mb, working set: ~811mb (game level visible in editor)

With Chrome, 7 processes are opened in Windows, and although the Kiwi process's footprint by itself is 105mb working set, I think it is fair to add all Chrome processes together, because Chrome serves as the platform to run Chrome.

Take this as you will.

My personal opinion is that Chrome gobbles up unnecessary amounts of RAM even before loading Construct 3 - and in the case of Windows I loaded up larger projects in Godot and Fusion 2.5! It also explains why Construct 3 struggles on my older 4gb Windows machine: Together, Chrome and Construct swallow almost a quarter of the memory!

*Private Bytes – the amount of memory allocated to this program alone.

*Working Set – the amount of actual RAM allocated to this program by Windows.

After testing and playing around with C3, here is my second impression.

I work on a Celeron N3050 (8GB ram, 850gb SSD and Intel graphics) laptop with Linux Mint, and Construct 3 feels laggy to me. I compared Godot with C3 in Chrome, and opened the Kiwi platformer project in C3, and a much more complex project (Diasporic Crypt, a Castlevania clone! See github.com/Algorithmus/DiasporicCrypt) in Godot.

Construct 3:

+ double-clicking a layout takes 1/3-1/2 a second to register and open. When I open the enemies script sheet, the screen displays "LOADING" for a second, and then displays it.

+ switching between loaded tabs takes again a 1/3-1/2 second to register and display.

+ loading a level layout takes a second, and often the level elements take another second to display/load first time around. Switching between open layout tabs again isn't quite as direct as I am used to in my other applications.

+ dragging the split borders to widen the properties or objects panel is terribly laggy and slow when a slightly longer script is open in the main view. For example, when I open the enemies script sheet, and drag the border, the screen updates becomes almost unbearably cumbersome.

+ all clicks take a split second to register and execute. Some respond acceptably fast: when I select an event it feels snappy enough. But many other things take just slightly too long to execute for my taste. Double-clicking an event to edit it takes again a split second, and feels not as responsive as I would expect from an application.

+ previewing projects works fine. Editing is, however, not snappy enough.

I compared with Godot, and I opened the Diasporic Crypt, which takes five seconds to load. After loading, everything feels snappy - much snappier than Construct 3. Clicking things feels more responsive and direct.

What bothers me is that Diasporic Crypt is a much more complex game, but also uses high resolution graphics, with a wide variety of animations and assets. Construct 3's Kiwi demo game is a relatively simple game compared. Yet C3 in Chrome feels somewhat unresponsive, and Godot remains snappy while working.

I tested both also on my older Windows 7 i5cgu@1.33ghz 4GB machine that I still use for Visionaire. Again Godot feels snappier, and working with Construct 3 in Chrome is slower. I noticed that Kiwi plays slow in the browser, while previewing Diasporic Crypt runs quite smooth. And previewing in Godot slows down the game compared to compiling it as a standalone game, so...

Anyway, Construct 3 is too slow for comfortable working for me in its current state. I had hoped for better performance on my newer Linux machine. Godot works fine in comparison. Well, I wasn't surprised, really. Chrome is an extra layer that slows things down, of course.

And the Kiwi game lagged on the slower i5 machine, while Diasporic Crypt ran satisfactory - so I believe Construct games wouldn't run very well on machines with lesser specs (I read in threads here that NW.js doesn't help to improve the desktop performance?). That would limit my audience on Windows to users with higher specs.

I did like the script sheets in Construct. But after testing, I think Godot is a better fit for me and my Minty Machine <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":-)" title="Smile" />

Articy:Draft is a game design/narrative/story writing tool that is uniquely suited for planning your game stories - and it is now on sale at Bundle Stars for only $5.49 this week.

bundlestars.com/en/game/articy-draft-2-se

I use Articy:Draft myself to plan and write my adventure stories and character dialogues. This is not the newest version (3 was released in February), but the main difference between v2 and v3 are expanded export options and Unity integration. You also get 35% off till April 16 if you want to upgrade to the latest version (around$60?)

There is nothing like it on the market. If you are at all interested in making good back stories and narratives for your games this is the tool to have. Used by game designers and writers at some very large game studios!

youtube.com/watch

Sorry for the shameful plug, but it really is a steal and fun to work with to plan out your game stories and design.

Zebbi The IDE GUI is much more modern feeling in version 5 - version 4 is still good, though - not like AGS at all.

Bleenx: yes, Visionaire is for 2D and 2.5D adventures. I use Spine animations, which work well - but no blending between animations is supported, unfortunately.

I checked into Unity Adventure Creator, and I discovered it even supports Dialog System with import of Articy:Draft files. That is pretty cool. I will have to test it to see how well that works.

I do think Visionaire's workflow is much friendlier for 2D point and click adventures.

Good to know! Gmscript looks pretty easy to understand, it's shame anything higher than that gives me sweats! <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy" /> I didn't realise it came with a built-in dialog editor, I though you needed a separate asset for that?

Have you tried Visionaire Studio yet? Compared to Unity Adventure Creator it's even simpler, yet very flexible and powerful. 3d model characters and spine animated characters and object are also supported.

The newest version (v5 - beta is available - download from the forum) is about to be released (physics and improved particle systems). It's the main game engine used by Daedalic Entertainment (of Deponia, Anna's Quest, Dark Eye, etc.). "Four Last Things" is a hoot to play too store.steampowered.com/app/503400

For custom things LUA scripting is easy to use. It's my favorite for point and click adventure making, and a lot of fun to work in.

visionaire-studio.net

Lets just not bash the developers away from the development of construct engine

instead providing feedback and replies should be more then enough all are futures depend on it in some way if we are to use construct and the developers too but their making it instead : ) .

I think all our futures depend more on how humanity will decide to (finally) act on issues like climate, over-population, and human greed/stupidity, rather than one piece of software

But that's just me thinking out loud.

I am new here, and shopping around for a new game maker (I come from Ren'Py and Visionaire) to try my hand at an action game which I would like to create which are very different than visual novels and adventure games I use to make, so I need a different tool.

I played around for an hour with the C3 alpha, and I did not like it very much. I had to install Chrome (which I hate), and C3 felt a bit "childish" to me? Is that the right word? Many things are hidden. When I opened the behaviours, it just diplayed an empty window, and no option to add a behaviour. I closed it, and tried it again, still empty. After 5 minutes I noticed the only way to insert a new behaviour is to click with the right mouse?

Can't see myself working in a browser-based game creator to build larger games either.

I checked the C3 site, and support for Chromebooks is touted - I think C3 is aimed at that market (children).

Perhaps I am wrong? It is just my impression so far.

Some of these are browser limitations, such as AFAIK you can't download anywhere other than the downloads folder. Local file management is one of the things we'll be improving with the desktop builds, where it can be on par with C2.

It is possible. Open Chrome's settings, and click "Show Advanced Settings". Then find "Downloads", and check "Ask where to save each file before downloading".

I never use the default download location in a browser. But many users (even you, the developer?) aren't aware that this can be changed.