When creating set the y coordinate to random(minimumY, maximumY)

with minimumY being the height needed to pass underneath and maximumY being the maximum height reachable by jumping.

Instead of using many sprite-objects you could use one and just have the numbers be animationframes.

That way in the calculation you could use the framenumber.

Very true, however, said limitations seems pretty blurry at the moment, which does not help as two systems can react differently while having the same type of hardware, and sometimes a better hardware will not support correctly something, hard to define the limits and so, to work with them.

I agree, the limitations could and should be a lot clearer and more predictable.

"Build once, publish anywhere" is too bold of a statement at this time.

In my opinion you should try and keep the database part as small as possible and while writing to database also write to webstorage, that way you can compare the in-game-data to the database-data, to try and prevent cheating.

Making secure calls through Ajax is probably something a php/datbase-programmer should look into.

I guess the solution above was better.. haha

Ninjaaaad..

You shouldn't need that code for this.

Adding the anchor-behaviour and putting the buttons on a layer with no parallax should do the trick.

By the way,

The reason I used viewportright(0)-viewportleft(0) was to make sure that when you use something like scrollto to get something to center it doesn't mess up the width,

for even if the coordinates of viewportleft were to be negative the width would still be correct.

I'm not sure what you mean, haha..

I'm guessing you have read the multiplayer part of the manual?

https://www.scirra.com/manual/174/multiplayer

A lot should be able to be done on the device of the player itself.

I've never worked with multiplayer myself and I have no clue as to which parts of your game require communication between devices, so I guess my ability to be of service kinda ends with trying to point in the right direction.

Nobody has answered my question and I'm genuinely curious.

Why is mobile performance of C2 games so bad? Is it the fault of the HTML5 wrappers?

The simplest answer is:

Mobiles are far less powerfull than desktops and to get good performance on mobile a game/app needs way more optimisation.

It will take a lot of bad programming and bad use of system recourses before a desktop gets into trouble.

Mobiles on the other hand, having less power and recourses, are far more likely to get into trouble when processor-time/graphic-abilities are mis-used.

The biggest challenge of programming is working within limitations and making it appear there are none..

A game like the one you'd like to make consists of many different elements and could take a lot of time to create.

A lot of these elements are covered in different tutorials.

For example Register-Login:

https://www.scirra.com/tutorials/525/si ... l-database

I'd suggest searching the tutorial section and the how-to part of this forum and combining all the elements in the way you'd like.

Problem with this solution is that there is a chance the x positions are never completely the same, so working with is between values would get better results.

Adding an event to stop that, would stop that.

Maybe this would work even better:

player.x = enemy.x

set direction to vertical

player.y = enemy.y

set direction to horizontal

That effect and is one of the ones shipped with Construct2.

It's called "inverse"

The information you provide is very limited.

What kind of game are we talking about?

Would the polishing include rewriting parts of the program?

How much time do you think will go into the work?

In what way will you try to earn money with the game?