I need to be sure everything is being transmitted securely and make it very difficult or impossible hackers to gain an edge. Are there any features that facilitate this, or will I have to do my graphics and all scripting manually in real code?

You'll have to implement cheat detection/prevention yourself with events, on the server. What do you mean by real code? When you're making a multiplayer game you're going to have to be more hands on at a low level with events. If you aren't experienced at programming you might have a hard time with this.

It's the same runtime as C2 so it should be exactly the same in terms of game smoothness. AFAIK right now the only thing different is the editor.

The reality is that HTML5 isn't good for console export. It sucks for WiiU, and it'll probably suck for the switch. You probably aren't going to get good performance on a complex game with HTML5 on anything that's not a PC. The exception might be Xbox one, since they're trying to unify apps across windows based devices, so they have more incentive to get things working smoothly on that front.

If you want a game with good performance on all consoles today, don't shoot yourself in the foot from the start by using HTML5.

If you're on Windows there's little reason to use or subscribe to C3 right now.

C2 does more than C3 right now, due to third party additions that greatly expand the feature set. I wouldn't put off buying C2 just because C3 is out; it's still useful and very good software, and they'll support it for a while. You won't get new features anymore, but it doesn't need new features really, it's pretty complete as is. Buy C2, it's great. C3 is just a browser based version of C2 with no third party support right now, and it's still in infancy.

What's really puzzling about this sub model is that they're releasing C3 with very little meaningful improvement over C2, no third party support (plugins have yet to be ported etc), and useful features way out on the horizon. When C2 first came out, it was CHEAPER because it was new and lacking features, hence the "early adopter" period. Once it got better, the price went up from there. With C3 you're an early adopter but you're paying full price right now unless you get that discount from owning C2. Will this mean the price to sub will go up even more once things like the new runtime come out? I don't think it will, but I sure hope not.

You need to retain something from a subscription as well. It would make people feel invested in the program and make them feel like they own it. The problem with subscriptions is that people don't want to subscribe in the first place if they know they'll end up with nothing. It's not like a magazine subscription where you get something concrete. Subbing for 5 years means 500$. At the end of those 5 years, you've got nothing to show for it, and are locked out of editing your projects. It's a huge disincentive to using the software in the first place. Consider letting people keep the versions released during their sub period. You will get a lot more customers this way, including ones who will continue to subscribe year after year just as you want. The idea that they own something will make them happy, and you won't be losing anything. Many people are extremely opposed to renting software. In this way people pay for continued updates, instead of continued use.

We'd rather come up with one system focused on browser usage that covers everything. The standalone versions are basically a bonus for Windows, Mac and Linux users only

Ashley

Game engines are a bit of a special case. People work on long term projects and absolutely do not want automatic updates to the editor or runtime. There's a reason Unity has every old release available for download, and even releases patches for old versions of the engine. Once you're on a release it can be a big headache to upgrade even one version ahead. You have to study patch notes like crazy and see if they apply to you. You have to re-test the entire game and hope nothing broke. Every little fix or change in a new version can heavily affect a big project. Will users be able to launch the release version of their choice when launching construct 3? If that's not an option on all platforms, that's a pretty big problem. You don't want someone on Chrome OS to always be running the latest version automatically. Users MUST be able to freeze their release version for stability reasons, including if there's no standalone versions. And users should be warned when saving an older version project to a new version.

EDIT: Ok, it appears that you can launch old releases from the website at least.

Like newt said, without a load this measurement is pointless. You're just measuring the performance of an empty project which is pretty much meaningless. It's not taking into account how things like the scripting engine, graphics, or collision engine scale. Similar to algorithms, the performance of the engine subsystems are xn+c where n is the size of the input (how much code, collision, sprite rendering etc.), x is some factor, and c is a constant. Right now you're just looking at c.

Obviously there will be bugs on the first days of release. The whole point of a beta is for bugs like this to surface and be dealt with.

Is this .c3p file supposed to show that when moving the circle back and forth, the black line doesn't always line up with the ground at the same place as when you started? (when pushing it back and forth against the wall, let's say, it becomes misaligned compared to the starting state.)

If that's what you're trying to show, here's my response:

Sampling delta time in an accumulator fashion like what you're doing in the .c3p will always show imperfect results. Why? Because delta time varies ever so slightly and you're summing a ton of floating point data over time. Floating point data does not represent an exact number (due to a finite number of bits used to store it), and is susceptible to rounding error/cutoff. The problem becomes exacerbated when you start summing up lots and lots of this approximated data, because you're losing some every time.

Ashley

Was implementing multiplayer really a waste of time though? Is your use data based only on your signaling server activity levels? If so, then it's quite obvious that the majority of users won't be using it much; it's a lot of work to make a multiplayer game and beyond the capabilities of beginners. But simply having multiplayer as a feature in C2 probably sold a lot of copies of the engine. Even if it goes unused. People buy things based on what they want, and not necessarily on what they will end up using. I'm sure a ton of hobbyist's first question on reading about C2 was "can it do multiplayer." And the answer is yes, so they bought it. It sounds cool to them and they like the idea. In reality, 99%+ won't ever make a multiplayer game, or even a single request? to the signaling server. But they bought C2 because they know the option exists. The poll on the forum clearly showed that there was a lot of interest in that option.

Dt will always have random variations, that's the entire point. The fix Ashley made is internal to the platform behavior code only, and has nothing to do with Dt or pixels per tick/second in general.

I think technical issues aside, there has been a huge ideological shift from Construct Classic to Construct 3.

I completely agree with this. I do think they are trying to make the best 2D HTML5 game engine possible still. However they seem to be excited about C3 running in a browser, without asking why people would want it running in a browser in the first place. Yes, it's very cool that complex software can run well in-browser, with hardware acceleration and multi threading. Kudos on the execution of this. I'm impressed at what you've accomplished. But why does professional level software need to be browser-based from an end user point-of-view? One big advantage is multi-platform support. But editing a game on a phone is not useful. Any for-PC game will not even work because there's no touch controls set up and/or the game is too demanding for the hardware. Nobody does work without a mouse and keyboard, it's just not practical. Even something like music creation software is a nightmare to use on mobile devices.

It's understandable that they're trying to reach a larger market with the multi-platform editor, but at the end of the day people just wanted another big paradigm changing upgrade. The paradigm change this time has nothing to do with the engine itself, but the editor.

Construct Classic was exciting because it had a great event based language, and the runtime was extremely performant, both in code speed and graphics, it was IMO the best 2D game engine at the time.

Construct 2 was exciting because it broke new ground on the HTML5 front and made the editor bug free and stable, at the cost of code execution speed (since it moved to JS from c++)(I haven't done any benchmarks recently with chrome's JS engine but I believe it's still slower than Classic). C2 was very well supported and they did their best. HTML5 based games are great in theory and they're almost there, but they aren't quite perfect. Reliance is on wrappers and device support. I'm not surprised that the Wii U can't run a "for-desktop" HTML5 game.

Construct 3 brings.. A better editor for all platforms (good for non-windows users I guess), and that's about it. I would even call the browser based editor a downgrade for windows users, simply because almost everything that they've added could have been done to Construct 2's editor. A browser based program will never be better than a native application. Easier to write, maybe. Better for the company for control/update purposes too.

I would never use the chrome based editor for a serious project if I were to use C3 (which is unlikely). It would be static versioned, tested, wrapped windows versions. I can't afford a chrome update breaking the IDE somehow or causing problems. Or what if chrome drops support for feature x or y which construct uses since it's so cutting edge?

The features in C3 are just quality of life improvements to the editor, or things which won't often be used. I've read all of them. Adding them together does make the experience better, but there's no "wow" features to the engine itself to be excited about, coming from C2. Especially considering the hefty subscription fee. Using C2 just makes more sense unless you want to support Scirra.

Decoupling a sprite from its frames is very useful. It makes the program a bit less beginner friendly unfortunately, which I don't think Ashley wants. The way it could work in Construct is that when you add a new sprite object, instead of being taken directly into the image editor to define the first frame, a popup box appears and you can assign an animation(s) from the project resources bar/some new UI window containing animations. This would mean animations are globally accessible to the project and not tied to sprites; sprites simply inherit them. This would require a change to the UI of course. Being able to decouple frame data from the image as suggested here would also be nice; you would be able to reuse frames when defining animations. I doubt these things will be added however as they require big changes to the way construct works. A workaround which might be possible and would be very useful is a runtime action on sprites to inherit animations from another sprite type and add it to its own animation list. It would come in handy for certain in-game UI cases where the same animations/images need to be displayed on different object types. (think of a level editor, where every graphic in the game needs to be accessible to a single sprite type, or a fighting game character selection screen that displays the character). Sprite types should inherit animations, and animations should be able to share and reuse segments of spritesheets. Construct's current way of setting up animations frame by frame is good for beginners though, if they don't work with sprite sheets.