Obsttorte

I don't know what games you are refering to but soulslikes for example wouldn't even work with free saving, as well as other genres. You normally can't save during a race in a racing game, you can't save in multiplayer titles during matches, you can't save during a match in pro evolution soccer. And I guess there are more examples. All of those games work flawlessy and nobody playing those consider this an issue or a restriction. The point is that this influences the way a game, or a mission in our case, plays and feels. Why should mappers not be in control of that. I am so tired of that "argument". It has no reference to the point I am trying to make. it is not about adding a challenge nobody forces anything on anyone. If you don't like it you are not obliged to play it. But others might find it entertaining and even refreshing. And this whole, "you don't have to save if you don't want to". I never stated that there is something wrong with saving often nor that I want to save less. I explicitely stated (several times whenever this discussion arose) that a save mechanism not controlled by the player doesn't imply the progress gets saved rarely. It's the same nonsense that I get to read whenever I criticised that in a mission the ai can be taken out to easely because of either the ai placement, the amount of gears handed to the player or both. "You don't have to take them out". Why on earth should I oblige myself on to not using the tools handed to me by the game. If I have a blackjack, I will use it. It can't be that players are made responsible for fine-tuning a game or a mission for it to be good. That's the mappers job. On the other hand, everytime some bigger change is on the table there is always the argument of not messing up with mission authors work and respecting their intellectual property. When one mapper however decides to use this specific gameplay mechanic in his mission there is immedetially a thread open "that the time for restriction removal mods has come."

A different save system doesn't necessarely equal to less saves. We are not only talking about limiting the amount of saves to a specific number, which I am honestly also no fan of. But saving in specific situations or at specific locations for example. How many saves are done when you can save at anytime also depends on the player. I am for example sometimes not saving for several minutes, which can also be annoying if I mess something up. And although one could state that this is my own fault then, I am not convinced that having to remember to press the save button every now and then is an improvement. At least it isn't very immersion enhancing. On another not restrictions doesn't have to be bad per se. Each game has rules, and basically each rule is a restriction. So is it bad to have rules? And are games that have more rules worse then the ones with less? I think that is oversimplified. As stated above, we are talking about a tool. If used right, it can be an improvement to both gameplay and athmosphere, otherwise it may gets you the exact opposite result. But the decision to let the player save at any time falls under the same category. People just got so used to it as they can do it in almost every game that they automatically reject the idea that a different approach could be good in some situations, as they felt drawn out of their comfort zone. I may repeat that I never stated that fms would get better if they use restrictive savegame mechanics, nor did I say that fms get worse when you can save at any time. Actually I repeatedly stated that the mission design is tied to that mechanic. Current fms are designed with the idea in mind that the player can always save, so they probably work best that way. A different mechanic would in return require a different mission design. So if mission authors would use this from time to time and really take the effects into consideration in their design process, we would actually get fms with a different setup, gameplay and athmosphere (or at least some of that). I don't see how this can be negative.

Which is exactly the case we have here. The game needs to differentiate between stance change and sliding when on ladders or ropes. So the original implementation makes perfect sense. Nope. See above. That buttons also in real life trigger something on key down is a convention, probably as it is most often the simplest way to get things to work, like here trigger on key up was the simplest way to get things to work. Just adding some spice to the soup

Well, realism isn't really an argument here. Or do you quickload irl if you mess up something. And in regards to this and this, I may stress that utilizing a different savegame mechanic doesn't imply that players get restricted or the mission becomes more difficult. I would even state that currently players get restricted much more due to the current mechanic, where reloading a game if you get detected for example is always the easiest option and therefore the option the players will take most likely. It is extremely unbalanced if from all options on the table in such a situation running away use equipment or the environment fight quickload one option provides a much higher usefulness then the others. This is also some kind of restriction if it doesn't make sense to take the other options into consideration. And the increased difficulty that may come from a different savegame mechanic (heavely depending on how often the game safes, which doesn't necessarely has to be seldom) can be easely outweighted by a hugh set of parameters the mission author can adjust. So you can easely create mission of the same difficulty as an average fm or even easier, but in difference encourage a thoughful and tactical approach to the challenges provided in a mission instead of try-and-error-ing through a mission, which imho feels much more natural and in the end less frustrating (with my experience comparing games that use one or the other mechanic). I don't quiet understand why everytime most people tend to assume that such mechanics are used to restrict the player. Why should any dev want that? Especially as a Thief fan, a game that came with a comparable high freedom in player choices to begin with?

It can become a problem if it involves the necessity to change a lot of other stuff. How? You have issues with the delay, I don't notice it because I don't hold the key down, I tap it. So obviously opinions differ, therefore it is subjective, therefore your claim of something beeing a fact is so, too, making it not a fact, but your personal perception. (Which is fine, but you can't expect others to see the world through your eyes). In regards to subjective matters this is exactly the definitions, me thinks. I wasn't refering to stagilov's solution. I trust him enough in such matters to expect his implementations to not be a deal, though.

Just my two cents, but savegame mechanics are a rather fundamental part of game design, and missions should be designed around such fundaments. Just adding savegame restrictions on top of a mission that isn't designed for that is neither creative nor fun. And whether it makes the mission more challenging also depends on the mission. In regards to implementation there are already means for mission authors to alter the savegame behaviour, and therefore players can, if they feel the desire, create mods to add such stuff. On the examples you listed: chronos mode: Having a timer that runs down may encourage the player to just wait. This will become tiresome pretty soon as the mission has to have elements engaging the player in moving forward. If the mission doesn't has this as it isn't designed for that... lethal mode: This approach means that the amount of savegames is tied to the amount of health potions available. As they are mostly placed in a rather thoughtless manner (they are for example part of some prefabs), the changes in gameplay will be erratic. treasure mode: Similar to the above loot placement is completely erratic in most missions. The amounts placed as well as the value normally don't follow any logical order and therefore saving tied to the loot amount found will have very different effects depending on the mission it gets used in. ironman mode: Length and difficulty of missions differ heavely. Some also include parcour like parts or a high amount of verticality, both of which makes dying more likely. Restricting it to one save without taking these aspects into consideration is pretty erratic either. As the person who both suggested as well as implemented the possibility for mappers to modify how saving in their fms work I may add that it was never my intention that this gets used to increase difficulty (it's an artificial approach similar to kill or ko restrictions and no good game design imho) added on top of existing missions A specific game mechanic isn't good or bad per se, it doesn't guarantee you fun or challenge. It is a tool that has to be properly used. My impression is that due to the lack of stealth games many people relied on playing games like thief (or fms or tdm) over and over again, getting bored or aren't challenged after a while and started to invent house rules to get more entertainment out of it. This led to all those, I never kill, I never get detected, I leave everything behind the way I have found it etc... players. Players who restrict themselves to have fun, which basically means that the game as it is isn't fun anymore. More tools (like the possibility to alter savegame mechanics) allow mappers to try to move away from the standarized gameplay, mix it with other things or other genres to get even experienced players out of their comfort zone and into an engaging experience (something that is very common in board games, but doesn't happen all too often even in professional computer game design). One that may cause them to make use of their possibilities again instead of restricting themselves by not using them at any means because they know the game would get boring pretty quickly if they do.

If you start your argumentation by stating that this is something nobody wants (so refering to the subjects) you can hardly conclude it to be an objective matter. The fact that almost nobody complained about it beeing like that doesn't mean that nobody noticed it. I was pretty aware of the behaviour all the time, but didn't considered it to be an issue but just part of how the controls work. And if a key is used as a toggle, I only tap it and don't hold it down for long. Other users may do it differently and therefore have a different perception, but that is, as said, subjective. And as you wrote yourself the majority of players don't seem to consider it an issue. So we are fixing something not really broken but therefore open up a can of worms in regards to how climbing works. In the beginning there was the question on why it was implemented like that, and there was the suspicion that it may have been due to limited access to the source code. But after considering all aspects that come as a consequence of the proposed change I think the reason is simple to get an easy implementation of the slide ladder feature: If the key gets released and the player hasn't slided, change stance, otherwise do nothing. Pretty straightforward compared to what we trying to do now. That doesn't imply that what Daft Mugi is trying to achieve is necessarely bad, but the question may be valid whether the amount of possible issues introduced simple due to the amount of stuff that has to be taken into consideration for this change stands in a reasonable relation to the issue that should be solved, especially if the vast part of the players may not even consider it as such.

@wesp5I was actually responding to Oktokolo. I am all with you that the setup as is isn't optimal. Similar to the ai's acuity it would be best if mappers would adjust the respective values for their fms. I don't think that is the case mostly, although I may admit that I never really checked. I know that I haven't done it either in my fms back in the day (in addition to a dozen other things I messed up )

That would definetely make more sense. While the TDM world does indeed not has to work like real life in all its aspects, teh similarities will make the player assume that this is the case. So many players may simple not get the idea that the could use the glasses in that way. In addition we already have a mission that features these glasses, and they were tied into the story. Reusing these gadget over and over again will probably become boring by the time, not to mention one may not want to run around with those on over and over again. It may be worthwhile to think about different usecases of this feature. Combining it with cameras might open up new possibilities. Note that, although it is called x-ray it doesn't have to be used in that manner. Basically you get to see something else when applied, which isn't the definition of x-ray per se.

I said these adjustments are possible. I fairly doubt mappers make much use of them. As far as I can tell the only thing that currently differs are indeed the objectives (with some exceptions, Springheel made use of them in some missions iirc).

Yeah, it takes very long for them to calm down. That is something Thi4f did definetely better. While many complained that the compareable fast cooldown times are unrealistic and easen the game, they at least provided a good gameplay which does not require you to either quickload immedetially or to sit on shelf unreachable to the ai anyways for minutes just to wait for the them to calm down again, which at least gives you some time to make yourself a coffee. That is you then. However, both TDM and the original games as well as almost every other stealth game hand the player weapons and other not so stealthy gadgets. So combat and fleeing has always been part of the game mechanics. It is just that a little stealth elite that thinks, that ghosting a mission is the way it is meant to be played. An attitude that imho comes from the lack of stealth games in general, where people replaying the same games over and over again start adding house rules for a challenge that they after a while they considered to be the standard. Something that sadly also shows in the TDM fms, where gameplay easely falls apart if you do not choose a ghosting approach and also seen in the reactions when criticising that, where typical responses are that it would been better to not use the blackjack or the other weapons too often making me wonder, while I get them handed out in the first place. Death means defeat. Everything else should be considered challenges to deal with.

The image on the camera screen is exactly that, an image rendering the view of the camera. All information on what entities were visible on that image is gone. The only way that I can think of would be to render the camera view both in xray and default and then pick the on depending on whether or not the player has the xray glasses on. This doesn't make much sense to me, though. I mean, if you look at a screen through a xray machine would you really expect that the xray move through the screen and the cables to the camera, from which they are emitted and then reflected again through the camera all the way back to the screen. Or what scenario do you have in mind?

I think it doesn't hurt to let the default be on low, less challenging levels. However, it might be worthwhile to somehow communicate it to players that they can increase the settings further (and may do so once they played a bit to get the experience the mission authors are aiming for) should communicate to mappers that acuity settings are more or less average values that need fine-tuning depending on the situation/geometry the ai is used in. I fairly doubt that there are a lot of mappers, if any, who actually make adjustments to that values. It may also be a good usus (by mappers) to make it difficulty dependent (even Thief Deadly Shadows did that)

Ko immuntiy and alert state are tied together. So if the ai calms down, you can knock em out again. It was a lengthy post was anyone really doubting that Well, in regards to making it a emergency feature and not the natural way of moving it probably makes sense to add a suspicious sound. Either that or reduce the delay and may give the ai the ability to open the doors faster when alerted, too. As @Oktokolo stated it looks really akward when alerted guards open doors in slow-mo.

@Daft MugiYou misinterpreted that sentence or I could have written it better, but either way, my intention was not to offend you. The "you" in that quote doesn't mean you personally. Would have probably been better if I have written "one". And I explicitely wrote earlier on that I only skimmed through the thread. Quoting one sentence from someone you haven't had communicated with yet and getting upset about your interpretation of that sentence isn't a nice move either. I'm, like most of us, no native english speaker. On topic: you cannot please everyone. If you try to, you end up with tons of settings and adjustments. And stating that this is not good doesn't mean that the work you have done isn't good. We need a compromise solving the issues (what you have already done) and may improve the system in a way the majority can agree on. Not twelve solutions to choose from. At least these are my two cents.

The best way (but not necessarely the easiest one) to tell players in which direction a door opens would be to us doors that actually have hinges. Irl you mostly can tell in which direction a door opens by its look. A bit easier would it be not to place the doors in the midst of a doorframe, but close to the side it opens to. However. I may stress again that the intention is to make fleeing as an option more attractive. This does neither imply that fleeing is always an option nor that it is without risk, especially if the player doesn't invest thoughts into it. And turning TDM into a parcour game isn't the intention either. You should not run through a mission constantly using this feature. Just an option in case you mess things up. The way you describe makes sense generally. But in the case of a stealth game not so much. It actually reads as if you would describe a match in Unreal Tournament

Multilooting happens under two conditions: It starts when the item frobbed was an item that goes to the inventory (loot, ammo, et. al.). This happens on frob key down while said item is frob hilighted. Pressing frob with nothing hilighted has no effect. The multiloot feature disables itself two seconds after the last item was added to the inventory, even if the frob key is still pressed. I wrote that a few posts above. The whole setup is made in a way that it cannot be exploited in a manner described by you (I already accounted for lazy thiefs )

Sorry, obviously the changes didn't get saved, why ever. Here is the fixed version. fastdoor.zip

I never intented nor wrote that. All I said is that the player should be treated as standing when climbing, and that the stance displayed by the icon next to the light gem reflects the stance the player will get into once climbing/mantling is finished. So exactly as it works when in tight spaces where you cannot stand up. But if a game is set in a scenario that is close enough to real life, players will derive how things work from how they do in real life. This is the fundament of the player expectations. There is a reason why many games, both digital and board games, choose to use a concrete scenario instead of beeing abstract, although in many cases the scenario isn't that important. It reduces the amount of rules you have to explain to the player. While I obviously agree with the first, I have to disagree with the latter, at least in the context used by you. While it is fine to add different possibilities to approach the problems laid out to the player by the game (as it makes the game fun) adding different options just for the sake of having them is not and is only feature creep, and therefore bad game design. If players expect to be exposed when climbing, and I am sure the majority does, there is no reason not to handle it like that. And I bet many assume that there is only one way to climb a ladder (head down with your back to the wall ). @Daft MugiI am against adding tons of cvar. Besides the possible bugs introduced players shouldn't have to deal with tons of settings, especially new ones that have no idea how they affect gameplay. In addition it would further clutter the menu. As far as I understood it the whole point is to improve an existing mechanic. So you look what the potential issues are and solve them. Providing dozens of different solutions and leave it to the player to find the one that more or less works isn't a solution. It is ok to have some aspects tweakable, like how long the crouch key needs to be pressed before sliding begins. Stuff that allows you (the developer!) to fine tune things for improvement. But your are basically asking the player to define core gameplay mechanics, which isn't his task. So my points stand: Always stand on ladders, ropes and when mantling as well when sliding down (therefore removal of the speed reduction used when crouching) crouch key defines the stance after you have finished movement the toggle is when crouch key is pressed, not released (I think that was the initial point)

That wouldn't work with the current implementation, though

Extract this into your TDM folder: fastdoor.zip If you are using SVN or have extracted the game archives, you would have to backup the original files first. Otherwise there is nothing to do. Note that I haven't added propagated sounds yet, so the ai won't notice the fast opening. Sometimes the doors opens way faster then intented. Don't know yet was causing this. I would assume that if a player runs away, he runs into the direction he is coming from, hence knowing in which direction the doors open. If he chooses to run into a different direction he takes a calculated risk (he could also run into a dead end). That a doors opens into your direction when running away can happen now, too. I don't see that this gets worsened. It's the opposite. You can hardly run into the door if you approach it slightly from the side. That's more or less the idea. It is still not the most simple move to be done when chased imho. And as stated, the parameters can be tweaked. The shorter the delay is between frobbing the door and it closing the better the timing of the player has to be. Currently it is half a second, which works pretty well. You can alter the scripts and use lower values and see if you get the timing right without blocking yourself. Yes, or something maybe only elite guards are capable of. I would like to have a minimum standard here. If this is done differently in every FM, it might gets frustrating otherwise. It's like if the water stim of the water arrows would have a different range in every FM, or the jump height of the player would differ. It is something mappers can do to fit the theme of their FM, but it should be set in a way that the majority of the mappers don't have to change it to get a proper gameplay. The opening speed is a multiplier. So if the mapper sets up a door to open slower (because it is heavy, for example), the fast opening will also happen slower. The delay when closing the door is fixed, though. In this regard it would be worth considering what one would expect here. I assume that slamming a door shut behind you is something that works worse with heavy doors, so the delay might be lower if the door opens slower.

Sounds interesting. It would neglect the purpose a bit if all ai could use it (as it is intented to give the player some advantage), though. I need to think this through.

The amount of enemies, their acuities and other settings, the amount of equipment, whether or not a door is locked and how difficult it is to pick it, patrol routes, whether or not an entity is present (which means anything from items to models blocking the way) and if randomized, the probabilities. Light radii and brightness, at which alert level an ai switches from on state to another, whether the ai is carrying a torch .... There is actually a built-in difficulty editor in DarkRadiant which allows to make difficulty dependent changes. (And it was already present back when I joined, so a decade ago). But that is just the fundament. You can also alter aspects of the mission via script that are not applicable via spawnargs and entity definitions.

I think the sound should be somewhere between the noise of a heavy object falling and a noisemaker maybe, so that nearby guards get alerted but not far away ones. I don't checked the numerical values yet, though, so this is up to tweaking. How about the settings? Do you think the timing is fine or would you change the values?

That's what the difficulty levels are for. Obviously I was refering to the highest difficulty. Sadly this quiet rudimentary feature is almost unused. It should be possible to balance a mission so that under the lowest setting a newcomer can pass it while under the highest setting a veteran gets challenged, and the second setting somewhere in between. That would be three difficulties then. And I consider myself definetely not an uber player. I am way too impatient for that.