Watching this thread from page 1 to 30 I concluded that Scirra should make an official "tutorial + capx + Android PlayStore published-proof-game showing the "best way" to export and publish a game that platform. (The rest of the many other platforms for another day).

For example using their "Space Blaster" game as the game to export. But optimized for moviles, giving info about important optimizations to target that platform (Android).

Then you have the same game, one made for desktop and one modified with any optimization needed for you to compare and learn.

This example should be able to be downloaded from the PlayStore so we can see that "It can be done" right there in our moviles.

We can then test performance and reliability knowing that every step in the process, from making the game, to the exporting was made as it should.

If all this is made by Scirra it will give confidence to viewers and customers, much more if the same is made by any other user (I know there's already exporting tutorials made by users).

I'm not discouraging user-made tutorials about exports, just saying that and official tutorial will do a lot to proof that it can be done and at the same time mitigate any "you made it wrong" criticisms. Then if you try and fail for whatever reason, you have a reliable source to check the process. And you know that the export isn't just plain broken.

This should be done with all wrappers/exporters to all supported platforms but, at least, one platform should be tackle.

I read the entire post, found valid points for detractors and defenders of Scirra course. While both sides can be right at the same time I saw that there's already games made with Construct 2 published at Steam, Android PlayStore and Windows phone.

So I can't believe that exports can't be done. At lest to Android phones and desktop with good enough quality and performance. At the same time some rough edges are undenaiable but, at least to me and seeing games released, are not a brick wall or a reason to say: "It can't be done".

Testing games released on Android (made with C2) i found that they not only worked fine but also worked fast.

I tried games made by — like "Firewall: Puzzle Shooter" and "Ninja Legacy Lite" in a Samsung S3, a Samsumg Galaxy Y Young and an Android tablet "MD7096" wich is so patetic that can only be released in Argentina (cof.. cof..). Anyway, in those devices, witch only one can be considered fast, all games worked well and fast.

I showed those to my girlfriend who found nothing to complaint, about speed or suspicious behaviour. She knows nothing about Construct or what the hell i'm doing throwing boxes against circles in a strage program.

I didn't test the Steam games yet but shouldn't be any major problems on this platform.

Conclusion:

A good tutorial about the process of exporting and publishing to Android (at least) made by Scirra itself, using a well made, no-complaints-sensitive example like Space Blaster as the test subject and this test game downloadable from the Playstore should proof enough, should mitigate fears and will serve as an example to follow and compare.

Firewall: Puzzle Shooter performed too well in all mentioned crappy hardware mentioned (poor S3) to just say: "We cannot export and publish to Android" and grin about it.

There's some nasty problems yes. But there's more than just an elusive future that doesn't deliver. I belive that with a good example many fears will dissipate, many known problems will be obvious enough to be carefull until are solved and also many games will find their way to the PlayStore too. Some people made it. You can too.

Any other not mentioned platform/brand/store will be discused another day.

Hopefully this can help both sides or at least ease fears... and hopes.

That's mostly my concern about that metod. But maybe C2 keeps 1 instance of each object type (with all it's animation) on memory even if there's no instance spawned at run time. Then it would be the same having everything in one object or divided in different object types.

I like having single-frame static object as one object (trees, rocks, walls, etc). But once i have more complex, dynamic objects i don't know if the burden of referencing each on one object has some real advantage.

In the same way, i don't know witch method is better on memory and loading times. Then there's differences in how this appears to work if you use, for example, CocoojJS.

I'm a little in the dark about this and is central once a project start to grow in assets and objects.

Someone else know more?

Below you will see Kyatric's example using one object type "monster" containing every monster type. So it uses "way 2". With an array and clever use of instance control he can spawn many monsters instances, each different in a random fashion.

Kyatric's Example "myMiniRPG"

https://www.dropbox.com/s/zmfsdpgh926nmu8/myMiniRPG.capx

Now, with this example in mind, if i add all animations for all the monsters to this single object. It won't kill performance more than using different object types within a family and then reference each instance with an array or whatever method for each of them?

What did you people found in your test? One big object or many to spawn different kind of enemies? (just to keep with the example above)

Hello All!

I have a long inching doubt about certain way to deal with objects.

Basicly there's two views and ways to deal with multiple objects of similar type:

1) you make a "goblin" object, another "panthom" object, "your char" object and "companion char" object. Then you use instance variables, families, containers and each object deals with it's own animations.

2) you make one "enemy" object wich contains all the different animations for all your enemies and then you spawn instances of this object with a starting animation frame related to the enemy you want.

Road 1 feels easier but you end up having many object types too similar and i heard that, for some reason, having many object types even if they are not active as instance slow down the game.

Road 2 feels better to avoid objects population, a little more counter intuitive in a graphical environment like c2 is buut this is the thing:

How much can hit an instance (and many instance) of this kind of object vs instance of individual object types? I feel like having 50 enemies in one object type will kill fps.

But i see this approach being used by many developers and i want to know how well it went against using multiple object types.

I will try to make a version of one protoype in method 2, using arrays like Kyatric did in one of his examples. But if you can tell me how it was for you it would help me a lot.

Thanks people!

oh oh oh... That's what i liked to hear :D

I was almost sure that a text object whould be treated in similar ways like a normal sprite. Good to know that the "more easy way" for me is also the right way.

Thanks to clarify this! Time to go back to the board :D

Hello all! I have a quick one this time..

I always add a text object as a debug panel to show FPS, number of objects, index number, etc. somewhere in my layout.

I tried using one single text object with many concatenated "&" and "newlines" to show all the info in this single text object witch, of course, becomes pretty big.

It also start to be a pain in the **** editing this big text object.

In other project i used many text objects each for every data i need. Then i put them one below the other. But this feels like a waste of resources. While the big single text object also feels like a rendering bottleneck.

Wich approach is better in terms of performance? As a reference i need more than 12 variables showing in this "debug panel". Some updates at every tick but are the less.

For now i stick with the big single text object. But this doubt buggers me from day one (let me exaggerate...)

Thanks in advance for any clarification about this.

John aka Hillstrom

You probably found it already but this topic seeks the same mechanic (if i'm not wrong). there's some capx there:

http://www.scirra.com/forum/collisions-with-multiple-objects-same-spot_topic71607.html

By the way i'm interested in this kind of mechanics, that's way i'm messing around.

Sorry to steal a topic but since there's an answer from just yerteday i better do it now:

My question in relation to this topic is:

In this kind of games where a lot of tiny sprites attacks in a fixed, predictable fashion as a whole. If i see this game i still imagine each group of tiny chars as one invisible object of the side of the entire group. And the little sprites are just a single sprite with animations that give the ilusion of being multiple different objects/sprites.

It's a good technique? It's the one used in this game or i'm talking nonsenses?

For example, Kingdom rush doesn't seems to use groups as Ninja Town do. Where each sprite/char can separate and be used individually.

Works like a charm! Now i can throw physical objects agains non-physical objects (and viceversa) and works almost perfectly to the naked eye!

Thanks you very much R0J0hound ! You make my friday!

In you capx I see the same code you posted in your first capx.

I'm installing Dropbox in this machine since my other blowed up on me.

What i mean is that in X an Y expresions of "Set angle toward" you could put:

X: lerp(Self.X, Touch.X, dt*0.5)

Y: lerp(Self.y, Touch.y, dt*0.5)

Play with dt until you have something less jumpy.

Also you can use this to stop the object at the touch position (your finger or the mouse's cursor):

(As a subevent of "Is in touch")

   System|>Compare two values|>distance(Player.X, Player.Y, Touch.X, Touch.Y)<=10 = Set Bullet speed to 0

Play with that 10 to match your desired offset. It helped me overcome shakiness when the player reach the destination point.

About the sprite trespassing your walls. I don't see it happening in my example.

My only difference is that my wall objects have always the same or more width. And i have "Pixel Rounding" on. But i doubt this cause issues on collisions.

Oh nice to see you R0J0hound helping me here! I'm still playing with your latest formulas for the same project :D

Damn, seeing your methods i feel dumb or you blow my mind..

Now is dumb time.

I will check this stuff once i leave my office.

Thank R0J0hound!

If you change the Speed Event to the Angle Event your sprite will move better.

Something like this:

Is In Touch=>|Set Speed to=> <<Something>>

                      |PlayerObj=>Set angle toward X= round(lerp(self.X, Target.X, 2))                                       

                                                                     Y= round(lerp(self.Y, Target.Y, 2))

You can add dt to the thir value as you did.

If you add Solid behavior to your moving Object and add Solid to the collison object for the walls it should collide.

(As long as you enable Bounce off solid on the bullet properties of course.)

This movement works for me.

And, by the way, if you find a better movement method tell me :D