Touchscreen Controls - Implementation?

Monkey Forums/Monkey Programming/Touchscreen Controls - Implementation?

Amon(Posted 2013) [#1]
Basically for certain games, that would be easy to control via joypad on a PC/Mac, on touchscreen devices like phones what kind of setup do you guys implement?

example... Platform game controlls, Shmup controlls...etc


Paul - Taiphoz(Posted 2013) [#2]
This is a problem I need to face and have given some thought to regarding my Terminal 2 project.

At the moment for full control targets I will be using WASD, JoyPad , for touch devices it gets a bit more complicated.

For me there are three options and each have their issues.

Drag : player taps their ship and drags it around, the ship then auto shoots, or the player taps with a second finger to shoot or bomb.

Keys : create ghost buttons at the sides of the screen tapping left side triggers a left move, right side a right move, etc etc.

Virtual Joystick : small circular vistual joystick input bottom left with fire buttons simulated bottom right.

I personally have not settled on a method yet, keys are out for me I have to many directions and buttons, so for me its going to be either drag or virtual joy, when I work with drag I plan to make the drag point bellow the player ship so the user can see his ship at all times, but this will create a dead point at the bottom of the screen, it also makes it harder to control player speed.

With a virtual joy pad, my issues are more that the player has no physical feedback and its really easy to over move with the finger or thumb which results in the user having the move their thumb back to center, its an annoying side effect and causes the player to lose control for a split second.

Not sure which method I will settle on, but I am leaning toward Drag as it gives perfect control over the player and less risk of the player losing control.

I will code both tho, and test both with my testers, in the end the system they use the most will be the one I go with. I THINK lol....


Grant(Posted 2013) [#3]
Hi Amon,

Personally I wrote a controllers class that lets me place toggle switches, fire buttons, sliders for changing values and analog sticks anywhere on the display. The touch input was a little confusing and weird to get to grips with when I first started with monkey, but like everything else it becomes second nature after a while, I also made my classes work with therevill's autofit module, which was completely painless.

Having the controls visible over portions of the game works, but really aint that desirable, all too often you're obscuring the world your trying to navigate with your thumbs. The solution to that is to define a part of the display where its dedicated for controls, but that shrinks the actual game area, for me touch is all about trade-offs.

Then there's invisible controls, say you were making a platform game like mario and the only controls were left, right and jump. you could make each half of the display a giant button for left and right, and when you touch both at the same time you jump, no overlay for the controls needed! some games do this and it seems a good solution for simple platform games.

Touch input is definitely better suited to puzzle and RTS type games than fast paced action games as you don't get anything in the way of feedback, you don't know if your finger has slipped off a control without looking at the control because there's nothing to feel.

The only real solution is to experiment like a madman to determine what types of controls are best suited to a particular game style. this can be beyond tedious at times, but when you get it right, it can be very rewarding.

Cheers, Grant.


Gerry Quinn(Posted 2013) [#4]
There's also the option to let the player choose, but this has its own issues as they may be confused, undecided, or choose badly.

I lean towards accepting all valid control actions automatically, if that's possible. E.g. if dragging an item is implemented, maybe tap and tap to select and move can work too, or tap and joypad.


ElectricBoogaloo(Posted 2013) [#5]
My framework includes a standard onscreen d-pad and buttons overlay thing, but so far I've yet to actually use it, mostly because I despise onscreen controls so very very much.
Like Grant says, it's better to figure it out per-game, and try your best not to resort to using a great big ugly d-pad.

I'll admit, since switching to Monkey and it's multi-targetting, I've found myself struggling to come up with nice controls schemes that work flawlessly on everything possible!
.. tricky. But you can usually come up with something, if you allow yourself a few concurrent control schemes, like cursors do one thing, mouse/touch does something else.


Paul - Taiphoz(Posted 2013) [#6]
Yeah I agree getting the right control system is hard when its touch, specially for a game or games that are traditionally controlled via a joistick, or joypad.

My plan is to code my three main systems, push it to testers and see what they play more.

I for the same reasons Electric mentioned don't personally like the virtual d-pad, I don't like the idea of obscuring the display, but as touch there will always be downsides.

I will go with what ever my testers prefer to use, I just hope its not the virtual joypad cos I hate it lol, but if that's what they like then I will implement it.