Great question! Hopefully, somebody else has already tested this and can let us know.

The same amount of pixels would be drawn in either case. So, I think it may depend on how well the particular browser scales the canvas versus not having to scale at all.

Would you be able to copy your entire project, and test the different dimensions in the copy?

To answer your first question, if IsKeyDown is true, then actions and subevents of it will be run every tick that it is true. IsKeyPressed is only activated once for the entire time that the key is down. Other than that they should act the same. Both may even be first activated on the same System.tickcount, but I haven't tested this yet.

I haven't experimented with the Gamepad.axis yet to know how that works. Have you already checked out the manual entry for Gamepad

suatozkan1987, sorry, I'm still not exactly sure what the issue is. But, if it works on all PC browsers, and just doesn't work after CacoonJS, then I'd say there is a problem on Ludei's end. You could create a bug report.

Why not just use different objects, and touch those objects to simulate the mouse?

This sounds like a good solution. And, perhaps you can have extra debug events as a subevent of System."Is in preview mode".

As alvarop said, tags for the music/sounds are VERY useful for starting and stopping them individually. I would also highly recommend putting the name of the audio files as global constant variables. It'll also help whenever you need to change a file name, and you get the added benefit of the name of the sound file appearing as a auto-completion.

In the paid version of Construct 2, this issue can easily be handled with a Containers.

In the free version of C2, when the trampoline moves, you can define each of the sprites to also move the same way. This would just take more events and actions.

statham, but if you want more jumping direction without adding additional sprites, you could possibly get the location of where the player collision occurs, the do some maths to calculate the angle the player should bounce.

miketv, okay, I can imagine scenarios where the background is most important. Maybe that sort of game would have different themes for the user to go through. In that case, you still don't need to load graphics that are nowhere near where the window the user is viewing. I think that idea to split the single very large image into multiple smaller images would work great. Then, when you only load the images as they are about to appear to the use (and destroy ones that leave), there will be less memory usage, thus a better performance.

When I said the "pseudo-infinite" layouts, I just meant that some game designers have manually created/programmed the level to look a certain way, and every time you play that level it will always look the same. Then, it could be made practically impossible to get to the end, or it could just loop around with more enemies, as an example. A somewhat popular game a while back that I tested was "Robot Unicorn Attack 2". In that game certain levels were always the same, but I never could reach the end.

For the randomized infinite layouts, the Construct 2 start dialog (Ctrl+n) has a great example called "Flying along". Also, the current game/app fad, "Flappy Bird" has an infinite random layout. And, when I say "random" with these games, there are typically restrictions on what can happen so that parts are impossible to complete.

Awesome! I recently found that part of the manual and was thinking about something like this. I'm glad you created it!

thejbos, +1. Thank you very much for sharing this. I mainly publish to Windows 8 (and WP8), and will probably experience this the next time I try to export/publish.

Was it a complicated or basic game you had? About how many sprites on the screen at once?

There is no single best platform out there for everything. Construct 2 specializes in 2D creations and ease of use (though people have also made imitation 3D apps and do develop very complex programs).

liquidsnake, C2's easy learning curve makes it ideal for you also because you can spend less time figuring out how the system works, and more time using your writing and artistic skills.

Since you rather more focus on story and artistic expression rather than gameplay, one idea is that you can work together with another C2 developer?

And, as alvarop said, the free version will get you very far. ;)

As — said, having the huge background image will take up a lot of memory which some low-end devices may not be able to handle.

miketv, it's all about the experience that you would like to provide for your users. There are successful games that design the entire pseudo-infinite levels and there are successful games that have entirely randomized infinite layouts. But, I doubt either has an image that is the size of the entire level. There are much more important aspects to the game that you probably want the users to experience.

komalrajsingh, thanks for sharing your code. I like learning how others also organize their code. And, I'm sure I'll learn a little more about C2.