Ashley's Forum Posts

  • From a cursory look, Playmaker is very different to Construct 2. It looks like it's based on 2D flowcharts, whereas Construct 2 uses a list of events and sub-events that work by filtering instances (see how events work).

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't think modern mobile networks are as bad as you think. Admittedly I've only done one or two tests, but connecting over HSPA cell data in the UK only added 20ms to my ping time to a US server (70ms from cell data, 50ms from wifi), and was otherwise responsive and smooth. The main problem with testing this is none of the tests we've made support touch input properly yet. Maybe I should make one specifically for testing in Chrome for Android...

    Anyways the multiplayer engine can cope well with high packet loss due to the buffering techniques it uses, and usually only complete packet loss (e.g. temporary reception drop, such as going through a tunnel on the train) will trip up the game. The biggest problem from the tests that I've seen is that a high PDV makes the synchronisation unstable, but I haven't done enough testing or research to know if PDV is worse over cell data. It might not be.

  • Yep, hopefully we'll get a solution soon, but the way asm.js works is kind of tricky. Meanwhile the workaround is of course just to skip minifying.

  • Are you using asm.js physics? I think there's a known bug where it gets broken by minify on export, but I'm not aware of anything else other than badly written third party addons that are also broken by minify.

  • Right now we're focusing on completing the engineering work. We will be considering custom-hosted infrastructure later down the line but don't have any clear plans right now.

  • True Valhalla - as of r163 they're well-optimised, stable and complete in the sense that we don't have any immediate plans to add further improvements. That doesn't mean we never will though.

  • It's not on the roadmap at this time.

  • Do not attempt to translate Construct 2. The feature to load strings from the .xml file was never finished. You cannot translate all of Construct 2, and sometimes if you translate something, it will break that feature.

  • We have no ETA, but it's taking longer than usual due to the sheer scope and complexity of the new multiplayer feature. Hopefully the next beta will be out within 1-2 weeks.

  • The 'Window size' project property is poorly named. It should be called the 'Viewport size'. (I don't think we will change it because other expressions and a lot of documentation refer to the same name.) It just sets how much of the layout you can see.

    When the game is actually displayed at runtime, the size it ends up on your screen is the display size. For example you could have a 'window size' of 854x480 and use letterbox scale mode to display it at 1920x1080. In that case the viewport to the layout is 854x480 and the display size is 1920x1080.

    In 'High quality' fullscreen mode, in practice only the display size affects performance. Note if you run a game in a browser window, you can resize the browser smaller and notice it's running faster. This is because the display size is smaller, so there's less GPU work. The project viewport is still the same (i.e., the project 'Window size' property has not changed, even though you resized the browser window. I do regret choosing that name for the project property!)

    In 'Low quality' fullscreen mode, the game is rendered at the 'Window size' in project properties, and the result simply stretched up to fit the screen. Usually the stretch is fast and the performance impact can be ignored, so the display size is effectively the same as the viewport size. Since the viewport size is usually smaller than the display size, this improves performance.

    In no case has the memory use changed. The viewport and display size do not affect the textures that are loaded to memory, which are always fully decompressed images at their original size they appear in the image editor.

  • Juryiel - in my experience, 90% of users don't even read the message, and click the first button. Then when it crashes they will email you complaining!

  • Perhaps contrary to 'test mode' it still fires the 'success' handler in the real store, but with 'Has product' returning false. This is at best confusing design on the part of Microsoft, and I'd consider it a bug... but we might be able to work around it.

    I presume it works fine if you add the 'Has product' condition under 'On successful purchase'? And if 'Has product' is false in that trigger, treat it also as a failed purchase.

    If that workaround works we can build it in to the plugin itself.

  • Scirra can't really take responsibility for the accuracy of information posted on third party sites. There's just no way we could logistically manage that. Also like the OP says I would strongly recommend not covering anything any official documentation covers; that is written as accurately as possible and is kept up to date with every stable release, whereas user-submitted documentation might not be.

  • Andre Krug - note that Construct 2 games stream audio after loading, so if you are concerned about loading times, don't count audio files in the 3mb limit.

  • Great summary as ever! Just a heads up the markup around the 'forum issues thread' link seems to have gone a bit funny.