Esta decisión se tomo en un encuentro entre pokerstars y los "representantes" de los jugadores elegidos en 2+2
Ratholing
Los razonamientos que hemos perpetrado para encargarnos del ratholing ya fueron posteados con todo lujo de detalles. Nuestro foco ahora tiene lugar determinando que exactamente hacer, para entonces ejecutarlo.
Queremos encontrar una solución preventiva en vez de una solución castigadora. Castigar a los jugadores crea una experiencia negativa para clientes que pueden no conocer las reglas. Y también conlleva demasiados recursos . Los casos de violaciones de reglas son raras veces lo suficientemente claros como para ser manejados rápidamente. Los jugadores que esten violando las reglas pueden no sentirlo incluso si los datos muestran que lo estan haciendo. Los jugadores también pueden sentir que otros jugadores específicos están violando las reglas basados en un pequeño número de incidentes cuando el ningún caso los datos dan tal tendencia a largo plazo, dando como resultado la frustración del jugador de que las reglas no están siendo aplicadas
Estamos de acuerdo con alguna cantidad limitada de ratholing y específicamente queremos protegerla. A veces los jugadores se encuentran en posiciones incómodas donde un jugador muy agresivo tiene posición con un stack efectivo muy deep. Esto ocurre tanto para jugadores de 100bb como para los de 40bb. Adicionalmente, los jugadores con pequeños balances en las cuentas pueden ganar un pot y querer dividir sus fondos a través de mesas múltiples.
También queremos proteger la habilidad de jugadores para jugar sesiones a través de muchas mesas, Comprando por el mínimo en cada una. Con tal de que no hagan ratholing, esto no es un problema.
Esto nos deja con el reto de definir muy precisamente el comportamiento que queremos terminar de modo que el comportamiento queremos permitir no este incluido. Necesitamos crear una definición verbal que sea fácilmente entendida por jugadores de póker y una definición técnica correspondiente que pueda ser codificada en nuestro software.
Querríamos hacer eso en una forma lo suficientemente simple, al igual que con todas nuestras mejoras. La simplicidad no sólo beneficia el tiempo de desarrollo y comunicación, sino que también las soluciones más simples tienden a ser más sólidas a largo plazo. La complejidad abre nuevas posibilidades de que imprevistas normas de conducta podrían ayudar a los jugadores a eludir el espíritu del cambio.
No hemos tenido éxito en encontrar tal definición que entrara tanto en nuestros estándares normales de simplicidad y que correctamente aislara el comportamiento problemático. En algún punto a principio de este año, nos resignamos a considerar soluciones más complejas.
Gracias a un post del usuario de 2 +2 ' mme ', logramos una definición muy precisa. Y les proveímos un documento de 18 páginas a todos los representantes de los jugadores que esbozaron la solución. Este documento de requisitos del negocio (BRD) es lo que le proveemos al equipo de desarrollo cuando pedimos una nueva característica. Habíamos hecho muchas ronda de revisión y edición en el BRD ya.
La premisa básica de la solución es que rastreemos los tamaños del stack de los jugadores cuando dejan mesas y entonces se les impongan buy-ins mínimos apropiados cuando ellos ingresen a otra mesa. Unirse una mesa crea una ' identidad de stack' para ese tipo de la mesa. Por ejemplo, si fuera sentarme en una mesa de 40-100bb con 40bb, entonces me levantara de la mesa con 67bb, yo ahora tendría (40bb-100bb) mi stack#1 fijado en 67bb.
Cada jugador tendría un número maximo de stacks en cada tipo de la mesa, con el tipo de mesa definido por el rango del buy-in. El número maximo del stacks sería igual al maximo de mesas del jugador (para mesas normales) y el maximo de mesas dividido en 3 (Zoom). Así un jugador podría hacer una sesión completa con el máximo de mesas con el buy-in mínimo,pero si dejaran cualquier mesa con más que el buy-in mínimo, entonces necesitarían volver a emplear la misma identidad de stack al entrar en otra mesa del mismo tipo.
Por ejemplo, si compro en 24 mesas (40-100bb) con 40bb cada una, me doblo en una a 80bb y salgo, entonces tendría que comprar al menos 80bb si entonces intentara entrar a otra mesa de entre 40-100bb. Digamos que hago esto. Entonces si pierdo 20bb y salgo con 60bb, la siguiente mesa que entrara podría entrar con 60bb. Esto asume que he estado en las otras 23 mesas todo el tiempo; Si hubiera dejado esas mesas, recibiría la opción a comprar por el número más pequeño de bb disponible de mis identidades de stack(el numero mas bajo con el que sali).
El zoom sería considerado un tipo separado de mesa como es 50-100bb, pero las mesas PLO y NLHE 40-100bb usarían las mismas identidades de stack.
Hemos respondido al angleshooting lo mejor que podemos predecir. Por ejemplo, si compras en una mesa de stakes significativamente más bajos que en el cual creaste tu identidad de stack, estás todavía atado por el número mínimo de ciegas grandes en el buy- in pero tú no puedes reducir, sólo puedes aumentar, el tamaño de la identidad de stack al dejar las mesas. Esto le impide a los jugadores doblarse en high stakes y entonces reducir su buy-in de regreso a 40bb perdiendo dinero en stakes mas bajos.
Las identidades caducan después de un período fijo de tiempo que es configurable. Configurar este período de tiempo es desafiante. Mientras más es, más efectivamente prevenimos comportamiento indeseado, pero más probablemente estaremos prohibiendo el comportamiento que queremos permitir.
Nuestro pensamiento actual es que las identidades necesitarían fijarse para caducar después de 18 hasta 20 horas. De este modo un jugador podría comprar en 24 mesas a 40bb, podría jugar una sesión completa y ganar grandes stacks en ellas, y entonces podría regresar el día siguiente a hacer lo mismo. 18 hasta 20 horas parecen más razonables que 24 ya que los jugadores no pueden estar supuestos a iniciar su sesión en la misma hora exacta cada día.
Lo negativo de esta configuración es que eso permite más ratholing que nos podría gustar de aquellos que eligen tomar ventaja completa dentro del sistema. A un jugador con un cap de 24 mesas que le gusta jugar sólo 6 mesas a la vez y está dispuesto a jugar tanto Zoom como mesas regulares podría hacer gran ratholing al día antes de alcanzar su cap de identidad para ambos tipos de la mesa.
Hay opiniones diferentes en lo que se refiere a si un jugador en 6 mesas haciendo ratholing 3 veces está haciendo cualquier cosa funcionalmente diferente que uno de 24 mesas que se une todas las mesas simultáneamente y entonces deja cada mesa después de doblarse. El impacto neto en el resto de la piscina de jugadores es el mismo, pero la oportunidad de cada accion tiene más la apariencia de ratholing. En todo caso, este comportamiento sería admitido bajo el sistema.
Hay también una preocupación con jugadores que han aumentado su maximo de mesas pudiendo ejecutar ratholes muy eficazmente. No somos capaces de fijar un número más pequeño de identidades de stack que el número maximo de mesas del jugador . Si un jugador tuviera 16 identidades y un maximo de mesas de 24,
¿Cuales serían sus opciones de buy-in cuándo se sentase en la mesa 17?
Los jugadores han sugerido que proactivamente se rebajara el numero maximo de mesas para jugadores que no están haciendo uso de su máximo número de mesas concurrentemente sería una opción. Algunos sugerían que debiéramos hacer esto no sólo para jugadores con cap por encima de 24, sino que también para esos con cap de 24 que sólo están jugando 12. Soy escéptico que esto podría ser implementado sin crear más problemas de los que soluciona. Los jugadores cambian su comportamiento de vez en cuando; un jugador que ha jugado 8 mesas por años sin causar cualquier problema puede no estar contento de encontrarse con que no puede intentar saltar a 16 mesas si lo decide. Tenemos un montón de clientes; revisar tales casos manualmente no es una solución deseable.
No pensamos que el multi-accounting para sortear las restricciones sea un gran problema, ya que las recompensas VIP son una fuente importante de ingreso para ratholers que hacen multitabling masivo.
Es difícil describir una solución de 18 páginas en un post del foro, pero lo antedicho debería dar una buena idea de cómo surte efecto y sus puntos debiles identificados.
Estamos actualmente haciendo investigación técnica significativa para identificar qué% de ocurrencias del ratholing éste prevendría si es implementado hoy, basado en una definición imprecisa de ratholing. Con tal de que el% sea significativo y ninguna mejor solución se presenta ahora mismo, seguiremos hacia adelante.
Habíamos esperado implementar esta solución en la primera mitad del año como he dicho en múltiples veces y nosotros teníamos pensado hacer eso, pero es claro en este punto que no vamos a alcanzar la fecha tope. Estamos haciendo todo lo que podemos para tener la solución lista para el verano. Es sumamente decepcionante para mí de que no logramos nuestra meta aquí, como sé que es decepcionante para muchos de ustedes.
===================================================
Fuente: http://forumserver.twoplustwo.com/showpost.php?p=38569978&postcount=22
Lo intente traducir lo mejor que pude con mis ingles basico 
