Random doesn't produce whole, rounded numbers.

This means that random(4) will give you anything from 0 to 3.999r, with 1.89237783 and 2.12301203 and everything else in between. You should use round(random(4)) to get a whole random number from 0-4.

It sounds like the events are running a loop, since reappearing at the destination triggers the collision event, sending the player back to the first teleporter, and on and on it goes...

I'd suggest adding a short timer to the player to prevent this from happening: reset the timer whenever the player teleports, and only activate the teleporters if the timer has elapsed a few seconds.

Rhindon, yeah, that sounds about right. I'll organise major groups under initialisation, UI, player controls, enemy behaviour and so on, with sub-groups for more specific things.

Personally, I find the tabbing in C2 to be pretty chaotic. It never saves tab positions and with all the tabs on one line it becomes a chore to flip through them when you get quite a few going.

I like to keep all of my core gameplay mechanisms in a single event sheet, which I organise by being very liberal with groups and sub-groups. It's also where I keep my debug group, which I sometimes split off into its own sheet if it gets too big. I then use a small event sheet for each of my game's levels. I also use a separate event sheet for global variables, as those can't be neatly tucked away in a group (for some strange reason).

I find that this process forces me to make my events reusable, so in my level event sheets I basically just put in the parameters for each level, like MonsterSpawnRate or LevelTime, which is then passed along to the main event sheet. If a particular level has its own unique mechanisms, then I just put those events in the local event sheet. As soon as I find that I want to use those events in another level, I go back to them and make them suitable for reuse by changing any fixed numbers that need to be variable, and move them to the core sheet.

Otherwise, I comment for every major block of code, but this is often superfluous and I just do it to visually break up the events. I also make sure that my projects tab is well organise with groups and sub-groups, and I do my best to use families wherever possible. I'm also now starting to get into the habit of making better use of functions where it's appropriate, like for character dialogue.

I can't be certain, and if you'd share your capx it'd make helping you a lot easier, but try format your events like this, with everything after num player in sub-events:

num player = 2

is touching player1area -> set animation

else -> set animation; destroy countdown

is touching player1area -> set animation

else -> set animation; destroy countdown

cesarzevil, we get that you're frustrated, but you need to keep a cool head about this. Nobody told you to shut up. There's been some bad advice given in this thread, but most of it has been good, and you seem to have ignored all the good stuff.

I still think that this is a matter of incorrect use of the software rather than the software itself, and I strongly suggest that you send an email to Scirra directly with your capx. That way the best possible people can have a look through your project without you standing to have anyone steal your idea/game/whatever.

I'm not saying that it's unreasonable to ask for a refund if the software doesn't do as advertised, or even if it's just not suitable for you (in my country, we have a seven day, no questions asked return policy for all goods, for example), but I do think that you should give it a proper go before giving up.

cesarzevil, Please post your capx. I think all of us here agree that there's a very good chance your game can be optimised to get the frame rate you want. It's at least worth trying before you give up entirely.

I use text objects that are off to the side of the layout I'm currently working on. I list them under TODO, bugs and milestones, and then colour-code them and order them according to priority. The system works for me but there's definitely room for improvement.

So, in that sense, I can get on board with the idea of a built-in TODO list thingy, especially if it could reference specific events and objects in that list.

But for every vocal complaint there could be 10 or a hundred people having the same issues who will just shuffle off without saying anything. If people are having issues that are caused by their lack of understanding, that cause needs to be addressed. Telling these people to give up and bugger off helps nobody.

philx Just tested it with my current project and it does indeed work. On Android 4.1.2, at least.

There isn't a way to disable the behaviour (oddly enough), but perhaps a better way to use the behaviour in general would be to have the screen follow and invisible dummy object. This gives you better control over smooth camera movements, and lets you customise the movement whenever you want by adjusting the position of the dummy object.

A relatively simple way to do this would be to give the sprite an instance variable called FixedY (or whatever you want). Then create these two events:

On Sprite created -> set Sprite.FixedY to Sprite.Y

If Sprite.Y > Sprite.FixedY [OR] If Sprite.Y < Sprite.FixedY -> Set Sprite.Y to Sprite.FixedY.

It's quick, but I would really appreciate it if this functionality was built in though.