Improved Teleport Spell Behavior for Controllers #7380
Comments
|
Suggestion: make it so that the longer you hold the button, the further away you teleport to. Could come with a visual indicator of some sort even though that would add to dev work a bit. If you just quickly tap the button, it teleports maybe 2 (or even 1) tiles (maybe even make this configurable), if you press it for longer, teleport more tiles. Up to maybe a limit depending on the resolution you are playing (since you can teleport to any player-visible tile, usually). This would give you a bit more control using a controller, without the slowness involved in moving the cursor manually to the spot. The time holding the button would happen in between the initial cast animation and the animation's hit-frame, so no actual time would be "wasted" holding the button down. In the worst case, this would be the 8 or so frames for Sorcerer. Could potentially apply this same idea to using firewall, guardian, golem, or any other targeted, non-projectile spells. |
|
The tiles teleported should not exceed the boundaries of the default 480p viewport. |
The button holding would probably be the most intuitive. Could add a tile highlight where the player will target, and holding the button in starts the highlight at 2 tiles away, and every so many frames, it advances the highlight one more tile away up to a maximum of the 480p viewport borders and teleports you to the highlight when you let go Sorc: 8 frames Warrior: 14 frames Rogue: 12 frames |
|
Love the ideas, they certainly represent the luxury alteration to changing how Teleport is handled with a controller. My version of the changes represent the economy fix; however after much testing with Teleport as it is handled now, I do still believe it will significantly upgrade Teleport for controller users with much less work. I also believe that it is important to allow an option for Teleport to be handled just like a spell such as Golem or Guardian in that it will cast the spell at the auto-targeted monster. The warrior really needs a way to efficiently employ the "telekill" part of his kit when using a controller. |
Oh, definitely agree on that. If you have a specific target, it should override the hold behavior and teleport you to that specific place. I was suggesting the "hold longer -> longer distance" behavior more for the scenario where you just need a quick way to teleport in a general direction but precision is not exactly required. |
|
So I've continued to investigate how the Teleport spell behaves with controller usage and have found some additional details that may assist with further refinement. As stated before, the current default teleport distance is 4 spaces in the direction the character is facing. I've play tested this on each of the vanilla dungeon levels (Cathedral, Catacombs, Caves, and Hell) and still find that 5 spaces would most likely be the sweet spot for the default Teleport distance. Anything more creates two potential issues, the spell would exceed its original limitations on the straight X and Y axis (according to kphoenix137's diagram above), and the spell becomes to restrictive in tighter environments such as the Catacombs where the player will often find themselves not able to Teleport because it would propel them into areas that they do not want to go to. With 5 spots, it remains manageable as long as the player is cognizant of the direction they will be Teleporting in. The Teleport spell, as is I believe with all actions, will only cast if the character is set within a tile. Meaning that if the character is in transition from one tile to another, the cast action will not function until the character has finished the transition. This causes some issues with choosing Teleport direction as your character will begin to move in that direction causing the cast to not occur until the movement is completed (also requiring another press of the cast action button). Controller users can easily bypass this by using the "Stand Ground" action which eliminates the whole problem. Unfortunately at the moment, the "Stand Ground" action does not allow for continued attacking by holding the attack button down (I believe this is a known issue already and sounds like it will be addressed down the round) If the player wishes to rapidly cast multiple Teleports by holding down the cast button, the spell will malfunction once in between each cast. As it stands now, after the first Teleport occurs the second attempts to cast to early resulting in the spell being cast but not producing any result. This makes holding down the cast button with Teleport non-efficient and players should instead attempt to do frame perfect additional presses of the cast button instead to achieve better results. A possible tweak that would fix this is to create a delay between Teleport casts that matches the frame perfect timing required to function normally. This way you could face the direction you wish to go and hold down the cast button to quickly Teleport 4 spaces (hopefully 5 in the future) at each increment. When it comes to walls, it appears that if the Teleport would get your character more than half way through the wall it will then automatically pop you out on the other side successfully. If it does not get you more than half way then you remain where you are despite the cast. This does not appear to be any problem at all, and most likely comports well with the intended usage in most case with some exceptions (on the diagonals). This is a point when controller users will simply need to use the right thumb stick cursor instead. As mentioned in the original post, I also believe that a "Telekill" Teleport behavior option should exist in order to allow the warrior character (mostly) to effectuate this very important tactic within the game while using a controller. I mention it again only in that I hope to get some insight on how Auto-targeting works in the game. It appear to be a line of sight function that relies on an unobstructed view (specifically walls) within the characters current light radius. I noticed that the Auto-targeting does not function with the use of infravision (a possible separate issue to discuss elsewhere). If it does work this way, then implementing a "Telekill" option shouldn't in theory allow for otherwise impossible Teleport distances (although I have not tested this with max light radius on a character as of yet). Cheers! |
Feature Type
Gamepad Controls
Describe
Why is this important:
Teleport is an integral spell within Diablo for all three character types. Each use the spell for various uses with some degree of overlap:
The Sorcerer for general travel at high level and as a retreat or reposition mechanic.
The Rogue will often use it as a means of a fighting retreat as she attacks from distance and then teleport away from oncoming enemies to continue her ranged onslaught. In certain situation she may even leap frog over enemies to achieve the same effect.
The Warrior's main use for teleport is in the art of the "telekill". (ask any high level warrior who has had to chase down a room full of Soul Burners) I'm sure most people know what the "telekill" is, but to illustrate for those who may not the operation is as such:
With teleport readied, activate spell while targeting monster with cursor. Warrior will then teleport to the monster (usually appearing to the bottom left of the monster unless that space is occupied, then top right is usually prioritized second). Upon arrival, begin hacking the monster to give it the death it deserves.
Current behavior of the teleport spell when using a controller:
If the cursor is hidden (the cursor hides anytime the player moves or performs an action) then the player will be teleported 4 spaces in the direction that the character is facing upon activation.
If the player is moving the cursor on the screen (usually keyed to the right analog stick) and activates the spell while the cursor is hovering over an empty space, the character will teleport to that location.
If the player hovers the cursor over an occupied space (be it monster or other obstruction) then the character will default back to teleporting 4 spaces in the direction they are facing.
Suggestions for improving efficacy of teleport spell for controller users:
First and foremost is to increase the default 4 space teleport to 5 spaces in the direction the character is facing. This will immediately make teleport a very viable and useful spell for all character; especially the Rogue and the Sorcerer. Once controller users understand and get used to this spell behavior, it will become very usable without having to even access the cursor.
Second is to have teleport function the same as it does with a mouse and keyboard when using the cursor. As in, when the cursor is active and hovering over a occupied space, it teleports the character to an open space next to that occupied space instead of defaulting to the generic 4 spaces as it does now.
Third is to have an option to increase the cursor movement speed when using the right thumb-stick on a controller. (A slider option would be nice)
Fourth is to have an option for teleport to behave the same as any other targeting spell (ie: Guardian, Firewall, Golem...etc.) in that it will teleport to the auto-targeted monster closest to the character. I say option because Rogues and Sorcerers will not want this option on as default. The warrior on the other hand will want this option on to support doing his much desired "telekill".
Final thoughts:
The teleport spell when used with a controller will never be as good as when using a mouse and keyboard; however it can be made much more usable than it stands at the moment with these alterations. As always I'm certainly all ears for other ideas that may improve the spell use further or alternative means of doing so.
Cheers!
Edit: I messed around with this further and found that 8 spaces as a default teleport distance would be to much and exceed the limits of the spell based upon the original Diablo resolution size. I have edited the distance from 8 to 5, 4 is just to short. Even this 1 additional space would significantly improve its performance usage and I would venture to guess that it would be relatively easy to implement.
The text was updated successfully, but these errors were encountered: