single-button ranged combat and movement

[twp...@gmail.com]

I have a game that involves lots of ranged combat (shooting). I'm looking for ideas on good ways to do this, but using only 1 mouse button.

The game is an HTML5 game and I have a decent flow for keyboard and standard browser-mouse interfaces.

However, since the game is in HTML5, it is (mostly) easy to play on a mobile device. The trick on a mobile device is that you basically just have one mouse button (finger touch). I know iOS devices get a little more complicated with their touch gestures but I'd rather not bank on anything existing other than 'touch to click'.

So, assuming the player is also using 'touch to click' to move, how do I differentiate between the two? I'm assuming someone else smarter than me must've tackled this problem already. :)

Problems I run into are:
1) how do I know a person is clicking on a monster in order to
(a) shoot it vs.
(b) move in that direction vs.
(c) melee attack it (if adjacent -- note you can also shoot it at point blank)

2) when clicking on a particular monster, it is easy to 'slip' and hit the grid next to it, thus moving you TOWARDS it instead of shooting (these seem like quite opposite tactical outcomes, and therefore bad!)

3) using a 'click behind' method for melee overcomes some problems but is not intuitive, (or is it?) -- in this method clicking on a monster ALWAYS shoots at it, but if you click on a square and your travel path would take you directly into a monster, it is a melee (thus requiring you to click 'behind' it)

Thoughts? Anyone seen this done before in an elegant way? Thanks!!

- HF

[paul-d...@sbcglobal.net]

twp...@gmail.com writes:

> However, since the game is in HTML5, it is (mostly) easy to play on a
> mobile device. The trick on a mobile device is that you basically just
> have one mouse button (finger touch). I know iOS devices get a little
> more complicated with their touch gestures but I'd rather not bank on
> anything existing other than 'touch to click'.

I don't know HTML5 programming, but could you rely on long presses as
well (just a thought, somehow they seem more likely to be usable than
pinches and swipes and whatnot)?

> 2) when clicking on a particular monster, it is easy to 'slip' and hit
> the grid next to it, thus moving you TOWARDS it instead of shooting
> (these seem like quite opposite tactical outcomes, and therefore bad!)

That's a reason I don't like click to move systems. I've been playing
some roguelike ports on my phone, and the most usable systems I've seen
are those which either provide an onscreen d-pad or divide the screen up
into click regions so that the whole screen acts as a big d-pad.

I think as a phone user I would like it best if taps were just used to
select targets and there was an on-screen button to shoot, and if
movement was accomplished with some kind of d-pad, or with hot screen
edges to take steps (since tapping anywhere on the screen is out)
(e.g. you would tap by the left of the screen to step left). You could
walk to melee as usual (not that I wouldn't like to see alternatives to
bump-to-attack, which seems a little tired).

I don't like trying to hit the right tiny tile with my finger on my
phone, and I don't like trying to hit a tiny monster without any retries
either. That's why I think it would be better to tap only to target and
have a fire button. The game would be less frustrating if missing your
target did nothing or highlighted the wrong target, instead of taking a
step or misusing your turn.

[twp...@gmail.com]

Hey Paul...

Yeah, that is what I don't like either: trying to hit a monster with my finger on my phone. Well, I don't mind TRYING to hit it, but I don't like the unintended consequences if I fail. So, maybe your idea of a 'confirm shoot' button would work.

Example: tap a monster, a larger pop-up appears next to it. Tap that pop-up to confirm and shoot. That would be obnoxious for 'regular' non-mobile players, but it is easy enough to have an 'enable mobile' option, or (even better) assume a user is on a mobile device based on their user agent (or however other 'real' websites do it!).

As for walking, I am torn. Taping the screen to move in a direction makes 8-directional movement really hard. It's tough to split a screen into large enough "octants" that you ALWAYS are sure of which direction you are telling the game to go. I think Keith Burgun touched upon this in one of his latest AURO updates (he decided hexes with 6 "hextants" was a good compromise).

However, I like having 8-directional movement. On-screen d-pad would be more explicit but I think one with 8 directions might take up too much real-estate. (obviously phones with keyboards like the motorola droid can avoid a lot of these issues if that want)

That's why currently tapping on the screen does a decent quasi-A* path follow towards that point. How do others feel about this?

[paul-d...@sbcglobal.net]

twp...@gmail.com writes:

> Hey Paul...
>
> Yeah, that is what I don't like either: trying to hit a monster with
> my finger on my phone. Well, I don't mind TRYING to hit it, but I
> don't like the unintended consequences if I fail. So, maybe your idea
> of a 'confirm shoot' button would work.
>
> Example: tap a monster, a larger pop-up appears next to it. Tap that
> pop-up to confirm and shoot. That would be obnoxious for 'regular'
> non-mobile players, but it is easy enough to have an 'enable mobile'
> option, or (even better) assume a user is on a mobile device based on
> their user agent (or however other 'real' websites do it!).

Hmm, to me it seems like that would block the view and be bad for motor
memory. I was picturing a "shoot" button at the bottom of the screen
that would shoot at whatever target was marked (there would always be a
target marked if any targets were in sight), and you could tap targets
to change it.

> As for walking, I am torn. Taping the screen to move in a direction
> makes 8-directional movement really hard. It's tough to split a screen
> into large enough "octants" that you ALWAYS are sure of which
> direction you are telling the game to go. I think Keith Burgun touched
> upon this in one of his latest AURO updates (he decided hexes with 6
> "hextants" was a good compromise).

Hex is awesome, I agree. I don't find 8-direction movement too bad
though; I rarely tap in the wrong area (although in Hydra Slayer I
frequently hit the message area or monster list by mistake). I think if
you were to use edge taps only for movement it would be pretty much
impossible to miss. The reason for edge taps is that screen taps would
be for targeting, and you wouldn't want to accidentally step if you
missed your target. I haven't used an edge-tap only system, but it seems
like it would be nice. You'd want to mark the tap zones clearly and have
visual feedback when you tap them. A lot of games skip this and it makes
it hard to tell what you're doing.

> However, I like having 8-directional movement. On-screen d-pad would
> be more explicit but I think one with 8 directions might take up too
> much real-estate. (obviously phones with keyboards like the motorola
> droid can avoid a lot of these issues if that want)

A d-pad needn't take up more real-estate than a few of the on-screen
keyboard's keys, and the ability to control the game without blocking
your view with your own thumbs would be nice. However my phone has a big
screen and I could see it being much nicer to do without on other
phones. Maybe if you could toggle it.

[twp...@gmail.com]

Good points!

Yeah, about half way through the day yesterday I realized my idea with 'click to confirm' wouldn't work, because what I am trying to stop is FALSE clicks.. so if you mashed a finger next to a bad guy instead of ON the bad guy, you'd still walk towards him. The confirm button would have to pop up any time you touched near an enemy, which... sounds a bit obtrusive to me.

Edge-tapping could work I suppose. I guess the screen is big enough to differentiate between 8 directions around the edge.

An on-screen shoot button sounds like it is a necessity. I actually have code that constantly tracks the closest/selected target for keyboard controls. So a lot of the time it'd only be 1 click. Another button to cycle, or maybe get fancy and swipe-to-cycle if the browser supports it.


The only other idea I had in the 'screen taps only' vein was to swipe OVER an enemy to shoot. In my experience even in mobile browsers, you can pick up the difference between a mouse 'click' and a mouse down/drag in the event code.

[Gerry Quinn]

In article <b21a0cd2-2152-4694...@googlegroups.com>,
twp...@gmail.com says...

> Problems I run into are:
> 1) how do I know a person is clicking on a monster in order to
> (a) shoot it vs.
> (b) move in that direction vs.
> (c) melee attack it (if adjacent -- note you can also shoot it at point blank)

What about setting player mode (click on one of three buttons to change
mode) so that a tap means one of:
1. melee the monster nearest the tap (moving first if necessary)
2. shoot the monster nearest the tap (moving first if necessary)
3. move to the place that was tapped

If you are in full-on barbarian mode you might just stay in state 1
nearly all the time, whereas an archer might tap a few times in 2 to
shoot, then switch to 3 and scoot.

(Been thinking about this myself a bit lately.)

- Gerry Quinn

[Jason Pickering]

Could you do Tapping to move and attack but a tap and drag to shoot. Like tap on the player and drag to the monster on release fire.

Also I am making a touch screen iOS that requires specific tile taps to play. one suggestion I can give is make the game very large. My total screen size is like only 10 wide. if the tiles are big enough tapping does not become a problem.

[twp...@gmail.com]

> 1. melee the monster nearest the tap (moving first if necessary)
> 2. shoot the monster nearest the tap (moving first if necessary)
> 3. move to the place that was tapped
>
> If you are in full-on barbarian mode you might just stay in state 1
> nearly all the time, whereas an archer might tap a few times in 2 to
> shoot, then switch to 3 and scoot.

Interesting! I have something similar now in that left-click will move, but shoot if its on a bad guy. Right-click will always move (or melee-bump) no matter what. This is kind of hard to grasp intuitively though. Also doesn't help for touch interfaces since there is no concept of 'right click'.

So your idea may work.. especially since switching between modes was done with something intuitive like a swipe or drag. Or an on-screen button even though I was trying to stay away from those! ;)

[twp...@gmail.com]

On Tuesday, May 22, 2012 9:58:20 PM UTC-4, Jason Pickering wrote:
> Could you do Tapping to move and attack but a tap and drag to shoot. Like tap on the player and drag to the monster on release fire.
>
> Also I am making a touch screen iOS that requires specific tile taps to play. one suggestion I can give is make the game very large. My total screen size is like only 10 wide. if the tiles are big enough tapping does not become a problem.

Yeah, big tiles make things a lot easier. The problem I run into is that the game (up until now at least) has primarily been a browser game, and having a tiny game-space on a giant web browser screen seems wasteful. Especially since my graphics are ASCII tiles and nothing amazing to look at.

The more I think about it the more I like drag to shoot. Maybe you don't need to drag all the way from the player to the bad guy, but at least drag somewhere 'near' the bad guy. (draw a line through him with your finger)

Changing targets would still need an intuitive interface though. (maybe drag the other way, or is that too obscure?)

[twp...@gmail.com]

I came up with a somewhat-obvious solution that SEEMS to minimize the number of buttons and probability of 'fat fingers' errors on screen-taps.

Instead of actively picking a target to shoot at, the game will passively track a 'current target' for you. By default, this is simply the closest enemy to you. The only extra rule: an enemy that you just shot at will automatically jump to the top of the list (if they are still in range).

I handle this on-screen by showing a targeting reticle on the current target.

Now I only need 2 buttons:
1) cycle targets
2) fire

I feel like having 2 buttons on-screen is not too much to ask in terms of screen real estate. Further, either option could be something fancy like a 'swipe', thus removing the necessity of 1 or both buttons. (swipe left to cycle, swipe right to attack)

I originally wanted to stay away from swiping, but playing Cursed Dungeons (http://droidgnome.blogspot.com/2012/05/first-official-release.html) on my android phone is starting to sway me.


Thanks for all the feedback and suggestions... I will report back if I come up with anything better. In the meantime if you (or a game you have played) have solved this problem I'd love to hear about it!

HF
http://heroicfisticuffs.blogspot.com/2012/05/adventures-in-ui-design.html

[twp...@gmail.com]

Edit to above: forgot to mention that the point if this solution is that it frees up MOST of the screen for simple tap-to-move, without the player having to worry about accidentally shooting instead of walking or vice versa!

[Jason Pickering]

Thats a cool idea. Will you focus on this mechanic? or just make as a way to control. by that I mean will switching targets like cost a turn, forcing the player to Kill in specific orders, or using ranged, to switch and get a hit in?

[Konstantin Stupnik]

Don't forget alternative controls for mouse (on desktop).
Swiping is anything but convenient with mouse :)

[twp...@gmail.com]

Oh for sure. The mouse controls are super-easy! I am very adamant about giving users flexibility of control. So you can do all-keyboard, or all-mouse, or whatever combination is easiest for you. Personally, I find keypad to move, mouse to shoot, to be the ultimate combo, but that uses 2 hands and sometimes you want to drink a coffee (or beer) while playing your RL.

So, for right now "desktop browser" is the delivery platform. I was mostly just thinking ahead for mobile, just because HTML5 should make that switch very easy.