The flight game looks like it's done in sprites, then uses sine based path.

as for Fruit Ninja. probably plotted points, then using smoothing techniques.

I can get this on my phone

play.google.com/store/apps/details

My suggestion is simple as that only requires a property box. Which with C2 Plugin system would be easy to implement without any difficulty.

However I think that would be a great addition for some kind of PIN EDITOR especially for CONTAINERS. I would love a CONTAINER EDITOR with PIN as part of CONTAINER BEHAVIOR.

But unless Ahsley is up for a PIN or CONTAINER editor for such things. I think a UID property box in the PIN properties for me would be good.

As we know now. C2 now gives UID to objects added to the game at development time. With this excellent benefit of knowing an objects UID at this time. I believe it would be fantastic that the PIN BEHAVIOUR now have a property in the beahviour property box on the the left side.

Pin to UID.

Here is my example use as to why this would be of a great assistance.

I'm creating a semi dynamic gui for a game. I am using a 9 patch of as the panel due to the ability for it to resize well to the various panels I will need.

These panels for graphical effect slide in and out of the screen as called per required. Doing this obviously requires I pin the objects to the panel. The dynamic changing objects are fine as they are added at run time.

However some of my static buttons that navigate through the UI panels are static and always need pinning. In this case instead of having to create an OnLayout Start to create various SOL, then proceed to pin. It would be very beneficial just to type the UID of the object to PIN to.

Anyways. That's my suggestions. Please consider :)

Nope it does not.

However, I have heard that if the staff increases at Scirra, then they will consider getting some one to do a Mac port. until then though don't hold your breath.

What it means is that your material is under your ownership.

However, the package that you produced is that section 6 talks about. They have the "do so grant, to Ludei, a royalty-free, non-exclusive, worldwide license to use, reproduce, modify, publish, list information regarding, edit, translate, and make derivative works of all such User Content and your name, voice, and/or likeness as contained in your User Content..."

the licence listed is for the purpose of adding a logo which counts for "reproduce, modify, publish, to also list name, likeness...." this is because the outputted version is a derivative product.If you don't agree to the modifications and reproduction, then they can't legally produce the package APK or IOS version.

Check out Sticky Sticky, I'm not sure if it's donein C2, but it is a HTML tech game on the Ouya.

The details is that there are no fantastic HTML wrappers for Ouya. CJS is still a wait to come, but there are a few people who have created some stop gaps in the mean time. They arnt performance great though, but good enough to run.

However, any game starting now would probably be ready for CJS and Ouya by time it's done.

I thought about applying for the same freegamesfund myself. but I need to finish my current Ouya game right now. Which is probably another month or 2(crossing fingers) by time it's done. I hope the funding will still be up. I want to create a scifi Multiplayer dynamic QTE fighting game. :D

I could be wrong, but I believe these portable devices do not change resolutions. Where as a PC can do some hardware switching and handle all the resolution definitions Android and IOS can't. They use a locked resolution and you need to handle the difference between device resolutions by way of software.

Also using a browser to test resolution can give all sorts of inaccurate results. A browser will do what it can to make pages fit if not using browser commands to resize.

I would suggest using CocoonJS to test your resolution as that won't play any resolution tricks on the device.

Are your sprites part of a FAMILY with SOLID?

There should be a reason why your objects are interacting in that way.

anchors for Gui and won't play nice with Physics.

Physics objects should only be playing with other Physics objects and no other behaviours relating to movement or position.

double check your collision boxes

those are the most common problems that crop up when learning C2 and using Physics. Physics in C2 uses a third party api known as Box2d, and Bosx2d isn't integrated with the rest C2 behaviours.

That is really cool. I can see AR being a lot more common for gaming in 20 years. We are seeing phone games becoming standard. So i'm looking forward to seeing AR in the coming days :)

Well I offer good luck. I hope you form your team. I think a good cooperative team is awesome. however, I've been tinkering with Pen and Paper, board game and fluff stuff for years. I really can't bring that to the table and lose out on controlling IP of the material.

Sharing the profits on an IP while in cooperative company work I'm ok with. Holyhell and the team keeping the game, I'm ok with, but lose of creative ownership of a fabricated setting. eh. i'm not ok with. It's not the game ownership that bothers me. it's losing the IP.I just can't lose all control of my IP in other areas(not just the one VG) due to one mini game under the label of another company. :)

however, besides my reservations I offer the best of luck to you finding a team :). There is a lot of people who are looking and I'm sure will fall under the banner.

I also personally don't have a problem with your name :) though someone did have a point. There is a small, but loud group that will take offence.

C2 only draws the objects on the screen. So if you have 30k objects. Only the object son the screen will be drawn. However, you should temper that with the idea that the engine still needs to determine what should be drawn.

Secondly. Never create one large image. This isn't a render issue as a rendered can handle the drawing aspect. What screws up is memory. If the object larger than the draw pipeline then you will get massive performance problem. I head that you should never have an image larger than I think apx 2048x2048.. I could be wrong, maybe it's 1024x1024. Regardless of the exact size. just never make a sprite larger. it will hit the memory draw pipeline limit. This is hardware design based on cost limits of creating graphical processors.