Conveying A Sense Of Weight And Movement Options

[Ishtvan]

You should really try the Oblivion grabbing, it works well for the whole moving/turning situation you just described. No can of worms. There is just a small lag with the larger items, no "waiting around" or anything, and they have a max speed of movement, so if you turn real fast you'll lose it, whereas a small item can be whipped around quick and tossed far.

There's no demo of Oblivion out is there? Otherwise I would be happy to try it out.

 

Is dropping the item when you turn around too fast how they avoid the problem of having the item go through the camera when you do a quick 180? I'm not sure I like turning real fast and losing stuff either. In a stealth game, AI will hear that item dropping to the floor and you could get into a very bad situation just because you turned your view around too quickly.

 

Also, some things you can't lift up off the ground, but just drag along the ground, because they are too heavy. Bodies were this way, but they could be adjusted to be liftable, or perhaps dragging is all we wanted anyway.

Yeah, we were planning to do that also with bodies. Would be nice to know how they did that. We'll also have an option to shoulder them.

[Nyarlathotep]

Personally, I'd like to see something similar to Oblivion, but not quite as annoying. Oblivion had issues with your character letting go too soon. I would prefer it work a bit more like this:

 

Your character has a grip point positioned at the center of the screen. This point defaults to half an arm's length from the character, but can extend to a full arm's length at pick up time (or contract to a quarter arm length). The point is "floating" point, allowed to stray 170 degrees (total: 340) from the center in any direction. To pick up objects, you attach this grip point to the object, and the point is assigned an appropriate amount of force in the direction of its default position.

 

Accidental dropping of the object can be handled by assigning the point an amount of gripping force--the amount of force to be exceeded before the character lets go (arguably entirely separate from the force assigned to bring it to bear). This can be modified by a friction coefficient, enabling it to be potentially more realistic (at the expense of potentially feeling less natural). The point is never allowed to exceed the maximum length, nor allowed to precess from the center of the screen more than the allotted 170 degrees. If the grip force is exceeded to maintain the position of the point, the character is prevent from moving the point further. This manifests in three ways: one, the character cannot move his screen faster than a certain velocity in that direction, two, the character is blocked from further turning his screen (the object has been obstructed), or three, the character is slowed down (more so than usual).

 

Of course, this does raise the question of how you plan to handle distinguishing between picking up items, dragging them, throwing them, dropping them, or using them.

[Ishtvan]

If it's obstructed and you let it deviate 170 degrees from the center, it is essentially behind the player. What happens if the player steps to the side and there's now a clear path from the item's position behind the player to the front of the player where the hands are? Does it move straight through the player and clip the camera? Or does it move in a circular arc around the player?

 

Btw, stopping the player's screen from moving all of a sudden is very jarring IMO. It actually started to give me motion sickness when I was testing out some stuff for leaning and turning. UT Infiltration did this with the weapon when your weapon bumped into something, but it was rather annoying, especially since IRL you can hold things closer to you and turn around if you have to, you don't have rigid pipe arms.

 

Of course, this does raise the question of how you plan to handle distinguishing between picking up items, dragging them, throwing them, dropping them, or using them.

There's no distinction between the first four, they all happen from the same mode of manipulating items in your hands. The last one happens when they're in the inventory and you hit use item. You'll be able to put items in your inventory or drop them into your "hands".

[Nyarlathotep]

The grip point can't go closer than about a quarter arm-length to the player, so it would have to go in a circular motion. As for stopping, the object is allowed to rotate around the grip point, so it wouldn't be as hard a stop. Furthermore, I was taking into account the fact that most physics simulators have discreet time steps (both in collision and in simulation) and would produce a shake effect naturally when the limit is reached. Alternatively, you could fix the issue by providing an amount of jerk to the screen, allowing it to extend a little past 170 degrees (by no more than about 5 degrees), and have the screen oscillate between 175 and 165 degrees with a strong dampening (lasting no more than, say, half a second).

 

Perhaps I should be more specific about what I'm asking to do with manipulation. Items in TDM can be in three positions where they can be manipulated: in the environment, being held by you, or in your inventory.

 

In the environment, you can use items, grab them (both picking up and dragging), or put them in your inventory. While being held by you, you can (potentially) use them, throw them, drop them, drag them, or place them in your inventory. In your inventory, you can use items, sort through them, drop them, throw them, or move them into your hands. Not all of these are useful or desired, and many of them can overlap (programmers: overload) their functions.

 

Obviously, you can't do all of this with a single button, nor would you want to. (Thief uses four buttons: two to shuffle inventory, one to use, grab, and throw, and one to drop items.) My question is what buttons are you using, and what functions do they enable? You have repeatedly described incidences where multiple functionality is desired (dragging and shouldering bodies), but you have given us no (clear) idea on how you intend to implement this (as least as far as my search concluded). My problem is that you've blithely covered a whole host of special cases in an uninforming way. I'm sure you've thought most of this out, of course.

[Ishtvan]

In the environment, you can use items, grab them (both picking up and dragging), or put them in your inventory. While being held by you, you can (potentially) use them, throw them, drop them, drag them, or place them in your inventory. In your inventory, you can use items, sort through them, drop them, throw them, or move them into your hands. Not all of these are useful or desired, and many of them can overlap (programmers: overload) their functions.

This system is still a work in progress.

 

I don't read much overlap in the things you just listed. It sounds like you've already compartmentalized it pretty well. In the inventory, you can sort through many inventory items, "use" certain items, or drop them into your hands. From your hands, you can drop it to the ground, throw it, or move it around in ways that interact with the environment: (e.g., drag things that are attached to it with AF constraints: bodies, ropes, using a broom handle to push a button you couldn't otherwise reach, building an anchor for a rope arrow, etc), or put it back in the inventory (exactly what controls are used to put it back into the inventory are still being debated. I've suggested hitting "use item", to put the item in your hands back in the inventory, but one could argue that you could accidentally hit it twice and use up an item you didn't want to, or what if you want to use an inventory item on an item you're holding, etc).

 

There will also be junk objects that can't go in the inventory. These can still be picked up and placed in the hands, thrown as a distraction, etc. Where the design gets fuzzy is that we've also talked about "using" some of these items in some fashion. That's still very WIP though.

 

Finally, once a physical object is out in the environment, you can either bump into it and move it in your standard FPS way, smash other objects into it, or pick it up by frobbing it. (We had talked about dragging heavier objects that are too heavy to go into the hands, but that's pretty low priority at the moment).

 

As for stopping, the object is allowed to rotate around the grip point, so it wouldn't be as hard a stop. Furthermore, I was taking into account the fact that most physics simulators have discreet time steps (both in collision and in simulation) and would produce a shake effect naturally when the limit is reached. Alternatively, you could fix the issue by providing an amount of jerk to the screen, allowing it to extend a little past 170 degrees (by no more than about 5 degrees), and have the screen oscillate between 175 and 165 degrees with a strong dampening (lasting no more than, say, half a second).

I don't think any of those cosmetic changes would make it any less jarring. Bottom line is, you're holding a crate in a narrow hallway, you try to turn around, and *clunk*, your view rotation doesn't go where you want it to go.

 

We'll certainly have to do something in this situation, and they all have pros and cons. Auto-dropping the object, risks alerting AI unintentionally, but stopping the view rotation dead in its tracks is not very appealing either. I think I might prefer auto-dropping if you turn too far past an object. Stopping the view turn when the object hits something, in a game with no depth perception and an inability to manuever things around your body would just make it feel very awkard for me.

 

The grip point can't go closer than about a quarter arm-length to the player, so it would have to go in a circular motion.

Something bugs me about how that would actually work in practice. I can't quite put my finger on it, but it seems like there would be problems. For example, how does the object know which side to move around? You might say always take the shortest angular difference, but what if that side was occluded and the other side was not? How would the system know when to switch the direction and bring it around in an arc the other way? And what if the player is already busted because the system chose the wrong arc direction and slammed it into another wall making, a loud noise?

 

I think it might be simpler just to keep it to a linear motion to the point right in front of you, but don't let the player turn more than 90 degrees or so away from a stuck object without dropping it.

 

Then there's the issue of what happens if the player tries to walk away from a "stuck" object? Do you prevent them from walking, or do you drop the object? It seems like that's what it comes down to in most of these situations: Either prevent the player from making the motion that they want but maintain a grip on the object, or let the player move but auto-drop the object.

 

I think it was Springheel who came up with a hybrid system: You initially stop their motion, maybe shaking the view a bit like you said, but if they keep trying to move in the same way for some amount of time, drop the object. That way, if they're in a panic, they can still drop the object without reaching for any extra keys, but if they don't want to drop the object, they get some warning that they're about to drop it if they keep trying to move farther.

[Nyarlathotep]

This system is still a work in progress.

Good. I'd like to help.

 

I don't read much overlap in the things you just listed. It sounds like you've already compartmentalized it pretty well. In the inventory, you can sort through many inventory items, "use" certain items, or drop them into your hands. From your hands, you can drop it to the ground, throw it, or move it around in ways that interact with the environment: (e.g., drag things that are attached to it with AF constraints: bodies, ropes, using a broom handle to push a button you couldn't otherwise reach, building an anchor for a rope arrow, etc), or put it back in the inventory (exactly what controls are used to put it back into the inventory are still being debated. I've suggested hitting "use item", to put the item in your hands back in the inventory, but one could argue that you could accidentally hit it twice and use up an item you didn't want to, or what if you want to use an inventory item on an item you're holding, etc).

 

There will also be junk objects that can't go in the inventory. These can still be picked up and placed in the hands, thrown as a distraction, etc. Where the design gets fuzzy is that we've also talked about "using" some of these items in some fashion. That's still very WIP though.

 

Finally, once a physical object is out in the environment, you can either bump into it and move it in your standard FPS way, smash other objects into it, or pick it up by frobbing it. (We had talked about dragging heavier objects that are too heavy to go into the hands, but that's pretty low priority at the moment).

The overloading happens at the player controls. You don't want to have a separate key for each and every function, especially if you have multiple keys to do the exact same thing in the different environments. On the other hand, you do want sufficient fidelity to keep players from being unable to do what they intended.

 

Let's look at an example in Half-Life 2. Do you remember that little hula girl toy in Kleiner's lab? No?

 

 

Thank you, Imageshack! In HL2, there are two versions of that little hula girl. The first is the one shown in that image, and the second is encountered later on. Visually, the two items are the same, so why are there two versions? Simple. In HL2, you use the 'use' button to both use items and pick them up (read: 'use' is overloaded). However, you can't do both to the same object; after all, how the hell would the game be able to distinguish between the two actions? Because of this, there are two versions: one to rigidly lock to a table (but it dances!), and the other, broken dancer, to be tossed about by a player that has already lost interest in the gimmick of being able to pick random shit up and throw it. Both hula girls use the same model--this isn't variety; it's broken! The player loses fidelity in his/her actions because of an overly limited game play mechanic.

 

On the other end of the spectrum, are games like Die By the Sword and Trespasser, where the developer uses an overly complex mechanism that is utterly incomprehensible to the average player and difficult to use by the hardcore gamer, not to mention much more prone to game-breaking bugs (Trespasser's much derided arm-flail). The only real solution is to use a much more intuitive interface (such as with the Wii) or use a more simplified control schema.

 

In the environment, you have use, grab, and drag available to the player at any time, and theoretically any object. Doom 3 actually provides one solution (which is admittedly not applicable to TDM in a general manner). D3 overloads the player's ability to shoot with the ability to use GUI's and talk to people. Whenever you are close enough to talk or use a panel, you probably don't intend to shoot, and vice versa. Thus, what would ordinarily be the use key ('e', 'f', or the right mouse button) can instead become a grab function (which itself could be overloaded).

 

Another solution, more appropriate to TDM, is to overload the same use key, such as distinguishing between a mouse click and a held mouse button. Holding the mouse button would always pick up or drag an object. However, clicking it would perform whatever use function the item has (use, add to inventory/loot, shoulder, open/close, or pick up in the case of random objects). The disadvantage is that it could limit the player's ability to throw items to those that are picked up normally by the use key (although the left mouse button could still be used to throw). The plus side is that dragging by holding the mouse button could be used to provide potentially new functions, such as being able to slowly crack open doors or slide open drawers. While it doesn't solve the problems with inventory management, it does solve the above problem.

 

I don't think any of those cosmetic changes would make it any less jarring. Bottom line is, you're holding a crate in a narrow hallway, you try to turn around, and *clunk*, your view rotation doesn't go where you want it to go.

 

We'll certainly have to do something in this situation, and they all have pros and cons. Auto-dropping the object, risks alerting AI unintentionally, but stopping the view rotation dead in its tracks is not very appealing either. I think I might prefer auto-dropping if you turn too far past an object. Stopping the view turn when the object hits something, in a game with no depth perception and an inability to manuever things around your body would just make it feel very awkard for me.

The idea behind your grip having a specific amount of force that it can apply is so that a player has to be more careful in his movements so that he does not drop it. Someone who is trying to escape or move very, very quickly in general is probably unconcerned with accidentally dropping the item. In that regard, Oblivion is far too sensitive, amongst other troubles.

 

Something bugs me about how that would actually work in practice. I can't quite put my finger on it, but it seems like there would be problems. For example, how does the object know which side to move around? You might say always take the shortest angular difference, but what if that side was occluded and the other side was not? How would the system know when to switch the direction and bring it around in an arc the other way? And what if the player is already busted because the system chose the wrong arc direction and slammed it into another wall making, a loud noise?

 

I think it might be simpler just to keep it to a linear motion to the point right in front of you, but don't let the player turn more than 90 degrees or so away from a stuck object without dropping it.

Not motion, force. The object is allowed to rotate around the grip point, and the grip point applies a force to the object. At no point does the grip point ever have to "make a decision." Let me illustrate:

 

 

(Not particularly to scale.) The arrow marks the direction the player is facing. The blue area represents the area in which the grip point can move, and the 'x' is the default position. At the two extreme vertices, there is not a direct path to 'x', but there is no decision problem. It can't take a straight path, but it can approximate one. We treat the boundaries of the grip point like (frictionless) walls; let the grip point naturally slide along the inside wall until it has line of sight to 'x'. When the object collides with an obstruction, we let it drag the grip point back, until the grip point hits its own limits. When that happens, we calculate the combined force to halt both the player and the object; if it exceeds the preset amount (our grip force), we drop the object, otherwise we stop the player.

 

Then there's the issue of what happens if the player tries to walk away from a "stuck" object? Do you prevent them from walking, or do you drop the object? It seems like that's what it comes down to in most of these situations: Either prevent the player from making the motion that they want but maintain a grip on the object, or let the player move but auto-drop the object.

 

I think it was Springheel who came up with a hybrid system: You initially stop their motion, maybe shaking the view a bit like you said, but if they keep trying to move in the same way for some amount of time, drop the object. That way, if they're in a panic, they can still drop the object without reaching for any extra keys, but if they don't want to drop the object, they get some warning that they're about to drop it if they keep trying to move farther.

I hadn't been thinking about a time-based system, but I had been thinking of a force-based system, as described above. If the player slams the object hard enough, the player will automatically drop the item.

 

One tweak might be to change the amount of force required for the player to lose their grip based on the angle of the grip point (closer to the vertices, easier to lose). The main point behind all of this is to provide a patient user the ability to move things to their heart's content, but not obstruct a player in panic, as you correctly observed.

 

Considering how long this damn post is, I hope I made myself sufficiently clear.

[Domarius]

My 2c

 

Obviously the problem stems from using the same control (mouse) to do two different things - moving your hands, and moving your head...

 

Ishtvan's capping of the applied velocity works really well. I think once the AFs are working with it, it will be great and he can spend his time on something more important.

 

Oblivion's implementation works really well, though I think maybe Ishtvan's is better for a thief game, since you get to still look around fast without dropping things.

 

@Nyar - I wouldn't jump down HL2's throat and call it an overly-limited mechanic; games are all about trades offs - I'd say their justification is that this little hula girl inconsistancy is worth keeping the controls simple.

 

I think the most important paragraph in your post is the one below the diagram (for anyone skimming...) it does sound like a good modification to the Oblivion style, and also sounds like what Ish was describing with the pause warning.

[Ishtvan]

The overloading happens at the player controls. You don't want to have a separate key for each and every function, especially if you have multiple keys to do the exact same thing in the different environments. On the other hand, you do want sufficient fidelity to keep players from being unable to do what they intended.

 

...

 

In the environment, you have use, grab, and drag available to the player at any time, and theoretically any object. Doom 3 actually provides one solution (which is admittedly not applicable to TDM in a general manner). D3 overloads the player's ability to shoot with the ability to use GUI's and talk to people. Whenever you are close enough to talk or use a panel, you probably don't intend to shoot, and vice versa. Thus, what would ordinarily be the use key ('e', 'f', or the right mouse button) can instead become a grab function (which itself could be overloaded).

Our controls are not that WIP. We decided long ago to have two controls: frob and use item. This had nothing to do with object manipulation, but stemmed from the fact that in T2, you could be trying to frob something in the environment, and easily use a consumable item in your inventory by accident. A separate frob and use key overcomes this problem, and doesn't complicate the controls too much in our opinion (a lot of games have separate controls for these actions).

 

You'll still be able to activate some items by frobbing them though. This means that frobbing a Viktrola for example will alway play the disc, not pick up the whole thing and run off with it. The player will learn which items do something when frobbed instead of being picked up pretty quickly. One could argue that you should instead frobhilight the item but hit 'use item' instead, so you could have the choice between picking up a viktrola and using it in place. That has the same problem of accidentally using inventory items when your frob focus shifts off of something, so I'm against that personally.

 

The only controls we don't have down at the moment are for moving items from the hands into the inventory, and for using some non-inventory items that can be used only when they've been picked up (does use item always get overloaded to use the thing you're holding if you're holding something? What if you are trying to use an inventory item on the thing that you are holding, you have to set it down first?).

 

Re: Holding Object Physics

Ah, yeah the diagram helps to explain what you are saying, and in that case I agree the object would only have one path to get back to the front of the player if it got stuck behidn them. I guess I was thinking about real life where you could pass an object behind your back to your other hand if it got stuck and couldn't be brought around the other side of your body, rather than turning all the way around to face it again.

 

I don't think force is a good game-metric for determining whether you can hold on to an object or if you must drop it. Thinking about what that means, if you had a heavy object, you would have to accelerate your mouse view extremely slowly or it would fall, since F = dp/dt = m * dv/t. How would the player know something was heavy before the first time they picked it up and dropped it like an idiot because they expected to be able to move their view at more than a sluggish pace?

 

Then there's problems with force in D3 physics specifically. D3 doesn't calculate real force balances. It's mostly event-based collisions which add some impulse instantaneously. It can add up a few forces on a single object to get an acceleration for that time-step, like its own weight, torque, and friction when sliding against something, but it leaves out a lot of forces in this calculation, like weight forces of objects pressing down on eachother. For example, if you were to take a rigid body cantilevered out over a ledge, and set something very heavy on the end very slowly, it would not tip down, because it only tracks the one-time impulse from the collision of the object and the cantilever, not the weight force.

 

So external forces on the object aren't really modeled. Objects get momentum from collision impulses, but not constant forces that would be there in real dynamic equilibrium, like the normal force and weight of other objects lying on top of it.

 

There is a function to add a force to an object, but it doesn't work too well if you're pressing the object against something. Instead of just stopping, the object goes *smack smack smack* against the surface. I'm not sure if this is only due to the force being too big for time step (finite differences stability criterion) or if it's other problems like not properly calculating the reaction force from the wall.

 

What I'm trying to say is that measuring the force you need to drag something won't really work in D3, since a lot of external forces that should be there are left out of the D3 force balance and faked in other ways. You could look at some other things, like distance from the dragged point on the object to the point you're trying to drag it to (the center of your screen). I think that's the only surefire way to detect if it's stuck somewhere. There is a function that's supposed to return all the surfaces an object is in contact with, but I've found it's not very reliable.

 

The way dragging is currently implemented is with a per-frame impulse that tries to give it enough velocity to get to where the center of your screen is in the next frame (with the option of some damping/drag force). If it collides with anything along the way (physics detects collisions parametrically and well tell you if there is one that frame), I clamp the velocity to a small number. This prevents the object from getting unstable when you try to force it into a surface it's colliding with, but it can still move away from the surface with this small velocity, stop colliding and move with an un-clamped velocity again. It works pretty well IMO, we just need to track the angle about the player from the current object's position and desired position, and flag it as "stuck" if this angle becomes too great and it's colliding.

 

If you really want to help with dragging objects, I'd suggest playing with D3 physics to get an understanding of what it's capable of. The source for it is all in the SDK.

[Nyarlathotep]

Ishtvan's capping of the applied velocity works really well. I think once the AFs are working with it, it will be great and he can spend his time on something more important.

 

Oblivion's implementation works really well, though I think maybe Ishtvan's is better for a thief game, since you get to still look around fast without dropping things.

It's all a matter of balance, really. Oblivion is touchy, and I'm not sure that Ishtvan's solution is significantly different than mine, once implemented.

 

@Nyar - I wouldn't jump down HL2's throat and call it an overly-limited mechanic; games are all about trades offs - I'd say their justification is that this little hula girl inconsistancy is worth keeping the controls simple.

You mean because the designers carefully avoided displaying any more significant breeches of control? When does Hl2 display any real sense of interactivity with the environment? You pick up phys-objects and throw them--oh, you have some glorified buttons to push too. Take those away, and all you've got is a glorified rail-shooter. When Valve made HL2, they replaced interactivity with physics. Do you think it was worth it, especially when you consider that having distinct methods of picking up objects and using them would have given a host of opportunities to add interactivity? Valve wanted to make the game so easy to pick up that they wound up patronizing their audience? Given that TDM's audience is strictly looking for either challenge or novelty (in the case of those who haven't played Thief), I would argue that we would be doing a disservice to them to oversimplify.

 

Our controls are not that WIP. We decided long ago to have two controls: frob and use item. This had nothing to do with object manipulation, but stemmed from the fact that in T2, you could be trying to frob something in the environment, and easily use a consumable item in your inventory by accident. A separate frob and use key overcomes this problem, and doesn't complicate the controls too much in our opinion (a lot of games have separate controls for these actions).

I'm not sure what you mean. What's the difference between frobbing and using an item? Unless you're talking about using an inventory item (irrelevant to my control scheme), I have no idea how they are any different.

 

You'll still be able to activate some items by frobbing them though. This means that frobbing a Viktrola for example will alway play the disc, not pick up the whole thing and run off with it. The player will learn which items do something when frobbed instead of being picked up pretty quickly. One could argue that you should instead frobhilight the item but hit 'use item' instead, so you could have the choice between picking up a viktrola and using it in place. That has the same problem of accidentally using inventory items when your frob focus shifts off of something, so I'm against that personally.

How about this? The use button works on items in your hand first and then whatever may be frobbed in the environment. Holding it down allows you to manipulate items that you would otherwise just use or bring to your hand. Finally, you have an equip/unequip button for your inventory items, bringing items from your inventory into your hands. It's not perfect, but at least you have a wider variety of control to give the player without forcing the player through esoteric hoops to keep from doing something they don't intend.

 

The only controls we don't have down at the moment are for moving items from the hands into the inventory, and for using some non-inventory items that can be used only when they've been picked up (does use item always get overloaded to use the thing you're holding if you're holding something? What if you are trying to use an inventory item on the thing that you are holding, you have to set it down first?).

I would imagine so. Look at it this way: you're holding a large object in your hands, but you want to grab something else you have in your person. How do you pull it out and use it without letting go of the object (which is too heavy or bulky to hold one-handed).

 

Re: Holding Object Physics

Ah, yeah the diagram helps to explain what you are saying, and in that case I agree the object would only have one path to get back to the front of the player if it got stuck behidn them. I guess I was thinking about real life where you could pass an object behind your back to your other hand if it got stuck and couldn't be brought around the other side of your body, rather than turning all the way around to face it again.

True, but we're looking for a system that could represent both one hand or two hands on the object. You can't pass a large box around behind yourself, nor would it be intuitive to do so.

 

I don't think force is a good game-metric for determining whether you can hold on to an object or if you must drop it. Thinking about what that means, if you had a heavy object, you would have to accelerate your mouse view extremely slowly or it would fall, since F = dp/dt = m * dv/t. How would the player know something was heavy before the first time they picked it up and dropped it like an idiot because they expected to be able to move their view at more than a sluggish pace?

Because very big objects tend to be much more heavy than even a small lead weight? When was the last time you swung a chair around without intending to throw it? Firstly, the grip force would be rather large, but not so large as to make our lovable taffer a superman.

 

Then there's problems with force in D3 physics specifically. D3 doesn't calculate real force balances. It's mostly event-based collisions which add some impulse instantaneously. It can add up a few forces on a single object to get an acceleration for that time-step, like its own weight, torque, and friction when sliding against something, but it leaves out a lot of forces in this calculation, like weight forces of objects pressing down on eachother. For example, if you were to take a rigid body cantilevered out over a ledge, and set something very heavy on the end very slowly, it would not tip down, because it only tracks the one-time impulse from the collision of the object and the cantilever, not the weight force.

That's a pity, but I only used force as means of describing my intent in a naturalistic, intuitive way. Seeing as I am still a little unsure of exactly where the limitations of Doom 3's physics engine lies, I figured a more general approach would keep me from making a grievous implementation error.

 

As for a more D3E specific implementation, the only force that arguably couldn't be limited to collisions is the grip force. (I don't suppose D3E has a particularly good way to find the force vector on an object, does it?) The rest could probably substitute acceleration if need be. Besides, TDM's gameplay is better suited to realistic physics engines, situations where players and mappers alike are going to quickly reach the limits of the physics engine.

 

There is a function to add a force to an object, but it doesn't work too well if you're pressing the object against something. Instead of just stopping, the object goes *smack smack smack* against the surface. I'm not sure if this is only due to the force being too big for time step (finite differences stability criterion) or if it's other problems like not properly calculating the reaction force from the wall.

How is that any different than HL2? It's immersion-breaking, but no more so than playing a telekinetic thief.

 

The way dragging is currently implemented is with a per-frame impulse that tries to give it enough velocity to get to where the center of your screen is in the next frame (with the option of some damping/drag force). If it collides with anything along the way (physics detects collisions parametrically and well tell you if there is one that frame), I clamp the velocity to a small number. This prevents the object from getting unstable when you try to force it into a surface it's colliding with, but it can still move away from the surface with this small velocity, stop colliding and move with an un-clamped velocity again. It works pretty well IMO, we just need to track the angle about the player from the current object's position and desired position, and flag it as "stuck" if this angle becomes too great and it's colliding.

That sounds like it works just fine. It sounds pretty close to what I was trying to achieve with my own (naive) system, but built around the limitations of the engine. The main differences lie in my attempt to make it feel a little more natural, by attempting to describe a natural point to let go of the object, but otherwise, the implementation is close enough that a layman would not be able to distinguish the two when set with identical parameters (such as the maximum allowed angle). In fact, I'm not even sure Doom 3 is capable of implementing my solution any differently, judging from what you told me.

 

If you really want to help with dragging objects, I'd suggest playing with D3 physics to get an understanding of what it's capable of. The source for it is all in the SDK.

It'll take me a while to understand, though, and I'll probably miss some important details along the way. Be prepared to be plagued with questions when I start checking it out. Hell, I'm already confused!

 

 

 

Edit: Is there a reason why quotations suddenly no longer work?

[sparhawk]

Edit: Is there a reason why quotations suddenly no longer work?

 

Yes. The post is to long. After a certain lengtht he quotation no longer works. It's a bug in the forum software.

[Komag]

you'll just have to double or triple post

[Nyarlathotep]

I'll keep that in mind...

[ZylonBane]

The only controls we don't have down at the moment are for moving items from the hands into the inventory

I don't see what the problem is here. Any item in your hands is implicitly also in your inventory (okay, except for junk items). To "move" it to inventory, you just hit the put-away key.

 

and for using some non-inventory items that can be used only when they've been picked up

What possible requirement is there for an object that can be picked up and used but not put in inventory? Sounds like some sort of hybrid junk/not junk object, which of course would complicate and confuse the interface. Don't allow them.

 

What if you are trying to use an inventory item on the thing that you are holding, you have to set it down first?).

Ugh. Don't even make this a possibility. Inventory items should only be usable on bolted-down world objects. We don't need a half-assed crafting system.

Edited March 8, 2007 by ZylonBane

[Ishtvan]

That sounds like it works just fine. It sounds pretty close to what I was trying to achieve with my own (naive) system, but built around the limitations of the engine. The main differences lie in my attempt to make it feel a little more natural, by attempting to describe a natural point to let go of the object, but otherwise, the implementation is close enough that a layman would not be able to distinguish the two when set with identical parameters (such as the maximum allowed angle). In fact, I'm not even sure Doom 3 is capable of implementing my solution any differently, judging from what you told me.

 

Yeah, I was also originally thinking about forces too, but realised that D3 physics is not really up to calculating force balances. I think the only difference between our systems in practice is that you want to limit the acceleration of large objects, so the player would auto-drop them if they tried to move too fast (distinct from trying to move too far from a "stuck" object). I could do that with the physics of our system, but personally I don't think that's good for gameplay. We'll probably never agree on that.

 

For dropping things, I'm thinking it would be best to do a combination of auto-dropping and stopping your view (or feet) from moving. E.g.: You're moving something, and if you get too far away from it in either angle or distance, your move direction stops and shakes back and forth for a small amount of time (maybe half a second), and if you continue to move in this direction, you auto-drop the object. This gives the player warning that they are about to drop the object, so they can decide if they want to keep going the direction they were going and drop the object, or go back the other way to keep the object.

 

 

Re: Controls for Using / Picking Up / Putting in Inventory

 

@Nyarlathotep : "Use item" as I've been defining it is only for using inventory items, but not things in the environment like doors. Personally, I don't really like the idea of separate keys for picking up objects and using them in the environment. I see your point that having the same "frob" control for both makes some objects ambiguous as to whether frobbing them will make them perform some function or pick them up, and limits your options to one or the other. However, I'm willing to make that sacrifice rather than have to think about which of two keys to hit every item I want to either grab something up or activate it in the environment.

 

I never had a problem with that in Thief. I just got used to which items are picked up when frobbed and which ones perform an action when frobbed, and it was quite convenient to just have one frob key. Our mod team is more or less a democracy though, so if more people vote for a system with separate keys for pick up/use in environment, we can always switch to it.

 

I don't see what the problem is here. Any item in your hands is implicitly also in your inventory (okay, except for junk items). To "move" it to inventory, you just hit the put-away key.

That could work. To clarify, do you mean the "clear inventory item" as featured in Thief? I had thought about having the next/prev item keys auto-put it away, and it would make sense to extend that logic to the "clear inventory item" key.

 

My only reservation is that some people might use the "clear inventory item" key very rarely, and might want a way to do it by overloading the more standard controls. However, if our inventory items go straight into the inventory by default, and only go into the hands if you specifically drop them, I think that's so rare that having another possibly rarely-used key to put them back in the inventory would work fine (if that logic makes any sense ). In any case, the player could also use the next/prev inventory item key just to put the hands-item back. They're almost certainly going to bind next/prev item in a useful keyboard position. So yeah, I think clear item or next/prev item to put a "hands" item back in the inventory would work.

 

What possible requirement is there for an object that can be picked up and used but not put in inventory? Sounds like some sort of hybrid junk/not junk object, which of course would complicate and confuse the interface. Don't allow them.

We were originally thinking of weaponized "junk" items like AI weapons or improvised weapons (table leg wielded as club). We would allow the player to pick up and (clumsily) wield certain junk items by hitting "use" while holding them. There's really no other logic than gameplay for why these wouldn't be able to go into the inventory or weapons, since the player has no problem carrying around any other bulky object. I think the idea was that the player can pick up say a crossbow and wield it, but it would unbalance gameplay if they could just always have that as a weapon, so they'd have to drag it around as a junk item all the time if they wanted to keep using it. [Disclaimer: This is a low priority feature and might not make it into the release].

 

Ugh. Don't even make this a possibility. Inventory items should only be usable on bolted-down world objects. We don't need a half-assed crafting system.

There are cases other than half-assed crafting system where the player would want to use something on a moveable item. For example: Player lights a moveable candle using a tinderbox in their inventory. Player fills an empty bucket with water from a waterskin in their inventory (now they have the ultimate weapon: water bucket!). I think even Thief had a moveble wax mold that you used on a moveable key in RTHC, right? Or did they do that with intermediary fixed objects? I forget.

 

You could argue that the player only has so many hands, so they'd have to set something down before using it. However, I was only thinking it would be a control problem if we overloaded "use item" to put the item from the hands into the inventory. If there are no conflicts with "use item" anymore, we might as well let them use inventory items on items in their hands.

[Springheel]

Ish: Are you sure we didn't come up with our control scheme already? I'm fairly certain I remember discussing all these issues before, unless there was something we hadn't considered that has appeared since then? I'll see if I can find the thread.

[SneaksieDave]

Put away makes perfect sense to me - I use it constantly (especially thanks to the bug in Thief after coming back from the menu). I too thought that was decided.

[demagogue]

Just a clarification question ... if you have separated a use-object and frob button, does that mean that the use button has been taken off the mouse and put on the keyboard -- so the mouse now has weapon-use & frob, but if you wanted to use a health potion or mine on-the-fly you'd have to find the key on the keyboard?

 

My intuition was that frob and use were integrated to have a good amount of interaction kept on the mouse, particularly the stuff you might be doing on-the-fly, like running through doors you need to open, using a weapon, using a health potion as you're getting pelted, or blowing the horn of Alarus just as the burricks start charging.

 

(I'm sure you have all thought about all the issues and have made a good decision, and have thought about the trade-offs; I'm just wondering about the mechanics and if I understand what's going on.)

[Springheel]

My intuition was that frob and use were integrated to have a good amount of interaction kept on the mouse,

If frob and 'use inventory object' were the same button, then you would constantly be using up inventory objects accidently when you actually wanted to pick up something or open a door (but missed because you went slightly out of frob range).

[Mr Retarded]

I never had a problem with use and frob being on the same button. Mostly because I wouldn't have my inventory open unless I was specifically looking for something in it. As long as it's clear that you have something highlighted in your view then there shouldn't really be a problem.

[Springheel]

Yep, here's the thread:

http://forums.thedarkmod.com/index.php?showt...=4283&st=25

 

Seems like pretty much everyone was in agreement that hitting 'use' when carrying an inventory object that's held in your hands puts it back in your inventory. Hitting use when carrying a junk object that is "useable" (like a body or a chair leg) makes it goes into it's "equiped" position. If it's a junk object that's not useable, nothing happens.

[demagogue]

@Spring, I completely understand the reasoning behind the decision; it was said a few times in this thread, and everybody knows how annoying it is to lose an inventory item when trying to open a door and missing the frob. I'm not questioning that.

 

My question was just if I understood the mechanic correctly that the decision means that the use-button is going to be taken off the mouse-button and put on the keyboard. I guess it would have to be (I couldn't imagine the other way around where frob is put on the keyboard), but I just didn't see it explicitly stated.

 

For my mouse (which doesn't have a wheel), I already need to go to the keyboard to scroll through inventory items with Tab (or is the mouse wheel just to weapon-cycle? I don't even know), so it's already a bit of a pain when I'm in a rush. Maybe the thinking is that it is not any *more* annoying to put the use key on the keyboard than a cycle-key (or maybe it's worse because now you have to fumble for two keys, cycle and use, instead of just one?).

 

On the other hand, with the classical system it often happens that the inventory item disappears automatically right before I want to use it (to facillitate dual frob use, presumably). Does the new system keep an inventory item always usable once it's set-up, or does it also disappear after a while?

[Ishtvan]

Yep, here's the thread:

http://forums.thedarkmod.com/index.php?showt...=4283&st=25

 

Seems like pretty much everyone was in agreement that hitting 'use' when carrying an inventory object that's held in your hands puts it back in your inventory. Hitting use when carrying a junk object that is "useable" (like a body or a chair leg) makes it goes into it's "equiped" position. If it's a junk object that's not useable, nothing happens.

@Spring: I wouldn't say it was voted on and locked down. I do agree that the majority of people in that thread (including me) wanted the "use" system to xfer the item from hands to inventory, but there was also a debate going on in that thread for another system that never really ended with a vote. We just got tired of debating and the thread stopped, it seems.

 

Anyway, now that we revisit it, I think ZB's "clear inventory" suggestion makes a lot more sense than "use item", and we don't have to worry about ambiguous cases where the player has to remember if use item is going to wield something, use an inventory item on something, or put something in their inventory.

 

@Demagogue: It all depends how many buttons you have on your mouse, and what things you want to prioritize on there. Some people have "attack" on the keyboard, or frob on the keyboard, or who knows how an individual's keybindings will end up. If you wanted to put the standard "attack" "block" and "frob" on the mouse, and had a 2 button mouse + mouse wheel depression, then it sounds like you'd have to put "use inventory item" on the keyboard.

[Springheel]

but there was also a debate going on in that thread for another system that never really ended with a vote

 

I only scanned it, but it seemed like there was only one dissenting opinion.

 

Anyway, now that we revisit it, I think ZB's "clear inventory" suggestion makes a lot more sense than "use item", and we don't have to worry about ambiguous cases where the player has to remember if use item is going to wield something

 

I have this nagging feeling that there might be times you want to clear your inventory while holding an object, though I can't think of one off hand.

 

On the second point, I don't think it's that ambiguous...if the object came from your inventory, then it goes back in your inventory. Inventory objects go directly to inventory when you pick them up, so the only way it would be in your hands is if it was in your inventory first. I think that would be fairly easy to remember.

[Nyarlathotep]

I get the feeling there's little I can do as ordinary member contributing to discussion.

 

Yeah, I was also originally thinking about forces too, but realised that D3 physics is not really up to calculating force balances. I think the only difference between our systems in practice is that you want to limit the acceleration of large objects, so the player would auto-drop them if they tried to move too fast (distinct from trying to move too far from a "stuck" object). I could do that with the physics of our system, but personally I don't think that's good for gameplay. We'll probably never agree on that.

No, it just has to be less sensitive. Tune it so that it feels fairly unambiguous (unlike Oblivion), and no one except total idiots should have trouble figuring out why the object was dropped.

 

For dropping things, I'm thinking it would be best to do a combination of auto-dropping and stopping your view (or feet) from moving. E.g.: You're moving something, and if you get too far away from it in either angle or distance, your move direction stops and shakes back and forth for a small amount of time (maybe half a second), and if you continue to move in this direction, you auto-drop the object. This gives the player warning that they are about to drop the object, so they can decide if they want to keep going the direction they were going and drop the object, or go back the other way to keep the object.

That sounds good. It'll definitely need a lot of beta-testing to get right though.

 

@Nyarlathotep : "Use item" as I've been defining it is only for using inventory items, but not things in the environment like doors. Personally, I don't really like the idea of separate keys for picking up objects and using them in the environment. I see your point that having the same "frob" control for both makes some objects ambiguous as to whether frobbing them will make them perform some function or pick them up, and limits your options to one or the other. However, I'm willing to make that sacrifice rather than have to think about which of two keys to hit every item I want to either grab something up or activate it in the environment.

One alternative is that frobbing will pick up items that can't be used to facilitate player comfort. If the player intends to grab the object, not use it, they can just as easily. I suspect that in the end TDM will wind supporting multiple styles (just not the first release).

[Domarius]

Ish: Are you sure we didn't come up with our control scheme already? I'm fairly certain I remember discussing all these issues before, unless there was something we hadn't considered that has appeared since then? I'll see if I can find the thread.

You might be talking about these threads

http://forums.thedarkmod.com/index.php?showtopic=4283

http://forums.thedarkmod.com/index.php?showtopic=4283

And the diagram I posted (but everyone also said that inventory objects should jump to inventory, which my diagram doesn't distinguish between)

http://forums.thedarkmod.com/index.php?act=A...post&id=981