Wow that sounds so promising! I'm now concentrating on Android, but I would love to expand my knowledge and hopefully test one in facebook in the very near future. I've added you on Facebook.

> What keeps me away from using Cocoon.io is the lack of a loading screen, immediately after their splash screen. A completely black screen for several seconds gives the user the impression that the game has crashed and in my opinion it looks really bad. Until this get solved I will continue to use the IntelXDK path.

>

yes the delay with the black screen same here too

That's weird, I tested a few of my games and I don't have that issue at all. It immediately goes to my splashscreen right after cocoon's. My game files and memory usage are all quite small, so could it be because of that?

I don't think C2 will recommend CocoonIO as their default export option for one single reason, it's free version is limited. I think we can all imagine the headache of having to explain in their C2 sales pitch about it.

You will need to read the manual on these as they are very important to making any games. For your case, if you are running the actions right after the trigger, you won't need to use UID. For example, enemy on collision with bullet, any events directly under that event will be run only for that enemy because it knows which enemy you want effected. But if you put the actions on another event that has no way of selecting he enemy sprites, it will select every single one of them.

Anyway, CocoonIO is limited to only 2 free apps so you'd have to pay $14.90/month to get at least 10 projects on it, but I'm not sure if you can just erase old projects after you've exported them to .apk then upload new ones.

Yup, that's the weird thing about it, you can do exactly that. I tested many of my previous built games to get an idea of the performance. I have yet to see any restrictions or limitations on that part. I guess the only issue might be convenience, where we can just upload a new zip file and have all our settings saved, but honestly that is something we can set in about 1 minute, so I think it should be an issue.

If you want to select an object that have many instances, you need to select it by UID or perform the action directly under the trigger that has the selection events (for example on collision and such). If not, every instances that fulfills the conditions in the events will be selected.

That the most effective method that I can think of is using arrays. Save the values for each weapon in an array slot, than when a new weapon is created, check to see if the slot for that weapon is empty, if not, load the value in it to the local variable.

I'm afraid local variables will always be reset. The next easiest way would be to use global variables since they won't reset. A more organized but tedious method would be to use arrays.

Usually if you set it under the same event as the collision check, it should work properly. However, if you want to set it on a different event, you can use UIDs.

For example, create a variable called EnemyUID. When on collision and you are running your other events, set EnemyUID to enemies. UID. Than when you want to show the damage, "select enemies family by UID" than use the variable EnemyUID to select the correct enemy.

After looking at the capx, I know what the issue is. You are setting the slider.y to touch.y. But they are on different parallaxes. The slider is on 0 parallax, but the touch works on the entire layout which is using 100 parallax. That is why when your sub goes down, your slider wants to go down too, because touch.y is actually much lower than the limit you imposed on it, but because of the limit, it won't go lower than the slidermarker.

Fortunately, the solution is easy enough. All you have to do is instead of "set Y to Touch.Y", set it to "set Y to Touch.Y ("UI")" This will tell C2 that you want the touch value that is based on the UI layout.

Hi can you please share a capx, that way I can test it out and try to find a solution for you.

Unfortunately Crosswalk is quite large in size. However, it will add roughly 10MB or something around that range. So that would mean your game assets alone are roughly 40MB. You might want to try reducing the size of your game, you can reduce it substantially if you manually compress our images used in the game.

frcol, thank you. It's one of the most satisfying feeling to hear that your children enjoyed playing it!