The anchor behavior only keeps an object in its position relative to the borders of the screen - it does not move it to the edge of the screen.

Have a look in the manual for "viewport". You can place the object using that system expression. For example, if you want to place an object touching the left edge of the viewable screen:

set Sprite.X to ViewportLeft("HUD" + Sprite.Width * 0.5) .... where "HUD" is the layer name of you HUD.

Have a look at this demo I put together for an example of this.

That 'tutorial' was rather brief but ok as an introduction. Try searching for "scale my game" in the tutorials section of this website instead. There are loads of tutorials there that will help - but reading is only part of the process, get in there and play around with various settings and see what they do and how they do it. Also search the manual for "scale" and see what comes up...

White edges implies that your background does not fill for the scale mode and aspect ratio you have selected.

I suggest you follow this thread and this thread. There's no way to access google leaderboards at the moment and cocoonjs offers the best short term solution now that the plugin has gone open source. Crosswalk should offer the option as well but I don't know the timing for that one either.

Same here. Just having the new plugin in the project causes it to fail to run.

You have to figure a way for a second touch function to not be acted upon by your events. Remember, the events run every tick, so the only way to ignore a touch event is to add a condition to the touch trigger so that your code can identify when the trigger has been actioned before. You can't simply disable touch on an object, it doesn't work like that. There really are a lot of ways you could do this.

One simple way is to add an object boolean to your sprite - something like object.Touched. Check that the boolean is false during your touch trigger and then set it to true during the subsequent commands so that the touch event trigger cannot fire again.

Also remember that if you have mouse input set to yes on the touch object then that can also trigger two touch events on some iOS and Android devices.

Just to clarify, because I think that my point about the manual may not have been clear. I read the manual within a couple of weeks of starting to use C2, however my comprehension of C2 was still lacking because I had very limited experience at using it. I had programmed before and used other game engines but that experience was only useful up to a point. A few months ago I had to completely re-write the engine for an app I have because I wanted to make a small adjustment and my original event system was so - frustrating - that I couldn't stand working around the inefficiencies I had coded into it. I had learned a lot in 6 months and was a little taken aback by how little I knew at the start. C2 looks easy to use (that's the big selling point) but is in fact a very powerful alternative to coding - and that power is its strength and weakness. The user has total freedom to do what they want but that means that they cannot cookie-cutter a game in 20 minutes because they need to create their own unique control features. That is why I like it so much above MMF and the other alternatives - I can do exactly what I want and not what scirra thinks I want.

WRT to the layout option - this would satisfy so few people and would only serve to complicate the interface. How would C2 know which layout precedes the one that's being played when you might have 50 layouts for the main game and another 20 for interstitial screens / settings / options etc? What about a game like angry birds where the user can select the next layout to attempt? Any changes to encompass your desire to 'goto next layout' would have to not make any of those alternative game constructs harder to create. I would rather Ashley and the team worked on one of the numerous other areas where C2 could be improved before they start adding complicating features that are already easily worked using the current event system. I guess that it could be a nice feature if I wanted to make a linear game like flappy bird but there is a reason why so many on this forum will oppose these sorts of suggestions.

There are areas where improvements could be made, but a good first port of call is the help forum. There you will be helped to learn how to take advantage of C2 and its strengths and, if there is something that could be made better (like sprite-font) then it will only be accepted if there is no easy and workable way to do it already.

DialgaBrite, the bullet behavior and other movement behaviors already have set speed commands.... I suggest you read the manual before suggesting things c2 already obviously has. Some of your ideas are relevant but it sounds a bit like you haven't really looked into and tried some of the things in c2 that you think are deficient.

If the manual, demos and tutorials don't do it then post a question on the how do I forum. If the answer still feels too convoluted or even plain daft then it could become a good suggestion for change. What this thread is becoming, though, is a list of a couple of good observations hidden by a smoke screen of evidence that you apparently just don't like a lot of c2 because it's different and you're not used to it. Just different isn't wrong....

Your next layout point. for example, doesn't work if you have a game with many adjacent rooms - next could mean one of 10 options, and so c2 doesn't handicap you to have to be limited to one way of managing your game.

It can be frustrating sometimes using spritefont just for score number generation or if you want your text to have better effects than Blackhornet's excellent font generator. What I would really like is C2 to support this free program. I would rather not spend a whole day setting up my bespoke shiny 3d effect font and tweaking the individual widths so there's no overlap if possible. I don't like the limitations of the mmf setup as championed above but the spritefont plugin would benefit from something like this...

I've had similar weird frustrations in the past but I've not encountered this one. Try creating a local variable and first assign it the token-at value before then passing the local variable in the function call? Ie no text calcs inside the function call command. Hopefully might help you...

Ignore the last one - this is even better. It uses a for-loop to set the timer value at the start of the layout according to the instance variable you set (better for editing in the layout view).

Here you go...

I substituted the bullet behavior for custom movement (that was why the hammers were creeping upwards - don't know why but I'm not a fan of using bullet behavior for things that aren't bullets). I added a timer behavior to the hammers and used that to trigger their falling - they are selected by UID at the start of layout but you could easily add a variable and select by position number etc if you wanted.

Edit - attachment deleted (see the example below - it's better IMO).

OK, I just spent ages implementing a plan B to spawn all instances at the start of the layout and - I can't tell the difference (in chrome and cocoonjs)! So, back to plan A because it's easier to manage.

It feels like there is a small spawning burden but it is only really noticeable when spawning more than one object. I try and avoid that sort of thing anyway and that's probably why I can't see an improvement (it was running pretty smoothly before). Science project over, back to actually trying to 'develop'....