I don't know about you guys, but I like to be lazy. Instead of distance checks. I like to use invisible sprites(visible with low opacity for testing) that are pinned to the object(also with the new container object).

That way you can create your collision polygon either by setting the collision points or creating an image shape to match your above example.

Looks like it has a lot of promise. After doing some research on it. I'm hoping that others take up the design of skipping the webuiview and just do something similar to this.

As it is Ash has a good point. Mac is out of my reach, but I admit I might pick up a cheap used one if required.

You need to use the Touch id system and not Nth Touch :\ Nth Touch in the manual represents the NUMBER of fingers touching. So the Red puck will only work when the second finger is on the screen.

To get a touchid

--start of touch--

onTouch(any puck)

puck variable touchid = touch.touchid

--move puck--

puck var touchid > -1(keep in mind that touchid starts at 0)

-> puck.xy = touch.XAtforID(puck.touchid)

--release puck--

on any touch end

check for which touch was release and then find the puck

you got the rest.

For any multi touch control. You must use touchid references. Nth Touch is nearly worthless unless you are literally making a game about the sequence order of number of fingers actively on the screen.

sorry

"@mattcoles

Any luck with that phonegap controller plugin? I just don't want to re-invent the wheel if you already made one."

I had originally thought you were doing the plugin until I read your comment. However, glad to hear there is progress.

I admit to the frustration at the phonegap, appmobi and ludie websites where there is no discussion about the Ouya or the upcoming gamestick too. There almost seems to be no interest. :(

there is more discussion about these devices here in the C2 forums than on the forums that actually do the hardware support :(

mattcoles, so hos is the plugin going?

One of the reasons people end up linking to begginer tutorials is because they often teach "how to use and UNDERSTAND the engine"

As an example there is behaviour called flash. This behaviour will get your sprite flashing.

Unity is not a standards compliant web browser, so even if it supports Javascript we would likely have to rewrite various parts of the engine for it to work.

This was my largest concern. As I'm sure C2 makes many canvas references where as a Unity export would require large amounts of api references instead.

I think with node-webkit in the next release there shouldn't be any need to use another engine anyway.

While i'm sure node-webkit is good or great. As I understand node-webkit from the website it's a desktop only solution. As it seems now performance on desktop is fantastic and it's going to get better as time goes on. As power increases and browsers improve, and as OS start increasing native-web app support(like Win8). it would strike me that packaging for for desktop isn't a long term productive future endeavour, but instead a current place holder for convenience and steam like support of distribution.

My suggestions and of course I understand the limitations. Was that Unity wasn't limited to the desktop environment. Right now that the desktop is starting to see a decline in average consumer purchases. This was replaced by the laptop and netbook market. It's now seeing a strong shift towards the tablet. While I believe that it's going a decade for this shift to become dominant factor for the average user to PC to mobile. It does eventually leave desktop support in a minority. However, I mention that I think C2 will have a very productive life in the direction it's going.

I guess part of the frustrations is the glacial pace that development of HTMl5 technology for mobile devices have hit in the last few years. For a while it seemed like there were great strides being made, but now not so much. Actually it seems like I can find comments from 2011 wondering when WebGL for mobile will be supported. Checking with current today's support(http://caniuse.com/webgl) it doesn't seem like it's coming all that soon or in anykind of realistic time. For groups trying to achieve native performance for mobile(CocoonJS, Phonegap, appmobi) it seems that they are strangely quite bursts.

Finally I'm dropping it from there as I do believe the technological limitations of the design structure between C2 and Unity would have been substantially large. However I thought to make the suggestion anyways as I only suspected the design differences rather than knowing the details.

suggestion dropped :D

With the talk of Awesimoum and nodewebkit going around. I had the thought of why not instead use Unity.

Why Unity. It takes JS as a scripting language. It runs on everything. Desktops, IOS, Android, Browsers AND Consoles.

Why Unity, it runs JS as script for it's own full on engine. This means that it doesn't require WebView. This means full acceleration on on the GPU. So all those WebGL effects work across all platforms.

Why not Unity, C2 currently supports platform exporting(CocoonJS, Phonegap, HTMl, CHrome Webstore.....). And these most likely are only tweaks to the current C2 runtime. My concern with this idea is that that a Unity Exporter may require massive changes.

Why Unity. There are great benefits to using Unity, two vs one. However the conversion from runtime to compatible unity script is a lot. I only present it as an idea. But I think it's a pretty good one. just may not be a capable one with C2 as it is.

However, it might be something to think about for C3? which I don't imagine is anytime soon.

array's only take number and words. however the word is enought. keep in mind that the word can match a file name.

stewarray(name of sound file references inside)

insult1

smarmycomment

funnysound

on sprite clicked -> playaudio(floor(random(0,3))

Are you thinking something top down like a train track? or a left and right?

Either way the Bullet behaviour is a awesome for straigt forward limited movement. I have a top down shooter where I ended up using bullet for movement instead of 8way. The reason being was that i am planning to use a analog stick.

BULLET is awesome. Just have it that at the junction, use a collision/ocerlapping to change the direction of the bullet object.

if you do a picture or share a sample of your idea we can help a lot more :)

Nice, simple, sorta fun :) looks good

Though as I was reaching 20k in points I notied a slow down. I also noticed that I could put my finger else where with minimum point loss.

You might want to increase the penalty for not touching the screen.

Yeah. I hope to hear about this information soon. Looks like i'm going to beworking on a simple DLC project soon. And the AJAX would make life much easier than using socket.io :|