For wall walking, a part of the problem is that the map geometry (on summit) is so complex that you can't really wall walk exactly, I mean if you follow the exact wall you would do crazy movement.
The principle of the walk walking is quite simple, you throw a bunch a vectors around the skulk and look for collision with the wall. If you catch any wall you disable the gravity and orient the skulk model along the wall normal.
The "collision vectors" make a circle around the skulk center and don't adapt or change with the orientation of the model:
Couldn't you sidestep the issue of complex geometry by simply limiting the view* to "three" different orientations (and, as a more difficult task, add smooth transitions)? *Actually it would be better described as your personal plane of movement, since it necessarily includes changing the mouse and keyboard input.
You have: 1) Gravity pointing down (on the ground, the right way up) 2) Gravity pointing up (on the ceiling, upside down) 3) Gravity pointing left/right/behind/forward, depending on personal and surface orientation.
Gravity (or "down") has a normalised vector of [0,-1,0], based on the absolute frame of reference Your model's "orientation" (the normal to the walking surface) has a vector (normalised?) of self.wallWalkingNormalCurrent, based on the absolute frame of reference If I have my math right, 1) A: When the dot product is between -1 and -0.5 (cos180 to cos120), your view (personal plane of movement) should not be offset (the right way up) [X-Z plane, +Y as up] 2) B: When the dot product is between 0.5 and 1 (cos60 to cos0), your view (personal plane of movement) should be offset by 180 degrees (upside down) [X-Z plane, -Y as up] 3) When the dot product is between -0.5 and 0.5, your view (personal plane of movement) should be offset by 90 degrees [X:Z-Y planes, X:Z as up] I'm using "0.5" since I think there should be a bias for floors and ceilings (i.e. up to a 60 degree angle, rather than 45), plus it makes the calculation easier. 3 is problematic, since your plane of movement changes with every new surface, so if you were to move around or within a wall corner, your plane of movement would change.
There was this fun half-life 2 mod called Ballmen that had wallwalking, but it was "simple" in that they simply shifted the direction of gravity with every ground shift. "Up" was 100% subjective. Is it possible to <b>change your plane of movement</b>** <u>without changing gravity</u>**? Perhaps, when not on any surface, your plane of movement (but not necessarily your view) changes back to normal (gravity straight down), and your view only changes when you touch a surface. Could be quite jarring though, even with smooth transitions. Perhaps, to tackle the issue of smooth transitions, you could predict a player's movement (which surface they are going to touch and when), and modify the transition accordingly. Fairly impossible when they have air control, however.
** I think these are the two goals we need to have. First, establishing <u>subjective</u> planes of movement, dependent on the surface normal (and then, to sidestep complex geometry, limiting them to ground, ceiling, wall). Second, re-establishing gravity once you leave a surface.
> All I can tell, is that it's way more involved than simply offsetting the view.
Regardless of the orientation of the view, I think that people need a focal point (e.g. an unmoving, unchanging crosshair in the centre of the screen) to counteract the dizziness that might result in switching the view.
<!--quoteo(post=1895771:date=Jan 19 2012, 04:42 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 19 2012, 04:42 AM) <a href="index.php?act=findpost&pid=1895771"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Silly hops is the way that all jumps work in just about every FPS game ever. It would put people off if people lost that ability. However, I think you raise a good point, but this "directional jump" should be in addition to, not a replacement for, "silly hops".<!--QuoteEnd--></div><!--QuoteEEnd--> Hops should only occur while your on the ground, and even then, should probably be triggered by tapping space bar quickly, not giving it a solid press. Hopping on the ceiling doesn't make any physical sense, you would simply fall, you should be making directed leaps.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->A lot of people get dizzy, disoriented or motion-sick with this feature. A suggestion I've seen to get the same idea across is to actually rotate the skulk viewmodel, rather than the skulk view; or else some kind of gravity indicator.<!--QuoteEnd--></div><!--QuoteEEnd--> If you don't change the actual view, you have a hard time looking around corners well and the system is ultimately clunky. In the end you can't have both and people who get motion sick would just need to stay on the floors. If the devs are willing to do the extra footwork to make it an option, that's fine too, I know which I'll be using, but it has to be available. You need to have a good idea of where you are in relation to everything else in the environment or you'll have problems.
@Harimau: we tried all that. Transforming the inputs, having only 3 modes for wallwalking. All had some of the issues still there. Changing the reference plane for movment we thought of too, but got no idea on how to change it. A nice fix for stickiness and not falling off would be to remove stick but change the gravity direction to the wallwalkingnormal and have it stay that way until you jump of, deattach or change plane to the floor.
I would live to see it working though. Reason I interested me in lua in the first place...
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Hops should only occur while your on the ground, and even then, should probably be triggered by tapping space bar quickly, not giving it a solid press.<!--QuoteEnd--></div><!--QuoteEEnd--> Why?
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Hopping on the ceiling doesn't make any physical sense, you would simply fall, you should be making directed leaps.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm confused by this. Have you tried looking at it in third person? There's a console command for it, but I don't remember what it is.
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you don't change the actual view, you have a hard time looking around corners well and the system is ultimately clunky.<!--QuoteEnd--></div><!--QuoteEEnd--> I don't see where this comes from. Why do you have a hard time looking around corners? What, particularly, is clunky about the system?
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In the end you can't have both and people who get motion sick would just need to stay on the floors.<!--QuoteEnd--></div><!--QuoteEEnd--> Or... we can keep it the way it is, and <b>you</b> just need to stay on the floors? Not sure if serious.
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If the devs are willing to do the extra footwork to make it an option, that's fine too, I know which I'll be using, but it has to be available.<!--QuoteEnd--></div><!--QuoteEEnd--> No comment, really. Some people believe there shouldn't be options and everyone should play the same (an even playing field). This idea of view rotation isn't new, and has been discussed at length in the past.
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You need to have a good idea of where you are in relation to everything else in the environment or you'll have problems.<!--QuoteEnd--></div><!--QuoteEEnd--> I don't see where this comes from. Why do you not have a good idea of where you are in relation to everything else in the environment?
Anyway, I don't know if you've been reading the rest of this thread, but Yuuki and Fluid Core <b>have</b> been trying to build something and get view rotation working; even I've attempted to brainstorm some ideas as to how to get it working. But the thing is, you come across as a little whiney and demanding; how about you help Yuuki and Fluid Core out with trying to make it happen, instead?
@Fluid Core: Maybe you need to build an overrideGravity function or something? It might not even be needed. I know that in the lerk code (at least one of the older versions), gliding (or flight?) involved changing the magnitude of gravity to something less.
Could you enumerate the types of wallwalking (including the live version) that you've tried, along with the issues they had/have or brought? I don't really have a good understanding of the desire or the problems.
Actually, hang on, what was the purpose of this thread?
Topics was speed, air control, wallwalking, jumping, walljumping and leap. I suppose we could continue abouts how to solve this issue in the dedicated thread, but a general discussion here. I talked with Yuuki about it yesterday; the lerk use a gravity override function. But gravity is exoressed as a scalar. Yuuki got the ideato override gravity and hardcode another force in another direction. That should probably work, but I leave that ciding for someone more proficient with lua. I'm decent with ideas and maths for making the physical representation, but more advanced cide I have to leave for others :)
<!--quoteo(post=1896094:date=Jan 20 2012, 01:46 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 20 2012, 01:46 AM) <a href="index.php?act=findpost&pid=1896094"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why?<!--QuoteEnd--></div><!--QuoteEEnd--> Because hops involve a lot of vertical movement in addition to relatively low horizontal movement. When you're on a wall vertical movement will drop you to the ground below without moving you forward, in the case of most of the corridors that means onto the floor because it can't reach wall to wall. Directed horizontal leaps would be necessary to cover the widths of hallways. You don't have vertical obstacles like crates you need to hop over on walls or ceilings and you couldn't hop over them even if they existed, thus hop, whose main purpose is to get you up and over, is ultimately less useful, to being almost useless.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I'm confused by this. Have you tried looking at it in third person? There's a console command for it, but I don't remember what it is.<!--QuoteEnd--></div><!--QuoteEEnd--> If you hop while upside down you will fall to the floor. Since hopping doesn't get you far enough forward to make it to another wall as most of it's movement is vertical, you'll just be dropping from the ceiling. Thus hopping as a mode of movement from ceiling to wall is not very useful.
<img src="http://img.photobucket.com/albums/v94/azimaith/wallleap.jpg" border="0" class="linked-image" /> The grey is a straight line leap, the red is the current hopping style jump. Eventually the red hop becomes stuck to the ground because he can't go far enough forward to make it from wall to wall. This means his ability to approach marines will eventually be down to areas around the floor, while the straight line leap could go from wall to ceiling to floor to ceiling or any combination thereof to make him difficult to target.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I don't see where this comes from. Why do you have a hard time looking around corners? What, particularly, is clunky about the system?<!--QuoteEnd--></div><!--QuoteEEnd--> Because when you're on a wall it becomes the new "down" for you. If you run up and stop at the edge of a cliff (like running across a wall and reaching a corner) you would naturally look down, over the edge, not sideways. This doesn't even include how easy it is to just pop off the wall when trying to look around the corner. This is why it's clunky, you can't depend on the wall walk to hold.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Or... we can keep it the way it is, and <b>you</b> just need to stay on the floors? Not sure if serious.<!--QuoteEnd--></div><!--QuoteEEnd--> It's an exasperated joke. The truth of the matter is, wall walking doesn't function well now because you can't rely on it holding you to a wall. There will be other issues, but I get the impression a lot of people complaining about motion sickness haven't given themselves the opportunity to get used to actually walking on walls. All versions of AvP had view shifted wall walking and I rarely saw complaints about motion sickness. It's much the same issue with HL2, where (apparently) the narrow FOV caused motion sickness in people (including myself) but I found that after some time I could adapt and get over it.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->No comment, really. Some people believe there shouldn't be options and everyone should play the same (an even playing field). This idea of view rotation isn't new, and has been discussed at length in the past.
I don't see where this comes from. Why do you not have a good idea of where you are in relation to everything else in the environment?<!--QuoteEnd--></div><!--QuoteEEnd--> Because you don't change view when you butt up to an obstacle. If your walking at the corner of a wall and ceiling you have no idea if you're walking on the ceiling or the wall as the view doesn't change. Those positions have different target profiles and can hide in different terrain. A small pipe poking parallel to a ceiling would cover a skulk on the roof, but not one on the wall. It gets even worse if you're moving around ceiling hideyholes. You can't tell if you're upside down on the ceiling, attached to the wall leading into the hiding area, or in the hiding area itself because you're view doesn't change. Take another example, the area between ventilation and data core, there's a alcove in the ceiling leading into data core, but you the best place to hide to prevent marines from seeing you is flat against the wall of the alcove, not on the ceiling of the alcove. But you can't tell which surface you're on because you're view remains the same. On the ceiling of the alcove you're long enough to be seen at an angle from an approaching marine, against the wall of the alcove the marine can't see you until he is literally under you and looking straight up.
Let me go to pictures (with my crappy MS paint skills) to make it clear. <img src="http://img.photobucket.com/albums/v94/azimaith/Skulkhiding.jpg" border="0" class="linked-image" /> As you can see Skulk A is visible to the marine while Skulk B is not and won't be until the marine is much closer, but in both cases the view is identical. If the view shifted with the surface, the default view for skulk A would be upside down and parallel to the floor, while skulk B would be perpendicular to the floor, giving a definite idea of where the skulk is.
<img src="http://img.photobucket.com/albums/v94/azimaith/Skulkpipe.jpg" border="0" class="linked-image" /> In this one the green represents a jutting pipe. Red skulk is on the wall but can't tell, and is protruding quite a bit from beyond the pipe. Blue skulk is on the ceiling and is well behind the pipe, providing cover and concealment. Both almost identical views because without view shifting it's very difficult to tell how far you've moved from a wall without turning to look at it, and even then, you don't know how "close" you stick.
<img src="http://img.photobucket.com/albums/v94/azimaith/alcoveskulk.jpg" border="0" class="linked-image" /> In this red, green, and blue skulk have difficulty ascertaining where they are in relation to the grating they are attached to (similar to the once that leads from flight control) because their view doesn't change angle as they move. Green and red will be almost identical views and will only be able to tell by consciously looking to the right to see the side of the grating, and even then, may not be certain. Green would have to look down to make sure he was actually in the relative concealment of the grating.
The most basic element of a FPS has to be knowing where the character is, but without knowing what surface you're standing on you can't tell immediately. No amount of crosshair changes or gravity indicators is a match for the unmistakable shift in view angle that can come from changing surfaces.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Anyway, I don't know if you've been reading the rest of this thread, but Yuuki and Fluid Core <b>have</b> been trying to build something and get view rotation working; even I've attempted to brainstorm some ideas as to how to get it working. But the thing is, you come across as a little whiney and demanding; how about you help Yuuki and Fluid Core out with trying to make it happen, instead?<!--QuoteEnd--></div><!--QuoteEEnd--> There's nothing whiny about pointing out the problem with not having view rotation/wall sticking/forward jumping in the game. This thread is "Let's discuss skulk movement." They haven't touched the issues with skulk wall walking since they increased wall stickiness, which is treating a symptom, not a cause. The thread mentioned skill based skulk movement by bounding off of obstacles, I pointed out bounding from wall to wall is currently impossible because of corridor width and measly lateral movement in hops and that a basis of skill based movement should not be restricted until second hive.
I suppose it's your choice to take it as whiny or demanding, but I see it as pointing out what I think are the fundamental flaws with the movement system for skulks and my reasons why. It's not intended to be whiny, and demanding is a side effect of it being about implementing an idea. One persons demanding is another persons argument.
As for helping beyond giving the argument of why it should be a particular way, you're out of luck there. I'm not a game designer nor do I understand a lot of the technical jargon you guys are throwing around, and I was never under the impression such was a prerequisite for participating in the thread. Obviously view rotation, wall clinging, view angle shifting, and lateral forward leaps are possible certain games, but I don't know whats possible in NS2 beyond what I've seen already done.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Actually, hang on, what was the purpose of this thread?<!--QuoteEnd--></div><!--QuoteEEnd--> I was under the impression it was this: Topics: speed, air control, wall walking, jump, wall jumping, leap, as per the first line of the OP post.<u></u>
I'm going to assume that by hoping you mean jump. Jumping doesn't work like you describe. What it does is function like a simple balistics. You get forward movment from your speed, and jumping just give you a vertical force. The directionn naturally depend on your orentation. If you want to be able to jump from eall to wall you have to increase the jump force so much that you din't arc down to much due to gravity. This would make the skulk always jump higher. Much higher.
For the record, I am no game designer, nor have I read any programming languahe. The level of the contribution feom me come mainly from common sense reading the lua files and basic physics and math knowledge.
I'm not sure I'm following you. How does it not work like how I describe. Grey is a high velocity jump where the trajectory is (effectively) very flat due to the velocity. Red is a low velocity jump where the arc is very pronounced because velocity is much lower. These pictures are just broad examples scraped together in MS paint in 5 minutes, obviously just like anything propelled in a ballistic fashion there's an arc, but it didn't seem worthwhile to put a tiny little arc in there when the broad difference between the two is pretty evident. Grey moves you directly between walls over long distances, red does not. You can't look at the velocity of the skulk itself as the sole determinant of the length and flatness of their jump, there's also the issue of the power the skulk puts into the jump to propel himself. In effect, I'm not asking for the skulk to be faster (that would be attached to the wall jump SBM idea the devs have, which would be much more usable with proposed jump changes) I'm asking for their jumps to be faster so they can cover more distance and ultimately make the wall bouncing leaps they're supposed to make for wall jumping.
You can differentiate a slower vertical jump from a propelling leap in whatever way you want, hold shift, hold down space, bind to a different key, but it should be available regularly so you can move from surface to surface easily.
If you can't move smoothly from wall to wall, wall to ceiling, ceiling to wall, ceiling to floor, and floor to ceiling quickly and smoothly, ultimately people are just going to approach targets in a much simpler way.
Now the obvious question here would be "If the skulk jumps faster, you're basically just replacing running with jumping as a faster way to get around." This may require leaping to be sensitive to a surface you're looking at, require a longer time to "prepare" from the ground but not from walls, or any other variation if you can't simply mess with physics and just cause the skulk to feel less gravity while he's leaping (effectively meaning his trajectory is still flatter, though not due solely to velocity.)
<!--quoteo(post=1896120:date=Jan 20 2012, 03:01 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 03:01 PM) <a href="index.php?act=findpost&pid=1896120"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm asking for their jumps to be faster so they can cover more distance and ultimately make the wall bouncing leaps they're supposed to make for wall jumping.<!--QuoteEnd--></div><!--QuoteEEnd-->
You completely missed my point. If their jumps are faster to make them able to jump wall-wall, then they will always jump much higher then now. There will be no "jump to chest hight" anymore. Every jump from the floor you do will send you to the ceiling unless it's very high, because jumping force is independent on view direction and forward speed. How HIGH you get (away from your surface, this is the wall-wall you want) will be your normal jump. How far you get depends on your speed. If you change so that you can easier jump wall-wall, then there is no way not to jump into the ceiling with a single tap of the space bar.
The ability to jump farther forward toward what you're looking at that isn't tied to hive 2. That's what I'm saying. There's no missed point. You can differentiate between chest high jumps and forward springing leaps in a number of different ways.
That doesn't make any sense, the leap ability from hive 2 doesn't send you from floor to ceiling but propels you much farther forward. The exact mechanisms in the game aren't terribly relevant unless you want to get into a big argument about semantics, which I personally don't. If the end result is you go forward farther, that's all that's whats going to matter.
I had a reply typed up last night, then my browser crashed.
Anyway, what exactly are you proposing regarding walljumping? Or just jumping in general? If it's for walljumps to move in the direction that you're facing, that's already how it works (at least, 10 parts your forward velocity, 1 part upward jump motion). If you give him any more speed than that (i.e. in order to move in an approximately straight line), you just give him a whole lot of speed that is not limited or subsequently reduced. Basically, leap. Jump, for comparison, is a vertical motion that is naturally reduced by gravity. Or is your point that leap shouldn't cost energy or be locked at game start?
With respect to view rotation etc, your main point was, as I understand it, self- and environmental-awareness. It's a valid point, but I wonder if simply knowing how you are oriented (e.g. with a gravity indicator, or viewmodel rotation) isn't enough for players to work it out for themselves? Even just having the surface you are currently 'standing' on marked, viewable only to yourself. The problem with view rotation is that if you change direction too often, you'll lose sight of whatever it was that you actually wanted to look at (not to mention disorientation). And if we do have walljumps such that players can move really fast in practically straight lines, then you exacerbate the disorientation, particularly on impact with a surface.
I have never played AvP2, so I'm not sure how their wallwalking works. But I have played a game with switching gravity, a Source engine mod called Ballmen. Originally, naturally it was difficult to get a hang of switching your reference plane, and difficult to keep track of important things, but I eventually got used to it (to some extent) and it was really fun. But it was relative, the geometry tended to be large and predictable enough to get a feel for, and tracking enemies wasn't made too big a task; but whenever there was any particularly complex geometry, you tended to misjudge, lose your bearings, and possibly fly off into space. Ballmen: <center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/J6JtH2Gg7EA"></param><embed src="http://www.youtube.com/v/J6JtH2Gg7EA" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center> Actually, this may be more relevant as a comparison with NS2, since it uses "real geometry" rather than simple blocks: <center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/oWYuFLdTgKU"></param><embed src="http://www.youtube.com/v/oWYuFLdTgKU" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
<!--quoteo(post=1896332:date=Jan 20 2012, 10:57 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 20 2012, 10:57 PM) <a href="index.php?act=findpost&pid=1896332"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I had a reply typed up last night, then my browser crashed.
Anyway, what exactly are you proposing regarding walljumping? Or just jumping in general? If it's for walljumps to move in the direction that you're facing, that's already how it works (at least, 10 parts your forward velocity, 1 part upward jump motion). If you give him any more speed than that (i.e. in order to move in an approximately straight line), you just give him a whole lot of speed that is not limited or subsequently reduced. Basically, leap. Jump, for comparison, is a vertical motion that is naturally reduced by gravity. Or is your point that leap shouldn't cost energy or be locked at game start?<!--QuoteEnd--></div><!--QuoteEEnd--> It's that there needs to be a leap equivalent move available from the start that shouldn't cost energy if the point of skulk skill based movement is bouncing from surface to surface. The leap doesn't need to do damage or anything, it's just necessary to traverse the environment in the way asked. It also makes navigating around on walls and ceilings vastly more fluid and useful because it becomes easy to switch surfaces at the touch of a button.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->With respect to view rotation etc, your main point was, as I understand it, self- and environmental-awareness. It's a valid point, but I wonder if simply knowing how you are oriented (e.g. with a gravity indicator, or viewmodel rotation) isn't enough for players to work it out for themselves? Even just having the surface you are currently 'standing' on marked, viewable only to yourself. The problem with view rotation is that if you change direction too often, you'll lose sight of whatever it was that you actually wanted to look at (not to mention disorientation). And if we do have walljumps such that players can move really fast in practically straight lines, then you exacerbate the disorientation, particularly on impact with a surface.<!--QuoteEnd--></div><!--QuoteEEnd--> I have a couple reasons why I don't care for gravity markers. 1: Gravity indicators don't solve the "on wall or ceiling" problem. In both cases down is in the same direction but your body is not oriented the same way. 2: In any case, when moving fast through the environment, you tend to be focused on what you're going at, not on little markers on your screen, thus you'll often miss the markers entirely when getting into combat. 3: Markers clutter up screens unnecessarily in my opinion.
View model rotation(if I'm understanding what you mean, as in the skulks mouth changes 90 degrees from floor to wall and 180 for floor to ceiling), provides more feedback but ultimately, changing your view model without changing the way your keys work is confusing. Certainly you'd eventually get over it, and it provides the same benefits of actual view rotation, but it seems different for the sake of being different. I also have a sneaking suspicious that view model rotation would cause motion sickness in some just like actual view rotation.
You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I have never played AvP2, so I'm not sure how their wallwalking works. But I have played a game with switching gravity, a Source engine mod called Ballmen. Originally, naturally it was difficult to get a hang of switching your reference plane, and difficult to keep track of important things, but I eventually got used to it (to some extent) and it was really fun. But it was relative, the geometry tended to be large and predictable enough to get a feel for, and tracking enemies wasn't made too big a task; but whenever there was any particularly complex geometry, you tended to misjudge, lose your bearings, and possibly fly off into space. Ballmen: <center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/J6JtH2Gg7EA"></param><embed src="http://www.youtube.com/v/J6JtH2Gg7EA" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center> Actually, this may be more relevant as a comparison with NS2, since it uses "real geometry" rather than simple blocks: <center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/oWYuFLdTgKU"></param><embed src="http://www.youtube.com/v/oWYuFLdTgKU" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center><!--QuoteEnd--></div><!--QuoteEEnd--> AvP2 definitely had you sticking to surfaces because there was a serious bug going down stairs where you'd walk on every surface of the stairs when wall walking. IE you'd go from the top of the stairs, to the vertical portion, to the top again, meaning you were very slow and the view jumped around crazily. A better example of good wall walking is AvP2010 (which had no stair issue.) The issues in that game had nothing to do with alien wall walking ability which is extremely smooth and something I don't recall ever getting stuck in. Would it help if I posted a video of wall walking in it with FRAPS? There is definitely complex geometry in AvP2010, but it's not exactly the same as NS2. NS2's map design has never struck me as being made with wall waking in mind. It has lot's of jutting ceiling pipes and other obstacles you can't get over well simply because the wall walking system isn't 100% sticky. I'll have to break out AVP2010 and mess around with the maps to see comparisons.
Some things I do remember from AvP2010 right off the top of my head. 1: There is a height threshold for wall walking disturbances. Objects that are small like lights, small protrusions, door frames, don't disturb wall walking. You can basically just go around them with no issue. This would indicate to me the these obstacles also need to be under a certain height from the wall surface to work this way.
2: The rotation of view is smooth, not rigid, if you walk in the seam of the corner and wall you're view shifts only part way.
3: Wall stickiness is 100%. You could never fall off a wall due to looking in a direction no matter how fast you moved. You could only detach voluntarily or be knocked off by certain attacks.
<!--quoteo(post=1896315:date=Jan 21 2012, 06:50 AM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 06:50 AM) <a href="index.php?act=findpost&pid=1896315"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The ability to jump farther forward toward what you're looking at that isn't tied to hive 2. That's what I'm saying. There's no missed point. You can differentiate between chest high jumps and forward springing leaps in a number of different ways.<!--QuoteEnd--></div><!--QuoteEEnd-->
Fair enough, your use of jumping and hoping made it unclear what it was you meant it as a different feature or mode of jumping.
<!--quoteo(post=1896358:date=Jan 21 2012, 12:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 12:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.<!--QuoteEnd--></div><!--QuoteEEnd-->
Never noticed that option myself, was it in settings or a mod? That's how I think it should be anyhow. Add it so that you can't walk off a surface: you only leave it by jumping, leaping or pressing crouch, and you're set to get around corners easily too.
Looking at Ballman, from what I can tell it behaves exactely like how I have played AvP2. As azimaith said above, that doesn't have to be like that, and I think it would add less motion sickness to have it in. Running forward and aiming for a wall and jumping into it, sticking htere, you would still aim at the wall then, tho it would have rotated 90 degree, and not at the same angle from the wall as you were from the floor.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->If it's for walljumps to move in the direction that you're facing, that's already how it works (at least, 10 parts your forward velocity, 1 part upward jump motion).<!--QuoteEnd--></div><!--QuoteEEnd-->
Not anymore, now you've got this speed storage system that gives you a forward bonus, but it doesn't really work so you mainly jump along the wall normal.
I agree with azimaith, the jump range should allow you to reach different surface on the map. The map becomes much more interesting when you can really use it. Ideally the skulk should be as agile as possible, the only constrain we have to take into consideration is that the marines should be able to track his movement and shoot him.
I think it's fine if the skulk can't reach the other wall in a normal hallway, but they should be able to jump wall-floor-other wall to be able to bound across the map and preserve speed.
Something I have noticed from time to time (I tried to practice some wall-jumping right now), is that if you jump wall-floor-wall, and the jump from the floor is to close to the second wall, then you will not attach to the wall and just fall down to the floor, effectively breaking any timing and speed you had acquired. I think this has something to do with the delay that turns of your stickiness to prevent you from jumping multiple times from the same wall in the same motion. You can also observe this by running towards a wall and jumping right before you reach it.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It's that there needs to be a leap equivalent move available from the start that shouldn't cost energy if the point of skulk skill based movement is bouncing from surface to surface. The leap doesn't need to do damage or anything, it's just necessary to traverse the environment in the way asked. It also makes navigating around on walls and ceilings vastly more fluid and useful because it becomes easy to switch surfaces at the touch of a button.<!--QuoteEnd--></div><!--QuoteEEnd--> Yeah, I agree. How, though?
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I have a couple reasons why I don't care for gravity markers. 1: Gravity indicators don't solve the "on wall or ceiling" problem. In both cases down is in the same direction but your body is not oriented the same way. 2: In any case, when moving fast through the environment, you tend to be focused on what you're going at, not on little markers on your screen, thus you'll often miss the markers entirely when getting into combat. 3: Markers clutter up screens unnecessarily in my opinion.<!--QuoteEnd--></div><!--QuoteEEnd--> Yeah, I guess so. But what about a simple marker (I just call it a marker, maybe you could call it a decal) which, when you look "down" (i.e. you look at the surface that you are currently attached to), there would be some indication of which surface you are currently attached to.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->View model rotation(if I'm understanding what you mean, as in the skulks mouth changes 90 degrees from floor to wall and 180 for floor to ceiling), provides more feedback but ultimately, changing your view model without changing the way your keys work is confusing. Certainly you'd eventually get over it, and it provides the same benefits of actual view rotation, but it seems different for the sake of being different. I also have a sneaking suspicious that view model rotation would cause motion sickness in some just like actual view rotation.<!--QuoteEnd--></div><!--QuoteEEnd--> Yeah, that's what I mean. Essentially it wouldn't change the system at all from what it is now, it would just give you an indication of the orientation of your player model. I think that the biggest issue is with walls where you are rotated 90 degrees and strafing. Essentially you can't strafe into a wall, so if you are on a "right wall", strafing up you press right, and strafing down you press left; then when you're on a "left wall", strafing down you press left, strafing up you press right - it isn't very intuitive. Ceilings aren't such an issue, move right = press right, move left = press left. The reason, I suspect, that they have the system this way is because the skulk is spending more time in the air (or on the ground) than actually on the walls; therefore you need very easy transitions between floor to 'space', wall to 'space', and ceiling to 'space': by keeping the view oriented "normally", you get to keep the skulk's reactivity and "air-based" manoeuvrability. For example, how does a skulk transition from ceiling to floor? In the game, you snap from upside down to right way up when you detach from the ceiling. In reality, a creature might flip or roll in mid-air to re-orient itself correctly. Currently the game sidesteps the issue by snapping the player model in 3rd person and keeping the "normal" view for the player in 1st person. With view rotation, it wouldn't work that way, since your frame of reference doesn't change, you would fall upside down and land on your back. That would be problematic. It makes me think we need almost a six degrees of freedom movement model for the skulk... at the very least we would need an option to roll in mid-air. Unless you use the same trickery and snap from upside down, detaching from the ceiling, to right way up while in mid-air. But then how do you deal with jumps from walls to ceiling? It would be pretty weird to be forced the right way up while jumping off a wall, then forced upside down once you hit the ceiling, rather than just rotating 90 degrees.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm not sure what you mean here.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->AvP2 definitely had you sticking to surfaces because there was a serious bug going down stairs where you'd walk on every surface of the stairs when wall walking. IE you'd go from the top of the stairs, to the vertical portion, to the top again, meaning you were very slow and the view jumped around crazily. A better example of good wall walking is AvP2010 (which had no stair issue.) The issues in that game had nothing to do with alien wall walking ability which is extremely smooth and something I don't recall ever getting stuck in. Would it help if I posted a video of wall walking in it with FRAPS? There is definitely complex geometry in AvP2010, but it's not exactly the same as NS2. NS2's map design has never struck me as being made with wall waking in mind. It has lot's of jutting ceiling pipes and other obstacles you can't get over well simply because the wall walking system isn't 100% sticky. I'll have to break out AVP2010 and mess around with the maps to see comparisons.<!--QuoteEnd--></div><!--QuoteEEnd--> So you think it basically worked on the principle of shifting gravity?
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Some things I do remember from AvP2010 right off the top of my head. 1: There is a height threshold for wall walking disturbances. Objects that are small like lights, small protrusions, door frames, don't disturb wall walking. You can basically just go around them with no issue. This would indicate to me the these obstacles also need to be under a certain height from the wall surface to work this way.
2: The rotation of view is smooth, not rigid, if you walk in the seam of the corner and wall you're view shifts only part way.
3: Wall stickiness is 100%. You could never fall off a wall due to looking in a direction no matter how fast you moved. You could only detach voluntarily or be knocked off by certain attacks.<!--QuoteEnd--></div><!--QuoteEEnd--> 1 and 3 I think are necessary, and the skulk could benefit from this. By 2, do you mean that you could, for example, rotate only 45 degrees if there were a surface oriented like that, rather than be in "three" states (floor, wall, ceiling)?
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yeah, I guess so. But what about a simple marker (I just call it a marker, maybe you could call it a decal) which, when you look "down" (i.e. you look at the surface that you are currently attached to), there would be some indication of which surface you are currently attached to.<!--QuoteEnd--></div><!--QuoteEEnd--> The problem is that, if you sit in a wall-wall-ceiling corner for example, you would need to look at all the three surfaces to notice wich one is highlighted. If your view rotated, you would know right away, as that surface would be the new down.
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think that the biggest issue is with walls where you are rotated 90 degrees and strafing. Essentially you can't strafe into a wall, so if you are on a "right wall", strafing up you press right, and strafing down you press left; then when you're on a "left wall", strafing down you press left, strafing up you press right - it isn't very intuitive. Ceilings aren't such an issue, move right = press right, move left = press left.<!--QuoteEnd--></div><!--QuoteEEnd--> If the view doesn't rotate, and the wall is sloped, then you strafe (slower) in the direction you strafe (assuming you stick). So if the hallway is wider at the ceiling then the floor, being on a "right" wall, strafing right makes you go up, and strafing left makes you go down. If your view would rotate so that the wall is orientated as if it was a floor instead (like I want it) then pressing right makes you go right on the wall, and pressing left makes you go left on the wall (like if you were on a floor - intuitive)
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->For example, how does a skulk transition from ceiling to floor? In the game, you snap from upside down to right way up when you detach from the ceiling. In reality, a creature might flip or roll in mid-air to re-orient itself correctly. Currently the game sidesteps the issue by snapping the player model in 3rd person and keeping the "normal" view for the player in 1st person. With view rotation, it wouldn't work that way, since your frame of reference doesn't change, you would fall upside down and land on your back. That would be problematic. It makes me think we need almost a six degrees of freedom movement model for the skulk... at the very least we would need an option to roll in mid-air. Unless you use the same trickery and snap from upside down, detaching from the ceiling, to right way up while in mid-air. But then how do you deal with jumps from walls to ceiling? It would be pretty weird to be forced the right way up while jumping off a wall, then forced upside down once you hit the ceiling, rather than just rotating 90 degrees.<!--QuoteEnd--></div><!--QuoteEEnd--> The game should be able to predict where you land, and when you will, and start rotating your view to that orientation (the least angle change) over the time. If with air control you change the prediction to another surface that changes this orientation, then the view should start to change to that. Might be code heavy though. <!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--><!--quoteo(post=1896358:date=Jan 21 2012, 12:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 12:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--> You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.<!--QuoteEnd--></div><!--QuoteEEnd--> I'm not sure what you mean here. <!--QuoteEnd--></div><!--QuoteEEnd--> If you look at the video from BallMan, you notice that where you aim changes while you change surface. If the view just rotates instead, then you will aim at the same point but the orientation will have rotated. <!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->By 2, do you mean that you could, for example, rotate only 45 degrees if there were a surface oriented like that, rather than be in "three" states (floor, wall, ceiling)?<!--QuoteEnd--></div><!--QuoteEEnd-->
Allow me to answer this. Yes, it means that there aren't any "states". The specific point here, I think, is that the game doesn't have to choose between floor or ceiling however, it sets the orientation to "floor+ceiling" and rotate the view to the combination of their normals. I haven't played AvP2010 myself, only AvP2, but that's what I would read the point as, and an improvement I personally would have liked to see in AvP2.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The problem is that, if you sit in a wall-wall-ceiling corner for example, you would need to look at all the three surfaces to notice wich one is highlighted. If your view rotated, you would know right away, as that surface would be the new down.<!--QuoteEnd--></div><!--QuoteEEnd--> I know, but I don't see that as a problem.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If the view doesn't rotate, and the wall is sloped, then you strafe (slower) in the direction you strafe (assuming you stick). So if the hallway is wider at the ceiling then the floor, being on a "right" wall, strafing right makes you go up, and strafing left makes you go down. If your view would rotate so that the wall is orientated as if it was a floor instead (like I want it) then pressing right makes you go right on the wall, and pressing left makes you go left on the wall (like if you were on a floor - intuitive)<!--QuoteEnd--></div><!--QuoteEEnd--> You're right, that just seems clunky and useless... that's certainly an area for improvement.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The game should be able to predict where you land, and when you will, and start rotating your view to that orientation (the least angle change) over the time. If with air control you change the prediction to another surface that changes this orientation, then the view should start to change to that. Might be code heavy though.<!--QuoteEnd--></div><!--QuoteEEnd--> Yeah, but air control makes this fairly impossible.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you look at the video from BallMan, you notice that where you aim changes while you change surface. If the view just rotates instead, then you will aim at the same point but the orientation will have rotated.<!--QuoteEnd--></div><!--QuoteEEnd--> Still hard to visualise (the latter, not the former), is there a video?
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Allow me to answer this. Yes, it means that there aren't any "states". The specific point here, I think, is that the game doesn't have to choose between floor or ceiling however, it sets the orientation to "floor+ceiling" and rotate the view to the combination of their normals. I haven't played AvP2010 myself, only AvP2, but that's what I would read the point as, and an improvement I personally would have liked to see in AvP2.<!--QuoteEnd--></div><!--QuoteEEnd--> You've been answering them all. :P As we discussed earlier in this thread, being able to override gravity (when attached to a surface) and switching it to a vector that acts in the opposite direction to skulk.wallWalkNormal would be ideal, and would most likely work exactly in this way.
<!--quoteo(post=1896406:date=Jan 21 2012, 05:25 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 05:25 PM) <a href="index.php?act=findpost&pid=1896406"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Still hard to visualise (the latter, not the former), is there a video?<!--QuoteEnd--></div><!--QuoteEEnd-->
Not that I could find. You can try it yourself by an easy mod to your Skulk_Client.lua file.
There's no use trying to play with it though, it's only the view that changes, your pitch, yaw and imputs still relates to "floor" mode.
<!--quoteo(post=1896406:date=Jan 21 2012, 05:25 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 05:25 PM) <a href="index.php?act=findpost&pid=1896406"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You've been answering them all. :P As we discussed earlier in this thread, being able to override gravity (when attached to a surface) and switching it to a vector that acts in the opposite direction to skulk.wallWalkNormal would be ideal, and would most likely work exactly in this way.<!--QuoteEnd--></div><!--QuoteEEnd-->
One thing I didn't mentioned about the wall walk is that it seems to pretty heavy, the check is done only every five time per second. Ideally one would like to do a lot of checks in all direction, but that's probably not possible for performance reasons.
I've been trying to change a bit the way the wall detection/attachment is done, I replaced the 8 circular vectors by something that adapt more to the skulk model, it looks a bit like his legs :
It works pretty well (it's in the file in my first post) but has some specific problems, for example it's sometimes hard to attach to the ceiling, because the "legs" are all pointing downwards. Maybe make then dependent on velocity would help, I don't know.
About the gravity, there is already something very similar, when you're attached to a wall, within a certain range, there is a force that make you stick to the wall (wallWalkingStickGoal is the wall normal) :
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->// Move towards the stick goal if there is a stick goal. if self.wallWalkingStickEnabled and self.wallWalkingStickGoal then self:PerformMovement(-self.wallWalkingStickGoal * (time * 2), 1, nil) end<!--QuoteEnd--></div><!--QuoteEEnd-->
I will have a look at the strafing, maybe it's not too hard to do.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The game should be able to predict where you land, and when you will, and start rotating your view to that orientation (the least angle change) over the time. If with air control you change the prediction to another surface that changes this orientation, then the view should start to change to that. Might be code heavy though.<!--QuoteEnd--></div><!--QuoteEEnd-->
You can probably throw a vector in the predicted landing zone (more of less in the velocity direction I guess) and get the surface orientation this way, shouldn't be too hard.
RE: your new wall-detector, is that 3-dimensional? What do you mean by making them dependent on velocity, rather, how do you imagine you might approach it? And is your wall-detector an improvement over the original, and in what way?
RE: the gravity, I think the issue is more about fundamentally changing how the skulk operates, so it may involve looking at the general player code, the general alien code, maybe the game world code, etc. We're talking about getting full view rotation here right? I mean you have to change: The reference plane (using surface-normal, switching gravity); the perspective (view rotation); and the movement and input.
RE: predicted landing zone, throwing a vector (maybe like hitscan, determining the surface-normal at the "landing point") could work, but it wouldn't account for the ballistic trajectory (and air control would be impossible to account for), and it would be problematic when your landing point is at corners for instance - your predicted orientation is like so, but a second after landing your orientation would have to change to match your actual landing surface.
Seeing as much of this is server-side, I don't see how it could be a client-side option. I think it would have to be one or the other.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->your new wall-detector, is that 3-dimensional? What do you mean by making them dependent on velocity, rather, how do you imagine you might approach it? And is your wall-detector an improvement over the original, and in what way?<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not sure if it's what you mean but it's 3D vectors yes. It works like you said "throwing a vector (maybe like hitscan, determining the surface-normal at the "landing point")", just that the hitscan has a finite range (length of the vector). We can arrange the vectors like we want, and put as many as we want (at computational cost or course).
One of the advantage of the original (the circle) is that it's invariant, so it perform equally in all situations. One of the disadvantage is that it's not very smart, sometimes like in the screenshot above you got a vector that is inside the skulk body and therefor has little chances to hit anything.
I wouldn't say my version is better, it's more or less the same I think from the point of view of the feeling, it's ok but not very good.
But if you imagine yourself running and try to jump on a wall (try it!) wouldn't you throw you're arms and legs in front of you, in the direction of your velocity ?
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->We're talking about getting full view rotation here right?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes and no, the full rotation would be optional anyway, so I'm thinking about both cases. Switching gravity all the time would be a bit ridiculous, can you imagine skulk flying up and down, left and right in a room ? In the current version "gravity" (wall sticking) is switched only close to the wall and is reverse to normal vertical gravity when you detach from the wall.
I think that if you did manage to change the referense plane, then both view rotation and inputs, at the very lesat imputs, would sort themselves out. They should be derived from the referense plane in the first place. What might need tweaking is to make the view rotation just rotate so that you keep aiming at the same point when you change rotation and doesn't move your mouse.
The idea with gravity is to make walking around not feel like you jo-jo from and to the wall if it is uneven. Compare it to walking on the floor, that never feel like you bounce up and down. The distance shoulden't matter, but you could not get far enough from the wall so that you would get skulks flying across the room and break immersion. With gravity approach and view rotation, you couldn't walk of the wall, and if you leap/jump/crouch your gravity would reverse to normal and you would fall towards the floor.
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'm not sure if it's what you mean but it's 3D vectors yes. It works like you said "throwing a vector (maybe like hitscan, determining the surface-normal at the "landing point")", just that the hitscan has a finite range (length of the vector). We can arrange the vectors like we want, and put as many as we want (at computational cost or course).<!--QuoteEnd--></div><!--QuoteEEnd--> That's what I meant by 3D, yes. From the image you posted of the original, it looked like it was circular in a 2D plane.
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->One of the advantage of the original (the circle) is that it's invariant, so it perform equally in all situations. One of the disadvantage is that it's not very smart, sometimes like in the screenshot above you got a vector that is inside the skulk body and therefor has little chances to hit anything.
I wouldn't say my version is better, it's more or less the same I think from the point of view of the feeling, it's ok but not very good.
But if you imagine yourself running and try to jump on a wall (try it!) wouldn't you throw you're arms and legs in front of you, in the direction of your velocity ?
Another view :
<img src="http://i.imgur.com/JDRTE.png" border="0" class="linked-image" /><!--QuoteEnd--></div><!--QuoteEEnd--> So, dynamic wall-detectors, essentially? I'm not sure about having it change with velocity, perhaps having it change if you're in mid-air would be better? From your implementation, it looks like it could be problematic or an improvement with corners, with the current wallwalking and an improved wallwalking, respectively. Essentially, at corners you would have rays hitting different surfaces, so which surface should you actually be on? However, you could actually turn this beneficial if you made it a smooth transition between the two. The planar version is more binary: you are on this surface, your feeler hits that surface, you are now on that surface. However, the planar version might suffer from the same issue when in a particularly claustrophobic space (e.g. travelling along a vent you have wall-detectors hitting the insides of the vent on both sides). Also the planar version doesn't actually have to calculate which surface to stick to while you're actually on the surface since it is parallel to the surface - you could probably achieve the same with a three-dimensional version by limiting the range of the 'feelers', such that they don't quite reach the surface, ordinarily. Please correct me if I'm misunderstanding something about the current wallwalking system.
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yes and no, the full rotation would be optional anyway, so I'm thinking about both cases. Switching gravity all the time would be a bit ridiculous, can you imagine skulk flying up and down, left and right in a room ? In the current version "gravity" (wall sticking) is switched only close to the wall and is reverse to normal vertical gravity when you detach from the wall.<!--QuoteEnd--></div><!--QuoteEEnd--> I don't think it could be optional (as in optional between current skulk and proposed skulk) since the changes would mostly be server-side, and the proposed skulk would change the mechanics of the skulk at a fundamental level. It would, essentially, be two different skulks. Regarding gravity, what I'm actually proposing is that this new "personal gravity" only applies when you're actually on (or <b>very near</b>) a surface - the moment you leave any surface (i.e. are in mid-air), your personal gravity is reset to world gravity. The reason I'm proposing switching gravity (as opposed to the current implementation of a sticking force) is that I want to switch the player's "reference plane" (see the Ballmen video) - this could possibly (ostensibly) allow us to achieve view rotation AND a proper movement scheme (i.e. your view and your movement are relative to your personal gravity, which is dependent on the surface normal, i.e. they are relative to the surface you are on).
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yes, but compared to the current situation (do nothing) it can only be better, or maybe much worse ^^'<!--QuoteEnd--></div><!--QuoteEEnd--> The thing is, the current situation (no view rotation) simply sidesteps the issue for the player: no view rotation means no real need to calculate mid-air "transitions" (I don't know about the third-person game world model however - that could benefit aesthetically). So the suggestion about landing surface prediction was really only for full view rotation. Another possibility is to give the player control over their <a href="http://en.wikipedia.org/wiki/Flight_dynamics_(aircraft)" target="_blank">roll</a> while in mid-air (mouse-look already gives them control over their yaw and pitch).
<!--quoteo(post=1896706:date=Jan 23 2012, 05:19 AM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 23 2012, 05:19 AM) <a href="index.php?act=findpost&pid=1896706"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think that if you did manage to change the referense plane, then both view rotation and inputs, at the very lesat imputs, would sort themselves out. They should be derived from the referense plane in the first place. ... The idea with gravity is to make walking around not feel like you jo-jo from and to the wall if it is uneven. Compare it to walking on the floor, that never feel like you bounce up and down. The distance shoulden't matter, but you could not get far enough from the wall so that you would get skulks flying across the room and break immersion. With gravity approach and view rotation, you couldn't walk of the wall, and if you leap/jump/crouch your gravity would reverse to normal and you would fall towards the floor.<!--QuoteEnd--></div><!--QuoteEEnd--> Yeah, exactly. I hadn't read your post before I replied to Yuuki's so I didn't realise you'd already beat me to a reply.
<!--quoteo(post=1896706:date=Jan 23 2012, 05:19 AM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 23 2012, 05:19 AM) <a href="index.php?act=findpost&pid=1896706"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What might need tweaking is to make the view rotation just rotate so that you keep aiming at the same point when you change rotation and doesn't move your mouse.<!--QuoteEnd--></div><!--QuoteEEnd--> I think this could be quite difficult; at least I don't understand, conceptually, how you might achieve this. What exactly constitutes "the same point"? Actually, now that I think of it - upon changing a surface (i.e. reference plane), your viewing direction (that is, essentially, player:GetViewAngles():GetCoords().zAxis) could simply be preserved. The actual orientation of your view (your "roll") would then depend on your <u>viewing direction</u> and your <u>surface orientation</u>... the orientation of your model, perhaps. This would be beneficial for maintaining orientation and being able to track targets, but this could actually be problematic as well, because... well let me illustrate it: <img src="http://i.imgur.com/GmANf.png" border="0" class="linked-image" /> Red is the player's trajectory. Coloured arrows represent the player's view direction. This is a side-on view and I'm assuming that the player moves in the direction of their view, like a leap. So basically the player has to move their mouse "up" every time, and this would be cumulative. Essentially this is, I think, what azimaith was describing as the second option in AVP2 - it makes moving around a little slower and more cumbersome, but lets you track targets more easily. If we made the game move the viewing direction along with your reference plane, movement would be easier but with perhaps a greater chance of getting disoriented (though I believe you would get used to it, as I got used to playing Ballmen) and more difficulty in tracking targets. Ideally, we would somehow give the player the ability to use both options in-game at will.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->From your implementation, it looks like it could be problematic or an improvement with corners, with the current wallwalking and an improved wallwalking, respectively. Essentially, at corners you would have rays hitting different surfaces, so which surface should you actually be on?<!--QuoteEnd--></div><!--QuoteEEnd-->
Well in the current implementation if several traces hit a wall, you simply take the average of the wall normals. So in my version if you have two legs on the ground and two legs on the wall you actually get a 45 degree angle. I should mention that in the vanilla version there is also a trace above (vertical in the game reference) and bellow the skulk in addition to the circle. The trace bellow has also priority over the others, so if it hits you just return this normal instead of doing the average.
Taking the average is good I think, because if you have a very convoluted surface, it smooths out a bit the details.
There is also a trade off between stickying strongly to the current surface and being able to transition smoothly to another one. At first I though: "this is stupid! why not do a trace in the direction of the past wall normal, this is the most likely direction to find the wall again". It works well, you stick strongly to the wall, but it's pretty much impossible to transition to another wall.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The thing is, the current situation (no view rotation) simply sidesteps the issue for the player: no view rotation means no real need to calculate mid-air "transitions" (I don't know about the third-person game world model however - that could benefit aesthetically).<!--QuoteEnd--></div><!--QuoteEEnd-->
Well the third-person game world model is important for marines, because it's what you shoot at ! It should be smooth and predictable as possible, so the marines can track a skulk even if he's very agile (which is what we want).
Also the model rotation and the view are linked, they should be the same actually in the full view rotation model, and almost the same in the "zero roll view model" (current one).
@Harimau: Well, conceptually, the only change you do to the view is to rotate it around your z-axis (middle of screeb) so that the new wallwalking surface is down. Compare it to if you change to a surface that you aimed parallell to, the view will just rotate and you will aim at the same point. But if you aimed in any otherr direction you would not aim to the same point. What you want is to keeo aiming at the same point regardless of prior orientation. You acomplish this by rotating the view around the z-axis so that your y-axis (up) is in the same plane as the wall normal and your z-axis. But make the change in the Skulk_Client.lua I mentioned earlier and try it yourself. You don't even have to make it a mod.
- The three angles of the camera: <b>(pitch, yaw, roll)</b> - The wall normal: <b>n</b> - Two mouse input angles: <b>input.yaw</b> and <b>input.pitch</b>
Write an expression for <b>(pitch, yaw, roll)=f(n,input.yaw,input.pitch)</b>.
Note that n = n(t) and that df / dn should be smartly chosen (i.e. you don't want changes in the wall normal to make crazy changes in the camera angles).
Comments
For wall walking, a part of the problem is that the map geometry (on summit) is so complex that you can't really wall walk exactly, I mean if you follow the exact wall you would do crazy movement.
The principle of the walk walking is quite simple, you throw a bunch a vectors around the skulk and look for collision with the wall. If you catch any wall you disable the gravity and orient the skulk model along the wall normal.
The "collision vectors" make a circle around the skulk center and don't adapt or change with the orientation of the model:
<img src="http://i.imgur.com/iSoQK.png" border="0" class="linked-image" />
*Actually it would be better described as your personal plane of movement, since it necessarily includes changing the mouse and keyboard input.
You have:
1) Gravity pointing down (on the ground, the right way up)
2) Gravity pointing up (on the ceiling, upside down)
3) Gravity pointing left/right/behind/forward, depending on personal and surface orientation.
Gravity (or "down") has a normalised vector of [0,-1,0], based on the absolute frame of reference
Your model's "orientation" (the normal to the walking surface) has a vector (normalised?) of self.wallWalkingNormalCurrent, based on the absolute frame of reference
If I have my math right,
1) A: When the dot product is between -1 and -0.5 (cos180 to cos120), your view (personal plane of movement) should not be offset (the right way up) [X-Z plane, +Y as up]
2) B: When the dot product is between 0.5 and 1 (cos60 to cos0), your view (personal plane of movement) should be offset by 180 degrees (upside down) [X-Z plane, -Y as up]
3) When the dot product is between -0.5 and 0.5, your view (personal plane of movement) should be offset by 90 degrees [X:Z-Y planes, X:Z as up]
I'm using "0.5" since I think there should be a bias for floors and ceilings (i.e. up to a 60 degree angle, rather than 45), plus it makes the calculation easier.
3 is problematic, since your plane of movement changes with every new surface, so if you were to move around or within a wall corner, your plane of movement would change.
There was this fun half-life 2 mod called Ballmen that had wallwalking, but it was "simple" in that they simply shifted the direction of gravity with every ground shift. "Up" was 100% subjective.
Is it possible to <b>change your plane of movement</b>** <u>without changing gravity</u>**?
Perhaps, when not on any surface, your plane of movement (but not necessarily your view) changes back to normal (gravity straight down), and your view only changes when you touch a surface. Could be quite jarring though, even with smooth transitions. Perhaps, to tackle the issue of smooth transitions, you could predict a player's movement (which surface they are going to touch and when), and modify the transition accordingly. Fairly impossible when they have air control, however.
** I think these are the two goals we need to have. First, establishing <u>subjective</u> planes of movement, dependent on the surface normal (and then, to sidestep complex geometry, limiting them to ground, ceiling, wall). Second, re-establishing gravity once you leave a surface.
> All I can tell, is that it's way more involved than simply offsetting the view.
Regardless of the orientation of the view, I think that people need a focal point (e.g. an unmoving, unchanging crosshair in the centre of the screen) to counteract the dizziness that might result in switching the view.
Hops should only occur while your on the ground, and even then, should probably be triggered by tapping space bar quickly, not giving it a solid press. Hopping on the ceiling doesn't make any physical sense, you would simply fall, you should be making directed leaps.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->A lot of people get dizzy, disoriented or motion-sick with this feature.
A suggestion I've seen to get the same idea across is to actually rotate the skulk viewmodel, rather than the skulk view; or else some kind of gravity indicator.<!--QuoteEnd--></div><!--QuoteEEnd-->
If you don't change the actual view, you have a hard time looking around corners well and the system is ultimately clunky. In the end you can't have both and people who get motion sick would just need to stay on the floors. If the devs are willing to do the extra footwork to make it an option, that's fine too, I know which I'll be using, but it has to be available. You need to have a good idea of where you are in relation to everything else in the environment or you'll have problems.
I would live to see it working though. Reason I interested me in lua in the first place...
Why?
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Hopping on the ceiling doesn't make any physical sense, you would simply fall, you should be making directed leaps.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm confused by this. Have you tried looking at it in third person? There's a console command for it, but I don't remember what it is.
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you don't change the actual view, you have a hard time looking around corners well and the system is ultimately clunky.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't see where this comes from. Why do you have a hard time looking around corners? What, particularly, is clunky about the system?
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->In the end you can't have both and people who get motion sick would just need to stay on the floors.<!--QuoteEnd--></div><!--QuoteEEnd-->
Or... we can keep it the way it is, and <b>you</b> just need to stay on the floors? Not sure if serious.
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If the devs are willing to do the extra footwork to make it an option, that's fine too, I know which I'll be using, but it has to be available.<!--QuoteEnd--></div><!--QuoteEEnd-->
No comment, really. Some people believe there shouldn't be options and everyone should play the same (an even playing field). This idea of view rotation isn't new, and has been discussed at length in the past.
<!--quoteo(post=1896044:date=Jan 20 2012, 01:46 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 20 2012, 01:46 PM) <a href="index.php?act=findpost&pid=1896044"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You need to have a good idea of where you are in relation to everything else in the environment or you'll have problems.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't see where this comes from. Why do you not have a good idea of where you are in relation to everything else in the environment?
Anyway, I don't know if you've been reading the rest of this thread, but Yuuki and Fluid Core <b>have</b> been trying to build something and get view rotation working; even I've attempted to brainstorm some ideas as to how to get it working. But the thing is, you come across as a little whiney and demanding; how about you help Yuuki and Fluid Core out with trying to make it happen, instead?
@Fluid Core: Maybe you need to build an overrideGravity function or something? It might not even be needed. I know that in the lerk code (at least one of the older versions), gliding (or flight?) involved changing the magnitude of gravity to something less.
Could you enumerate the types of wallwalking (including the live version) that you've tried, along with the issues they had/have or brought? I don't really have a good understanding of the desire or the problems.
Actually, hang on, what was the purpose of this thread?
<!--quoteo(post=1896094:date=Jan 20 2012, 01:46 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 20 2012, 01:46 AM) <a href="index.php?act=findpost&pid=1896094"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Why?<!--QuoteEnd--></div><!--QuoteEEnd-->
Because hops involve a lot of vertical movement in addition to relatively low horizontal movement. When you're on a wall vertical movement will drop you to the ground below without moving you forward, in the case of most of the corridors that means onto the floor because it can't reach wall to wall. Directed horizontal leaps would be necessary to cover the widths of hallways. You don't have vertical obstacles like crates you need to hop over on walls or ceilings and you couldn't hop over them even if they existed, thus hop, whose main purpose is to get you up and over, is ultimately less useful, to being almost useless.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I'm confused by this. Have you tried looking at it in third person? There's a console command for it, but I don't remember what it is.<!--QuoteEnd--></div><!--QuoteEEnd-->
If you hop while upside down you will fall to the floor. Since hopping doesn't get you far enough forward to make it to another wall as most of it's movement is vertical, you'll just be dropping from the ceiling. Thus hopping as a mode of movement from ceiling to wall is not very useful.
<img src="http://img.photobucket.com/albums/v94/azimaith/wallleap.jpg" border="0" class="linked-image" />
The grey is a straight line leap, the red is the current hopping style jump. Eventually the red hop becomes stuck to the ground because he can't go far enough forward to make it from wall to wall. This means his ability to approach marines will eventually be down to areas around the floor, while the straight line leap could go from wall to ceiling to floor to ceiling or any combination thereof to make him difficult to target.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I don't see where this comes from. Why do you have a hard time looking around corners? What, particularly, is clunky about the system?<!--QuoteEnd--></div><!--QuoteEEnd-->
Because when you're on a wall it becomes the new "down" for you. If you run up and stop at the edge of a cliff (like running across a wall and reaching a corner) you would naturally look down, over the edge, not sideways. This doesn't even include how easy it is to just pop off the wall when trying to look around the corner. This is why it's clunky, you can't depend on the wall walk to hold.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Or... we can keep it the way it is, and <b>you</b> just need to stay on the floors? Not sure if serious.<!--QuoteEnd--></div><!--QuoteEEnd-->
It's an exasperated joke. The truth of the matter is, wall walking doesn't function well now because you can't rely on it holding you to a wall. There will be other issues, but I get the impression a lot of people complaining about motion sickness haven't given themselves the opportunity to get used to actually walking on walls. All versions of AvP had view shifted wall walking and I rarely saw complaints about motion sickness. It's much the same issue with HL2, where (apparently) the narrow FOV caused motion sickness in people (including myself) but I found that after some time I could adapt and get over it.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->No comment, really. Some people believe there shouldn't be options and everyone should play the same (an even playing field). This idea of view rotation isn't new, and has been discussed at length in the past.
I don't see where this comes from. Why do you not have a good idea of where you are in relation to everything else in the environment?<!--QuoteEnd--></div><!--QuoteEEnd-->
Because you don't change view when you butt up to an obstacle. If your walking at the corner of a wall and ceiling you have no idea if you're walking on the ceiling or the wall as the view doesn't change. Those positions have different target profiles and can hide in different terrain. A small pipe poking parallel to a ceiling would cover a skulk on the roof, but not one on the wall. It gets even worse if you're moving around ceiling hideyholes. You can't tell if you're upside down on the ceiling, attached to the wall leading into the hiding area, or in the hiding area itself because you're view doesn't change. Take another example, the area between ventilation and data core, there's a alcove in the ceiling leading into data core, but you the best place to hide to prevent marines from seeing you is flat against the wall of the alcove, not on the ceiling of the alcove. But you can't tell which surface you're on because you're view remains the same. On the ceiling of the alcove you're long enough to be seen at an angle from an approaching marine, against the wall of the alcove the marine can't see you until he is literally under you and looking straight up.
Let me go to pictures (with my crappy MS paint skills) to make it clear.
<img src="http://img.photobucket.com/albums/v94/azimaith/Skulkhiding.jpg" border="0" class="linked-image" />
As you can see Skulk A is visible to the marine while Skulk B is not and won't be until the marine is much closer, but in both cases the view is identical. If the view shifted with the surface, the default view for skulk A would be upside down and parallel to the floor, while skulk B would be perpendicular to the floor, giving a definite idea of where the skulk is.
<img src="http://img.photobucket.com/albums/v94/azimaith/Skulkpipe.jpg" border="0" class="linked-image" />
In this one the green represents a jutting pipe. Red skulk is on the wall but can't tell, and is protruding quite a bit from beyond the pipe. Blue skulk is on the ceiling and is well behind the pipe, providing cover and concealment. Both almost identical views because without view shifting it's very difficult to tell how far you've moved from a wall without turning to look at it, and even then, you don't know how "close" you stick.
<img src="http://img.photobucket.com/albums/v94/azimaith/alcoveskulk.jpg" border="0" class="linked-image" />
In this red, green, and blue skulk have difficulty ascertaining where they are in relation to the grating they are attached to (similar to the once that leads from flight control) because their view doesn't change angle as they move. Green and red will be almost identical views and will only be able to tell by consciously looking to the right to see the side of the grating, and even then, may not be certain. Green would have to look down to make sure he was actually in the relative concealment of the grating.
The most basic element of a FPS has to be knowing where the character is, but without knowing what surface you're standing on you can't tell immediately. No amount of crosshair changes or gravity indicators is a match for the unmistakable shift in view angle that can come from changing surfaces.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Anyway, I don't know if you've been reading the rest of this thread, but Yuuki and Fluid Core <b>have</b> been trying to build something and get view rotation working; even I've attempted to brainstorm some ideas as to how to get it working. But the thing is, you come across as a little whiney and demanding; how about you help Yuuki and Fluid Core out with trying to make it happen, instead?<!--QuoteEnd--></div><!--QuoteEEnd-->
There's nothing whiny about pointing out the problem with not having view rotation/wall sticking/forward jumping in the game. This thread is "Let's discuss skulk movement." They haven't touched the issues with skulk wall walking since they increased wall stickiness, which is treating a symptom, not a cause. The thread mentioned skill based skulk movement by bounding off of obstacles, I pointed out bounding from wall to wall is currently impossible because of corridor width and measly lateral movement in hops and that a basis of skill based movement should not be restricted until second hive.
I suppose it's your choice to take it as whiny or demanding, but I see it as pointing out what I think are the fundamental flaws with the movement system for skulks and my reasons why. It's not intended to be whiny, and demanding is a side effect of it being about implementing an idea. One persons demanding is another persons argument.
As for helping beyond giving the argument of why it should be a particular way, you're out of luck there. I'm not a game designer nor do I understand a lot of the technical jargon you guys are throwing around, and I was never under the impression such was a prerequisite for participating in the thread. Obviously view rotation, wall clinging, view angle shifting, and lateral forward leaps are possible certain games, but I don't know whats possible in NS2 beyond what I've seen already done.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Actually, hang on, what was the purpose of this thread?<!--QuoteEnd--></div><!--QuoteEEnd-->
I was under the impression it was this: Topics: speed, air control, wall walking, jump, wall jumping, leap, as per the first line of the OP post.<u></u>
For the record, I am no game designer, nor have I read any programming languahe. The level of the contribution feom me come mainly from common sense reading the lua files and basic physics and math knowledge.
You can differentiate a slower vertical jump from a propelling leap in whatever way you want, hold shift, hold down space, bind to a different key, but it should be available regularly so you can move from surface to surface easily.
If you can't move smoothly from wall to wall, wall to ceiling, ceiling to wall, ceiling to floor, and floor to ceiling quickly and smoothly, ultimately people are just going to approach targets in a much simpler way.
Now the obvious question here would be "If the skulk jumps faster, you're basically just replacing running with jumping as a faster way to get around." This may require leaping to be sensitive to a surface you're looking at, require a longer time to "prepare" from the ground but not from walls, or any other variation if you can't simply mess with physics and just cause the skulk to feel less gravity while he's leaping (effectively meaning his trajectory is still flatter, though not due solely to velocity.)
You completely missed my point. If their jumps are faster to make them able to jump wall-wall, then they will always jump much higher then now. There will be no "jump to chest hight" anymore. Every jump from the floor you do will send you to the ceiling unless it's very high, because jumping force is independent on view direction and forward speed. How HIGH you get (away from your surface, this is the wall-wall you want) will be your normal jump. How far you get depends on your speed. If you change so that you can easier jump wall-wall, then there is no way not to jump into the ceiling with a single tap of the space bar.
Here's the other thread btw:
<a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=115601&st=0" target="_blank">http://www.unknownworlds.com/ns2/forums/in...115601&st=0</a>
That doesn't make any sense, the leap ability from hive 2 doesn't send you from floor to ceiling but propels you much farther forward. The exact mechanisms in the game aren't terribly relevant unless you want to get into a big argument about semantics, which I personally don't. If the end result is you go forward farther, that's all that's whats going to matter.
Anyway, what exactly are you proposing regarding walljumping? Or just jumping in general? If it's for walljumps to move in the direction that you're facing, that's already how it works (at least, 10 parts your forward velocity, 1 part upward jump motion). If you give him any more speed than that (i.e. in order to move in an approximately straight line), you just give him a whole lot of speed that is not limited or subsequently reduced. Basically, leap. Jump, for comparison, is a vertical motion that is naturally reduced by gravity. Or is your point that leap shouldn't cost energy or be locked at game start?
With respect to view rotation etc, your main point was, as I understand it, self- and environmental-awareness. It's a valid point, but I wonder if simply knowing how you are oriented (e.g. with a gravity indicator, or viewmodel rotation) isn't enough for players to work it out for themselves? Even just having the surface you are currently 'standing' on marked, viewable only to yourself. The problem with view rotation is that if you change direction too often, you'll lose sight of whatever it was that you actually wanted to look at (not to mention disorientation). And if we do have walljumps such that players can move really fast in practically straight lines, then you exacerbate the disorientation, particularly on impact with a surface.
I have never played AvP2, so I'm not sure how their wallwalking works. But I have played a game with switching gravity, a Source engine mod called Ballmen. Originally, naturally it was difficult to get a hang of switching your reference plane, and difficult to keep track of important things, but I eventually got used to it (to some extent) and it was really fun. But it was relative, the geometry tended to be large and predictable enough to get a feel for, and tracking enemies wasn't made too big a task; but whenever there was any particularly complex geometry, you tended to misjudge, lose your bearings, and possibly fly off into space.
Ballmen:
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/J6JtH2Gg7EA"></param><embed src="http://www.youtube.com/v/J6JtH2Gg7EA" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
Actually, this may be more relevant as a comparison with NS2, since it uses "real geometry" rather than simple blocks:
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/oWYuFLdTgKU"></param><embed src="http://www.youtube.com/v/oWYuFLdTgKU" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
Anyway, what exactly are you proposing regarding walljumping? Or just jumping in general? If it's for walljumps to move in the direction that you're facing, that's already how it works (at least, 10 parts your forward velocity, 1 part upward jump motion). If you give him any more speed than that (i.e. in order to move in an approximately straight line), you just give him a whole lot of speed that is not limited or subsequently reduced. Basically, leap. Jump, for comparison, is a vertical motion that is naturally reduced by gravity. Or is your point that leap shouldn't cost energy or be locked at game start?<!--QuoteEnd--></div><!--QuoteEEnd-->
It's that there needs to be a leap equivalent move available from the start that shouldn't cost energy if the point of skulk skill based movement is bouncing from surface to surface. The leap doesn't need to do damage or anything, it's just necessary to traverse the environment in the way asked. It also makes navigating around on walls and ceilings vastly more fluid and useful because it becomes easy to switch surfaces at the touch of a button.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->With respect to view rotation etc, your main point was, as I understand it, self- and environmental-awareness. It's a valid point, but I wonder if simply knowing how you are oriented (e.g. with a gravity indicator, or viewmodel rotation) isn't enough for players to work it out for themselves? Even just having the surface you are currently 'standing' on marked, viewable only to yourself. The problem with view rotation is that if you change direction too often, you'll lose sight of whatever it was that you actually wanted to look at (not to mention disorientation). And if we do have walljumps such that players can move really fast in practically straight lines, then you exacerbate the disorientation, particularly on impact with a surface.<!--QuoteEnd--></div><!--QuoteEEnd-->
I have a couple reasons why I don't care for gravity markers.
1: Gravity indicators don't solve the "on wall or ceiling" problem. In both cases down is in the same direction but your body is not oriented the same way.
2: In any case, when moving fast through the environment, you tend to be focused on what you're going at, not on little markers on your screen, thus you'll often miss the markers entirely when getting into combat.
3: Markers clutter up screens unnecessarily in my opinion.
View model rotation(if I'm understanding what you mean, as in the skulks mouth changes 90 degrees from floor to wall and 180 for floor to ceiling), provides more feedback but ultimately, changing your view model without changing the way your keys work is confusing. Certainly you'd eventually get over it, and it provides the same benefits of actual view rotation, but it seems different for the sake of being different. I also have a sneaking suspicious that view model rotation would cause motion sickness in some just like actual view rotation.
You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->I have never played AvP2, so I'm not sure how their wallwalking works. But I have played a game with switching gravity, a Source engine mod called Ballmen. Originally, naturally it was difficult to get a hang of switching your reference plane, and difficult to keep track of important things, but I eventually got used to it (to some extent) and it was really fun. But it was relative, the geometry tended to be large and predictable enough to get a feel for, and tracking enemies wasn't made too big a task; but whenever there was any particularly complex geometry, you tended to misjudge, lose your bearings, and possibly fly off into space.
Ballmen:
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/J6JtH2Gg7EA"></param><embed src="http://www.youtube.com/v/J6JtH2Gg7EA" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center>
Actually, this may be more relevant as a comparison with NS2, since it uses "real geometry" rather than simple blocks:
<center><object width="450" height="356"><param name="movie" value="http://www.youtube.com/v/oWYuFLdTgKU"></param><embed src="http://www.youtube.com/v/oWYuFLdTgKU" type="application/x-shockwave-flash" width="450" height="356"></embed></object></center><!--QuoteEnd--></div><!--QuoteEEnd-->
AvP2 definitely had you sticking to surfaces because there was a serious bug going down stairs where you'd walk on every surface of the stairs when wall walking. IE you'd go from the top of the stairs, to the vertical portion, to the top again, meaning you were very slow and the view jumped around crazily. A better example of good wall walking is AvP2010 (which had no stair issue.) The issues in that game had nothing to do with alien wall walking ability which is extremely smooth and something I don't recall ever getting stuck in. Would it help if I posted a video of wall walking in it with FRAPS? There is definitely complex geometry in AvP2010, but it's not exactly the same as NS2. NS2's map design has never struck me as being made with wall waking in mind. It has lot's of jutting ceiling pipes and other obstacles you can't get over well simply because the wall walking system isn't 100% sticky. I'll have to break out AVP2010 and mess around with the maps to see comparisons.
Some things I do remember from AvP2010 right off the top of my head.
1: There is a height threshold for wall walking disturbances. Objects that are small like lights, small protrusions, door frames, don't disturb wall walking. You can basically just go around them with no issue. This would indicate to me the these obstacles also need to be under a certain height from the wall surface to work this way.
2: The rotation of view is smooth, not rigid, if you walk in the seam of the corner and wall you're view shifts only part way.
3: Wall stickiness is 100%. You could never fall off a wall due to looking in a direction no matter how fast you moved. You could only detach voluntarily or be knocked off by certain attacks.
Fair enough, your use of jumping and hoping made it unclear what it was you meant it as a different feature or mode of jumping.
<!--quoteo(post=1896358:date=Jan 21 2012, 12:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 12:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.<!--QuoteEnd--></div><!--QuoteEEnd-->
Never noticed that option myself, was it in settings or a mod? That's how I think it should be anyhow. Add it so that you can't walk off a surface: you only leave it by jumping, leaping or pressing crouch, and you're set to get around corners easily too.
Looking at Ballman, from what I can tell it behaves exactely like how I have played AvP2. As azimaith said above, that doesn't have to be like that, and I think it would add less motion sickness to have it in. Running forward and aiming for a wall and jumping into it, sticking htere, you would still aim at the wall then, tho it would have rotated 90 degree, and not at the same angle from the wall as you were from the floor.
Not anymore, now you've got this speed storage system that gives you a forward bonus, but it doesn't really work so you mainly jump along the wall normal.
I agree with azimaith, the jump range should allow you to reach different surface on the map. The map becomes much more interesting when you can really use it.
Ideally the skulk should be as agile as possible, the only constrain we have to take into consideration is that the marines should be able to track his movement and shoot him.
Something I have noticed from time to time (I tried to practice some wall-jumping right now), is that if you jump wall-floor-wall, and the jump from the floor is to close to the second wall, then you will not attach to the wall and just fall down to the floor, effectively breaking any timing and speed you had acquired. I think this has something to do with the delay that turns of your stickiness to prevent you from jumping multiple times from the same wall in the same motion. You can also observe this by running towards a wall and jumping right before you reach it.
Yeah, I agree. How, though?
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I have a couple reasons why I don't care for gravity markers.
1: Gravity indicators don't solve the "on wall or ceiling" problem. In both cases down is in the same direction but your body is not oriented the same way.
2: In any case, when moving fast through the environment, you tend to be focused on what you're going at, not on little markers on your screen, thus you'll often miss the markers entirely when getting into combat.
3: Markers clutter up screens unnecessarily in my opinion.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah, I guess so. But what about a simple marker (I just call it a marker, maybe you could call it a decal) which, when you look "down" (i.e. you look at the surface that you are currently attached to), there would be some indication of which surface you are currently attached to.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->View model rotation(if I'm understanding what you mean, as in the skulks mouth changes 90 degrees from floor to wall and 180 for floor to ceiling), provides more feedback but ultimately, changing your view model without changing the way your keys work is confusing. Certainly you'd eventually get over it, and it provides the same benefits of actual view rotation, but it seems different for the sake of being different. I also have a sneaking suspicious that view model rotation would cause motion sickness in some just like actual view rotation.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah, that's what I mean. Essentially it wouldn't change the system at all from what it is now, it would just give you an indication of the orientation of your player model. I think that the biggest issue is with walls where you are rotated 90 degrees and strafing. Essentially you can't strafe into a wall, so if you are on a "right wall", strafing up you press right, and strafing down you press left; then when you're on a "left wall", strafing down you press left, strafing up you press right - it isn't very intuitive. Ceilings aren't such an issue, move right = press right, move left = press left. The reason, I suspect, that they have the system this way is because the skulk is spending more time in the air (or on the ground) than actually on the walls; therefore you need very easy transitions between floor to 'space', wall to 'space', and ceiling to 'space': by keeping the view oriented "normally", you get to keep the skulk's reactivity and "air-based" manoeuvrability. For example, how does a skulk transition from ceiling to floor? In the game, you snap from upside down to right way up when you detach from the ceiling. In reality, a creature might flip or roll in mid-air to re-orient itself correctly. Currently the game sidesteps the issue by snapping the player model in 3rd person and keeping the "normal" view for the player in 1st person. With view rotation, it wouldn't work that way, since your frame of reference doesn't change, you would fall upside down and land on your back. That would be problematic. It makes me think we need almost a six degrees of freedom movement model for the skulk... at the very least we would need an option to roll in mid-air. Unless you use the same trickery and snap from upside down, detaching from the ceiling, to right way up while in mid-air. But then how do you deal with jumps from walls to ceiling? It would be pretty weird to be forced the right way up while jumping off a wall, then forced upside down once you hit the ceiling, rather than just rotating 90 degrees.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not sure what you mean here.
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->AvP2 definitely had you sticking to surfaces because there was a serious bug going down stairs where you'd walk on every surface of the stairs when wall walking. IE you'd go from the top of the stairs, to the vertical portion, to the top again, meaning you were very slow and the view jumped around crazily. A better example of good wall walking is AvP2010 (which had no stair issue.) The issues in that game had nothing to do with alien wall walking ability which is extremely smooth and something I don't recall ever getting stuck in. Would it help if I posted a video of wall walking in it with FRAPS? There is definitely complex geometry in AvP2010, but it's not exactly the same as NS2. NS2's map design has never struck me as being made with wall waking in mind. It has lot's of jutting ceiling pipes and other obstacles you can't get over well simply because the wall walking system isn't 100% sticky. I'll have to break out AVP2010 and mess around with the maps to see comparisons.<!--QuoteEnd--></div><!--QuoteEEnd-->
So you think it basically worked on the principle of shifting gravity?
<!--quoteo(post=1896358:date=Jan 21 2012, 07:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 07:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Some things I do remember from AvP2010 right off the top of my head.
1: There is a height threshold for wall walking disturbances. Objects that are small like lights, small protrusions, door frames, don't disturb wall walking. You can basically just go around them with no issue. This would indicate to me the these obstacles also need to be under a certain height from the wall surface to work this way.
2: The rotation of view is smooth, not rigid, if you walk in the seam of the corner and wall you're view shifts only part way.
3: Wall stickiness is 100%. You could never fall off a wall due to looking in a direction no matter how fast you moved. You could only detach voluntarily or be knocked off by certain attacks.<!--QuoteEnd--></div><!--QuoteEEnd-->
1 and 3 I think are necessary, and the skulk could benefit from this.
By 2, do you mean that you could, for example, rotate only 45 degrees if there were a surface oriented like that, rather than be in "three" states (floor, wall, ceiling)?
@Yuuki: I agree, but, how do we do it?
The problem is that, if you sit in a wall-wall-ceiling corner for example, you would need to look at all the three surfaces to notice wich one is highlighted. If your view rotated, you would know right away, as that surface would be the new down.
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think that the biggest issue is with walls where you are rotated 90 degrees and strafing. Essentially you can't strafe into a wall, so if you are on a "right wall", strafing up you press right, and strafing down you press left; then when you're on a "left wall", strafing down you press left, strafing up you press right - it isn't very intuitive. Ceilings aren't such an issue, move right = press right, move left = press left.<!--QuoteEnd--></div><!--QuoteEEnd-->
If the view doesn't rotate, and the wall is sloped, then you strafe (slower) in the direction you strafe (assuming you stick). So if the hallway is wider at the ceiling then the floor, being on a "right" wall, strafing right makes you go up, and strafing left makes you go down. If your view would rotate so that the wall is orientated as if it was a floor instead (like I want it) then pressing right makes you go right on the wall, and pressing left makes you go left on the wall (like if you were on a floor - intuitive)
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->For example, how does a skulk transition from ceiling to floor? In the game, you snap from upside down to right way up when you detach from the ceiling. In reality, a creature might flip or roll in mid-air to re-orient itself correctly. Currently the game sidesteps the issue by snapping the player model in 3rd person and keeping the "normal" view for the player in 1st person. With view rotation, it wouldn't work that way, since your frame of reference doesn't change, you would fall upside down and land on your back. That would be problematic. It makes me think we need almost a six degrees of freedom movement model for the skulk... at the very least we would need an option to roll in mid-air. Unless you use the same trickery and snap from upside down, detaching from the ceiling, to right way up while in mid-air. But then how do you deal with jumps from walls to ceiling? It would be pretty weird to be forced the right way up while jumping off a wall, then forced upside down once you hit the ceiling, rather than just rotating 90 degrees.<!--QuoteEnd--></div><!--QuoteEEnd-->
The game should be able to predict where you land, and when you will, and start rotating your view to that orientation (the least angle change) over the time. If with air control you change the prediction to another surface that changes this orientation, then the view should start to change to that. Might be code heavy though.
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec--><!--quoteo(post=1896358:date=Jan 21 2012, 12:18 PM:name=azimaith)--><div class='quotetop'>QUOTE (azimaith @ Jan 21 2012, 12:18 PM) <a href="index.php?act=findpost&pid=1896358"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->
You can also always just not change the point of view when meeting a new surface, merely the orientation. IE if you go from ceiling to wall looking at a crate, you're now viewing the crate at a different rotation, but still looking at it. They did this as an option in AvP2 and it helped maintain sight on targets, but it also meant you'd be slower around corners.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'm not sure what you mean here.
<!--QuoteEnd--></div><!--QuoteEEnd-->
If you look at the video from BallMan, you notice that where you aim changes while you change surface. If the view just rotates instead, then you will aim at the same point but the orientation will have rotated.
<!--quoteo(post=1896383:date=Jan 21 2012, 02:52 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 02:52 PM) <a href="index.php?act=findpost&pid=1896383"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->By 2, do you mean that you could, for example, rotate only 45 degrees if there were a surface oriented like that, rather than be in "three" states (floor, wall, ceiling)?<!--QuoteEnd--></div><!--QuoteEEnd-->
Allow me to answer this. Yes, it means that there aren't any "states". The specific point here, I think, is that the game doesn't have to choose between floor or ceiling however, it sets the orientation to "floor+ceiling" and rotate the view to the combination of their normals. I haven't played AvP2010 myself, only AvP2, but that's what I would read the point as, and an improvement I personally would have liked to see in AvP2.
I know, but I don't see that as a problem.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If the view doesn't rotate, and the wall is sloped, then you strafe (slower) in the direction you strafe (assuming you stick). So if the hallway is wider at the ceiling then the floor, being on a "right" wall, strafing right makes you go up, and strafing left makes you go down. If your view would rotate so that the wall is orientated as if it was a floor instead (like I want it) then pressing right makes you go right on the wall, and pressing left makes you go left on the wall (like if you were on a floor - intuitive)<!--QuoteEnd--></div><!--QuoteEEnd-->
You're right, that just seems clunky and useless... that's certainly an area for improvement.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The game should be able to predict where you land, and when you will, and start rotating your view to that orientation (the least angle change) over the time. If with air control you change the prediction to another surface that changes this orientation, then the view should start to change to that. Might be code heavy though.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah, but air control makes this fairly impossible.
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If you look at the video from BallMan, you notice that where you aim changes while you change surface. If the view just rotates instead, then you will aim at the same point but the orientation will have rotated.<!--QuoteEnd--></div><!--QuoteEEnd-->
Still hard to visualise (the latter, not the former), is there a video?
<!--quoteo(post=1896395:date=Jan 21 2012, 10:41 PM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 21 2012, 10:41 PM) <a href="index.php?act=findpost&pid=1896395"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Allow me to answer this. Yes, it means that there aren't any "states". The specific point here, I think, is that the game doesn't have to choose between floor or ceiling however, it sets the orientation to "floor+ceiling" and rotate the view to the combination of their normals. I haven't played AvP2010 myself, only AvP2, but that's what I would read the point as, and an improvement I personally would have liked to see in AvP2.<!--QuoteEnd--></div><!--QuoteEEnd-->
You've been answering them all. :P
As we discussed earlier in this thread, being able to override gravity (when attached to a surface) and switching it to a vector that acts in the opposite direction to skulk.wallWalkNormal would be ideal, and would most likely work exactly in this way.
Not that I could find. You can try it yourself by an easy mod to your Skulk_Client.lua file.
Change
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Skulk.kCameraRollTiltModifier =0.05<!--c2--></div><!--ec2-->
to
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Skulk.kCameraRollTiltModifier = 1<!--c2--></div><!--ec2-->
There's no use trying to play with it though, it's only the view that changes, your pitch, yaw and imputs still relates to "floor" mode.
<!--quoteo(post=1896406:date=Jan 21 2012, 05:25 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 21 2012, 05:25 PM) <a href="index.php?act=findpost&pid=1896406"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->You've been answering them all. :P
As we discussed earlier in this thread, being able to override gravity (when attached to a surface) and switching it to a vector that acts in the opposite direction to skulk.wallWalkNormal would be ideal, and would most likely work exactly in this way.<!--QuoteEnd--></div><!--QuoteEEnd-->
Well, that one was specificly for someone else...
I've been trying to change a bit the way the wall detection/attachment is done, I replaced the 8 circular vectors by something that adapt more to the skulk model, it looks a bit like his legs :
<img src="http://i.imgur.com/iSoQK.png" border="0" class="linked-image" />
<img src="http://i.imgur.com/vJmsd.png" border="0" class="linked-image" />
It works pretty well (it's in the file in my first post) but has some specific problems, for example it's sometimes hard to attach to the ceiling, because the "legs" are all pointing downwards. Maybe make then dependent on velocity would help, I don't know.
About the gravity, there is already something very similar, when you're attached to a wall, within a certain range, there is a force that make you stick to the wall (wallWalkingStickGoal is the wall normal) :
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->// Move towards the stick goal if there is a stick goal.
if self.wallWalkingStickEnabled and self.wallWalkingStickGoal then
self:PerformMovement(-self.wallWalkingStickGoal * (time * 2), 1, nil)
end<!--QuoteEnd--></div><!--QuoteEEnd-->
I will have a look at the strafing, maybe it's not too hard to do.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The game should be able to predict where you land, and when you will, and start rotating your view to that orientation (the least angle change) over the time. If with air control you change the prediction to another surface that changes this orientation, then the view should start to change to that. Might be code heavy though.<!--QuoteEnd--></div><!--QuoteEEnd-->
You can probably throw a vector in the predicted landing zone (more of less in the velocity direction I guess) and get the surface orientation this way, shouldn't be too hard.
RE: the gravity, I think the issue is more about fundamentally changing how the skulk operates, so it may involve looking at the general player code, the general alien code, maybe the game world code, etc. We're talking about getting full view rotation here right?
I mean you have to change:
The reference plane (using surface-normal, switching gravity); the perspective (view rotation); and the movement and input.
RE: predicted landing zone, throwing a vector (maybe like hitscan, determining the surface-normal at the "landing point") could work, but it wouldn't account for the ballistic trajectory (and air control would be impossible to account for), and it would be problematic when your landing point is at corners for instance - your predicted orientation is like so, but a second after landing your orientation would have to change to match your actual landing surface.
Seeing as much of this is server-side, I don't see how it could be a client-side option. I think it would have to be one or the other.
I'm not sure if it's what you mean but it's 3D vectors yes. It works like you said "throwing a vector (maybe like hitscan, determining the surface-normal at the "landing point")", just that the hitscan has a finite range (length of the vector).
We can arrange the vectors like we want, and put as many as we want (at computational cost or course).
One of the advantage of the original (the circle) is that it's invariant, so it perform equally in all situations. One of the disadvantage is that it's not very smart, sometimes like in the screenshot above you got a vector that is inside the skulk body and therefor has little chances to hit anything.
I wouldn't say my version is better, it's more or less the same I think from the point of view of the feeling, it's ok but not very good.
But if you imagine yourself running and try to jump on a wall (try it!) wouldn't you throw you're arms and legs in front of you, in the direction of your velocity ?
Another view :
<img src="http://i.imgur.com/JDRTE.png" border="0" class="linked-image" />
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->We're talking about getting full view rotation here right?<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes and no, the full rotation would be optional anyway, so I'm thinking about both cases. Switching gravity all the time would be a bit ridiculous, can you imagine skulk flying up and down, left and right in a room ? In the current version "gravity" (wall sticking) is switched only close to the wall and is reverse to normal vertical gravity when you detach from the wall.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->predicted landing zone<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, but compared to the current situation (do nothing) it can only be better, or maybe much worse ^^'
The idea with gravity is to make walking around not feel like you jo-jo from and to the wall if it is uneven. Compare it to walking on the floor, that never feel like you bounce up and down. The distance shoulden't matter, but you could not get far enough from the wall so that you would get skulks flying across the room and break immersion. With gravity approach and view rotation, you couldn't walk of the wall, and if you leap/jump/crouch your gravity would reverse to normal and you would fall towards the floor.
We can arrange the vectors like we want, and put as many as we want (at computational cost or course).<!--QuoteEnd--></div><!--QuoteEEnd-->
That's what I meant by 3D, yes. From the image you posted of the original, it looked like it was circular in a 2D plane.
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->One of the advantage of the original (the circle) is that it's invariant, so it perform equally in all situations. One of the disadvantage is that it's not very smart, sometimes like in the screenshot above you got a vector that is inside the skulk body and therefor has little chances to hit anything.
I wouldn't say my version is better, it's more or less the same I think from the point of view of the feeling, it's ok but not very good.
But if you imagine yourself running and try to jump on a wall (try it!) wouldn't you throw you're arms and legs in front of you, in the direction of your velocity ?
Another view :
<img src="http://i.imgur.com/JDRTE.png" border="0" class="linked-image" /><!--QuoteEnd--></div><!--QuoteEEnd-->
So, dynamic wall-detectors, essentially? I'm not sure about having it change with velocity, perhaps having it change if you're in mid-air would be better?
From your implementation, it looks like it could be problematic or an improvement with corners, with the current wallwalking and an improved wallwalking, respectively. Essentially, at corners you would have rays hitting different surfaces, so which surface should you actually be on? However, you could actually turn this beneficial if you made it a smooth transition between the two. The planar version is more binary: you are on this surface, your feeler hits that surface, you are now on that surface. However, the planar version might suffer from the same issue when in a particularly claustrophobic space (e.g. travelling along a vent you have wall-detectors hitting the insides of the vent on both sides). Also the planar version doesn't actually have to calculate which surface to stick to while you're actually on the surface since it is parallel to the surface - you could probably achieve the same with a three-dimensional version by limiting the range of the 'feelers', such that they don't quite reach the surface, ordinarily. Please correct me if I'm misunderstanding something about the current wallwalking system.
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yes and no, the full rotation would be optional anyway, so I'm thinking about both cases. Switching gravity all the time would be a bit ridiculous, can you imagine skulk flying up and down, left and right in a room ? In the current version "gravity" (wall sticking) is switched only close to the wall and is reverse to normal vertical gravity when you detach from the wall.<!--QuoteEnd--></div><!--QuoteEEnd-->
I don't think it could be optional (as in optional between current skulk and proposed skulk) since the changes would mostly be server-side, and the proposed skulk would change the mechanics of the skulk at a fundamental level. It would, essentially, be two different skulks.
Regarding gravity, what I'm actually proposing is that this new "personal gravity" only applies when you're actually on (or <b>very near</b>) a surface - the moment you leave any surface (i.e. are in mid-air), your personal gravity is reset to world gravity. The reason I'm proposing switching gravity (as opposed to the current implementation of a sticking force) is that I want to switch the player's "reference plane" (see the Ballmen video) - this could possibly (ostensibly) allow us to achieve view rotation AND a proper movement scheme (i.e. your view and your movement are relative to your personal gravity, which is dependent on the surface normal, i.e. they are relative to the surface you are on).
<!--quoteo(post=1896691:date=Jan 23 2012, 03:33 AM:name=Yuuki)--><div class='quotetop'>QUOTE (Yuuki @ Jan 23 2012, 03:33 AM) <a href="index.php?act=findpost&pid=1896691"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yes, but compared to the current situation (do nothing) it can only be better, or maybe much worse ^^'<!--QuoteEnd--></div><!--QuoteEEnd-->
The thing is, the current situation (no view rotation) simply sidesteps the issue for the player: no view rotation means no real need to calculate mid-air "transitions" (I don't know about the third-person game world model however - that could benefit aesthetically).
So the suggestion about landing surface prediction was really only for full view rotation.
Another possibility is to give the player control over their <a href="http://en.wikipedia.org/wiki/Flight_dynamics_(aircraft)" target="_blank">roll</a> while in mid-air (mouse-look already gives them control over their yaw and pitch).
...
The idea with gravity is to make walking around not feel like you jo-jo from and to the wall if it is uneven. Compare it to walking on the floor, that never feel like you bounce up and down. The distance shoulden't matter, but you could not get far enough from the wall so that you would get skulks flying across the room and break immersion. With gravity approach and view rotation, you couldn't walk of the wall, and if you leap/jump/crouch your gravity would reverse to normal and you would fall towards the floor.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yeah, exactly. I hadn't read your post before I replied to Yuuki's so I didn't realise you'd already beat me to a reply.
<!--quoteo(post=1896706:date=Jan 23 2012, 05:19 AM:name=Fluid Core)--><div class='quotetop'>QUOTE (Fluid Core @ Jan 23 2012, 05:19 AM) <a href="index.php?act=findpost&pid=1896706"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What might need tweaking is to make the view rotation just rotate so that you keep aiming at the same point when you change rotation and doesn't move your mouse.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think this could be quite difficult; at least I don't understand, conceptually, how you might achieve this. What exactly constitutes "the same point"? Actually, now that I think of it - upon changing a surface (i.e. reference plane), your viewing direction (that is, essentially, player:GetViewAngles():GetCoords().zAxis) could simply be preserved. The actual orientation of your view (your "roll") would then depend on your <u>viewing direction</u> and your <u>surface orientation</u>... the orientation of your model, perhaps. This would be beneficial for maintaining orientation and being able to track targets, but this could actually be problematic as well, because... well let me illustrate it:
<img src="http://i.imgur.com/GmANf.png" border="0" class="linked-image" />
Red is the player's trajectory.
Coloured arrows represent the player's view direction. This is a side-on view and I'm assuming that the player moves in the direction of their view, like a leap.
So basically the player has to move their mouse "up" every time, and this would be cumulative. Essentially this is, I think, what azimaith was describing as the second option in AVP2 - it makes moving around a little slower and more cumbersome, but lets you track targets more easily.
If we made the game move the viewing direction along with your reference plane, movement would be easier but with perhaps a greater chance of getting disoriented (though I believe you would get used to it, as I got used to playing Ballmen) and more difficulty in tracking targets.
Ideally, we would somehow give the player the ability to use both options in-game at will.
Well in the current implementation if several traces hit a wall, you simply take the average of the wall normals. So in my version if you have two legs on the ground and two legs on the wall you actually get a 45 degree angle.
I should mention that in the vanilla version there is also a trace above (vertical in the game reference) and bellow the skulk in addition to the circle. The trace bellow has also priority over the others, so if it hits you just return this normal instead of doing the average.
Taking the average is good I think, because if you have a very convoluted surface, it smooths out a bit the details.
There is also a trade off between stickying strongly to the current surface and being able to transition smoothly to another one. At first I though: "this is stupid! why not do a trace in the direction of the past wall normal, this is the most likely direction to find the wall again". It works well, you stick strongly to the wall, but it's pretty much impossible to transition to another wall.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The thing is, the current situation (no view rotation) simply sidesteps the issue for the player: no view rotation means no real need to calculate mid-air "transitions" (I don't know about the third-person game world model however - that could benefit aesthetically).<!--QuoteEnd--></div><!--QuoteEEnd-->
Well the third-person game world model is important for marines, because it's what you shoot at ! It should be smooth and predictable as possible, so the marines can track a skulk even if he's very agile (which is what we want).
Also the model rotation and the view are linked, they should be the same actually in the full view rotation model, and almost the same in the "zero roll view model" (current one).
Given :
- The three angles of the camera: <b>(pitch, yaw, roll)</b>
- The wall normal: <b>n</b>
- Two mouse input angles: <b>input.yaw</b> and <b>input.pitch</b>
Write an expression for <b>(pitch, yaw, roll)=f(n,input.yaw,input.pitch)</b>.
Note that n = n(t) and that df / dn should be smartly chosen (i.e. you don't want changes in the wall normal to make crazy changes in the camera angles).