Jump to content
The Dark Mod Forums

Nyarlathotep

Member
 View Profile  See their activity

  • Posts

    1196

  • Joined

  • Last visited

 Content Type 

Posts posted by Nyarlathotep

  5. More Religious Insanity From The Us Of A

    in Off-Topic

    Posted

    Are you sure that's for real? I swear that sounds just like something straight out of The Onion.

    It isn't... <_<

     

    You know what to do. Join us in our demonic country of dooms and curses. Join usss now! :ph34r:

    Actually, it might not be too bad, so long as the beer is good. How much more is imported Jack Daniels?

     

    This is pure sparkling madness, not even what he said but the fact that he thinks it might work. If this actually finds some traction in the form of political support from any group here over the size of 25 people, I'm going to the Canadian embassy and declaring myself a political refugee.

    If it works, I'll pick you up on my way out. I hear Toronto is nice this time of year.

  7. Conveying A Sense Of Weight And Movement Options

    in The Dark Mod

    Posted

    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).

  12. I'm Officially Under Demonic Oppression

    in Off-Topic

    Posted

    Funny, your stick worshipers think your flag is the mark of the devil, our stick worshipers think our flag is the Face of God....

    No, they think our capital is the mythical city on the hill of Revelations fame. These people are retarded. Did I mean it's these same people that are currently in the White House? <_<

  15. Crank

    in Off-Topic

    Posted

    It seems like it might be interesting, but I don't think anything could possibly beat seeing Snakes On A Plane in theaters. Having the entire audience quote Samuel L. Motherfucking Jackson in unison is an insane experience:

     

    "I'm tired of these muthafuckin' snakes on this muthafuckin' plane!"

     

    I've never, ever, heard a movie audience do that--ever. You hear that on stage occasionally, with especially popular plays or plays that are adapted from especially popular movies (Spamalot, anyone?). I've never heard a movie audience do it before--I was stoked.

  16. Remember Ford =d?

    in Off-Topic

    Posted

    This just in: Ford recalls entire police fleet for defective wheel hubs. Unable to patrol, police have been spotted in unprecedented numbers relaxing at doughnut shops.

     

    Ford himself was last seen entering a crescent-shaped canyon in the Middle-East in search of an unknown archaeological artifact. An earthquake of magnitude 6.7 on the Richter scale struck the region shortly thereafter. Ford is currently presumed dead. More news after the break.

  18. Let The BBC Pick Your Lotto Numbers

    in Off-Topic

    Posted

    This thread sure went nowhere fast! Oh well, time to join in the frivolity! :D :D :D

     

    17706-1d68e97f5e8457375ed687e587dabe78.jpg

     

    P.S. Nyarlathotep this is an internet discussion, not a debating society. At least, I don't see the Bartlet-Jones Piano here.

    You're right; I forgot. Civility is far beneath the internet. I shouldn't be here flailing about like idiot until I learn the rules of internet discussion. I guess I'll just go back to my debate club with its nonexistent piano and masturbate to Aristotle. :rolleyes::P

     

    No, I don't imbibe.

    I stand corrected.

  19. American Accents In Fantasy

    in Off-Topic

    Posted

    The only American accent that's really acceptable in fantasy would be the Midwestern accent--given as it is considered to be the "accentless" American accent, and even then only in moderation. Although, if you were doing a period piece on the Elizabethan court, you could always use an Appalachian accent (it's almost identical).

     

    In general, accents work better in fantasy when they're only barely noticeable. The nationality of the accent invariably becomes what is most noticeable, with only the slightest hint of any particular region. Certain accents are probably too grating to be heard in fantasy at all, such as a North London or a Bronx accent, being extremely distinctive and rather harsh (not to mention they are only barely recognizable as English).

     

    ...and if you just want to be unintelligable put on a Babwa Wawwa accent

    Eh...whaa?? :huh:

  20. Conveying A Sense Of Weight And Movement Options

    in The Dark Mod

    Posted

    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! :wacko:

     

     

     

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

  22. Let The BBC Pick Your Lotto Numbers

    in Off-Topic

    Posted

    Reason has no place in my journalistic domain! Mwahahahaha.

     

    I know how to debate, Mr Nyarlathotep, it's just that there is nothing in SneaksieDave's argument to debate.

    I've dealt with so many damn idiots that couldn't recognize legitimate debate if it knocked them over their heads I have difficulties telling whether or not someone is even remotely aware of the fallacies their stepping in. Anyways, it's easy enough to avoid fallacies without sacrificing one's humor; the fact that you didn't implied that you weren't fully aware. In the strictest sense, I have no evidence to the contrary (with the exception of one post--made after my post, mind you), so you can't argue that I should have known any other than what I had seen.

     

    And I'm accused of ad hominem attacks?

    Well... do consider this:

     

    Probably just drunk again. Pay it no mind and don't bother.

    I would assume he's talking of himself.

     

    Stuff.

    So you CAN debate!

  23. Conveying A Sense Of Weight And Movement Options

    in The Dark Mod

    Posted

    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?

     

    hulalife2jr6.jpg

     

    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:

     

    grabbingcy1.gif

     

    (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.

  24. Conveying A Sense Of Weight And Movement Options

    in The Dark Mod

    Posted

    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.

×
×
  • Create New...