Ashley's Forum Posts

  • What exactly goes wrong? We can't help without a detailed description of any problems. Note you have to submit a few scores before the hi-score table appears.

  • The only way to solve this is to use framerate dependent physics. It's one of the few cases where you should avoid dt.

    The Box2D manual explains this issue a bit:

    ox2D uses a computational algorithm called an integrator. Integrators simulate the physics equations at discrete points of time. This goes along with the traditional game loop where we essentially have a flip book of movement on the screen. So we need to pick a time step for Box2D. Generally physics engines for games like a time step at least as fast as 60Hz or 1/60 seconds. You can get away with larger time steps, but you will have to be more careful about setting up the definitions for your world. ... generally you should use a time step no larger than 1/30 seconds

    Basically physics engines become unstable with large time steps. I guess the error compared to the "true" result gets really big. If you use dt as the time step, then the FPS gets really low, dt becomes big and the physics will become unrealistic. The only solution is to use a fixed timestep and let the game go in to slow-motion. (Increasing the iterations to improve the simulation quality will reduce the FPS even more!) 10 FPS is usually unplayable anyway, are users really getting that bad results?

    The Box2D manual actually recommends against a variable time step for stability reasons (and dt can have quite a lot of variation). That's part of the reason physics defaults to a fixed timestep. It's still nice to have framerate independence, but I guess Physics is unique in that it can cause problems, and it might be less bad to use fixed stepping.

    Edit: I guess we could add a maximum time step for Physics, to be 1/30. So it's framerate independent down to 30 FPS, then slows down the motion beneath that.

  • Hmm... I guess this is a trickier problem than I thought.

    But how does your custom engine solve this? Even using events, Construct 2 will still register a collision at the entrance of a 25px tunnel and stop you moving down it, right?

    Surely the easiest thing to do is just use a 1px smaller player object with a transparent background. Then the 1px thing is hardly noticable.

  • ramones - from Performance tips:

    ommon misconceptions ... Image formats (e.g. JPEG, PNG-8, PNG-32) affect the download size but have no effect on runtime performance (they are all decompressed to 32-bit bitmap on startup).

    Setting an image format affects the transmission of the file over the network, but has no effect at all at runtime.

    Tobye - From Best practices:

    emory use ... Some designers are tempted to design entire levels as single large images, for example 10,000 x 10,000 pixels. This method should be avoided at all costs... (snip)

    The section goes on, and you should read it all. In other words, as much as you might like to design your game by drawing the entire layout as a single image, you really shouldn't. From a memory use point of view, it's the worst way you can possibly design a game. If you cover your whole 10,000 x 8,000 layout with unique image content, it will use over 300mb of memory. This means you'll need a desktop with at least a 512 MB graphics card to even start the game up, which rules out a lot of common computers, and all mobile devices. And that's just the background before you've even started the rest of your objects and animations! You could end up with a game that won't run anywhere except the most powerful gaming systems.

    For this reason, in practice nobody designs games like that. Use tiled backgrounds and creatively recycle a smaller set of images. Even pro commercial games use that approach!

  • The top score on Go Faster is only about 50% higher than your own score. Surely if they hacked it they'd just put a score of 999999 or something? Or do you think they're trying to hack it while looking plausible? :P It's had 16,000 plays so far, it seems plausible someone insanely good came along!

    (I wouldn't be surprised if the scores ended up hacked though, we will probably make a way for authors to delete any scores they like from the table)

  • It works fine here, I can't see any problem at all. You realise by default it's a dropdown list, which only shows the first item, right? If that doesn't explain it can you show exactly what's wrong with screenshots?

  • The arrow keys use the unicode symbols for arrows pointing left, up, right and down. They appeared fine for me, but maybe you're using a different font? Perhaps that was too clever to try and use symbols, and I should just replace them with words...

  • What exactly are you doing in step 2?

  • You should report this type of issue to Ludei; our audio system works in all browsers, and if it doesn't work in CocoonJS, it must be a problem with their system.

  • I would recommend you just use the built-in Windows 8 object. It can do most of what the third party plugin does, and is stable as far as I am aware, whereas this one seems to have some bugs and isn't being updated.

  • I'm not sure what help to offer, the problem sounds like it is unique to your computer. Presumably the format broke it. Try reinstalling all the drivers and OS updates you had before the format.

  • jayderyu - that's a bug in Spriter, and you're just working around it with 'wait 0'. You shouldn't have to do that. If Spriter is not ready internally for some action to work yet, it should just queue up the action and run it when it's ready. For example the Pathfinding behavior does this. Internally it's not ready to accept any 'find path' actions in the first tick. But if you do use something like 'On start of layout - find path', it queues up the action and runs it on the second tick, so everything works like you expect. Spriter should to the same.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • An event with two triggers in it is a bit like an event saying "On the exact moment lightning strikes, AND the exact moment the clock reaches midnight". They will effectively never happen at the same time. It's not a perfect analogy though - in Construct 2 triggers always fire one at a time, so rather than being highly unlikely, it's actually impossible that any such event could ever run.

    You most likely just want to have this instead:

    + On collision

    + Z key is down (not 'on pressed', the 'is key down')

    or this:

    + On Z key pressed

    + Sprite is overlapping (not 'on collision', the 'is overlapping')

  • I'm afraid I'm not sure what could be the problem; nobody has ever reported this type of issue in the standalone version, so maybe it's a problem with Steam itself. Have you tried contacting Valve?

  • I've got a few items on my todo list aimed at searching and refactoring large projects. It takes time to get round to everything though.

    Have you tried putting a folder-based project on source control? That allows multiple people to work on the same project at once and then merge changes. It can resolve conflicts if you both edit the same thing as well, although you should still avoid that (you'd have to merge the XML files by hand). Good source control is very effective, and I think it would be very difficult for us to get anything as good as that if we tried to come up with our own system.