Ashley's Forum Posts

  • Optimisation: don't waste your time. If your game already runs 60 FPS, it's pretty much just a waste of your time to try and optimise it. C2's collision engine is pretty good, and objects which are not overlapping their bounding boxes can be discarded from collision checks in virtually no time, so trying to reduce that further with a timer will probably just have no effect and unnecessarily complicate your events.

    Node-webkit uses the Google Chrome browser engine. So it ought to work identically to Chrome...

  • Please stick to English on the forums, thanks.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It would be best to contact Ludei about this issue.

  • Good summary as always, thanks :)

  • Web security is hard, especially in Javascript where all the code is locally viewable. However the size of Construct 2's engine actually works to something of an advantage here: it's so big, and all obfuscated by Closure Compiler, that it can actually be quite a lot of work just to find out where the relevant code for posting a score will be.

    The most important thing IMO is not to have a single URL where you post a score, i.e. game.com/submit.php That's trivially controllable. You should make it more complicated than that, e.g. introduce a back-and-forth (so there are multiple posts with other processing/logic steps in between). Then at least the bar is raised from being able to find or emulate the javascript logic running that rather than being able to enter a single URL. Then there are some cheap tricks you can throw in like appending the URL from individual characters so the URL isn't directly viewable in the source. Combine that with some other ideas in this thread and you should be able to make it script-kiddy proof, but I still wouldn't pretend it's actually secure, it's just obscure. If you put a prize on a highscore, even with these methods the prize would probably provide enough motivation for someone to crack it. You should avoid giving prizes for highscores, unless you require substantial proof like a complete playthrough video, which would be a pain.

  • Construct Classic has been retired, so you should not use it. Give Construct 2 a go!

  • Looks pretty smooth to me. Are you sure you're not just spotting V-sync misses?

  • Try playing it in Safari. It should run full performance there. (I don't know what DPS does, but it probably uses a very slow browser control.)

  • Sounds like you were on the right track using the object's ID in the tag to identify samples uniquely. What didn't work about it?

  • Construct 2 has a WebGL renderer which allows it to make full use of the GPU when supported. Even if a platform does not support WebGL (and it looks like most will in the near future, even IE), almost every platform has a hardware accelerated 2D canvas, which still uses the GPU but is a little slower due to extra CPU overhead.

  • This sounds like everything is working perfectly normally. If the 'Pick instance with UID' condition is not met, it does not run the event actions (so does not log anything). If you log text in the 'On function' event, it always logs text first when the function is called, then after that tries to pick an instance with a UID (which may or may not work). Nothing is amiss here.

    The console log message refers to a different function, called "highlight block". It's unrelated, the event you've shown uses a function called "MyFunction".

  • The tutorial delta-time and framerate independence covers exactly this.

    Normally games run at 60 FPS. So if you move 6 pixels per tick, it's moving 6 x 60 = 360 pixels per second. However it will change if the framerate changes.

    So to prevent it changing when the framerate changes, move it 360 * dt pixels per tick instead. Then it moves exactly the same speed as it did before at 60 FPS, but the actual speed does not change if the framerate changes.

  • You can do infinitely scrolling backgrounds without this, e.g. in the autorunner template. Also Sprites are better for tilesets - if you have crashes using them, you should report it as bugs and we can look in to fixing it. C2's spritesheeting on export will make them in to a few large images anyway, so you still get the fast download and low memory usage at runtime.

    The main reason it's not supported is while it's easy in WebGL, the canvas2D API for tiling images is completely flat out bonkers. I have no idea why they designed it the way they did, but it was a struggle just to get it working with scrolling, and a huge PITA to get it working with rotating layers, so I dread to think of wrestling it in to doing offsets. In the mean time there are workarounds, such as using masking layers or just sprites for tiles.

  • Manfred - it's on my todo list to add an official geolocation plugin. You should probably wait for that, or if you're desperate, use the Javascript SDK yourself - the ExecJS expression is entirely unsuitable for this type of thing.

  • Yup, it's all on the todo list, but you can get a lot of mileage out of an ordinary for each or for-each ordered followed by compare two values.