As of now, I've considered the following setup:

1 - [Crouch] Tap or click the ground directly beneath the character.

2 - [Run] Tap or click the ground on the left/right hand side of the character.

3 - [Jump] Tap or click a space above the character.

ASCII Mock-Up:

    3   3   3
        o    ____    ___________
    ____|___| :  |  | :  :  :  :
   | 2  1  2  2  |  | 2  2  2  2

I don't really want to use a virtual D-Pad, but if you think that it's a better solution, I can do so. My initial goal was to bind all game actions to a single input method (mouse-only, or tap-only). What do you think?

Hmm... To start with, I have two questions, if I may:

First, what sort of reactions are expected of the player? Will they be required to manage split-second timing, or to dodge multiple incoming projectiles, or is this a fairly sedate affair?

Second, I see that you've marked some fairly distant spots for the "run" command--is there some degree of path-finding, or does tapping that far to the right simply have the character run to the right for some duration or distance, with the player being required to jump and so on as called for?

The main advantage that I see to a virtual d-pad is reaction speed: I imagine that it's quicker to move one's thumb a short distance than to tap a screen with precision. That said, Silly Sausage in Meat Land managed to get away with something similar (albeit using swipes, not taps)--it's not technically a platformer, but it's pretty much analogous, I feel.

All of that said, I'm inclined to fall back on my usual advice: if feasible, prototype it, let people play it, and see whether it's fun!

One more suggestion, if I may: If the game doesn't require fast reflexes (in particular, if it's okay for the character to stand around for a short time), you could perhaps handle jumping via something similar to the controls in "Angry Birds": have the player drag a line in the desired direction and use the angle and length of that line to determine the elevation and power of a jump.

First, what sort of reactions are expected of the player? Will they be required to manage split-second timing, or to dodge multiple incoming projectiles, or is this a fairly sedate affair?

For now, it's a fairly sedate affair. The primary goal is to reach the end of the stage by traversing obstacles (ex. jumping from one platform to another) and solving small puzzles along the way.

Second, I see that you've marked some fairly distant spots for the "run" command--is there some degree of path-finding, or does tapping that far to the right simply have the character run to the right for some duration or distance, with the player being required to jump and so on as called for?

I haven't implemented any form of pathfinding just yet. If the player taps a ground tile that's far away, I planned to have the character run in that direction until an obstacle is encountered (ex. wall). If a pitfall is encountered while the previous action is being executed, the player can tap above the ground to jump over it.

The main advantage that I see to a virtual d-pad is reaction speed: I imagine that it's quicker to move one's thumb a short distance than to tap a screen with precision. That said, Silly Sausage in Meat Land managed to get away with something similar (albeit using swipes, not taps)--it's not technically a platformer, but it's pretty much analogous, I feel.

That's true. Thanks for the link.

All of that said, I'm inclined to fall back on my usual advice: if feasible, prototype it, let people play it, and see whether it's fun!

One more suggestion, if I may: If the game doesn't require fast reflexes (in particular, if it's okay for the character to stand around for a short time), you could perhaps handle jumping via something similar to the controls in "Angry Birds": have the player drag a line in the desired direction and use the angle and length of that line to determine the elevation and power of a jump.

Ok.

I really like the idea of utilizing "swipe" actions for movement. I'm currently using dynamic bounding boxes to check for mouse clicks within a region of the canvas (I'm using HTML5 and JavaScript). I'm probably overthinking this, but if I were to track the direction of a swipe, I would have to save the coordinates of the click, the coordinates of the release, and calculate a line/angle based on the two points, right? If I'm not mistaken, elevation and power can be determined through the distance fomula? Sorry if I'm asking too many questions (not sure if I should go to mobile & console development for further inquiry).

For now, it's a fairly sedate affair. The primary goal is to reach the end of the stage by traversing obstacles (ex. jumping from one platform to another) and solving small puzzles along the way.

I haven't implemented any form of pathfinding just yet. If the player taps a ground tile that's far away, I planned to have the character run in that direction until an obstacle is encountered (ex. wall). If a pitfall is encountered while the previous action is being executed, the player can tap above the ground to jump over it.

Aah, fair enough--sounds fun. ^_^

In that case, I see little problem with using taps or swipes.

Thanks for the link.

Honestly, even if you don't find it useful--although, given your description above, I feel that you might--I found Silly Sausage to be a rather fun little game, and it's free, so I'm inclined to recommend it. ^_^

I really like the idea of utilizing "swipe" actions for movement.

Before we continue, I feel that I should add one caveat: In my own experience, quick "swipes" don't work quite as well with a mouse as with touch-based controls. They can be done, but I feel that they can be a little awkward at times. Touch-based swipes, on the other hand, can be wonderfully intuitive.

That said, the mouse may be perfectly fine when speed and precision aren't significant factors.

I'm probably overthinking this, but if I were to track the direction of a swipe, I would have to save the coordinates of the click, the coordinates of the release, and calculate a line/angle based on the two points, right? If I'm not mistake, elevation and power can be determined through the distance fomula? Sorry if I'm asking too many questions (not sure if I should go to mobile & console development for further inquiry).

I honestly haven't used HTML5 and JavaScript to a significant degree, so I don't know what facilities they offer. However, presuming that you have only the coordinates of your touches/mouse-clicks, as well as the press- and release- events, then what you describe sounds more or less correct, yes. It's vector maths and/or trigonometry, essentially.

Regarding the distance formula specifically, do I take it that you mean this? I'd suggest first checking that HTML5 or JavaScript don't offer pre-made vector-classes with functions like vector -subtraction and -length (which should hopefully calculate the distance for you--it's just the length of (pointA - pointB)), and trigonometric functions (which should allow you to calculate the elevation, if called for).

How are you moving your character during a jump? Do you have a velocity-vector, separate x- and y- velocities, or some sort of angle-and-speed arrangement? If the first, then you should be able to simply take the vector defined by (releasePoint - pressPoint), scale it appropriately, perhaps cap its length if called for, and use that as your character's jump-velocity. Separate x- and y- velocities would be similar, I believe, but might call for a bit more work on your end. Angle-and-speed arrangements would call for a bit of trigonometry to determine the elevation, I believe.

Before we continue, I feel that I should add one caveat: In my own experience, quick "swipes" don't work quite as well with a mouse as with touch-based controls. They can be done, but I feel that they can be a little awkward at times. Touch-based swipes, on the other hand, can be wonderfully intuitive.

That said, the mouse may be perfectly fine when speed and precision aren't significant factors.

Ah. Well in that case, I may have to implement a different control system based on the platform (swipes for mobile, clicks for browser). Playtesting will certainly aid in determining the optimal control scheme.

Regarding the distance formula specifically, do I take it that you mean this? I'd suggest first checking that HTML5 or JavaScript don't offer pre-made vector-classes with functions like vector -subtraction and -length (which should hopefully calculate the distance for you--it's just the length of (pointA - pointB)), and trigonometric functions (which should allow you to calculate the elevation, if called for).

Yes, that's the formula that I was referring to earlier. I'll look into that, for sure. I'm fairly new to web development, so I'm not aware of all the functions and utilities that HTML5 and JavaScript have to offer.

How are you moving your character during a jump? Do you have a velocity-vector, separate x- and y- velocities, or some sort of angle-and-speed arrangement? If the first, then you should be able to simply take the vector defined by (releasePoint - pressPoint), scale it appropriately, perhaps cap its length if called for, and use that as your character's jump-velocity. Separate x- and y- velocities would be similar, I believe, but might call for a bit more work on your end. Angle-and-speed arrangements would call for a bit of trigonometry to determine the elevation, I believe.

To be honest, I've only implemented the crouch/stand action to date. The rest is just theory (though I plan to finish level one by the end of this week). However, I have used separate X and Y velocities for movement in previous games. Thank you for the explanations!

Ah. Well in that case, I may have to implement a different control system based on the platform (swipes for mobile, clicks for browser).

Hmm... Thinking about that, it occurs to me that some browser players may wonder why they're using such an interface when they (presumably) have a keyboard available. (Of course, this presumes that your gameplay doesn't rely on such an interface; I don't know your game beyond the descriptions above, so my worry may be thoroughly unfounded.)

That said, I do very much agree that playtesting is likely to reveal any such issues, and a good means of testing potential solutions.

To be honest, I've only implemented the crouch/stand action to date. The rest is just theory (though I plan to finish level one by the end of this week). However, I have used separate X and Y velocities for movement in previous games. Thank you for the explanations!

It's my pleasure, and good luck with that first milestone! ^_^