Lephys

I get the point with which you're rebutting, but... negatory, Ghost Rider. First of all, the "LA" in LARP stands for "Live Action," which specifically involves quite literally playing a role, not drawing experience from some other representative form of character control (you say "avatar," I say "character." They are not mutually exclusive.) Secondly, A first-person shooter, though closer to simulating more of a first-hand experience, both from a control and perspective standpoint, in no way gives you the ability to fire military-grade automatic weaponry with your actual arms. The game simulates weapons fire and movement as though peformed by a fully-trained, elite human entity, and you choose how to control that entity accordingly. When you pull left trigger (or right-click, or whatever), your "avatar" aims with his own level of keeping-a-gun-steady skill, not with your own personal skill at such a thing. You control where to aim, and when to fire. You tell him to reload, he reloads as quickly as his reloading skill allows. It may be a different control scheme and viewpoint, but the player-controlling-a-character principle remains the same. And hell, in a lot of modern shooters (at least in single-player campaigns), if you aim at an ally, your "avatar" will actually un-ready his weapon, completely preventing you from firing at friendlies because your character wouldn't. I would say that falls directly beneath this statement: So... I honestly don't know why you chose to suggest that everything I stated was simply LARPS instead of exactly what I said it was. Immersion is immersion. It doesn't matter if it's a sports game, a shooter, an RPG, or what. Doesn't matter if you've got a first-person view or not. You control someone who's in a different world, with a different skillset, and you experience varying degrees of things through them. An NPC in an RPG doesn't tell YOU what's going on. He tells the character. You find out story and quest details by reading conversations between the character you're controlling and the NPCs. The NPCs certainly don't need to read the dialogue, and neither does your character. And if it wasn't for immersion's sake, there'd be no point in having it be dialogue, instead of the characters providing quest instructions directly to the player. "If you go find a cave and fight some stuff and prevent this character from dying, you'll get experience and loot." I feel that's a reasonable explanation for my desire to have lockpicking not be reduced to instantaneous actions. That's all. Regarding the last few replies about lockpicks, in the event that a process-representative lockpicking system WERE implemented, I definitely feel it might be a good idea to have some sort of cumulative progress in the lockpicking. This way, if you have lockpicks break, or you slip something up, you don't have to start all the way back over. It would result in less-frustrating lockpicking (a hard lock just takes longer, instead of taking 73 individual mulligans), and less ridiculous lockpick loss. Sure, the player can always just pull the old save-before-you-pick method and reload when they run out of lockpicks. But, if you can reasonably reduce the fickleness of lockpick quantities and/or breakage, there's less reason or incentive to do so.

No, but that does not automatically mean that everything in game should happen completely on its own, arbitrary schedule. The NPCs don't care if world time is passing realistically. The player is making no one but himself wait if he decides to search a section of forest for 10 minutes as opposed to 1 minute. Having a clock start ticking when you begin a playthrough, and having things be based on that serves no purpose whatsoever that relative option-restrictions do not serve. You allow the player to pause, or save his game and exit the program and shut his computer down and use the restroom, right? So why does it matter how long it takes him to re-outfit his characters, or decide what to do with level-up points? You're suggesting that virtual realism isn't served by having time pass no matter what you're doing (just as it does in reality?). I don't understand the question. I didn't say "Anything in the game that's a challenge should be adjusted so that it is no longer a challenge." I'm merely suggesting that, by having a real-time, active timer that makes the world go round, you're achieving the urgency of which you speak in aspects of the game in which it is appropriate, PLUS every single other aspect of the game in which it isn't appropriate. I.e. if after a month a town gets burned down no matter what, but you don't know that that town even exists, much less is under threat of being attacked by anyone from the very start of the game, then you may very well do plenty of things that aren't benefitted by a sense of urgency, only to come to a flaming pile of rubble when you DO make it to that town. Therefore, for the timer to serve any purpose, you have to FORCIBLY convey the player to that town within a certain amount of game time. Absolutely nothing is gained by starting a countdown before the player even has knowledge of what it applies to. In other words, for ANY content for which a sense of urgency makes no sense or serves no purpose, you still have one applied to it. This wasn't in opposition to what I was saying elsewhere in my post. This continues directly from what I said above. If you get to a point at which you discover a town is going to be attacked, and you're at that town, and it hasn't been attacked yet, then restricting the player to only those things that wouldn't pass hours and hours of game world time makes more sense than saying "You can totally go get the blacksmith to repair your armor now, but you only have TWO MINUTES!". Even though time is essentially frozen during this point, as long as the player can't do anything like sleep for the night, or run off across miles of countryside and come back, or go play darts in the tavern for 12 hours, then it's understood that their decision is time-sensitive. Obviously, you could allow them to do these things, at the cost of the town attack occurring (once they unfreeze time by making a time-passing choice), but the alternative is pointless (making the attack start in 10 minutes no matter what). If I'm a slow reader, I'm not nilly willy CHOOSING to read some text for 15 minutes instead of 5. I just either choose to read that text and it takes me 15 minutes, or I choose to skip it and it takes me no minutes. You essentially end up penalizing the player based on game-world time (which is silly, because, if YOU were your character, in the actual game world, a brief conversation or the browsing of some wares at a merchant's shop would ACTUALLY take 5 or 10 minutes, rather than 5-or-10-minutes-which-represent-2-hours-in-the-game-world) for performing actions at a certain speed in non-game-world time. Unless, of course, you have the game-world time be real-time. 24-hour clock. I hope that makes sense. Also, I'm not suggesting you're arguing against all my points or anything. I'm merely clarifying what my points are.

^ I don't know that we should absolutely avoid any situation in which you don't know how many enemies you might have to deal with before combat is over, but any waves should definitely be implemented and balanced in a reasonable manner.

^ Fair enough, I think, if they have the time and resources, a pseudo-optional approach could be taken. Say that, without the mechanic (just the skill system and skill check) you could only pick locks up to your skill level (1-100, for simplicity's sake). Well, maybe the interactive mechanic could come into play only to attempt locks with a difficulty that's within a small range above your skill (like 70-80 if your skill were 70, purely for example). Either that or there could basically be a toggle option. Either way, you could avoid it like the plague if you wanted to, or partake in it if you wanted. That would be very simliar to the difference between difficulty levels, and/or the toggle that's often available for friendly-fire with AOE spells and such. *shrug*

^ Well, whatever doesn't float your boat. Some people don't play the game to fight things, or hate reading quest dialogue, and yet calling quest dialogue or interactive combat a waste of resources would be silly. I don't play the game specifically to pick locks, but I like to experience some degree of what my character is doing. I'm playing the role of my character, which is exactly why, when I discuss RPGs with my friends, I say things like "Oh, you killed that guy? I totally let him live. u_u" when referring to differences in our gameplay choices. Hell, it's the basis for the enjoyment of pretty much any genre of game that involves controlling a sentient entity. Immersion. The player controls choices and actions from the shoes of someone with a different skillset, in different scenarios. A first-person shooter isn't called a role-playing game, but you take on the role of a character, with a gun. I can't accurately take down 17 people with an MP5, but my character can, and I can directly control his skills. Obviously an FPS has a different setup and control scheme, but the immersion, in whatever form, is still what makes it enjoyable. So, yes, to some degree, you want to experience things AS your character with all these skills, even if it's not in a first-person view. You get to be awesome at combat, and you get to cast spells, and you get to overcome challenges and shape the story. Lockpicking is just another task in the world that you could experience to various degrees of immersion. It is a challenge to pick a lock, so it could be nice to experience part of that challenge as a skilled lockpicker. Doesn't mean it's mandatory. But it makes sense as a possibility. So, I'm curious... Why do you advocate the existence of obstacles that require a character skill in which you have absolutely no interest in order to overcome? Why not just replace all the door locks in the game with find-a-switch-to-open doors and drop the skill system and get rid of locks on chests? That would certainly save development resources.

I think DA:O and DA2 provide some good points for making sure combat tactics remain relevant. Both were pretty bad about the whole one-dimensional aggro thing ("I only saw you for a millisecond, but I know exactly where you are and am COMING FOR YOU FOREVER!". And it wasn't so much the number of enemies or the fact that they came in waves in 2 that hurt it. It was the fact that all the waves were essentially ambushes mid-combat. "Oh, you're strategically keeping your party well-positioned to effectively keep them alive while taking down these enemies? Well NOW there are 12 more rogues and tanks right around your ranged/magic folk!" It's fine to have a reinforcement wave enter combat, or an ambush, but a wave should cause you to say "Oh no, we've got to readjust to those things that just came into the room from that side!", not "Well, they've literally just appeared all around us, so there's absolutely no opportunity to make any meaningful decisions to affect how we engage them." Of course, I don't think anyone here is worried that Obsidian's going to say "Hey, you know whose mechanics we should copy directly because they're amazing and perfect? Dragon Age!" Haha. BUT, it's good to analyze examples of both good and bad gameplay mechanics to figure out what about them, exactly, caused the problems or lack of problems.

That seems like a pretty good idea. The icons could just be simple command categories, so that, at a glance, you'd know "Oh yeah, once he moves there, he's going to cast a spell... and once he gets there, he's going to enter stealth." One other thing to consider, regarding allowing for unlimited command queuing, is how to allow for viewing and control of the queue itself in the interface. If you limit it to, say 6 (arbitrarily picked for simplicity) actions that can be easily displayed as icons in a small amount of space on the HUD/interface. But, if you allow players to queue up 50 moves, how do you show all of these so that the command-queue may be interpreted and edited? It's just an obstacle, is all. I'm not saying there's no way to deal with that. I just don't know how, off the top of my head.

I think time-sensitive content can be very valuable, as many have pointed out already. If you eliminate it completely, you suck all urgency or tension out of anything in the entire game. However, I think the line should be drawn at relative time limits. What I mean by this is, if the town is under attack, you essentially shouldn't be allowed to do anything with your characters that would progress world time (i.e. travel to some far away cave, rest for a week, etc.) until you've delt with the town defense. And, once the attack on the town has begun, you can even have active time limits (i.e. get to this gate and barricade it closed before too many hostiles get through, or get to it before the forces defending it die and allow all the hostiles through, etc.). But, UNTIL you decide, the attack on the town should not actually commence. Essentially, you've got a gameworld time freeze while you prep (for things you know about any amount of time in advance). The reason for this is, people involuntarily have differing speeds at which they interact with things and take in information. A person might be able to read just fine, but they might read a paragraph at 1/3 the speed that you do (someone proposed, I think in the day/night cycle thread, that the passage of world-time be paused during conversations, and this makes perfect sense.) It's not just dialogue, though. Some people have ADD, or other variants in brain function that cause them to take longer to figure out the layout of a town, or to take longer to decide which weapons and armor to purchase. So if the town is going to be attacked in 5 minutes, real-time, no matter what, then some people are going to be capable of getting their preparations done in 4 minutes, and some people are going to take 6 minutes to get those exact same preparations done, despite their best efforts. Not only that, but you could simply save often and reload the game to basically mulligan your attempts to get ready. So the active time limit isn't really gaining anything from a design standpoint, other than pissing off the people who were "too slow." Again, I'm it's fine to have the "get to the gate!" or "get out of here before the cave collapses!" scenarios, but it would be silly to run into instances of "I didn't even know I was supposed to get to the gate yet, or that the town was being attacked now, because it just happened after a certain amount of time no matter what" or "that cave collapsed before I even went inside once!". Anywho, the point of urgency is that you must manage your time, as opposed to not-managing it. Beyond that, you don't really gain anything by holding everything to a single, active clock. The urgency of something should be relative to a point of non-urgency before it. There's no need to turn the game into a speed run. If it takes me 30 minutes to talk to everyone in town, and it takes my friend 15 minutes to talk to everyone in town, what does it matter? It should be understood, for the purposes of realism, that the characters would take the same amount of time no matter what if they got to do it themselves. And as for complete failure? That's even worse when it's not attached to a short time-sensitive duration. You start the game, you do some stuff, you save. You do some stuff, you save. You do some stuff, you save. 50 hours of gameplay later, it turns out you've missed the date on which some evil broke out of its tomb by about an hour of gameplay, spread out here and there over various actions and choices throughout the last 10 hours you've played. Well, I guess it's just time to reload a save from 10 hours ago and redo all the stuff you didn't fail at, simply because it happened to all add up to just a little too much time. If you even HAVE a save from that far back. So, no I don't think you should be able to go off questing in a completely different direction when the town's supposed to be under siege that night, but nor should you have to frantically make sure you time everything perfectly to match up with the start of the siege. Your time limits should exist in segments, and they should be relative to progression milestones. As long as you have to address the immediate urgency of a given situation as opposed to being able to go do random other things, the benefit of the restriction is there.

There should probably be a limit on action-queuing. The more commands you queue up at once, the less likely each subsequent command is to still be what you want to happen by the time your character gets to execute them. For example, it would be ridiculously difficult to go ahead and tell your Mage to do 4 different things in order, then cast fireball at a designated location. You'd either be targeting a group of enemies who was currently clustered together (and who might move apart at any point in time), or you'd be trying to anticipate exactly where and when a group of enemies was going to become clustered together. It just isn't very feasible after a certain point. Movement waypoints/commands, sure. If you want a character to run in a figure eight the entire battle, then by all means have them do so. But with action commands, there are only so many you can effectively queue.

See, I'm sure that was done simply because it was easier from a programming standpoint than removing the roll altogether. But, obviously, the fact that the roll was always 20 completely defeats the purpose of the roll in the first place. The only value of a dice roll is that it can possibly turn up any one value within a range of values.

Well, I was thinking that actually designating the movement path (basically click and drag, even non-straight lines) would give you a lot more control than simple waypoints. With waypoints, getting your character to travel around something rather than through it requires many waypoints. I've seen the draw-the-path mechanic used in some simpler flash games. While I'm no experienced programmer, I would think that it might be fairly easy to implement. If it would require too many resources compared to the waypoint system, then I will gladly not worry about it.

No, I was actually trying to make the point that, despite how flexible the definition of "minigame" can be depending on just how technical you want to get, and despite exactly which of the mechanics in question you want to claim should officially be called "minigames" and which ones shouldn't, what you can call them or not call them has absolutely no bearing on whether or not they serve any kind of purpose in the suggested implementation being discussed in this thread. You identified both Bejeweled AND Skyrim lockpicking as minigames, and yet one blatantly functions as a skill-mechanic in a larger RPG FAR better than the other does. My point is that, regardless of whether or not they could technically stand on their own and function as something that would fit the loosest description of "game" imaginable, the ideas I'm advocating here are only those that are designed to specifically represent and deepen (quantifyably deepen, not "automatically makes everyone like them" deepen) certain character skill process interactions in an RPG. I went out of my way to elaborate on exactly what I meant when referring to "minigames" very, very early in this thread, as I realized that trying to refer to an in-depth mechanic without using that word would simply cause confusion. So, I don't understand how trying to better explain myself when you keep trying to correct me on semantics that are beside the point. Since I'm referring to interfaces that aren't designed specifically to fulfill all the aspects of a game, by themselves, I felt the need to distinguish, but "minigame" is the closest thing to what I'm describing that I know to use as a label. So, I apologize for arguing for the sake of claryifying my point when it seems to be misunderstood. I'll try to avoid that in the future. Well, since you're obviously correct and aren't focusing on a specific degree of usage of the word, I guess I'll have to start snapping into a Slim Jim whenever I "engage" in conversation with someone from now on. Or maybe we'll just have to start punching each other in the face while we talk, or conversing only whilst hanging from helicopters. Because, clearly, it is impossible to engage in an activity without doing so to an intense degree. Thanks for clearing that up. You have a good point. But it's still slightly sliding past the point I'm trying to make. Look at the two methods we're comparing like this: In yours (aka, "no minigame" mechanic), the skill-usage interface essentially IS the general gameplay interface. In mine (the "minigame" mechanic), the skill-usage is separated out. You're suggesting that mine is creating player control where, with yours, there was none. You said the player doesn't control pickpocketing. BUT, if you've got to use the regular gameplay interface to move your character to the pickpocket target before his skill check can handle the pickpocketing action, and it's possible to be caught if you walk straight up in front of the target, then the player is actually controlling part of the success of the pickpocket. Even if your character is a VERY good pickpocket, you, the player, COULD fail to initiate the pickpocket command before the target NPC turns around, even though your character would never have made such a mistake on his own. So, in this way you are directly controlling a factor in the outcome of a successful pickpocket, one that is completely separate from your character's skill check. Sometimes, which items you manually choose to pilfer actually affects the likelihood that you'll get caught. It is the same as in combat. Opponents in combat move in various ways, use different abilities at different times, and change their behavior on the fly, requiring you, the player, to directly control certain aspects of your character (movement, ability usage and timing, etc.) REGARDLESS of their combat experience and stats and expertise. In the process of killing an enemy, you might have to specifically move your character out of harms way before the task is done, even if you use only one type of attack (and therefore only 1 skill-check over and over again). You welcome this amount of control, rather than insisting that the character's combat prowess be used as an entire "combat-check" to decide how he handles these dynamic factors in combat. Just as you're totally fine with having to partially make sure you don't get caught pickpocketing by your own actions, rather than having your character just automatically take care of all the factors involved. The only difference with my suggestion for lockpicking is that it has its own interface, because a lock cannot spot you, or move, or change its behavior, or use special abilities. The ONLY effect on it, in the non-"minigame" system is the skill-check. So, in that way, it gets more simplified than almost any of the other skill mechanics. I mean, with bluff, you get a separate interface (the dialogue interface), and you usually have to choose the right things to say to get TO the bluff choice before being able to choose it. Sometimes you even get several choices, based on how high your character's bluff skill is, or with varying amounts of truth to them, with different NPCs reacting better or worse to different types of bluffs. At the very least, it's broken down into more individual, controllable steps and affected by more factors than lockpicking. In other words, with the other skills, your character's skill rating provides you with the tools you need to complete a process (defeating an opponent in combat, pickpocketing without getting caught, etc.), but it allows you some control over HOW that process is completed. With lockpicking, it just either completes the process for you or doesn't. So, you could have an RPG that's perfectly playable and fine with lockpicking handled entirely by your character's skill and stats, just as you could allow equipment to be handled entirely by your character's skill and stats (shouldn't your experienced warrior always pick the better armor, rather than allowing you to equip whatever you want on him?). But that system would OBVIOUSLY be less fun. Why? Because you don't get to affect it. Thusly, lockpicking is a process that is complex enough for it to be reasonable to allow some dynamic range of factors for the player to overcome, just as is done with the other processes involving skill checks (to whatever extent). The main difference is that there is precedent set for it to be reduced to a single action in most previous RPGs, whereas there is no precedent for other processes to be reduced to a single action. Also, the implementations of the "minigame" interface mechanics that games HAVE used have not been the best designs (i.e. character skill not factoring in enough, not being as dynamic as they could be, etc.). And @Anubite, I don't know if you missed one my posts or not, but you took that one line completely out of context. No matter how many things are involved with swinging a sword effectively, "effectively" takes into account factors OTHER than the character's skill at swinging the sword, some of which are handled by the player in combat (like maneuvering through fireballs and arrows to make sure the character lives to make it within melee range, because you cannot swing a sword from 30 feet away "effectively") rather than being included in the skill check on the sword swing. "Effectively" using a lockpick isn't as simple as aiming it and making contact with the lock. While your character may possess the expertise necessary to swing his sword effectively rather than ineffectively, he will not automatically decide to perform different actions depending on the specifics of his foe, and he will never swing the sword so effectively that he makes 19 swings in a single swing. Yet, a lock may require 19 lockpick movements that take longer than the duration of a sword-swing. This is precisely why there's often a little duration bar that the player must wait for while the character makes a lock-picking attempt. The ONLY purpose of this bar is to more realistically emulate the complexity of the lockpicking process. All I'm saying is that, A) the lockpicking process is complex enough to be emulated in more depth than a single instant action, should one choose to do so, and B) IF you choose to do so, some kind of controllable interface that allows you to interactively overcome certain factors (exactly like strategically moving your characters in combat and choosing and timing their ability uses) would achieve this goal to a better end than simply waiting while the attempt takes longer.

He's in cahoots with the DM! I KNEW IT! o_o

That's actually kind of what I was getting at. Just swinging your sword = a single action. Doing all the things necessary to not die, get into the correct position, and swing your sword in various ways until your opponent lies dead = a more involved process comprised of many actions. Inserting a set of lockpicks into a lock = a single action. Performing all the subsequent actions necessary to effectively bypass all the tumblers in a lock with your lockpicks = a more involved process comprised of many actions. I'm not seeing how that does anything but reinforce my previous response. I understand what you're saying, but you're dealing with factors outside of my argument. "Effectively swinging a sword" refers to more than whether or not you've successfully swung your sword. Whether or not you've swung your sword isn't dependent upon whether or not it strikes something. Just like whether or not you've inserted a lockpick into a lock and/or moved it isn't dependent upon whether or not you successfully unlocked the lock. You can swing a sword (no matter how skillfully) without killing something, and you can jiggle a lockpick within a lock without unlocking it. This is exactly why killing a foe is a process and swinging a sword is a single action, just as picking a lock is a process and inserting a set of lockpicks into a lock is a single action. The process of killing a foe COULD happen to require only a single swing of the sword (if the opponent were, say, a rat), or it could require 20 minutes worth of dodging and sword swings (if the opponent were, say, a dragon.) In the same way, the process of picking a lock COULD require one simply twist of the lockpicks (if it's the lock was crafted by a child and is made of cheese), or it could require 10 minutes of extremely delicate lockpick finagling (if the lock was crafted by the most technologically advanced locksmith in the world to house some artifact of the gods.) Which is exactly why, in a minigame-mechanic system, locks that your character skill well exceeds should be reduced to a single action, and locks that are still actually tricky should require multiple actions, assuming the goal is to somewhat-accurately represent the process of lockpicking as well as combat somewhat-accurately represents the process of killing a foe.

^ Everyone rolls a 1 now and again. We're only human. Also, I think Dream rolled a 20. Haha.

Not only is this a splendid idea, but I think we should be able to designate our characters' paths easily as well. A lot of times, you want to send your character to the opposite side of an enemy, but you either have to tell them to move to that point and watch them run suicidally through the fray (as Ocelot said, you don't always know what route they're taking) or essentially reposition them again and again and again until you've finally gotten them around the battle along a safe route to the desired destination behind the enemy. Perhaps a path-drawing control would work well. Just click and drag the route you want them to take so that they go to where you want them to HOW you want them to. *shrug*

You both misunderstood me to a degree (perhaps because I did not explain well enough. I'm not trying to be pompous here.) If you implement a system that is intentionally designed to take advantage of chance to determine an outcome (any outcome whatsoever), then the only way chance comes into play is if chance determines that outcome. i.e. 3 options are possible, but only 1 can ultimately occur at a time. If chance decides which one occurs, then that chosen outcome is left in place and the game is continued, then there was a difference between chance selecting the outcome and the player picking the outcome. The fact that you can simply save before letting chance roll its dice, then reload your game LITERALLY negates any effects or purpose of chance picking anything in the first place. By reloading until you get a certain outcome, you are literally picking your outcome, only in an unnecessarily inefficient manner. It's not that "you shouldn't be able to pick something." It's that, IF you should be able to pick something, then you should simply be able to pick it. If you go to a merchant, why should he sell you a random item when you just want a sword and he has a sword in-stock? Allowing a dice roll to determine which item the merchant gives you for your money is utterly ridiculous, and serves only to arbitrarily delay the item-purchasing process. So, what I'm saying is, if the player is ultimately allowed to choose the outcome (however annoyingly inefficiently), then the purpose of the chance-roll making selections is 100% useless and should not even exist. It is counter-productive; a waste of resources. That's what I'm saying. If you've decided to have chance choose instead of the player, but you let the player ultimately choose anyway, then you have failed in your design goal. Whether or not the player should be allowed to choose something is a COMPLETELY separate argument, and is based on a ton of other factors. I'm not even addressing that decision here. Yeah, I'm sorry. I'm aware that my brain doesn't always supply me with the best analogy ammunition. They tend to always make sense in a way, but often only in a way that I wouldn't expect the person who didn't think them up to understand. I'm sorry about that, heh.

Perhaps I should say that lockpicking is a significant process, whereas swinging a sword is not. To put it another way, if you're holding a sword, and you're physically capable of swinging it in any capacity, you don't TRY to swing the sword. You simply swing it. Whereas, if you come upon a locked lock, and break out your lockpicks, you still have to TRY to pick the lock. You could fail to pick the lock, but you will not fail to swing a sword (again, assuming here that the only factors involved are your own skill and ability, and that no other outside forces act upon you during the attempt.) Using a key on a lock essentially becomes a single action, because your brain handles it all at once, and it always takes the same (tiny) amount of time. You know ahead of time that the key fits the lock, and that it opens the lock, so you think "open the lock," and you perform the appropriate motion with your hand using the key. For the purposes of simplicity, I was referring to "processes" as tasks that require multiple actions that vary in complexity, duration, and number. I've already accounted for the existence of locks of trivial difficulty in my proposal for a working lockpicking interface by suggesting that locks below your skill level would not prompt the interface, and would, instead, simply be unlocked. However, this is not because lockpicking is not a more involved process than using a key, but instead is because your character's skill has caused both of them to require the same amount of time, no matter how many steps are involved. You may be against the choice to implement a lockpicking interface within the game, but that doesn't change the fact that the lockpicking process is inherently more involved than a single action and could rationally be represented by an interface that represents the process in more detail than reducing it to a single mouse-click. Basically, there is a reason for such a mechanic to be implemented, as opposed to there being absolutely no reason for it's existence as a potential design choice. That would function, but I see no benefit to immersion, depth, or dynamics from a simple action that in no way represents the lockpicking process, much less in any kind of enjoyable manner. Even if you dismissed the thought, the back of your mind would wonder "why did THAT action unlock the chest, as opposed to something else?" It would be like having to type "bananas" to make your character attack. Clicking, while not representing an attack any more than typing an arbitrary word would, does not have the detriment of requiring as much time as typing bananas and unnecessarily hindering your control over the timing of issuing attack orders. Which sort of brings me to why I feel that a lockpicking "minigame" might work better than a "click'n'pick" interface. In combat, you're fine with clicking to attack, because you're simply indicating that you wish for your character TO attack, and what it is, in the game world, you'd like them to attack. A click performs both of these actions admirably. However, if you want your character to attack differently, you must issue some other order. You have more than a single "attempt to kill" button when issuing attack orders, and you may have to change what you're doing depending on how combat pans out. Whereas, with a locked item, you have ONLY the option of clicking to attempt, or not-clicking to not attempt. Even though it is possible to complete an action within the lockpicking process (such as fixing a tumbler in place and out of the way, such as in the Oblivion system *which is purely an example and is not being endorsed in its entirity*) without actually completing the entire process, the game usually just reduces the whole process to a single command. If the developers don't have the time or resources to avoid doing this (after getting the more priority systems and content implemented), then so be it. I will not insist that a more in-depth mechanic is necessary to the whole game. But I will insist that is a logically sound design decision, whether or not it gets implemented.

You actually just supported my point. Moving things around in an inventory interface isn't a game, just like kicking a soccer ball around isn't a game. Kicking a soccer ball around while keeping it within a boundary and trying to get it into a goal IS a game. Its being a game relies directly upon the existence of more factors than the existence of the soccer ball and your ability to kick it around. Not one have I cited that those two minigames were not standalone games. I was blatantly referring to the recent Fallout/Elder Scrolls lockpicking mechanics (as they are so similar to one another), which do not function as a game without the skill system in place, or the loot and area-accessability content in place. They serve only to interactively emulate a process. The HR and Bioshock minigames are standalone games. The outcomes of those games are then substituted into an effect in another area of the game. Technically correct: the kind of correct that says "I know what you meant, and what you meant made perfect sense, but I'm going to ignore that fact and insist that you could only have meant some other technically-possible meaning of your words, which I'm now bestowing upon what you've said because it makes me feel better." "intensely" is actually an adverb whose meaning is in NO way a direct part of the meaning of "engaging." Otherwise, if you were "engaged in conversation," any conversation you could ever have would be "intense." I actually posted the exact definition of the word several replies back. Since you didn't acknowledge my doing that in any way, shape, or fashion, I can only assume you disregarded it completely. "Engage: to occupy the attention or efforts of (a person or persons)". I stated that a minigame is "more engaging" than the "click'n'do" method. So, unless you're suggesting that clicking on a locked chest or door, then waiting for your character to perform a 2-second jiggle-my-hands-around animation, then being informed of the results of their attempt occupies more of your attention and/or effort than an interface that literally requires further action on your part before anything else happens, I don't even understand what you're even trying to say. So, if you meant something other than the base definition of "engaging," then I apologize for misunderstanding you, but I had no way of knowing. I clarified the specifics of my understanding of the usage of the word, and you merely replied that I was wrong, and insisted that you meant the exact words you stated. Nothing more. I'm not trying to annoy you here by breaking this down so far, but I don't appreciate all of my efforts and attempts and explaining my reasoning and showing my work, so to speak (specifically to avoid misunderstandings and obvious questions that would've existed in the absence of such details), being not only ignored, but also reduced to the accusation that my only argument is that I childishly cannot accept differing opinions.

I'm going to briefly address the "why not let people play however they want?" argument. It's not really even about whether or not Player A should be able to do something different than what Player B did. It's the principle of what it is they're doing, and the fact that it's bypassing something that was not intended to be bypassed. If you build a storage shed and put a deadbolt on the door, but then find that one of the sections of wall allows people to walk straight through it, then it doesn't matter if you're talking about someone who is allowed in that shed or not getting in through that quantumly-defective wall. The fact of the matter is, you specifically put time and resources into building that shed so that the door with the lock was the only way to enter it. The only reason there is to prevent such a thing is the fact that it is completely unintentional for it to exist in the first place. If you made a painkiller that sometimes CAUSED more pain, you wouldn't say "Well, this one patient who's taking it LIKES pain. Therefore there's no reason to worry about it." That being said, I don't think there's really a reasonable way to fix such holes right now. And even on the notion of the random quest/story branches being locked to each playthrough (which I personally expressed support for earlier in the thread), I acknowledge the negative effects of doing so and am not suggesting that it should DEFINITELY be done. I suppose the best way to handle that right now might be to allow people to pretty much pick their branch at such forks, having been informed a little ways up the road what choices will lead to which no-turning-back branches. That completely eliminates any reason for reloading to circumvent the path you didn't want, AND makes sure you don't get locked into the same branches on the same quests on multiple playthroughs. As for the "play a minigame to deter reloading," I don't see that serving any purpose other than delaying your reload. A delay can be achieved without a minigame, which is why this would be one use for minigames I am wholeheartedly against. It's counterproductive to spend time implementing something inherently designed for enjoyment, SOLELY for the purposes of its ability to delay your game reload.

Everything gets boring "after a while." That's why we like variance so much in life. We eat different foods, go different places, watch different movies, wear different clothes, discover new things. Something's ability to become boring is not a legitimate reason to never implement it, or we would never implement anything, and games wouldn't exist. You cited AC3 minigames as being "acceptable," indicating that, despite the fact that they possess the ability to bore at some point, some factor besides that caused you to give them a check mark. It is precisely that idea that's at the core of my stance on this discussion. And I'm sorry, but I still don't see any reason that "lockpicking or other mandatory annoyances" are inherently annoyances. The very mechanic of lockpicking, itself, is an annoyance if you choose to acknowledge ONLY the fact that locks are preventing you from getting loot and are requiring time and repetitive actions (even a second or two of clicking and waiting as opposed to ANY manner of minigame-esque interface). If that's the case, and such things offer nothing positive to a given player, then so be it. But if they DO offer something positive, then what is it that they offer? If the cons are "worth it," then there must be pros in place as well. I'm simply trying to explore what those pros are, and what makes them worth the cons. I realize how analytical I'm being, but I promise it is not my intention to be derisive or simply cause grief by arguing.

"Process: a systematic series of actions directed towards some end." Swinging a sword is not a process. It is an action. Just like picking up a block isn't a process. Stacking a group of blocks a certain way is, however. Fighting an enemy or group of enemies is a process, though, in which you get to control your characters each step of the way until the process of fighting that enemy is complete. In the exact same way that a fight with an enemy is a process comprised of multiple actions, so, too, is lockpicking. (Crafting is also a process, which is why it is one of the other main things I have supported a minigame mechanic for.) Also, I think you might be misunderstanding that incorporating player skill does not mean "player skill at a 1:1 simulation of the thing that your character is doing" (nor does it mean character skill ceases to remain a factor, as has been addressed several times before in this thread.) You decide what your character does every step of the way in combat, even though your character's skill decides whether or not he strikes his target, or how well he strikes his target, or how much damage he does. So, in a way, player skill factor's directly into combat. It's not your skill at swinging a sword or aiming a bow. It's your skill at utilizing your player's skills. He's not going to perform a strategic series of actions on his own. Just as your character has to guide his sword for it to cut effictively (his skill with a sword is not his skill at cutting... the sword does the cutting, but it's only effective when combined with his ability to properly direct it), you guide your character to perform their available actions effectively. Someone's hurling a fireball at you? You direct him to move out of the anticipated spell radius. He might dodge a melee attack in the flow of melee combat, but he's not going to relocate himself on his own. Then, you have to direct him to begin attacking his target again after he has successfully avoided that spell. Regardless of how much or how little, player skill is required to complete the process of combat. So, it is not ludicrous to suggest that maybe player skill should come into play when directing a character to complete the less-extensive set of actions required to pick a lock. Having said that, if you reduced the entire process of combat to a single action, the game would be quite, quite lacking. Whereas, if you reduced the process of lockpicking to a single action (which most games do), then, obviously, the entire game isn't shattered. My point is only that the decision to take the time to implement a mechanic that represents the process of lockpicking is, objectively, a more engaging and dynamic mechanic than the simple single-action approach. That is the reason that I support the lockpicking minigame mechanic, as a design template, rather than the single-action design template. There are many things that aren't required for an RPG to function (such as a special lockpicking mechanic, or even lockpicking in general, for that matter). You could have only a single character the entire game, as opposed to a party. You'd still have an RPG, but, in a lot of ways, the party system is much more complex and interesting. However, it requires a lot more management and time and effort to utilize than the single-character approach.

Good points, . Combat is comprised of so many factors, it's a very difficult thing to balance perfectly. You get a little math wrong and everyone's picking one class over all the others (just have a caster and you win!), or people are neglecting entire sets of abilities (like trap-usage in certain games). But, aside from the math balancing (damage, durations, etc.), one very important aspect is the level of control presented to the player. The intuitiveness of the gameplay controls should be well in-line with the complexity of the gameplay. Trap-usage actually brings up a very good example of precedent in a lot of RPGs. You tend to have the option of using various traps (maybe even crafting/customizing them) that, in theory, will help you dispatch or at least potently affect several enemies. However, there's often absolutely no thought put into any controls for manipulating the enemies into your traps. You end up taking an unnecessarily long time setting up the rest of your party so they won't be in the way or get injured while you jiggle your bait character around at some enemies in the hopes of attracting ONLY the ones you wish to, then attempt to cause them to path into your trap with very plain movement controls whilst avoiding your own trap, THEN making sure your party doesn't just stand around for 10 seconds after the trap goes off in the event that it doesn't outright eliminate your foes. If you allow for controls that are pertinent to trap-using as well, such as some kind of party ambush stance (which isn't necessarily absent from all previous RPGs) and some kind of luring ability or control mechanic for your Stealthy McStealtherton, you end up with a useful mechanic that isn't overshadowed by the greater ease and equal usefulness of all other combat choices. You could even incorporate something like trap-usage into the regular flow of combat, rather than limiting it to the stealth system and combat initiation. Say one of your hearty melee characters can be put in a sort of "hold off" behavior, set to engage his target while focusing on minimizing damage to himself at the cost of aggression and, essentially, damage output. Perhaps this is some menacing troll or something that would take quite an effort to go head-to-head with no matter how you do it. So your hearty melee person is making sure the troll doesn't run amok, smashing your less armored folk into columns and floors and such, while making sure he doesn't become ensmushed, as efficiently as possible, basically to buy your trap-layer (not even necessarily a stealthy character, in this situation) to set up some kind of elaborate trap. Then, once it's ready, you have your holder-offer deliver some kind of leg blow or stunning/crippling attack just to by himself a few seconds to get his butt out of there, and your whole party runs off past the trap while your trap-layer stands at the ready. When the troll steps onto the trap, the trap-layer springs the trap, holding the troll in place for much longer than any of your combat skills could have, perhaps, while others unload arrows into it and/or hack away at it. Maybe even now your Rogue easily gets behind it for some backstab action. This is difficult to do real-time with when you're trying to control each member of the party to make sure they're there to support the main holder-offer character, but also making sure, manually, that they don't attack enough to make themselves too much of a threat for the troll not to charge them instead, while also making sure the person trying to hold the troll's attention is minimizing his damage at the same time. Sometimes there are behaviors in place beyond the "passive, defensive, aggressive" "stances," but they need to have a lot of care put into them to work well and to provide some sort of actual utility besides simply changing numbers like damage output and damage mitigation. This sort of touches on AI, I suppose, but specifically for friendlies rather than enemies. Your party shouldn't be a burden to control, but you should still get to decide how they go about combat. This drastically adds to the combat flow.

Unless one or more of the developers happen to be telekinetic, in which case I expect NOTHING LESS than a hands-free-crafted world, u_u

^ Haha. I'm glad. Being able to occasionally incite laughter is one of my few strong suits. And yeah, it definitely depends on all the other factors in a given game's item system, but, at a glance, it just seems like it makes the most sense for the more abstract types of crafting. It's really, really weird how our brains tend to accept certain representations of completely abstract things (such as magical item catalysis) over other ones, heh.