Universal Controller

I gave the arcade a trial on my iPad2 but alas all games are not iPad friendly. Some run fine but without a controller all of them are useless on the iPad.

I'm sure this is true for other mobiles, tablets, etc.

I was thinking about this question: Is it possible to add a universal controller to all games? This can be done (If possible) on the arcade side to cover all games.

All is needed is a left/right/up/down and space/ctrl key simulation.

The problem with this question is that the answer can be one of these two totally different directions:

• Are you crazy? This will take 5 years to accomplish
• Cool idea. We'll just add this plug-in to the arcade and all games will enjoy this controller simulation

I have the feeling the answer is the first option but just in case it's the other one I decided to raise this question.

Tbh, the first thing that comes to my mind is about : "All is needed is a left/right/up/down and space/ctrl key simulation.".

I'm afraid this is not true.

I mean, it really depends on the game. A simple game with two actions, sure this will be enough, but on a game using more keys, or using only the mouse plugin (instead of/not having a touch with "use mouse input: yes") I'm afraid your idea isn't as effective in those cases.

I'm maybe missing some big picture there, but it seems to me that it should be the game's author responsability to make its game accessible to mobile devices, not an "after-thought" patch.

Also I don't know if, technicaly, a plugin could cover all cases.

Everyone really needs to support touch controls in their games. It's not so much our fault as most game developers work on a keyboard and mouse and don't add touch controls. It's a shame because they lose out: loads of people browse the web on touchscreen devices so they're making their games unplayable for a lot of people. Do you think there's something we can do to encourage more people to add touch controls? It's mentioned in the manual (but who reads that? ;))

Also I think Tom was going to add a special category for touch-enabled games.

i have read the manual 1time :D

Also I think Tom was going to add a special category for touch-enabled games.

Good idea.

Do you think there's something we can do to encourage more people to add touch controls? Also I think Tom was going to add a special category for touch-enabled games.

A separated category is a good start.

I think the best solution would be to show little icons which will "tell" things about the game. If it's iPad friendly it will show an icon. If it's not the icon will show the icon in gray with a strike over it. The same goes for Android, etc, etc.

As for my proposal, I guess I didn't explain well.

In the past I saw online forms with a little keyboard icon. People who didn't have keyboard in the language they needed simply pressed this icon which popped up a virtual keyboard in JavaScript.

My idea is in that direction. I was sure that since we're talking about an interpreter it would be easy to add 1 layer of a keyboard/mini-controller to arcade games. I guess it was a crazy idea.

As for the "how to encourage" question, that's a good question. In the long run games which are accessible to more machines will float to the top. In the short run it's important, as I see it, to add "Does your game support touch screens?" question to the arcade upload procedure.

The uploaded can also check check-boxes for different machines. This alone will make them think "Hey, my game only supports PC and Mac and not the iPad, Android, etc, etc."

A special badge would also help (Something like "The Touchy Badge" :)

Also, I don't understand why there're two objects - Mouse and Touch. If the touch can simulate the mouse why not unite these two into one object. This will allow mouse events as well as Touch events. The creator will have to know what's the difference between these two but it will cover 99% of cases without duplicated code.

Because the touch object doesn't emulate the mouse to 100%.

Mouse still has more buttons, and can have the "cursor over" object condition, where touch can only "on touched/is touching", but not "over".

It's still two different inputs, but the common basics have been added/supported in the touch plugin.

Kyatric, The Touch in its mouse-simulation can have the "cursor over" event/condition. In the tablet it won't return anything but in a mouse oriented environment it will return the mouse correct information.

I know these two are different entities but I offered to combine them completely into one entity. This can be done!

If this will be created it will eliminate code duplicated (Since there's a shortage of "OR"), it will make life easier for creators and it makes sense which I like.

The finger on touch-oriented machines is almost equal to a mouse pointer on mouse oriented machines. To me it makes no sense to separate the two. 1 Touch/Mouse entity with attributes which are unique to touch machines and attributes which are unique to mouse machines is the right path to take.

Again, this is how I see this issue.

The Touch in its mouse-simulation can have the "cursor over" event/condition.

HotGod: Could you give an example ?

I've messed with the touch plugin, but having no touch device to test, I relied on pure "it should logicaly work like this".

And I really can't see how you can have a cursor over an object without using the "on touched/is touching" conditions (which in my sense, are not the same as a "cursor over" conditions)

If you have some tip on this, I'm willing to take it.

Also it may be tricky to emulate a multi-touch with the mouse.

Kyatric, :) I guess it's another case of my language barriers. I didn't say this situation can be achieved now. I tried to say it should be that way.

Just imagine the current "touch" object with additional mouse related events/vars.

If I create a game today with the touch object I can convert it to the mouse in no time - simply check the "simulate cursor". This, to me, should be expanded till there's no separation between mouse and touch objects. Just 1 expended object - Touse or Mouch, which will cover all events/vars.

I totally agree about the multi-touch. This is a special case and as far as I recall the touch object itself doesn't deal with that. The behavior "Drag and Drop" does this well but the touch, AFAK, doesn't deal with "Touch[2]" for example.

As I see it, people will keep creating games in the mouse environment while testing them on touch environment. In such operation it's best to develop on the "touch" object and check the mouse simulation. If the touch object will be expanded it will cover both mouse and touch games.

I don't think we can make a touch-keyboard because it would probably have to be different for every game. It's also a difficult technical challenge to make it so I would simply prefer game developers properly supported touch controls, which is a more natural way to control games than a virtual keyboard.

As Kyatric notes, Mouse and Touch are two very different forms of input, both in terms of what they can do, and in accuracy. So it is much better for game developers to treat each separately. Also people tend to make games dependent on features like "Mouse is over object" which will never fire in the touch version of the game, and it's all too easy to miss that if you design your game on a desktop. Using a separate touch object forces you to design your game to the capabilities of the input method.

FYI you can switch on 'Use mouse input' for the Touch object and clicks will count as single touch input. This is great for testing simple games, but obviously a mouse cannot simulate multi-touch. The Touch object does also fully support multi-touch, the only gotcha is the Touch.X and Touch.Y expressions only return a single value, but usually you don't need them. Basically, there's no shortcut to having a real touchscreen device, using the Touch object, and using Preview-on-LAN to get your touch input working really nice... but not everyone has a touchscreen and wifi, which is probably the main reason lots of games don't support touch.

When I got my iPad2 I went over many C2 creations I did in the past and tried to convert them to be iPad friendly.

Since there's no "OR" operation built into C2 I simply found myself copying big chunks of code and replacing the conditions to the touch object instead of the mouse.

If there was an "OR" I would have simply added the touch checking side by side with the mouse checking. This would have take 1/100 of the time.

Maybe once the "OR" is introduced people will see that it takes them about 20 seconds to make their game a touch-friendly without making their event sheet look like spaghetti.

Is there a chance we'll see the "OR" in the future?

I am missing the OR too

OR, like many many things, has been on the todo list for ages. We'll get round to it eventually.

Looking forward to the "OR" operation myself.

Also is there a way to emulate a touch device on a Windows computer? Since I do not own a tablet at the moment. Thanks.