A Touch of BlitzMax

BlitzMax Forums/BlitzMax Programming/A Touch of BlitzMax

Brucey(Posted 2014) [#1]
Since I'm now looking into the Android port of BlitzMax, the issue of interaction with the device has come up - specifically in this case, how to make Digesteroids "mobile friendly" in regards to not having a keyboard.

SDL has a touch interface, which I'll need to implement, but otherwise, are there any "standards" for interaction for these things? Such as how to gather steering input, etc?


zoqfotpik(Posted 2014) [#2]
It's a problem when any mobile game has too many controls. Look at Defender which is one of my favorite games but is unplayable on mobile because of too many controls. Hands down the best control for an asteroids style game is twin stick, with multi-directional shooting (ie a separate turret) and movement that is not based on facing and thrust (Sinistar style or Geometry Wars.) It might be that old asteroids / spacewar style movement controls are rightly a thing of the past. You have to ask if newtonian physics make an enjoyable game for people just picking it up.

Is there an IOS port for Blitzmax?


Brucey(Posted 2014) [#3]
Is there an IOS port for Blitzmax?

Not yet.
Android costs less to build a working prototype ;-)


Derron(Posted 2014) [#4]
IOS needs subscription for publishing ... for local coding you should be sufficient with xcode ... dont you?


@Input

Many games use a virtual "DPAD" ... so this means a special area to "press/click" and this then translates to "move left/right/...".

What I would do:

- wrap "MouseHit()" for compatibility: MouseHit == JustTouched()
- wrap "MouseDown()" for compatibility: MouseDown == IsTouched()

Of course you could only react to MouseHit(1) - so you will ignore the requested button.

IsTouched(): received touch event and no release event
JustTouched(): received release event (means previously was "touched")

SDL sends out events for this: SDL_TouchFingerEvent

Act similar for MouseX() and MouseY() - but it then just refreshes when someone is touching ... so if you place a cursor image at that position, you will be able to "swipe" the cursor on the screen. ScummVM does it similar on android.

You have 2 options there:
- a touch sets the position
- only moving while touching sets the position
(graphics tablets offer similar options - relative or absolute positioning).


Keyboard-Input of course is not available then - so you just can emulate things (cursor keys). - Either with "virtual dpad" or "4 sides" (left 20 pixels = left, top 20 pixels = top ... and so on). A Dpad is better, as you could code it once and then just copy the code to other samples :p.


bye
Ron


therevills(Posted 2014) [#5]
A lot of Android devices can support multiple touches, I think this would need to be supported.

Using the inbuilt virtual keyboard would be cool and the sensors (accelerometer and gyroscope).


Derron(Posted 2014) [#6]
I just talked about emulating the "personal computer"-input on a smartphone/tablet.

The commands are "generalized" (IsTouched) but of course it could get extended to accept fingers ... so IsTouched(2) only returns true if two fingers touch currently. But you cannot distinguish between them like you could do with mousebuttons. Hmm, so if the device accepts multitouch, you could transfer touch1 to leftbutton, touch2 to rightbutton and touch3 to middlebutton ... and if you do not have multitouch, it behaves like an old apple mouse with only 1 button :p.

Also "If KeyHit(bla)" does not work that well on android, as you wont play a game with the virtual keyboard being active (I mean for "steering/controlling" the player).

Think the "control" is what Brucey wants to know - and this is what I tried to explain (how I would tackle it).


@Gyroscope
You could use this for "left/top/right/..." controls - but as not every device has one, the virtual dpad is the more "stable" variant to show off the BlitzMax-samples on an android device.
Also gyroscopes do not have a "is tilted left/right/..."-flag - the value at which you want it to be "tilted left" is really upon to you - means it is a 3rd party implementation (same for virtual resolution which is really needed on mobile devices).


bye
Ron


zoqfotpik(Posted 2014) [#7]
One idea for input would be to have a sort of pipper, say a green dot with a line drawn back to the ship, and you drag the green dot around. The ship then steers toward the dot. Then a fire button and maybe a hyperspace. You really have to make decisions on the interface to make arcade games playable on tablets but there are a lot of games like robotron so again you could use twin stick and that's super easy to implement.

I am assuming you are asking about touch-feely interface considerations rather than hypertechnical because I can't imagine you having much trouble on the latter. But it's surprisingly difficult to get an interface feeling good on a tablet.


*(Posted 2014) [#8]
Monkey uses the TouchX etc and on mobile MouseX etc returns the first touch I would go that route


Derron(Posted 2014) [#9]
If Brucey talked about the specific implementation for "digesteroids" then I would do it similar to zoqfotpiks idea.

Instead of having to drag a "dot around" you just check if the "touch" is on the left or right half of the space ship (paying attention to the current rotation). As you do not set the rotation per "now" but rotate in ticks (eg 5 degree per "update") this means "touching longer will keep rotating until spaceship looks into the direction of the last touch position".

While you could use "distance" for throttling etc - you could just introduce a "power" area in one of the corners for throttling. But as you need "fire" too, I would misuse the touchtime for throttling.
So a "hit" indicates the target rotation based on the moment of the hit (so while the ship is still moving it will still "target" that hit position). While still touching the screen the ship will speed up. So the other hands one finger is available for "fire".


bye
Ron


LT(Posted 2014) [#10]
Digesteroids really needs some kind of separate d-pad simulation, in my opinion. Anytime my finger gets in the way of an asteroid...

Brucey, since you've mentioned Android, do you have Digesteroids working on an Android (minus the control issues) device? I was also wondering about whether Lua and LuaJIT are functional...


Brucey(Posted 2014) [#11]
do you have Digesteroids working on an Android (minus the control issues) device?

Not yet, but there's no harm in asking in advance :-)
(hopefully an Android device will be arriving this week for testing. Thanks donators!)

Lua (and reflection) works on the Pi - as my bmk requires it. I've no experience with LuaJIT and BlitzMax.


... it may well be that Digesteroids, in its current form, is not suitable for a touch-based interaction, but well, even if it turns out crap to play that will be relatively insignificant in relation to actually having it running on the device at all :-p


zoqfotpik(Posted 2014) [#12]
I think you could go for an analog joystick and fire button. Along with a friction-like velocity cap I would think that would work pretty well.


Derron(Posted 2014) [#13]
Maybe it helps someone ... I just fiddled that together, maybe some of the "event"-stuff could be done differently/easier.


So what it does: it provides a simple "input object" which emits a keypress/keyhit when the mouse is over it and the button is pressed.
For now it just checks for the first button - but could of course check for all available ones .

Then there is a "group" which is there for nice alignment. For now I just coded the simple ones: align horizontally, vertically or - in the case of max 4 inputs - in a "+" form.

After that a simple example can be found - allowing to move a little rectangle using the mouse or the keyboard. The rect only listens to keypresses.

I do not know how "android" reacts to keypresses at all ... I never checked to press "ESC" on my hackers keyboard.


licence is BMK-NG-style (I think that's "libPNG/ZLib")


EDIT: changed licence to "libpng/zlib".

bye
Ron


skidracer(Posted 2014) [#14]
Why Digesteroids?

The simple answer is pick a blitzmax game more suited to the platform.


Derron(Posted 2014) [#15]
I think because it was the "previous" showoff game.


bye
Ron