Delenne's Forum Posts

  • 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.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

    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.

  • You do not have permission to view this post

  • 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