Here are some results from my testing this....

So, I made a quick demo. There are 2 layouts, each with 99 custom movement objects of the same image bounded to the screen by obstacles. Layout 1 has 99 different objects while Layout 2 has 99 instances of the same object.

Draw Calls results:

99 different objects: 5.8% cpu

99 instances of same object: 2% cpu

Now.... when I delete half of the objects on each layout:

50 different objects: 3.8% cpu

50 instances of same object: 2% cpu

So there is quite an overhead for drawing different objects v the same object and a constant and significant minimum overhead on my computer at least for drawing anything on the screen. I didn't have the energy to create different images for each object to see what, if any, that sort of change might make on the draw calls. So, for my laptop at least, although the draw calls demanded 3 x the processing power to draw the different objects, the increase was still only 4% in magnitude - not a problem for most desktop games I am guessing, but such an increase could cause a slow down on a mobile device.

I started with Assembly on my old Commodore 64. That was terribly long winded - as soon as I found out how hard it was to simply make a sprite move across the screen I pretty much gave up!

I think you're a bit confused about Node Webkit - that is a wrapper to create stand alone versions of your game for Windows / OSX / Linux - as an export option it's got nothing to do with android or saving data!

That aside, at the bottom of the Array page in the manual is the AsJSON expression - use that to return the contents of your array as JSON format, which you can then save using webstorage. If you want to load the array from webstorage, load the saved string into the array using the Load expression. Have a search of the tutorials for these features and you'll be able to find some examples of how to do this.

vtrix,

It would be interesting to compare the performance gains / losses between using 1 instance as you say and using dozens of different instances. Without having tried it (yet) I imagine that there's a trade off where the performance gains of one way will eventually out weigh the gains of the other - such that a given layout style and number of sprites will have a range of number of instances that will give an optimum performance. I also am not sure exactly what draw calls are - are they only measured in the debugger profile page or do they also have an impact on collision checking and are indirectly measured in the event analysis?

I have a couple of embryonic games I'm working on - the intention is that I will ultimately release them on mobile and desktop, providing I can keep my focus (!), so I frequently test them both export options. Even for my most visually demanding scenes I don't see the draw calls using that much of the cpu time (up to 20% of the total cpu demand), so I simply don't worry about it yet. I frequently see that events associated with collision checking and sprite control are the most demanding so they get most of my attention...

—, perhaps a little too harsh with the "your second language grammar is not as good as mine" banter.... How do you know he wasn't trying?

Ribis, as answered above - you're much better off keeping your objects and behaviors as separated as you can. It will make your project easier to understand when you look at the event sheets and will make behaviors and instance variables much easier to manage.

STARTECHSTUDIOS & Juryiel - those are both very interesting solutions to the Unity code writing nightmare. I think you've both found me something to tinker with over the next couple of weeks as a means to avoid working on my C2 game, which I'm feeling a bit bogged down by... I tried Playmaker a while ago and, as will all things Unity, that seemed quite complicated but also quite a comprehensive solution to the 'I don't want to learn code' issue. Maybe one of these are what I've been searching for...

Arima / stefanos - gents, that wasn't aimed at you! Arima, I thought your responses were particularly well balanced and reflected my own views, especially page 2 - I don't think I would have been quite so polite or eloquent if I had tried to say the same!

This is my second go at writing this post because the stupid editor logged me out and deleted my text (wft? twice in one day!) .

I re-read the thread and I don't think I can support my assertion that anyone appeared to show a lack of appreciation. Neck - winding in.... Perhaps I suffer from having too much empathy with Ashley because we were all out to criticize his baby and his business decisions.

However, I really do think it's important to talk about C2's shortcomings. Especially those areas where the Scirra website front page assertions differ somewhat from C2's true capabilities. I just hope to avoid being slain by accusations that it's my coding technique that is the only thing between me now and me making a bad piggies android clone...

spongehammer - LOL - couldn't agree more!

This ‘help’ thing will work as long as it doesn't take the form of a winking paperclip....

I had a massive diatribe written earlier but it got deleted by the editor (aarrgghh!!). Here’s the short version of my thoughts, it won’t surprise many….

- I bought C2 because I wanted to make android and iOS games; that’s what it said on the tin…

- Huge disappointment at discovering that mobile export is really an apparently continuous beta program – cocoonjs, phonegap, intel xdk (now agi?), and now crosswalk (no iOS – really? Pity...).

- But C2 editor is light years ahead of the competition. I mean, it is really very good. I can still make games (for browser / node) and the process is pleasurable. I have mostly recovered from the poor mobile performance/export problem because the editor is so good.

I think all of the optimization comments are valid but only to a point. I recall using Corona SDK not even a year ago to make a trial android apk to run on my trusty old Samsung S2 with dozens of physics balls all bouncing around at 60 fps on a complex ground shape while using the accelerometer to 'tilt' gravity – with no collision stuttering (I think it began to slow at well over 100 objects, but that might be my memory selecting a rose tint); that is something that is just not possible using C2 – I would like to be proven wrong and I defy anyone to produce a demo to counter this observation. Code optimization can improve a 'first stab' or beginner event sheet for sure, but the relative slowness of JavaScript when ported to mobiles is, IMO, a fact that I feel is being denied only to quiet those who criticize C2’s mobile performance. This video is a year old but it makes the point about C2’s JavaScript performance when wrapped using (old, admittedly) cocoonjs:

. How awful was that old cocoonjs splash? But at least it didn’t flicker…

I feel kind of sorry for Ashley - unappreciated by some as a one man coding guru and he's probably wearing his fingers out making an awesome browser based game engine. The lack of mobile support made me a little unhappy at first but I've gotten over that now and I recognize that what we get in terms of browser game development massively offsets the mobile limitations. And all of this for one payment - no annual rental plan required!! That doesn’t seem to get much of a mention but it carries a lot of weight for me because at the end of the day I’m still an amateur and my rate of productivity cannot justify an annual subscription.

To upload to iTunes Connect you need to use the XCode Application Loader, whether you compile long-hand in XCode, use PhoneGap or CocoonJS. You could do this via a virtual Mac if you're very patient and know your way around OSX well enough to be able to configure it to your needs. Or (as I did after trying option 1) you could buy a cheap old MacBook Pro on eBay instead....

There is no way to load to iTunes without using the Application Loader, unfortunately - Apple have been very careful to ensure you need to buy one of their products for this purpose. If you do elect to buy one, just make sure you can install XCode 5 - ie you need OSX 10.8 or newer so you can compile for iOS7; there are some hardware limitations with older systems that will prevent you from installing 10.8 (all designed by Apple I cynically suspect to ensure you have to keep upgrading....). I think you can get away with using 10.7 and XCode 4.6 with cocoonjs compiled projects, but I wouldn't bet a couple of hundred dollars on it - get the newest system you can afford.

Do you have 'use mouse input' in the touch object set to yes? That can sometimes return 2 separate triggers in my experience...

I agree - one button to post a game-advertising screen shot is WAY better than just posting a bit of text or even asking the player if they wouldn't mind taking a screen shot, cropping it and then uploading it themselves....