Make yourself lighter to drag

[SekoETC]

If you're going to implement it, a mechanic for resisting dragging should be implemented before self-dragging is changed. It would mean that for a moment there were two protection mechanics existing side by side, but that's better than removing the only method of protection we currently have.

[marginoferror]

I'm not really talking about implementing a protection from dragging (although a "handcuffs" item, which can either be used to restrain someone, or to lock yourself to an immobile object, is an attractive idea). I mean, let's look at why dragging is overpowered and overused and what we can do to fix it on a basic level.

[formerly known as hf]

That's quite annoying, since I've lost a few characters after dragging - I don't mind the 'quirks' of Cantr, but I do think we should do more to advertise the slightly more obscure ones.

This doesn't make a whole lot of logical sense - and, yes, I know the wiki is there, but as a player of four years, I'm surprised that I've not come across this.

Obviously, some people have worked it out, and it's then spread around by word of mouth or seeing it in game. Which basically gives a massive and unfair advantage (given how central dragging is in all kinds of 'conflict' in Cantr) to those who are in the know...

I remember when poeple would ask about 'lockpicking' and the response would be 'FOIG'... Those days seem to have gone now - thankfully - but the various 'tricks' to Cantr - such as those around travelling, project timing etc. should probably be documented somewhere...

[Tiamo]

All the more reason to get rid of this kind of quirks, fkahf.

[SekoETC]

I'm not saying that a protection from dragging should be infinite as it is now, or that it could only be ended by the person who's doing it. I'm saying it should just make dragging considerably harder.

My suggestion:

For a method of protection, add a project called Clinging. There would be several possibilities for what you could cling into. Door frames for one, since self-dragging has been associated with buildings. Another thing I thought about is landmarks, and why not any stationary object? Although it would be funny to see someone clinging to a spindle, knowing how light they are in real life, so I wish that it was limited to objects that are heavy enough.

If the target is capable of moving then if the target moves, it should either break the clinging project straight away, or increase tiredness of the clinging person on each travel tick according to the speed or weight of the moving target. The target wouldn't actually be moving while being held, but if it was a boat (small ones could be clung into), they could still undock and choose a direction for undocking, and the undocking would be processed when the clinger gets tired enough to let go. If it was a land vehicle, a road would be picked to start pulling away from their grasp and when the clinger's strength runs out, the vehicle would be moved to the pre-selected road. Note that a person alone could only hope to hold back a small vehicle such as a dinghy or a bike and maybe not any longer than an hour, but if several people were clinging to the same moving target, it could be held for longer.

Also a person could cling to another person. I'm not quite sure how it would work though.

People could use "pull away from project" to stop someone from clinging, but the negative effort of the clinger would be reduced from their dragging effort, so generally it would require one more dragger in order to succeed.

If clinging is implemented, dragging yourself could be changed to something that works instantly. In that case it should cancel the project if you don't have a key to the target.

[Tiamo]

Seko,

this 'clinging' project would have to be started in advance, before the dragging attempt is started? And as it is a project the player cannot work on another project at the same time?

[formerly known as hf]

I started a new topic in the GF, suggesting that we really should publicly document and advertise this type of thing.

All the more reason to get rid of this kind of quirks, fkahf.

I'm not against this example, and others I can think of per se - I think they add a depth to gameply that otherwise wouldn't be there. Removing them without thinking properly about an alternative would be damaging.

But, rather than hording this knowledge, it really should be shared. otherwise new players and players like myself are at an unfair disadvantage. With the hope that some of these things may be 'fixed' at some point, I think, in the meantime, players should be willing to openly share and advertise these tricks. So I added a wiki page:

http://www.cantr.net/mwiki/index.php/Tips_and_Tricks

[Tiamo]

fkahf,

with 'get rid off' i don't mean just remove it, but, if necessary, replace it by a more realistic, fair and publicly known procedure.

[SekoETC]

Seko,

this 'clinging' project would have to be started in advance, before the dragging attempt is started? And as it is a project the player cannot work on another project at the same time?

Yes. Although I don't see why it couldn't also be started also after a person realizes they are being dragged. In that case their effort would be reduced from that dragging project.

[marginoferror]

I'm not really sure this is the right direction to move in. If dragging doesn't already assume some level of resistance, why does relative strength matter so much?

Part of the problem is that dragging is used for two completely different things. One, dragging is used to move sleeping people around for peaceful purposes. As a ship captain I use this all the time.

Two, dragging is used to move an alert, possibly violent person to a locked room during combat. Or, possibly, to take an unsuspecting victim by surprise; but presumably in real life if you try to drag someone somewhere without warning, they'll fight you.


Clinging would address this somewhat by making it possible to avoid being dragged in an emergency, IF you happen to be awake or plan in advance. But I would rather go in the opposite direction:


1) Make dragging in peaceful situations unnecessary (maybe by making it possible to expressly give a specific person permission to move you around, or by some sort of system where you can specify if you are "alert" and ready for combat/resisting drags, or not).

2) Make it possible to try and "subdue" an opponent, at the cost of taking a penalty in combat. The idea here is to give a way to keep someone from attacking anyone else OTHER than dragging. Dragging is overused because it and execution are the only ways to keep a violent person from attacking random people. This would require significant design work to make sure it's balanced properly.

3) Make dragging something that can only be done on a subdued opponent.


Don't worry about programming complexity; I'd rather have a little bit of complexity in code by design than have a patchwork quilt of fixes after fixes. That's what I'm joining the department for. This will need some refining, but I think it's a better direction to move in. However, if the community does agree that a big change like this isn't necessary and the clinging option is a better way to do things, I'll be happy to implement that instead.

[Tiamo]

Hmm, let's try to see what the options are. What can you do to avoid being dragged (supposing you are unwilling)?

1) you could evade, run away.
If you do this before te dragging has started this will suffice, so you will have to do this beforehand, or be alert and decide quick enough.

2) you could fight your oppressor(s), by attacking him/them.
As long as you can use a weapon it will be very hard for an attacker to start dragging you without being stabbed and probably killed. A mob would have a good chance though of disarming and overpowering you eventually.

3) you could counter your opponent and try to drag him somewhere.
This is simply a contest of strengths. The one with the most support will probably win it in the end. But getting this support means all characters involved will have to be alert, and probably online.

4) you could try to cling onto something immovable, or someone else.
This makes it harder to drag you away, but not impossible. Some extra strength is needed to break your hold.

5) you could tie yourself onto something immovable or onto someone else.
This will make dragging impossible unless the attacker can somehow untie you.

6) if you are sleeping, or surprised, there really is no defense.
The dragging will simply proceed and be successful if enough combined strength is applied.

What happens if the victim is not alert, not aware of a possible dragging attempt? Option 6 i guess. End of story.

What happens if the victim is not prepared, but online? If he (and his friends) are quick enough options 1 to 5 would be possible, otherwise option 6 will be the result.

What happens if the victim is prepared? He should be able to choose from options 1, 2, 4 or 5, even when not online. This is what Ulo de Tero called 'undraggable'. There is no guarantee the defense will be successful though, especially when there are (too) many attackers.
Being prepared would mean the character will have to be 'alert' and has made a choice as to how to react to a possible dragging attempt. Being alert would mean the character cannot be working on anything but the 'alertness project', even if nothing actually happens.

What do you think, does this make sense?

[UloDeTero]

What happens if the victim is prepared? He should be able to choose from options 1, 2, 4 or 5, even when not online. This is what Ulo de Tero called 'undraggable'.

Just to clarify my point:

In my idea, people could still be dragged but when they login and see their character being dragged, they can decide whether to assist or resist (or maybe even 'break' the drag). This seems to me much simpler than creating a whole 'clinging' system and requiring resistance/clinging projects.

An 'undraggable' option, if possible, would simply make the character alert and, I guess, automatically resistant.

You've to think about how these things would work in real-life. If one person tries to drag another person, that person will react and either go along with it (if the person is guiding them somewhere,etc) or will resist. Someone guarding or something similar would be extra alert and therefore more difficult to move/drag.

Adding extra people to the mix only complicated things slightly. Surely the combined strength of the draggers should be compared to the strength of the draggee. In other words, a gang of draggers would easily be able to drag a person, whereas one person would find it very difficult if not impossible.

If someone noticed a gang dragging someone off, they could try to help the draggee. This would probably work as a kind of 'anti-dragging' project, where the combined strength of the draggers would be compared to the combined strength of the draggee and associated 'anti-draggers'. This would simulate a struggle between the two groups.

I'm kinda tired. I hope I explained this properly.


Um.. so I guess when I say "undraggable" I mean "alert and resistant" *shrugs*

[Missy]

But it isn't something that works. It's just something that's broken in a different way.

Let's get the design right. If the programmers don't get around to it, fine. Then we won't get around to fixing the programming bug on its own either. But if we do get around to addressing dragging, we'll need some sort of design that tells us what the community thinks is best for the game.

Ever hear of the saying, "If it's not broke, don't fix it?" This is just one of those things.


The last damn thing this game needs is another genre of players trying to quirk the mechanics of the battle/drag system. We go through this like once every other year. Does this game never get done thinking about how better to whack someone? What's wrong with coming up with plans IC that you have alternative plans in case your first plan doesn't work? You know, if you don't get to drag someone away because you helped them into a locked building, ditching the idea and running as fast as you can or calling all your army to break down the lock. Instead, you think there has to be an implementation so you don't have to come up with those things.

[marginoferror]

I think the rules as they are are very, very broke. It's hard to specify exactly how they're broken since there are no overriding design principles for the game that I know of, but the current system is not intuitive (i.e., a new player couldn't possibly understand them without specialized knowledge of the game) and is loaded with things that make no sense whatsoever. The system is so poorly designed that players are seizing on a programming bug as the mitigating factor that makes the system usable at all!

It is harder to roleplay when the mechanics of the game follow no overriding logic whatsoever. IC roleplaying opportunities would be better with a more realistic system.

[Solfius]

I think the rules as they are are very, very broke. It's hard to specify exactly how they're broken since there are no overriding design principles for the game that I know of

The single most important thing in any software project is the design.

It specifies what, why, and sometimes how. It also provides the direction and focus by making the goals of the project explicitly known.

Does Cantr have any explicit goals to guide it's development?

Does the GAC/GAB or whoever is responsible want the game to develop any more, or are they happy with it as it is?

Rather than trying to fix individual things we ought to take a top down approach and decide just what Cantr is trying to be, what it's trying to achieve, what are the goals of the game, and then we have the measure we can use to evaluate all features of the game to see if they're good or bad for the game.

Once you have the goals written down, you can produce a design that achieves those goals, and then work towards implementation.

Cantr is a complex software system, I'm of the opinion it needs to be treated as such to achieve the full potential of its concept. That requires a software engineering approach and knowledge of game design.

I think the best thing staff can do regarding development of the game is read up on game design and software engineering and apply that to Cantr.

(I'm not saying that the staff are in a position to do that; I'm just saying that in my opinion that would be most beneficial to the game's growth)