Spiral Knights - End looping of levels

End looping of levels

10 replies [Last post]

Sun, 09/04/2011 - 23:22

Quasirandom

I'll start with my proposal, and then come back to explain why it is necessary.

If someone joins a group after the start of a level or goes solo during the level, then start a 10 minute timer that is invisible to players. If the group completes the level or activates a party button, then get rid of the timer. Once the timer expires, the group is restricted so that no new players can join, just like in boss levels. Players already in the group and return to Haven, go solo, or stay in the group as normal. Players fighting mobs continues as normal, and they wouldn't be kicked out of the level. Once the group moves on to the next depth or activates a party button, players can join again as normal.

Furthermore, if someone goes solo, the new group inherits the timer from the old group. If you're in a group that has already had the 10 minute timer expire, then you can go solo. But no one will be able to join your new solo group until you finish the level or get on a party button. If the old group didn't already have a timer active, then going solo would start one, both for the old group and for your new group.

The timer would not allow players to do anything that they can't do now. If you lock your party to intentionally not allow people to join, then the timer wouldn't allow them to join a party that they wouldn't otherwise be able to.

In addition, there should be no timer at all in non-combat levels, that is, depths 0, 4, 8, 13, 18, 23, and 29. This system would not impose any new restrictions on joining at those depths.

-----

First, let's consider the impact on normal gameplay. This would have no impact on the PUG system at all. That only adds players to a group shortly after the start of a new level, which is guaranteed to be long before any 10 minute timer could expire.

Next, it would have no impact whatsoever on groups that don't spend more than 10 minutes between party buttons. That is, it would have no impact whatsoever on the overwhelming majority of parties at the overwhelming majority of depths, as even if a 10 minute timer does start, it would never expire.

Even if a group does spend more than 10 minutes between party buttons or elevators, it usually won't be very much more than 10 minutes. It would be very rare for someone to join a group or go solo near the start of the segment, and then for someone else to try to join through a guild, friends list, or direct invite more than ten minutes later.

Even in those rare situations where it does block someone in the course of normal gameplay, it's probably a case where someone went AFK for a while, and everyone is waiting for him to get on the party button. The late joiner wouldn't actually miss any combat, but would have to wait for someone to come back and get on the party button.

So as you can see, the 10 minute timer mechanic would only rarely impact normal gameplay. People could easily spend hundreds of hours in the game without ever once seeing its effect directly. It's very narrowly targeted.

-----

After that whole discussion, it may not be obvious to some readers what this is intended to restrict. Let me explain the activity that I want to see stopped.

What happens is that a player will pick an easy level with large payouts (typically an arena in an even stratum; the tier can vary depending on the desired difficulty and payouts) and kill all of the mobs up to the first party button. He'll intentionally avoid picking up any of the loot, however. Rather, he'll go AFK, but not let the game kick him out for idling too long. Presumably this is a simple macro. He'll leave his group open so that guildmates and/or friends can join it. And then he'll stay like that for hours or days at a time.

What then happens is that a guildmate joins his group, and then immediately goes solo. In the new solo group, he can pick up the loot that was dropped by everything up to the first party button, without having to fight anything himself. He then finishes the level and goes back to Haven, ending his group. Because it's a level that gives very large payouts, he gets the large payout for the full level, while only clearing some of it himself.

Then he joins the group with the AFK guildmate and goes solo again. And then does it again. And again. And again. This doesn't just let him do one high-payout endlessly. It lets him get the full loot while only doing the work to clear part of it. That's allowed by the game mechanics as they stand, but surely shouldn't be encouraged.

So how does my proposal break this method of looping? As soon as someone joins the original group once, people can only join it again for another ten minutes. After that, the AFK person will have to start over and get back to the level again. Trying to kill mobs without picking up loot is something of a pain to do. So is doing other depths, and waiting for the "right" level to cycle in. It's would also a hassle to sit in Haven and wait for someone else to do the work to set up looping, and then have to jump on it as soon as he's ready.

Furthermore, the work to set up the looping system would no longer allow a bunch of guildmates to loop the level dozens of times each. They'd only get ten minutes. Maybe they'd get to loop it once. Maybe if they hurry, they could do it twice. But no longer would it be dozens of times. This wouldn't completely kill looping levels, but it would sure make it a lot harder than it is now.

Now, I don't know if dropped loot stays forever. I know that crowns, heat, materials, and vials stay for a long time, at least; I don't think I've ever seen them despawn. Hearts despawn much more quickly. But even if everything does despawn, a group could still loop a level endlessly from the very start, where the AFK person doesn't kill anything before going AFK. My proposal would greatly restrict that. Again, this wouldn't completely kill looping levels, but it would make it a lot harder to do than it is now.

Mon, 09/05/2011 - 00:34

Milkman

"He'll intentionally avoid

"He'll intentionally avoid picking up any of the loot, however...It lets [his guild mate] get the full loot while only doing the work to clear part of it"

Just a note: What you are talking about there is a bannable offense. It is allowed by the game mechanics, but it will get you banned, like various other things you can do in the game.

Other than that, while looping is not encouraged by OOO, they are well aware of it and have not yet acted to prevent it. In any case I agree with your sentiment that looping should be stopped.

Mon, 09/05/2011 - 00:49

Hammahtime

@quizzical

I can understand your undertaking of this particular crusade. But this being implemented may actually further alienate bad players. What would you say on average might be the run time between party buttons for Grave yards? Especially for newer players given the amount of roadblocks/monsters/level length and finally the added hassle of phantoms. A 10 minute timer seems a bit excessive. It would probably be on par with the Blast Network fiasco in which the dev's themselves admitted it was excessive. Scale back the timer itself or the idea behind it is too hardline to be of any use.

These ideas while curbing the behaviors of players looping levels doesn't help the case for players who are not as well experienced or capable. Players that were stuck on Jelly Kings palace levels and were waiting for other players to supplement them would be out of luck if no one came to join. They've already implemented a system for stopping players from abusing the exploits associated with looping. As for fixing the exploits for arenas your shields no longer regenerate and maintain a broken status. And in all honesty I'd rather not go down to an arena for the cost of 10 ME for the piddling reward of the first arena wave even if it required absolutely no effort. In terms of earning potential it most certainly is not maximized.

As for it's application during non combat related levels it is impractical. What would stop players from parking a character at depth 13 (which by your plan has no timers for stopping players from joining) and then boosting a party into a depth 14 arena, allowing a player to go down and set up a loop every ten minutes until the gate change occurred and repeat the process.

It's a novel idea, but it seems like it would be difficult to come up with a proper and concise method that wouldn't inadvertently harm poor players or those that have the intention of waiting on others to join them mid run.

Mon, 09/05/2011 - 06:10

Trias

Simpler way to achieve same thing:

Here is a simpler way of achieving the samething.

Generate a unique party ID each time a new party is started (through the "start new party" button).
Each party that is forked from the original party (through "go solo" or being kicked) will inherit the ID from the original party.
The party ID consists of a unique identifier part and a progress counter.
Each time the party steps on a party button (or elevator) the progress counter is increased by one.
The game records the party ID for each player, when he/she leaves party for any reason. (inlcuding disconnect)
Players are only allowed to join parties with an identifier that they had been in before, if the progress counter of that party higher or equal to his own.

This will consistently end arena looping or the looping of other areas that require you step on a party button to begin a fight (which is all the lucrative ones).

Mon, 09/05/2011 - 06:51

Algol-Sixty

while looping is not

while looping is not encouraged by OOO, they are well aware of it and have not yet acted to prevent it.

OOO has acted to prevent the obvious ways of looping. That they haven't closed all the loopholes doesn't mean they haven't acted.

Mon, 09/05/2011 - 12:28

Quasirandom

"What would you say on

"What would you say on average might be the run time between party buttons for Grave yards? Especially for newer players given the amount of roadblocks/monsters/level length and finally the added hassle of phantoms. A 10 minute timer seems a bit excessive."

I don't think you catch the purpose of the timer. The timer does not start until someone joins the party after stepping on the initial party button, and not counting the game automatically throwing people in via the game's random grouping system. In most cases for newer players, the timer would never even start.

And then if the timer expired, it doesn't kick the players out of the level. If the timer expires and players still need another hour to finish clearing the level, they can take another hour. The only thing that the timer does is to make it so that other players can't join the group after the timer expires. Think of treasure vaults as a level where the timer has already expired, for example.

"It would probably be on par with the Blast Network fiasco in which the dev's themselves admitted it was excessive."

The Blast Network timer had much stronger effects than merely saying that no new players could join the group. It was also much shorter than a 10 minute timer.

"Players that were stuck on Jelly Kings palace levels and were waiting for other players to supplement them would be out of luck if no one came to join."

Red Carpet Runaround has a lot of party buttons, so it would be very rare for a timer to expire there. Remember that a party button eliminates the old timer, and a new timer does not start until someone joins the group. Even if a timer does expire, it gets eliminated by the next party button, and then people can join again as normal.

Garden of Goo isn't littered with party buttons the way that Red Carpet Runaround is, but it does still have a party button well into the level. If people are really taking their time and then an hour into the level get stuck and want someone to join, then people can still join, unless someone else already joined more than ten minutes ago, which is pretty rare. Furthermore, if people did join right at the start, then that would be before the first party button, and so the timer would quickly be eliminated.

New players will tend not to have the extensive friends list or guild list of people to call on for help, either.

"As for it's application during non combat related levels it is impractical. What would stop players from parking a character at depth 13 (which by your plan has no timers for stopping players from joining) and then boosting a party into a depth 14 arena, allowing a player to go down and set up a loop every ten minutes until the gate change occurred and repeat the process."

My proposal doesn't completely kill looping like that. But it sure does make it a lot harder and less effective. For starters, an earlier depth in a given stratum will tend to give less loot than a later depth in the same stratum, so having to do a level immediately after Basil decreases the payouts. Next, if it's one player going AFK forever at Basil, then anyone who joins had to sit and wait for the arena level to cycle in every single time. If it's one player going AFK forever at Basil, and then another player going into an arena every time it cycles in and going AFK there, then it takes two accounts to set this up, not one. And the second account can't merely AFK forever; it has to be reset every 10 minutes.

That greatly increases the hassle of looping, while decreasing the payouts. It's not a hard ban on looping, but it would surely discourage a lot of people from doing it. Decreasing arena payouts would also be necessary, of course.

-----

"This will consistently end arena looping or the looping of other areas that require you step on a party button to begin a fight (which is all the lucrative ones)."

I agree that your proposal would largely shut down looping. Given the choice between that or nothing, I'd favor your proposal.

But there are a couple of issues. One is that it could have unintended effects. Suppose that I join a friend's party and do several depths, get to the Core, and go back to Haven. I then want to join a different friend's party that is perhaps at depth 27. Except that at depth 20, the parties split when someone went solo. It's not hard to imagine this happening in a guild with several people who like to join each others' parties for normal gameplay, and not looping. Under your proposal, I couldn't join the other friend's party at all, ever. Saying I can't join at depth 27 because of something that happened at depth 20 is hardly a looping-prevention mechanism.

Next, you call your proposal simpler, but it is not. Or at least from a programming perspective, it surely is not. In my proposal the only coding thing that would have to change is that each party would have one new time variable. Usually the variable is empty. If someone joins a party while in a "real" level through an invite, guild list, or friends list, then you take the current time, add 10 minutes, and store that time as the variable. If you end a level or do a party button, you clear the variable. When someone tries to join a party, you check to see if the current time is later than the stored time in the variable, and if so, you don't let the person join.

When someone goes solo, if there is already a time stored in the old party time variable, that time gets copied into the new solo party. If not, then for both the old and new parties, you take the current time, add 10 minutes, and store that in the time variable for each party.

Now, a couple of paragraphs might seem complex. But it might well take less space to code than it does to describe it in English. All of the operations involved are very simple. The space needed to track it is a fixed one variable per party, and couldn't result in arbitrarily large vectors.

Compare that to your proposal. You would have to have an entry for each combination of a party and a player. That could give you arbitrarily many counters corresponding to a single party, or arbitrarily many corresponding to a single player. You can't get rid of them until all branches of a party have been eliminated, and that's not a trivial thing to check. I don't see an obvious way to store this information that won't either be tremendously wasteful on space or else make it take a serious search effort to see if there is a counter corresponding to the particular combination of a player and party that you're looking for. People who have worked with databases might know of an obvious way to code it, but it's surely not as trivial as what I proposed.

Can your proposal be done? Probably. But it's far from a trivial thing to do.

-----

"OOO has acted to prevent the obvious ways of looping. That they haven't closed all the loopholes doesn't mean they haven't acted."

Whatever they've done hasn't ended looping, so they need to do something else.

Mon, 09/05/2011 - 13:49

Character-Name

The problem is NOT blocking 'legitimate looping'

I'm not going on a tirade to explain how these things work at a code level. I'll just offer a few scenarios that you may or may not choose to block.

* You are at Depth 20. Someone invites you to Depth 24, same gate. You want to join.
* You are at Depth 13 in a full party. Someone asks "Hey, care to give me a jump point?" and you go "Sure! Hey, Kobayen! I'm gonna go solo, invite me back in this party in 10 seconds."
* You are anywhere else in the Cradle. Someone asks "Aaaaagh I need backup save my skin here!" and you go "Sure! Hey Kobayen! Gonna rescue my guildmates, invite me back when I call!"
* You are anywhere in the Cradle. And you go "Shoot. I brought the wrong bomb. I'll go back to haven, invite me back in a minute' kay?"
* You are at Haven. Your friends are at Depth 19. You just left Depth 19. You go "Hey Kobayen! Invite me in!"
* You are at a Boss dungeon. You lost connection for 30 minutes. When you rejoin the game, you go "Hey Kobayen! Invite me back!" and you still can get your tokens, look at that! (As long as everyone sat and waited 30 minutes on the same level. They're such good chaps...)

Think of how many possibilities would be broken for trying to stop this:
* Your guild placed an farm-alt at an Arena's door

Frankly, the problem is the stage, not the mechanic. You could block them from being accessed like you do to a boss level. But that would block you from rescuing someone in there... oy.
The only other option is stopping the invitebot from sending invites. But how do you judge that?

Mon, 09/05/2011 - 22:45

Quasirandom

I'm not sure who you're

I'm not sure who you're replying to. My proposal would very rarely to never block any of your bulleted points other than the farm alt at the start of an arena, and even if it did, it would just be a brief wait for the next party button or elevator, and then you could join. The boss level is an odd exception, as the game already blocks you from joining there.

Mon, 09/05/2011 - 23:22

Trias

@quizzical

"But there are a couple of issues. One is that it could have unintended effects. Suppose that I join a friend's party and do several depths, get to the Core, and go back to Haven. I then want to join a different friend's party that is perhaps at depth 27. Except that at depth 20, the parties split when someone went solo. It's not hard to imagine this happening in a guild with several people who like to join each others' parties for normal gameplay, and not looping. Under your proposal, I couldn't join the other friend's party at all, ever. Saying I can't join at depth 27 because of something that happened at depth 20 is hardly a looping-prevention mechanism."

Well, that also is looping, or at least it is hardly distinguishable from looping the entire second half of a tier.

"Compare that to your proposal. You would have to have an entry for each combination of a party and a player. That could give you arbitrarily many counters corresponding to a single party, or arbitrarily many corresponding to a single player. You can't get rid of them until all branches of a party have been eliminated, and that's not a trivial thing to check. I don't see an obvious way to store this information that won't either be tremendously wasteful on space or else make it take a serious search effort to see if there is a counter corresponding to the particular combination of a player and party that you're looking for. People who have worked with databases might know of an obvious way to code it, but it's surely not as trivial as what I proposed."

Well, counters would automatically expire when a gate closes. A player cant rake up too many counters in a week, especially since each is just a few byte. Raking up 1 KB of counters would already be a lot. This really would be only a few lines to code. (And I believe it is not that far from the current "anti-looping" code.)

Tue, 09/06/2011 - 17:38

BiggestLoser

Legacy Username

Zelda

"If someone joins a group after the start of a level or goes solo during the level, then start a 10 minute timer that is invisible to players. If the group completes the level or activates a party button, then get rid of the timer."

"Furthermore, if someone goes solo, the new group inherits the timer from the old group. If you're in a group that has already had the 10 minute timer expire, then you can go solo. But no one will be able to join your new solo group until you finish the level or get on a party button. If the old group didn't already have a timer active, then going solo would start one, both for the old group and for your new group."

thers a little contradiction there

If someone joins a group after the start of a level then start a 10 minute timer that is invisible to players.
if join group, set timer A to 10

If someone goes solo during the level, then start a 10 minute timer that is invisible to players.
if go solo, set timer A to 10*

If someone goes solo, the new group inherits the timer from the old group.
if go solo, set timer A(new group) to timer A(old group)*

If the old group didn't already have a timer active, then going solo would start one, both for the old group and for your new group.
if go solo, test timer = inactive(however its expressed), set timer A to 10*

thats 3 different actions for the same event and object

i didnt read anything else, because i wana outline this contradiction to prevent any further off-topic fictions based on errors and i would like to support the suggestion

in this rare case, do NOT correct me if im wrong, just vote for or against the suggestion (;

Tue, 09/06/2011 - 20:53

#10

Quasirandom

If there is already a timer

If there is already a timer active or expired, then don't start a second timer, as it would be superfluous. If a timer is expired so that no one can join a group, for example, and then someone goes solo, then both the old group and the new solo group have an expired timer. Thus, no one new can join either of those groups until the group reaches a party button or elevator.

As I explained in post #5, the server wouldn't need to keep some ticking timer in the background. It would just store, this is the time that the timer would expire, so no one can join the group after this time. Clear that time if the group gets on a party button or elevator.

It would also only need to store one time for a group, as if one person joining means that no one can join after 3:25, and then another person joining five minutes later means that no one can join after 3:30, then the latter is superfluous and can be ignored. Once the group gets on a party button or elevator, it all gets cleared, and anyone can join the group again.

Search

End looping of levels