lucid those all sound awesome :) thanks for the reply.

lucid

Can you please add the visible and invisible option. Since Spriter needs a few frames to initialize it would be nice to hide object briefly if needed. plus Sprites have this option, and having to go through all container sprites for a large complex object is overkill to be invisible.

I seems my post was sorta ignored.

caou.org/stickysticky

thsi game was written in HTML5(or 4). It is on the Ouya.

Currently we are waiting for Ludie to finish up with the Ouya compatibility.

In the mean time you can use Phone Gap with Fast Canvas and Ouya Plugin.

So it's doable, but not very simple yet.

ok, So I have come up with a problem in my game where I could use some help on.

I have been tinkering with a particle effect. I need the particle effect spawn generation along a line. However the line can be set to any angle. With C2 using the 0 Right angle facing. I decided to use random.y for the line.

However, upon rotating the particle emitter. The Y is still a pure Y rather than Y angle. This seems to be the intent of the design, but I'm not sure then how to generate the particles along the line :(

The red line shows the Y element of the spawning, however it's the green line desired.

Here is the CAPX

docs.google.com/file/d/0B0V2EvCXNzYUS2FMTXhZQm9MU0U/edit

I'm putting Bubble on hiatus. We had a lot of hope and promise for the project. However my few recent communications have resulted in that my partner is busy, very busy; and likely to only get busier; happy news busy, but busier.

With JoyfulDreamer with DreamSpaceJS and another new developer coming onto the scene wanting to do websockets. I'm going to put Bubble on hiatus. I may still put together a prototype of bubble, but for the time being considered to be sleeping until further news.

I thank every ones interest and I am really saddened that there weren't more to show, but it didn't seem to turn out that way. If my partners schedule changes and the situation picks up where more time can be dedicated I will repost here with an update.

I get this problem a lot, but I don't really care. Nothing that a CTRL+ALT+DELETE won't fix. However I heard that if you clean up the registries; this action will reduce C2 from not closing problem.

I apologize for not looking at the CAPX. However what you want is Spriter Character Mapping. Character Mapping is the PRO version of Spriter, but not yet implemented in the plugin.

I am also now critically requiring the Character Map for the plugin. So I know what your looking for.

Trying to mix and match Spriter animation and non Spriter animation is going to give more of a headache than it's worth.

My suggestion is to nicely request lucid to get the C2 plugin character map going.

NOt that I know of. As it is gamepad have to be explicitly polled for information rather than triggered.

Personally I feel the gamepad should be

On gpad Left

-- if gpad = 0 then do player 1 stuff

as it is now

On gpad 0 Left

-- do player 1 stuff

this is really annoying as it requires duplicating all the controller events. This can be easily done by putting all controller events into a single group say "Player 1".

Then copy/paste Player 1 to new versions. then go through each event and reference controller index 0 to 1, and repeat for every controller :(

alternativly you can do what I did.

Repeat 4 Times

-- Is gpad loopindex Left then Function.Call("Pad.Left", loopindex)

-- Is gpad loopoinex A Then Function.Call("Pad.A", loopindex)

I do a little more than that to handle Press, Release and analog state. but that's the jist of handling X number of controllers with the same code base.

The disadvantage is that the controller is constantly polled every tick rather triggering on an input event :(

This is and always has been an interesting topic. Once with pitfalls. The first myth that must be dispelled is

TCP is slower than UDP. TCP and UDP have the same speed of transfer over the internet. Where the draw back is that TCP has safe guards for lost packets and data fragmentation. This will lead to a bottleneck. Often the bottleneck won't be a problem, but sometimes it can build up and that's where it all goes wrong.

For most real-time games. TCP is fine. It's only in high twitch gaming like Fighters(Street Fighter) and Shooters(Halo, CoD....) where the bottle neck is extremly bad. However RTS games and most other real-time will run fine with TCP.

However the link you show is an excellent source of information that WSS can stream data and then using a frame system reduce that problem subsantially.

However I wrote a shooter in C2 using Photon Websocket. My server on a an Acer netbook located in Vancouver BC Canada, was able to play reliable well with some one from Europe. However, a friend of mine located in Vancouver too. Had an extremly choppy experience.

So distance wasn't the problem. Also my shooter had no latency correction, dead reckoning or any advance stuff. All it implemented was a catchup move to system and worked really well.

Websocket is totally doable. However if you can use UDP you might as well :D

But there are examples of TCP being used for active competitive games like Guild Wars. I won't say TCP is better, but it's certainly usable.

On ANY multitouch event

compare two values(touch.index = 0)

On Touch Start

touch.index = 0

on Touch.End

touch.inde = 0

Is in Touch

touch.index = 0

Is Touching object

touch.index = 0

this shuold always evaluate to the touch object of 0.

This however has one draw back and I don't see away around it.

1. Touch to screen. This is index 0 which we will name A

2. Touch another finger to screen. This is index 1. with say name B

3. Untouch finger A. Finger B now becomes index 0

that as what I can figure the best alternative. There is no simple option to just disable Multi touch in the properties. If you want a true single touch experience and avoid the index shifting in above example. You will need then need to be a little more advance be associating a Touch.index with a Touch.ID. but then your getting into more work.

Yes, but with out the "advice" technical hurdles addressed it comes off that the game is more idealized rather than having a solid plan of development. As it is the project you want needs the areas addressed and a very solid direction than "our vision". You need the path to get there which hasn't been addressed.

Have you addressed the networking?

Have you addressed that the game is standard AA release title which usually has 20+ people being paid. Yet ARK is free developement.

Have you addressed that doing Street Fighter controls on a keyboard sorta sucks.

Is your artist seriously going to draw X moves times FPS for 20 characters? In what time frame? Spriter offeres the benefit of tons of animation opportunity at the fraction of developement time.

These aren't just advice. These are discussion topics on your approach. Which haven't been answered.

I think we all want the project to succeed. A solid robust fighting is what is drawing people into thread, but there is little selling encouragement to really get anyone on board. What do you have, can do, why it will work?

And Skyping questions loses a lot of benefit. the benefit of a forum is that any questions you answer hear are now shared. Where as skyping a simple question means the question is unanswered for anyone else.