So What Is Your Second Impression of C3 And Will You Buy?

Ashley, and Tom, If you need any help with benchmarks, and or moderation of our little terrorist, Im more than happy to help.

He struck again? What was the name of the incarnation this time?

The last one I saw was namedlike "Juan Escobare" or something like that.

Sos about not our job to do benchmarks.

I guess development and bug fixing is deferred to answering the same questions, making pointless benchmarks on a beta product, and banning the same person over, and over.

Obviously this isn't a product for making games, it's just for him to play one.

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

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.

This is of course aside from the suspension of disbelief required to refer to 30fps as "great performance in a browser" on even a mid-range desktop PC with a decent GPU for a strictly 2D project. An "actual measurement" would hold more value - or any value at all - if it were based on usage more related to real-world performance. Which is exactly why performance-related benchmarking tools use real-world scenarios instead of (or in addition to) just spawning a bunch of static objects and calling it a day.

That said, Kiwi Story seems locked at 60fps, unless the debugger is open and updating all the stats on the default tab (that we can't switch off of in the free version and it heavily impacts performance) so there may be some other issue going on here than anything C3 or Chrome is causing. Memory usage hovers around 160MB if C3 is launched from a desktop shortcut with no plugins enabled, and that looks about right and is less of a memory footprint than I'd expect from Chrome by itself.

I can't even make a simple platform with two sprites without running into problems. After moving the player sprite back and forth for a couple seconds, the player sprite starts to sputter across the screen. In debug mode, it's says it's 60 fps, but it doesn't appear that way. Maybe it has something to do the preview window.

If the problem is Chrome, I don't see how Ashley can fix that. We are kinda at the mercy of Google.

Moot

Can you post the .c3p file that is giving you trouble? Maybe there is a problem with one of the behaviours you are using.

Moot

Can you post the .c3p file that is giving you trouble? Maybe there is a problem with one of the behaviours you are using.

It's just two 64x64 sprites, one with a solid behavior and the other with a platform behavior. The sprite with the solid behavior is stretched to make the ground. Everything else is just default settings. No events. Super basic.

I'm using the most current stable version of Chrome and an iMac.

Mac Specs:

macOS Sierra Version 10.12.4

iMac (Retina 5k, 27-inch, Late 2015)

Processor 3.2 GHz Intel Core i5

12 GB 1867 MHz DDR3

AMD Radeon R9 M380 2048

Nope...I am not sold on it. It just does not ...feel...right. Perhaps if I need to use it to upgrade my current projects, but all future planned projects have been moved elsewhere (sadly).

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

I've read through every post carefully.

I'm a hobbyist dev, I've bought two personal licenses for C2 in the last 5 years (one for a friend) and I loved every second of it, apart from the platform jump height bug that I've had to live with in C2 and I'm hearing is now fixable. Could it, I wonder, be an optional switch in C2 as well? It would mean a lot to me <3

Re: pricing, I've been priced out of software before, I stopped upgrading photoshop at CS6. $99 a year is too steep for me, the economic situation in greece being what it is and declining further every day. I know that's my problem to deal with, not something a company that needs to stay competitive needs to assess, but seeing formerly well-to-do friends suddenly have no money for food and shelter makes me think twice about switching to C3.

So in this precarious economy (which is reaching other European countries fast) switching to C3 isn't just about one year's worth of subscription, which I can fit into my budget, it's about becoming chained to one more recurring expense, when every survival instinct is telling me I should cut down on everything.

I know you've assessed the market and think that's the way to go if you want to have a viable product, and it's ok.

I'll be sad to miss out, but since the new product is better, it makes sense that it's a lot more expensive and that poor people will be priced out of it.

Was about to suggest that the game jam be related to benchmarking somehow, but it feels like I've said that before.

C2 inspired me to learn basic JavaScript programming, and for that I am very grateful. If c3 offered more than just renting c2 in a browser then it would have grabbed my interest, but the subscription model and its lack of progress over c2 has caused me to look at other engines. I don't believe c3 will be usable by serious devs for at least another 2 years - runtime re-write anyone?

If scirra used c2/c3 and their features to make top-notch games then many of the issues reported in these forums would have been fixed years ago. Armed with the disappointment that c3 appears to be in a cycle of indefinite amendment, I spent the last few weeks trying out Corona SDK, Unity and Godot Engine - all to compare to c2 html5 exports with other 'native' offerings.

Here's what I found:

C2 exports really don't perform well on low-end tech - and this is not always caused by the gpu. Something to do with using a full browser to do some simple maths and move a few objects, I guess. If scirra made games using their game editors then there would be universal acceptance that browser-wrapped JaveScript gives poor performance on low-end devices. A simple moving object and parallax background from a c2 export (wrapped in either phonegap or accelerated cocoon.io) ran at 15 fps on my Lenovo tablet. The same assets and a similar test from Unity, Godot and Corona all performed at 60 fps (Corona perf was truly amazing with physics as well...). The very same assets...

I think that the c2 editor is excellent, but the c3 editor feels slightly slower and offers less workspace to the user (bigger fonts and icons, like reading a news website in mobile-mode on a laptop). Not to my taste, but not truly terrible either. I have no idea how usable it will be or how it will perform when a complex project is loaded... Of the other engines I tried, Unity felt most visually comfortable to work in, but the API is truly complicated - Godot was the friendliest overall...

All game engines have bugs and require work-arounds for design limitations. However, with the recent announcement that the c3 runtime is to be re-written, I think it's safe to say that it will be a couple of years before this is finished and stable. It reminds me of the last few years of c2 development, where the excitement was found in adding new stuff rather than completely adding new stuff and then supporting it...

My main concern, however, was the poor performance of browser-wrapped exported games on low-end tech. For that reason above all I have decided to move on to use the Godot Engine - an excellent editor, used by the devs to make games, and with a less complicated API than Unity (based on Python, looks a bit like Lua). Who wants a full browser engine to run a 2d side-scroller?

c3 = not for me. I will occasionally tinker with c2 (where it's far easier to make plugins than it is for c3). Perhaps one day I will finish making a system to export layers into a Corona SDK project...

Was about to suggest that the game jam be related to benchmarking somehow, but it feels like I've said that before.

I think most people have just accepted by now the tradeoff between performance and ease of use. It may not be in their best interest to have a jam which could potentially focus on a downside and maybe highlight for some that Construct isnt always as fast as people think it should be. They may end up not subscribing.

My second impression is that I can not buy, only rent

I do not know why they say to buy when it is to rent

Was about to suggest that the game jam be related to benchmarking somehow, but it feels like I've said that before.

I have a feeling the gamejam will be a disaster- using a buggy/untested product isn't going to go over well with people who want to make their games work in a short period of time.

I don't believe c3 will be usable by serious devs for at least another 2 years - runtime re-write anyone?

I have a similar feeling, but for different reasons- They are using the latest browser tech which isn't supported across all devices/computers. So it might take a couple years for everything to balance out. It's a good strategy for Scirra if they want to get a headstart, but I think it just means that for a while it's going to be messy.. Not everyone is going to have the right setup to use C3.

> Was about to suggest that the game jam be related to benchmarking somehow, but it feels like I've said that before.

>

I have a feeling the gamejam will be a disaster- using a buggy/untested product isn't going to go over well with people who want to make their games work in a short period of time.

Well it's always been about what you can do with what you have. The problem starts when people equate what you shouldn't do, as something you can't do with the product.

What they have is viable, it's just going to be very niche, at least till some really big advances come around, cli exporter, new runtime, etc.

It pains me to say, but I just can't see the worth as is, not when I'm struggling with a saturated market, that this will only add to.

Not to mention that the C2 store seems to have stagnated in response.