Thursday, December 13, 2007

Movement: Arrows VS point and click

From the start movement has been handle by keyboard arrows. I'm not really a fan of point and click movement in 3d games and my model was SWG. Move with arrows and click on skills located in the toolbar.

I never really looked back until yesterday when I was messing around in my 2 zones world.

If your gentle with the keyboard, the actual system works just fine. However, when you start doing fancy maneuvers (long run, switching direction really fast), the results are unpredictable.

It's true that it's been a long time since I worked on movement and that I'm now at that point of checking back everything but the technical limits of javascript and browsers might bring some problems.

When an arrow is pressed, a message is sent to the server, the event listener for keys is detached from the browser and is reattached half a second later. The listener is detached because constant key pressed brings some heavy loop that the browser have some difficulties to handle.

While the /move action is sent to the server, others /move action can be receive from it to show movement of the character on the screen. Between each /move action received, an animation process takes place to animate the character going from point A to point B.

As you can see, a lot of things are happening to move a character and synchronizing all of this can become quite difficult (and I'm not even talking of what happens if the client computer slows down). The character on the screen might not be at the exact real location with the result of the player holding too long the arrows and then the character moving 1 or 2 square too far from the desired location.

Like I said, all of this is not a problem is you're gentle with your keyboard... but I don't expect players to be (or the right thing to say would be I can't ask players to be). Now the question I'm really not sure to know the answer right now is "Will I be able to make the movement process more stable the way it is currently handled?".

There's probably some tricks I'm missing or maybe those tricks would be a bit difficult if not impossible to do in javascript. So that brought me to think about point and click movement.

First, a lot less signals would be sent to the server. To move 10 squares left, only one click would be needed compared to 10 /move commands with the keyboard.

Second, the ending position would really be for sure the desired position. No more "oops, I hold too long the arrow while the interface was trying to catch up".

So far it's all good. The downside is that more work on the server is needed to calculate character's position when a movement is asked (well, a new coordinate to go to is sent). I don't see this as a great problem but there's surely a small challenge there.

With arrows movement, the server is dumb. It only check if movement is allowed in this direction. With point and click, it needs to calculate all coordinates the character needs to hit in order to get to the desired location. I could do this in two ways.

The first would consist of going in straight lines. Player clicks on the interface, character try to go in this direction, if there is an obstacle it stops. The player then have to click somewhere else to get around the obstacle.

The other way is to use what the NPCs' AI is using: path finding. The code is already done for NPCs so I could easily use it for PCs as well. Player clicks on the screen, coordinate is sent to the server, server calculate best path to reach the destination, movements are sent back to clients one after another with the correct downtime between each movement (so the animation match the real location of the character) and if an obstacle is met, the character will go around without the need for the player to click elsewhere.

The main (only?) problem I see with the latest is that characters might sometimes go to places players didn't expected to reach the destination. Of course, the player would be able to change it's course by clicking elsewhere, sending a new destination coordinate to the server while the previous path to be sent is dumped.

What impact this would have on the interface? It's probably a bit early to know exactly since the toolbar isn't yet implemented. For now I'll probable just add it anyway while keeping the old method not too far and alpha testing should shine some light on this.

Anyone have some comments on this? Any links to keyboard VS mouse articles?

2 Comments:

Poo Bear said...

Mouse control makes the game potentially more mass market, so that's one good thing. The casual game portals won't even accept a game unless it has mouse support. Plus, they prefer you only use the left mouse button too. I only mention it because these requirements come out of dealing with millions of players so I guess they know what they are talking about when it comes to usability.

Over00 said...

yeah, I agree.

I'm often wasting my time on Kongregate and it bothers even me when I have to use the keyboard. I guess I've been spoiled by too many games with good mouse gameplay.

Yesterday I implemented the code for point and click movement and the results are really interesting. Movement is now much more fluid and so far I haven't seen bugs or glitches.

The only thing missing for complete point and click now is support to enter building and changing zones. I'll have to change the interface a bit to support changing zone with the mouse but it shouldn't be a big problem.

Most games using point and click have the world scrolling with the character but since it's not like that for this project (would have been a bit more challenging but I had to draw the line somewhere), I'll have to add borders on which players will have to click to switch zone.