Ashley's Forum Posts

  • Nintendo are very strict about their NDAs, and I don't want to upset them - so I'd rather Nintendo could step in and answer any questions. I'll ask someone at Nintendo if they can answer any questions.

  • The size of Construct 2's runtime might actually work to its advantage here. Hacking small, custom-written games is often easy - there might just be global variables with your score or position or whatever in them, and once you've found them, game over. However C2 has tens of thousands of lines of JS, all making up a fairly large framework that tends to store things buried fairly deep in lists and tree structures. Even pretty printing the code and running it through dev tools is a pretty daunting task. It's also possible to "protect" variables by keeping multiple copies of them in different places, but modified in some way (e.g. converted to a string and reversed). Then you can check for modifications if the variable doesn't match up with the copies. Combine that with a large and complicated obfuscated engine and it would probably be tricky enough to keep out casual scripters. And then, only the host can mess around with things - and if you're playing with a cheating host, I guess you can just find someone else to play with.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I think people just delete things from their dropboxes from time to time. Tom's working on a forum upgrade which can attach files to posts so hopefully that will solve it!

  • Yeah, the backup folder should not be the project folder! If you do that, each backup file will include all the other backup files, causing them to grow in size.

  • So as STARTECHSTUDIOS reported (thanks for the clear repro!) there is an edge case with collision cells: turret behaviors with extremely long ranges can in some closes be slower. The turret behavior is not really designed for that, and it should be easy to work around. More details in this thread: http://www.scirra.com/forum/improving-upon-the-performance_topic84725.html

  • The Turret behavior now uses collision cells to avoid having to check lots of objects. This is good for games like RTSs, where you have loads of objects. In this case you just have one player object so it doesn't benefit so much.

    The problem is the turret range is set to 10,000 - which seems excessive, it's the size of the entire layout. This is inefficient, since surely you don't want to bother dealing with turrets very far away from the player? It would be faster to simply ignore those turrets.

    Collision cells mean that checking a 10,000 pixel radius involves checking a few hundred collision cells. Since you've told every turret to detect range over the entire layout, then created over a thousand turrets, it's now checking hundreds of thousands of collision cells. Before collision cells it would have only checked the player directly, so it is indeed doing a lot more work. So this is indeed a worst-case-scenario for collision cells. However if you had a reasonable turret range and hundreds of Player objects spread out over the layout, collision cells would make this far, far faster than not using collision cells (as is true of many other cases).

    Basically this is mis-use of the turret behavior. Hit the range down to 1000, and the game appears to function identically but at an easy 60 FPS. If you could reduce the range further it would be even more efficient. If you want to detect the player over an infinite range, don't use the turret behavior - just use an 'every tick, rotate towards player' event (which effectively does a turret behavior over infinite range while circumventing collision cells).

    Collision cells do make a trade-off, and some edge cases like this may be slower, but it should be easy to work around. Note this is also specific to the Turret behavior's use of collision cells, and does not affect collision cells in general. Closing as won't fix.

  • Can you provide a project that reproduces this issue?

  • Closing as an issue with third party plugins.

  • Kybele - post a bug report following all the guidelines or the problem won't be looked at.

  • asm.js code is basically assembly code represented in Javascript syntax, so there is probably no easy way to find that line and change it.

  • Part of the reason we have a Javascript SDK is so they can go and add support themselves. We are too busy to support every service that could possibly be integrated - there are probably hundreds.

  • We're all under NDAs so I don't think we can discuss the particulars of the Nintendo Web Framework. Perhaps you could try to ask Nintendo directly.

  • Nintendo make everyone sign NDAs when they get the dev kits, so most likely nobody is allowed to tell you.

  • My Nexus 5 can get over 20,000 sprites on-screen at 30 FPS. This is higher than a couple of the desktop machines in our office. When these devices become old devices, things will be looking pretty good for mobile games.

  • I can't reproduce this in either the standalone or Steam version. It launches just fine.

    Normally this type of issue is caused by third party plugins which make breaking changes. Can you still reproduce if you remove all third party addons?