Normativa de roleplay

Cada decisión lleva una etiqueta para saber qué está cerrado y qué no:

1.1. Finalidad

Esta normativa existe para que todos los jugadores vivan historias creíbles, criminales, policiales o civiles, sin que el juego se rompa por abusos, lagunas o errores técnicos. Sirve de referencia tanto para quien entra por primera vez como para la administración que debe resolver conflictos.

1.2. Ámbito

Se aplica a:

• Todo el servidor y a cualquier actividad que ocurra dentro de él.
• Todos los personajes, sin importar su antigüedad, rol o facción.
• La comunicación IC y OOC por cualquier canal que el servidor ponga a disposición (voz, texto, comandos y Discord oficial).
• Los reportes, tickets y solicitudes administrativas.

1.3. Principios

1. Coherencia: toda acción debe tener sentido dentro del mundo del juego.
2. Equidad: las mismas reglas para todos los jugadores, sin excepciones informales.
3. Proporcionalidad: la sanción depende de la gravedad, la intención y la reincidencia.
4. Respeto a la escena: el rol se negocia con las personas implicadas, no se impone.
5. Prevención del abuso: ninguna regla debe poder eludirse aprovechando un hueco del sistema.

1.4. Contenido no permitido Propuesta

No se permiten roles que:

• Promuevan odio, discriminación por origen, religión, sexo u orientación, ni acoso dirigido a personas reales.
• Incluyan contenido sexual o de +18 sin consentimiento explícito de todas las personas implicadas.
• Traten temas de política, ideología o religión de forma que ofendan a otros jugadores fuera del personaje.

Si el tema de una escena incomoda a alguien fuera del personaje, cualquier jugador puede pedir que se cambie o se cierre. Esa petición debe respetarse sin preguntas.

1.5. Carácter de la normativa

• Esta normativa puede cambiar. Los cambios se comunicarán con antelación por Discord oficial.
• Las reglas se aplican desde el momento de su publicación. No se sancionan retroactivamente conductas que no estaban prohibidas en su momento.
• Donde la normativa no llegue, decide la administración según la sección 14.

2.1. IC y OOC

Regla básica: lo que tu jugador sabe no siempre lo sabe tu personaje. Si lo viste en un stream, en Discord o en otra escena a la que tu personaje no asistió, no puede utilizarse dentro del rol.

Ejemplo correcto: un jugador oye por Discord que otro personaje tiene una caja fuerte en su casa. Su personaje no sabe nada de eso y debe averiguarlo por medios IC.

Ejemplo incorrecto: el mismo jugador acude a esa casa a robar la caja fuerte porque "lo ha leído en Discord". Eso es MetaGaming.

2.2. Conceptos de infracción

Para cada concepto se indica la definición, la conducta limitada, un ejemplo de infracción, un ejemplo correcto y las consecuencias posibles. Las consecuencias son orientativas: cada caso se valora según la sección 13.

MetaGaming (MG)

• Definición: usar en el personaje información obtenida fuera de la ficción, de forma intencionada o por error.
• Conducta limitada: cualquier decisión IC basada en conocimiento OOC.
• Infracción: un personaje avisa a un miembro de su banda de que la policía ha conectado un agente nuevo, porque lo vio en el chat OOC.
• Correcto: el personaje reacciona a lo que puede ver o oír; si no lo sabe, pregunta IC o busca la información por el rol.
• Consecuencias posibles: aviso, corrección de la escena, y en casos reiterados o deliberados, sanción según la sección 13.

PowerGaming (PG)

• Definición: hacer algo que el personaje no puede hacer en la realidad o forzar el rol de otro sin darle margen de respuesta.
• Conducta limitada: acciones imposibles, sobrehumanas o que anulan la decisión ajena.
• Infracción: "le desarmo, le esposo y le hago confesar" en un solo mensaje, sin que la otra persona pueda contestar.
• Correcto: "Me acerco con la pistola en alto y le ordeno que suelte el arma. Espero su reacción."
• Consecuencias posibles: aviso y corrección; repetición deliberada, sanción.

DeathMatch (DM)

• Definición: agredir o matar a otro jugador sin motivo IC previo ni escena válida.
• Conducta limitada: cualquier violencia sin rol previo, salvo en los contextos que la normativa permite expresamente (sección 4.6).
• Infracción: un jugador dispara a otro que pasaba por la calle, sin haberse cruzado con él y sin motivo.
• Correcto: dos personajes tienen un conflicto IC, lo negocian y se produce un enfrentamiento con rol previo.
• Consecuencias posibles: sanción según reincidencia y gravedad, ya que la muerte gratuita afecta a la experiencia de otros.

Vehicle DeathMatch (VDM)

• Definición: usar un vehículo como arma contra otro jugador sin rol previo que lo justifique.
• Conducta limitada: atropellar, embestir o perseguir a alguien sin motivo.
• Infracción: un jugador acelera contra un peatón que cruza la calle.
• Correcto: un conductor que frena al ver un peatón y se detiene. Si hay conflicto IC previo, se negocia antes.
• Consecuencias posibles: igual que DM si hay intención; si es accidental y el jugador lo corrige, aviso.

Fear RP

• Definición: el personaje debe reaccionar con miedo cuando está en una situación de peligro real que la escena le presenta.
• Conducta limitada: ignorar amenazas, seguir actuando con normalidad mientras se le apunta con un arma, o no reaccionar tras una agresión.
• Infracción: un personaje es amenazado con un arma y responde con un combate, sin intentar reaccionar a la amenaza.
• Correcto: el personaje levanta las manos, suplica o intenta huir, según su situación.
• Consecuencias posibles: corrección de escena; repetición, sanción.

Bad Driving (BD)

• Definición: conducir de forma irreal o inapropiada para el contexto: giros imposibles, velocidades incoherentes o maniobras que no respetan la física del juego.
• Conducta limitada: conducción irreal fuera de persecuciones y de roles agresivos justificados.
• Infracción: un vehículo gira sobre sí mismo a gran velocidad en una calle concurrida sin motivo IC.
• Correcto: conducción arriesgada dentro de una persecución que se ha planteado en el rol.
• Consecuencias posibles: aviso y corrección; repetición, sanción.

Ver la sección 8 para el detalle.

Bunny Jump (BJ)

• Definición: saltos repetidos o aprovechamiento de comportamientos físicos para ganar velocidad o posición.
• Conducta limitada: totalmente prohibido.
• Infracción: saltar de forma repetida para desplazarse más rápido que a pie normal.
• Correcto: desplazarse a pie de forma normal y, si hace falta, usar un vehículo o medio permitido.
• Consecuencias posibles: sanción proporcional a la reincidencia, ya que se trata de un abuso técnico.

Revenge Kill (RK)

• Definición: buscar venganza contra quien causó una muerte (PK) o contra quien participó en esa escena, tras haber vuelto a la vida.
• Conducta limitada: volver al mismo conflicto después de un PK como si no hubiera pasado nada.
• Infracción: tras un PK, el personaje regresa a la zona y dispara al mismo jugador.
• Correcto: el personaje acepta lo ocurrido, lo gestiona IC y, si quiere venganza, lo plantea como nueva trama con el tiempo y el contexto necesarios.
• Consecuencias posibles: sanción según gravedad. Ver sección 11.1.

Player Kill (PK), Player Kill Total (PKT) y Character Kill (CK)

Definiciones y procedimientos completos en la sección 11. Resumen:

• PK: muerte no definitiva. El personaje sigue existiendo, pierde los recuerdos de la escena.
• PKT: ruptura narrativa definitiva con un grupo. El personaje sigue vivo. Requiere aprobación administrativa.
• CK: muerte definitiva del personaje. Requiere aprobación administrativa previa.

Bug Abuse

• Definición: aprovechar un error técnico, de físicas, de interfaz o de sistema para obtener una ventaja o evitar una consecuencia.
• Conducta limitada: cualquier uso deliberado de un bug, incluido el de desconexiones y reinicios.
• Infracción: un jugador descubre que puede saltarse un requisito policial al reconectarse en mitad de un atraco.
• Correcto: el jugador reporta el bug a la administración de inmediato y no lo explota.
• Consecuencias posibles: sanción; el abuso deliberado se considera especialmente grave (sección 13.4).

Forzar el rol

• Definición: imponer acciones, resultados o respuestas a otro personaje sin dejarle margen de reacción.
• Conducta limitada: decidir lo que hace o siente el otro personaje. Insistir tras un rechazo.
• Infracción: "te rindes, te esposo, me das el dinero" en un único mensaje. También buscar reiteradamente a alguien para empezar un rol que ha rechazado.
• Correcto: proponer la escena y esperar la respuesta. Si la otra persona no quiere, la escena termina.
• Consecuencias posibles: aviso; repetición, sanción.

Evadir o interrumpir una escena

• Definición: cortar una escena para no asumir sus consecuencias, o alejarse de una escena agresiva para salvarse.
• Conducta limitada: salir de la escena cuando te está resultando desfavorable, sin resolverla. Usar zonas seguras para escapar de un rol agresivo.
• Infracción: un personaje pierde un tiroteo y, en mitad, pulsa el comando de salida para no morir.
• Correcto: el personaje asume lo ocurrido, o pide aclaraciones antes de empezar, o la escena se detiene por la administración.
• Consecuencias posibles: sanción según gravedad y reincidencia.

Información OOC dentro del personaje

• Definición: trasladar al rol cualquier información que el jugador tiene por canales externos al juego.
• Conducta limitada: igual que MG; se incluye aquí por su frecuencia.
• Infracción: un personaje reconoce a otro por su voz después de que el jugador lo haya escuchado en un directo.
• Correcto: el personaje reconoce solo lo que puede reconocer IC.
• Consecuencias posibles: como MG.

Uso indebido de cámaras, vigilancia, grabaciones y comunicaciones

• Definición: usar los sistemas de vigilancia, grabación o comunicación del servidor para obtener información que el personaje no podría obtener, o para intimidar o acosar.
• Conducta limitada: acceder a grabaciones o cámaras sin justificación IC, publicar o difundir grabaciones fuera del rol, o usar las comunicaciones para espiar escenas ajenas.
• Infracción: un personaje consulta las cámaras de una tienda para ver dónde está escondido un rival, sin tener acceso IC.
• Correcto: el acceso a cámaras o registros se negocia IC y solo cuando el personaje tiene una vía legítima para ello.
• Consecuencias posibles: sanción según la gravedad; la difusión de grabaciones fuera de rol es especialmente grave.

Las herramientas exactas disponibles se definen en la sección 3 y en el Anexo A.

Uso del entorno como elemento narrativo

• Definición: los testigos, ciudadanos y espacios del juego pueden reaccionar a los hechos. Un delito en un lugar concurrido tiene consecuencias.
• Conducta limitada: ignorar a los testigos, actuar como si la ciudad no existiera o convertir el entorno en un escudo.
• Infracción: un atraco en una tienda llena de gente sin que nadie reaccione ni se mencione a los presentes.
• Correcto: el jugador describe a los testigos y su reacción, y deja margen para que la escena se desarrolle.
• Consecuencias posibles: corrección de la escena; repetición, sanción.

Robos, estafas, secuestros y otras actividades criminales

• Definición: actividades delictivas dentro del rol, reguladas en las secciones 5 a 9.
• Conducta limitada: ejecutarlas sin cumplir requisitos, sin /entorno cuando es obligatorio, o eludiendo mínimos policiales.
• Infracción: iniciar un atraco sin el /entorno previo.
• Correcto: cumplir los requisitos de la sección 5 y de la sección correspondiente.
• Consecuencias posibles: según la sección 13.

Abuso de desconexiones, reinicios o errores técnicos

• Definición: usar una desconexión, un reinicio o un error para evitar una consecuencia o cambiar el resultado de una escena.
• Conducta limitada: desconectarse para no morir, para no ser detenido o para evitar un requisito.
• Infracción: un personaje se desconecta al ser apuntado con un arma para no perder el dinero.
• Correcto: si la conexión falla, el jugador lo comunica a la administración y se revisa la escena. No se reanuda para cambiar el resultado.
• Consecuencias posibles: sanción, especialmente si se repite; en caso de desconexión justificada, revisión de la escena.

Interferencia injustificada en escenas ajenas

• Definición: intervenir en una escena en la que el personaje no está involucrado IC.
• Conducta limitada: acudir a un tiroteo ajeno sin motivo, o entrar en una negociación que no te concierne.
• Infracción: un personaje aparece en mitad de un secuestro que no le afecta para "ayudar" sin ninguna razón IC.
• Correcto: el personaje se entera de forma IC y solo interviene si tiene motivo; si no, se aleja.
• Consecuencias posibles: aviso; repetición, sanción.

Los nombres concretos de los comandos pueden cambiar según las herramientas disponibles en el servidor. La finalidad de cada comando se mantiene.

3.1. /me

• Uso: describir una acción de tu personaje que las animaciones o mecánicas del juego no muestran suficientemente.
• No se debe usar para: decidir la reacción, el pensamiento o el resultado de otro personaje; describir como hecho consumado algo que afecta a otra persona.

3.2. /do

• Uso: describir la situación, el estado o el entorno, y plantear preguntas narrativas que permitan una respuesta coherente.
• No se debe usar para: imponer resultados, ocultar información de forma engañosa o decidir lo que percibe otro personaje.

3.3. /entorno Aprobado · para robos y atracos

• Función: comunicar sucesos relevantes a los servicios de emergencia o a la policía, según las funcionalidades del servidor.
• Obligatoriedad: el /entorno es obligatorio antes de iniciar cualquier robo o atraco. Quien comete el delito debe enviarlo antes de empezar.
• Contenido razonable:
  • Ubicación aproximada.
  • Naturaleza del incidente.
  • Número aproximado de sospechosos, si es observable.
  • Descripción general de la vestimenta.
  • Vehículos implicados, si los hay.
  • Otros detalles que puedan conocerse de forma razonable.
• Límites:
  • No se exige que el personaje conozca datos que no podría percibir.
  • No se permiten alertas falsas, engañosas o repetidas para manipular a la policía.
  • Un /entorno no permite que el delito se considere "anunciado" para aprovechar tiempos de espera.
• Si el sistema falla: se comunica a la administración y no se aprovecha el error para realizar actividades que de otro modo estarían restringidas (ver sección 5.2).

3.4. Comunicación OOC

• Canal: el chat OOC y Discord oficial.
• Uso permitido: preguntar por disponibilidad policial, dudas sobre comandos o teclas, y consultas de funcionamiento del servidor.
• Uso prohibido: usar el canal OOC para negociar IC, para coordinar acciones dentro del rol de forma que se interprete como información IC, o para insultar.
• Regla de separación: lo dicho OOC no se convierte en conocimiento IC. Si un personaje necesita una información, debe obtenerla dentro del rol.

3.5. /report, /calladmin y herramientas equivalentes

• Cuándo usarlos: para comunicar infracciones, errores técnicos, problemas con un sistema del servidor o conflictos que requieran intervención administrativa.
• Cuándo no usarlos: para interrumpir una escena que puede continuar de forma válida, o para resolver un desacuerdo de rol. Ver sección 4.4.
• Calidad del reporte: debe ser detallado: qué ocurrió, cuándo, quién intervino, y qué pruebas existen. Los reportes sin especificar el problema pueden no atenderse.
• Pruebas: capturas, vídeos o registros, cuando sea posible. Ver sección 13.2.
• Trato: respetuoso, sin insultos. Las faltas de respeto OOC se sancionan.

4.1. Valora la vida de tu personaje

Tu personaje debe priorizar su supervivencia ante cualquier situación. Actuar de forma temeraria sin motivo IC, o ignorar un peligro real, es una infracción. Ver también Fear RP (sección 2.2).

4.2. Respeto a la escena

• Una escena se negocia con las personas implicadas.
• Si alguien no quiere participar, la escena termina.
• No se puede forzar a otra persona a entrar en un rol, ni reiterar invitaciones tras un rechazo.

4.3. Evadir y dejar roles a medias

• No se puede evadir un rol. Si la escena te resulta incómoda, puedes pedir una aclaración antes de continuar.
• Cancelar una escena para no asumir sus consecuencias es evadir rol.
• Refugiarse en una zona segura durante un rol agresivo es evadir rol.

4.4. Interrumpir una escena para reportar

• No se para un rol para reportar. Primero se termina la escena y después se reporta si es necesario.
• Antes de reportar, se intentará aclarar la situación por OOC o Discord cuando sea posible.
• La administración puede cortar una escena cuando sea necesario para evitar que la situación se agrave.

4.5. Volver al rol

• No se puede retomar una escena después de un PK, ni regresar a la zona de un conflicto como si no hubiera pasado nada.
• Alejarse de una zona para volver después con ventaja es una infracción.

4.6. Uso de violencia y armas

• Para usar violencia o un arma debe existir un rol previo, salvo en contextos ilegales que la normativa o la administración reconozcan (por ejemplo, zonas de organizaciones criminales).
• Si se amenaza a alguien, debe dársele tiempo suficiente para reaccionar antes de disparar.
• La violencia debe ser coherente con la situación. No se puede usar como excusa para matar sin justificación.
• Las limitaciones de armas por actividad están pendientes de definición. Ver Anexo A.

4.7. Armas en vehículos Propuesta

• El conductor no dispone en movimiento de ventajas de tiro que sean irreales.
• Durante una persecución, el objetivo es detener o inmovilizar el vehículo, no matar a los ocupantes sin escena previa.
• Para un enfrentamiento a muerte, la escena debe desarrollarse con las personas fuera del vehículo, salvo en los casos previstos por la administración.
• Los detalles técnicos de disparo desde vehículos dependen de las mecánicas finales (Anexo A).

4.8. Identificación y máscaras Propuesta

• Todo ciudadano debe poder identificarse si se le pide, con documentación IC coherente. No se puede rolear una identificación falsa salvo en actividades de rol previstas para ello.
• Llevar máscara no hace al personaje irreconocible. Puede investigarse por vestimenta, vehículo y matrícula, pero no por la voz.
• Un personaje que ha sido grabado o identificado por una vía IC no puede fingir no reconocer a quien lo identificó.

4.9. Software externo y trampas

Prohibido:

• Moduladores de voz.
• Multicuentas para beneficiarse de las mismas escenas o recursos.
• Cualquier software de ventaja: cheats, autoclickers o similares.

El software de grabación es el único externo permitido, siempre que se use de forma que no altere el rol de otros.

4.10. Simulación de inconsciencia y coma Propuesta

• Cuando un personaje muere o queda inconsciente, su estado se representa con el rol que el servidor permita.
• Simular inconsciencia para evadir un rol está prohibido.
• Si la inconsciencia es real dentro de la escena, se usa /do para describirla y se respeta la escena.

4.11. Llamadas de servicios

• Está prohibido hacer llamadas falsas a emergencias, mecánicos o policía.
• Toda llamada debe indicar el motivo.

4.12. Trabajos legales y zonas de trabajo Propuesta

• Un ciudadano que realiza un trabajo legal no puede ser objeto de roles agresivos, salvo que él mismo se involucre en un conflicto previo, o que sea una actividad policial.
• No se puede utilizar la vestimenta o el vehículo de un trabajo para cometer delitos.

4.13. Uniformes y equipamiento de servicio Propuesta

• Un jugador no puede usar uniformes de policía, EMS o mecánicos si no pertenece a ese servicio IC. Las prendas se adquieren y utilizan según el sistema del servidor.

4.14. Cuerpos y restos

• No se puede interactuar con un cuerpo de forma que aporte ventaja IC si el personaje está incapacitado o fallecido según la escena.
• Los cuerpos calcinados no pueden ser objeto de interacción salvo que la administración lo indique.

4.15. Faltas de respeto OOC

El lenguaje ofensivo, la discriminación o el acoso fuera de personaje son sancionables. Se pide sentido común también en el rol: la ficción puede ser dura, pero no puede servir de excusa para ofender a una persona real.

4.16. Eventos organizados

Durante un evento oficial no se realizan actividades delictivas en la ciudad salvo que el evento lo permita expresamente.

4.17. Menús y acciones de interfaz

Un jugador que está dentro de un menú de interacción (garaje, tienda u otro) no puede iniciar un rol agresivo mientras lo está usando.

4.18. Bindeos y automatismos

• No se pueden usar bindeos o macros para realizar acciones IC de forma automática o para cortar comunicaciones (por ejemplo, esposar o inmovilizar sin escena).
• Las acciones deben hacerse de forma manual y dentro del rol, con las herramientas que el servidor ponga a disposición.

5.1. Requisitos generales

Toda actividad criminal debe cumplir estas reglas:

1. Debe existir una situación de rol coherente y una motivación IC razonable.
2. Debe respetarse el mínimo de agentes disponibles exigido para la actividad (tabla de la sección 5.4).
3. El /entorno debe enviarse antes de iniciar cualquier robo o atraco Aprobado.
4. No se puede iniciar una actividad restringida si no se cumple el mínimo policial.
5. No se puede empezar una actividad esperando que la policía se conecte después.
6. No se puede aprovechar que la policía esté desconectada, ocupada o con problemas técnicos para eludir los requisitos.
7. No se puede alternar personajes, miembros de una organización o responsables de iniciar una actividad para saltarse los tiempos de espera.
8. No se pueden iniciar varios atracos importantes simultáneamente para dividir la atención policial.
9. Cambiar de vehículo, vestimenta o participante no sirve para eludir restricciones que correspondan al mismo grupo o actividad.
10. La violencia debe ser coherente con la escena (sección 4.6).
11. No se pueden explotar errores técnicos ni elementos no previstos por el sistema (sección 2.2, Bug Abuse).

5.2. Disponibilidad policial, no solo conexión

El mínimo policial cuenta agentes disponibles para responder a la actividad, no simplemente jugadores conectados.

No cuentan como disponibles, entre otros:

• Agentes ocupados en otra escena activa.
• Agentes en traslado que no puedan llegar en un tiempo razonable.
• Agentes fuera de servicio o que no están en turno IC.
• Agentes atendiendo un incidente anterior.

Propuesta La administración definirá en el Anexo A cómo se contabiliza la disponibilidad cuando el sistema lo permita. Mientras tanto, si no es posible determinar la disponibilidad real, se considera que el mínimo no se cumple.

Si el sistema de disponibilidad falla, se comunica a la administración y no se aprovecha el fallo para iniciar actividades restringidas.

5.3. Tiempos de espera

• El tiempo de espera se aplica al grupo u organización responsable, no solo al personaje que inicia la actividad.
• Cambiar de personaje, vehículo, participante o iniciador no reinicia el contador.
• No se puede dividir artificialmente una misma actividad en varias para esquivar el límite.
• Si participan varias personas, la administración determina qué grupo es el responsable.
• La tabla indica el tiempo mínimo entre repeticiones. No permite iniciar actividades simultáneas ni ignorar los mínimos policiales.
• La norma de rol es vinculante desde el lanzamiento. Su futura automatización técnica no altera esa obligación (Anexo A).

5.4. Tabla de requisitos iniciales Propuesta

5.5. Actividades sin clasificar todavía Pendiente

Cualquier actividad delictiva que no encaje en la tabla queda pendiente de clasificación. Hasta que la administración la clasifique, no puede iniciarse si el requisito mínimo policial no puede comprobarse.

Todas las actividades de esta sección requieren /entorno previo Aprobado y el cumplimiento de la sección 5.

6.1. Robo a un ciudadano

• Debe existir una situación IC razonable: una deuda, un conflicto, una oportunidad, o una necesidad creíble.
• La víctima debe tener una respuesta posible: entregar, huir, negociar, resistirse según su situación. El robo no puede convertirse en un monólogo.
• Aplica Fear RP: la víctima reacciona de forma realista ante una amenaza.
• El robo no es una justificación automática para matar. La muerte requiere escena válida (sección 4.6).
• No se puede usar el robo para obtener información OOC sobre la víctima o su entorno.
• No se pueden forzar transferencias de objetos, dinero o propiedades que las mecánicas del servidor no permitan. La transferencia se hace por los mecanismos disponibles.
• No se puede encadenar robos contra la misma víctima de forma abusiva; la administración puede considerar esa conducta acoso.

Ejemplo correcto: dos personajes abordan a un ciudadano en la calle, le apuntan y le piden la cartera. El ciudadano entrega la cartera y la escena termina con su huida o con su reacción IC.

Ejemplo incorrecto: el jugador apunta, dispara al ciudadano sin darle opción y lo despoja de todo en un único mensaje.

6.2. Robos a tiendas y cajeros

• Uso de armas, amenazas, huida e intervención policial según las secciones 4.6 y 5, sin inventar mecánicas no confirmadas (Anexo A).
• El personal y los clientes son personajes con respuesta propia. La escena debe dejarles espacio para reaccionar.
• Está prohibido aprovechar errores de interacción, recompensas repetibles o fallos del sistema.

Ejemplo correcto: tres personajes entran en una tienda, anuncian el atraco, el dependiente abre la caja y la escena termina con la huida. El /entorno se envió antes de entrar.

Ejemplo incorrecto: el jugador repite la interacción con la caja para obtener recompensas varias veces seguidas.

6.3. Robos a viviendas

• Reglas de acceso, registro, extracción de bienes y salida se definirán según las mecánicas de viviendas, cerraduras, alarmas e inventario (Anexo A).
• No se puede entrar en una propiedad sin una situación o mecánica IC válida. El robo no es un permiso para entrar en cualquier casa.
• Los ocupantes tienen derecho a reaccionar. Si están presentes, la escena se negocia con ellos.

Ejemplo incorrecto: entrar en una vivienda ajena a la que el personaje no tiene motivo para acceder, solo porque se ha decidido "robar allí".

6.4. Joyerías y sucursales bancarias pequeñas

• Coordinación interna: el grupo asume la responsabilidad de sus miembros durante el atraco.
• Respuesta policial: la policía reacciona según su disponibilidad real (sección 5.2). Si no hay mínimo, no se empieza.
• Huida y cierre: la escena termina con la huida, la detención o la negociación. No se abandona a medias para evitar consecuencias.
• Prohibido iniciar varias actividades importantes a la vez para dividir a la policía.

6.5. Atracos a bancos medianos

• Negociación: los rehenes y el personal tienen respuestas propias, y la policía puede negociar según la escena.
• Control de rehenes: si el atraco incluye rehenes, se aplica la sección 7. Esta norma no obliga a incluir rehenes; la mecánica de rehenes depende del sistema disponible (Anexo A).
• Finalización: la escena termina con la rendición, la huida, la detención o la negociación acordada.

6.6. Atraco al banco principal

• No se puede iniciar si no se cumple el mínimo policial.
• Negociación, rehenes, huida y coordinación policial se rigen por las secciones 5 y 7.
• Prohibido utilizar errores, desconexiones o reinicios para obtener ventajas (sección 2.2).

6.7. Golpes de gran escala e instalaciones especiales

• Coordinación y resolución de escenas complejas: la administración puede pedir un plan previo por OOC para verificar el cumplimiento de los mínimos, sin revelar información IC a los demás participantes.
• Los aspectos que dependerán de las mecánicas finales (botín, requisitos de objetos especiales, límites económicos) quedan pendientes en el Anexo A.

7.1. Definiciones

7.2. Reglas generales

• Debe existir una motivación IC razonable.
• Respeto a Fear RP y a la integridad narrativa de los personajes retenidos.
• No se puede usar a un rehén para exigir cualquier cosa sin límite. Las exigencias deben ser coherentes con la situación.
• No se puede retener indefinidamente a un jugador sin permitir una resolución razonable: liberación, negociación, huida, detención o cierre de la escena.
• No se puede usar un secuestro para obtener información OOC sobre la persona retenida.
• No se usan secuestros repetitivos o abusivos contra la misma persona. La administración puede considerarlo acoso.
• La liberación, la huida y el cierre de la escena deben estar claros para todas las partes antes de terminarla.

7.3. Secuestro con negociación policial

• La negociación con la policía es el eje de la escena. La policía debe tener una posibilidad real de responder.
• Si no hay mínimo policial disponible, el secuestro no puede iniciarse.

7.4. Aspectos pendientes de la sección 7 Pendiente

• Número máximo de rehenes.
• Tiempos de negociación obligatorios.
• Secuestros sin negociación policial: mínimo y tiempo de espera todavía no definidos.

Estos valores se fijarán cuando se conozcan las mecánicas reales (Anexo A).

7.5. Ejemplo

Correcto: tres personajes retienen a un ciudadano en un local, anuncian sus condiciones IC, la policía responde y se negocia la liberación. Se cierra la escena con la liberación pactada.

Incorrecto: el secuestrador retiene a la víctima durante horas sin negociar y sin permitir que la escena avance, o exige una cantidad o acción sin relación con la situación.

8.1. Principio

No se prohíbe la conducción agresiva dentro de escenas criminales ni en persecuciones. Se regulan los abusos y el uso irreal de las mecánicas.

8.2. Conducción en escenas

• Un accidente se rolea como en la vida real: daños, detenciones, atención a heridos o huida, según la situación.
• Una persecución debe tener un motivo IC y debe ser coherente: no se debe usar el vehículo como arma fuera de la escena.
• La persecución busca detener o inmovilizar, no matar sin escena previa.
• Un vehículo dañado debe comportarse según su estado. No se puede seguir conduciendo con daños que lo imposibilitan, salvo que la escena lo permita.

8.3. BD y BJ

• BD (Bad Driving): la conducción irreal o inapropiada está prohibida, salvo en persecuciones y roles agresivos justificados.
• BJ (Bunny Jump): totalmente prohibido. Cualquier desplazamiento que aproveche saltos repetidos para ganar velocidad es infracción.

8.4. VDM

Atropellar a alguien usando un vehículo como arma sin rol previo es VDM. Si la colisión es accidental, el conductor debe detenerse y rolear la situación.

8.5. Vehículos y terrenos Propuesta

• Un vehículo no diseñado para terreno difícil no se usa en terreno difícil como si lo fuera. La decisión depende de la mecánica del vehículo (Anexo A).
• Los vehículos especiales o de trabajo no se usan para acciones ajenas a su función.
• Las rutas por terreno no transitable en eventos o roles no agresivos se valoran por la administración según la coherencia y la seguridad.

8.6. Uso de vehículos para escapar, bloquear o interferir

• Usar un vehículo para bloquear a otros jugadores sin motivo IC es interferencia (sección 2.2).
• Un vehículo no puede usarse para escapar de una escena que el personaje debe resolver (sección 4.3).
• No se puede aprovechar un daño o desaparición del vehículo para evitar una consecuencia.

8.7. Daños, reparaciones y desapariciones

• El daño de un vehículo tiene consecuencias IC.
• No se puede usar una reparación, un guardado o una desaparición del vehículo para cambiar el resultado de una escena.
• Si el vehículo desaparece por un error técnico, se comunica a la administración.

8.8. Diferencia entre maniobra arriesgada y ventaja

9.1. Robo y estafa

• Robo: obtener algo por la fuerza, la intimidación o un acto físico contra otro personaje.
• Estafa: obtener algo engañando o manipulando a otro personaje sin violencia directa.

Una estafa puede formar parte de una historia IC. Lo que no se permite es el fraude OOC: engañar al jugador o manipular el sistema.

9.2. Transferencias entre personajes

• Las transferencias de dinero y bienes deben hacerse por los mecanismos que el servidor ofrece.
• Una transferencia sin contrapartida IC plausible (regalo excesivo, transferencias masivas) puede considerarse abuso.
• Prohibido aceptar o regalar cantidades de dinero o bienes desproporcionados fuera de un contexto IC. Cada personaje debe conseguir sus recursos con su propio rol.

9.3. Traspasos entre personajes de un mismo jugador

• No se permite usar personajes alternativos del mismo jugador para mover dinero o bienes y evadir límites.
• Un traspaso entre personajes del mismo jugador debe tener una justificación IC y no puede usarse para eludir una sanción o una restricción.

9.4. Explotación de errores económicos

• Duplicar dinero, objetos o bienes mediante un error está prohibido.
• El jugador que detecte un error económico debe comunicarlo de inmediato. No debe aprovecharlo.

9.5. Uso de personajes alternativos para evadir límites

• Crear personajes para repetir actividades, recuperar un patrimonio o eludir un tiempo de espera está prohibido (sección 5.3).

9.6. Patrimonio tras un CK

• Después de un CK, el personaje fallecido no transmite bienes a otros personajes del jugador ni a personas vinculadas.
• No se puede recibir ayuda económica de personas vinculadas al personaje fallecido (sección 11.3).
• El destino concreto de los bienes de un personaje CK está pendiente de decisión (Anexo A).

9.7. Uso de información o bienes de personajes fallecidos

• Un personaje nuevo no puede utilizar información que solo conocía el personaje fallecido.
• No se pueden reclamar bienes de un personaje fallecido por una vía IC no prevista.

9.8. Límites económicos Pendiente

No se fijan en esta versión:

• Cantidades máximas de dinero o de objetos robables.
• Límites de venta de bienes o armamento entre personajes.
• Reglas económicas definitivas.

Estos valores se definirán cuando se conozca la economía del servidor (Anexo A).

10.1. Creación de personaje Propuesta

• El personaje debe tener un nombre propio, creíble y adecuado para una identificación real.
• Debe tener una historia coherente. No se permiten identidades que imiten a personas reales o a figuras públicas de forma ofensiva.

10.2. Continuidad

• El personaje mantiene su historia de un rol a otro. Cambios importantes deben tener causa IC.
• Un personaje no puede cambiar de identidad o de historia para escapar de las consecuencias de sus actos, salvo que sea un CK por cambio de identidad autorizado (sección 11.4).

10.3. Separación de conocimiento

• El conocimiento del jugador no es conocimiento del personaje (sección 2.1).
• Un personaje nuevo no puede compartir información IC con un personaje anterior del mismo jugador.

10.4. Uso de varios personajes

• Prohibido usar varios personajes para compartir información IC, coordinar actividades o beneficiarse de la misma escena.
• Un personaje que existe a la vez que otro del mismo jugador no puede participar en la misma actividad criminal de forma que eluda los límites.

10.5. Pertenencia a organizaciones

• Un personaje que sale de una organización no puede seguir usando sus recursos, su información o sus contactos.
• Un personaje que ha sufrido PKT no puede regresar a la organización de la que se separó (sección 11.2).

10.6. Nuevo personaje para continuar una historia terminada

• No se puede crear un nuevo personaje para continuar una historia o una venganza que debería haber terminado.
• Si la historia ya ha terminado por PK, PKT o CK, el jugador debe aceptar la resolución.

10.7. Consecuencias de PK, PKT y CK

10.8. Diferencia entre pérdida de recuerdos, ruptura y eliminación

• Pérdida de recuerdos: el personaje no recuerda lo ocurrido en una escena (PK). Sigue siendo el mismo personaje.
• Ruptura narrativa: el personaje deja de relacionarse con un grupo o persona (PKT). Sigue vivo.
• Eliminación: el personaje deja de existir en el rol (CK).

Esta sección es la referencia para las tres figuras. Las reglas son propias y no se derivan de otras comunidades.

11.1. PK — Player Kill

El PK es una muerte no definitiva. El personaje sigue existiendo y puede continuar su historia.

1. La escena de muerte debe resolverse de forma coherente con lo ocurrido.
2. El personaje pierde los recuerdos de los acontecimientos relacionados con la escena, desde el inicio del conflicto hasta su desenlace.
3. No puede regresar inmediatamente para vengarse, continuar el tiroteo o retomar el mismo conflicto como si no hubiera muerto (sección 4.5, RK).
4. Debe interpretar las consecuencias físicas que permitan las mecánicas del servidor.
5. Conserva su identidad, relaciones, historial y bienes, salvo que exista una consecuencia IC legítima y permitida por otra regla.
6. Un PK normal no requiere autorización administrativa para cada muerte producida durante una escena válida.
7. El PK no puede usarse para borrar arbitrariamente la historia completa de un personaje.

Ejemplo de PK normal: dos personajes se enfrentan en una escena negociada. Uno muere. Su jugador olvida lo ocurrido en esa escena y se despierta en un hospital, sin volver a por el otro personaje.

Ejemplo de uso abusivo: un jugador muere y, en lugar de rolear la escena, pide que se borre toda la historia de su personaje para empezar de cero sin autorización.

11.2. PKT — Player Kill Total

El PKT es una ruptura narrativa definitiva con una organización, grupo o trama concreta. El personaje sigue vivo.

1. Debe existir una motivación IC sólida: una ruptura grave, una traición, un abandono o una trama equivalente.
2. El solicitante abre un ticket con los motivos, los personajes implicados y las pruebas IC disponibles.
3. La administración revisa la solicitud y comprueba que no se utiliza para resolver disputas OOC.
4. El PKT requiere aprobación administrativa previa.
5. La resolución define exactamente qué recuerdos pierde el personaje y qué vínculos debe abandonar.
6. Si el PKT implica abandonar una organización, el personaje no puede regresar a ella ni utilizar los recuerdos declarados perdidos para continuar la trama desde fuera.
7. El PKT no elimina automáticamente dinero, vehículos, propiedades u otros bienes.
8. Cualquier pérdida material debe tener base IC y respetar las reglas económicas del servidor.
9. El PKT no puede utilizarse como CK encubierto ni para borrar toda la vida del personaje.

Ejemplo de abandono definitivo de una banda: el personaje Marco traiciona a su banda entregando un alijo a la policía. La banda decide la ruptura y el jugador solicita un PKT. La administración aprueba el PKT con estos términos:

• Marco pierde los recuerdos de los planes, escondites y contactos de la banda.
• Marco no puede volver a la banda ni a sus miembros como aliados.
• Marco conserva su dinero, su vivienda y su vehículo, que no se modifican por el PKT.
• Marco puede seguir su vida en otro entorno, sin usar la información de la banda.

11.3. CK — Character Kill

El CK es la muerte definitiva del personaje. El jugador deja de poder utilizar ese personaje para continuar su historia.

1. La solicitud debe presentarse antes de ejecutar la acción definitiva.
2. El solicitante abre un ticket con el motivo IC, la historia previa, los personajes implicados y las pruebas disponibles.
3. La administración revisa la justificación, la coherencia de la trama y el cumplimiento de las reglas.
4. Se requiere aprobación administrativa expresa antes de ejecutar el CK.
5. La autorización define el alcance y las condiciones del CK.
6. El CK se desarrolla mediante una escena coherente y respetando las normas de combate, secuestro, negociación y valoración de la vida.
7. No puede imponerse unilateralmente por haber perdido un tiroteo, haber sido secuestrado o haber incumplido una orden IC.
8. Una vez aplicado, se registra el CK y se desactiva o archiva el personaje conforme a las capacidades técnicas del servidor (Anexo A).
9. El jugador puede crear un personaje nuevo con identidad, historia y relaciones independientes.
10. No puede trasladarse al nuevo personaje el patrimonio del anterior para eludir las consecuencias del CK.
11. El nuevo personaje no puede aprovechar información IC que solo conocía el personaje fallecido.
12. Los registros administrativos del personaje fallecido se conservan para auditoría, prevención de fraude y resolución de incidencias.
13. No se puede convertir retroactivamente una muerte normal en CK para perjudicar a otro jugador.

11.4. Tipos de CK

No existen CK automáticos por cantidad de años de prisión, multas impagadas o entrada en una sede. Esos supuestos quedan pendientes hasta que existan las mecánicas y las reglas correspondientes (Anexo A).

11.5. Salvaguardas comunes

• Un PK no puede convertirse retroactivamente en CK para apropiarse de bienes.
• Un PKT no puede utilizarse para resolver disputas OOC ni para expulsar a alguien de una comunidad mediante una trama ficticia.
• Un CK requiere aprobación administrativa previa.
• Las pruebas deben proceder de la historia IC y de registros legítimos.
• La información OOC no se convierte automáticamente en conocimiento del personaje.
• Los conflictos pueden revisarse mediante ticket, sin permitir que se interrumpan escenas válidas.
• Las excepciones deben quedar justificadas y registradas.
• No existe una vía informal para saltarse el procedimiento.

11.6. Comparativa rápida

12.1. Creación y funcionamiento Pendiente

Las reglas técnicas de creación de organizaciones, sus jerarquías, límites de miembros y permisos dependen del sistema del servidor (Anexo A). Mientras no existan, cualquier organización es una agrupación de rol y sus miembros responden por sus acciones colectivas.

12.2. Responsabilidad de los integrantes

• Los integrantes responden por las actividades que la organización decide y ejecuta.
• Un miembro que actúa por cuenta propia en nombre de la organización sin autorización asume la responsabilidad de esa acción.
• La administración puede determinar qué grupo es responsable cuando participen varias personas (sección 5.3).

12.3. Conflictos entre organizaciones

• Los conflictos deben negociarse IC.
• Un conflicto entre organizaciones no autoriza a atacar a personajes ajenos a ese conflicto.
• Las guerras entre organizaciones se rigen por las reglas de violencia (sección 4.6) y de tiempo (sección 5.3).

12.4. Información obtenida por otros miembros

• La información que obtiene un miembro se comparte IC si el personaje la comparte.
• Un miembro no puede usar información obtenida por otro para actuar de forma que el personaje no podría saber.

12.5. Superioridad numérica

• No se puede usar la superioridad numérica para eludir los mínimos policiales o los tiempos de espera.
• Un grupo grande no puede someter a un personaje aislado de forma repetida sin una escena IC razonable.

12.6. Entrada, salida y abandono

• Entrar en una organización requiere un rol IC y la aceptación de la organización.
• Salir de una organización puede hacerse por decisión IC. Si la salida implica una ruptura definitiva, se aplica el PKT (sección 11.2).
• El personaje que sale no puede seguir usando recursos o información de la organización.

12.7. Decisiones IC y OOC

• Una decisión IC de la organización se toma dentro del rol.
• Una decisión OOC no se convierte en decisión de la organización sin que exista un rol que la respalde.

12.8. Relación entre PKT, CK y la organización

• El PKT supone abandono definitivo del grupo afectado (sección 11.2).
• Un CK de un miembro no implica consecuencias automáticas para la organización. Si la organización se ve afectada, se resuelve dentro del rol.

13.1. Cómo presentar un reporte

1. Antes de reportar, se intenta aclarar la situación por OOC o Discord cuando sea posible.
2. Se termina la escena antes de reportar (sección 4.4).
3. El reporte debe ser detallado: qué ocurrió, cuándo, dónde, quién intervino y qué se pide.
4. Se aportan pruebas cuando existan.
5. Se usa el canal oficial: /report, /calladmin o equivalente (sección 3.5).

13.2. Pruebas

• Capturas, grabaciones y registros del servidor son las pruebas válidas.
• Las pruebas deben ser completas: una captura recortada que oculte el contexto no es prueba suficiente.
• Las pruebas no deben obtenerse mediante software externo ni manipulación (sección 4.9).

13.3. Investigación

• La administración revisa el reporte, las pruebas y, si es necesario, las versiones de las personas implicadas.
• Si hay versiones contradictorias, la administración puede pedir más pruebas o revisar la escena.
• La administración puede pausar o revisar una escena cuando sea necesario.

13.4. Clasificación de infracciones

La administración distingue:

• Error involuntario: la infracción no fue intencionada y se corrige.
• Reincidencia: la misma infracción se repite tras una advertencia.
• Abuso deliberado: la infracción se comete a sabiendas para obtener ventaja.
• Explotación de errores técnicos: la infracción aprovecha un bug o fallo del sistema.

13.5. Sanciones Propuesta · estructura orientativa

La siguiente estructura es orientativa. No es una tabla cerrada ni incluye duraciones: esas se fijarán con decisión de la comunidad.

Principios:

• La sanción es proporcional a la gravedad, la intención y la reincidencia.
• No se aplican sanciones automáticas sin revisión.
• Las duraciones concretas de cada nivel quedan pendientes de decisión (Anexo A).

13.6. Solicitud de revisión y apelación

• Toda sanción puede ser objeto de revisión mediante ticket.
• La revisión la realiza una persona distinta de la que impuso la sanción cuando sea posible.
• Las alegaciones se presentan con pruebas, si existen.

13.7. PKT y CK

• Las solicitudes de PKT y CK se tramitan mediante ticket.
• La administración registra la decisión y su motivo.
• Una solicitud rechazada puede volver a presentarse con nuevos elementos IC.

13.8. Registro de decisiones

• Las decisiones administrativas importantes se registran con su motivo.
• Los registros se usan para auditoría y para mantener la coherencia de decisiones futuras.

13.9. Conflictos de interés y arbitrariedad

• Un miembro de la administración no resuelve casos en los que tenga interés personal, relación con las personas implicadas o participación en la escena.
• La administración debe decidir con criterios iguales para todos los casos similares.
• Las decisiones importantes deben explicarse.

1. Cuando una situación no esté contemplada, la administración la resuelve con estos principios: coherencia narrativa, equidad, proporcionalidad y prevención de abusos.
2. Los administradores pueden interpretar como indebidos comportamientos no recogidos en la normativa, siempre con justificación.
3. Esta cláusula no es una autorización ilimitada. Las decisiones importantes se explican y se registran.
4. Si una norma deja un hueco que permite un abuso, la administración puede cerrarlo mediante una actualización de esta normativa.
5. La duda se resuelve en favor de la escena válida y de la prevención del abuso, no en favor de quien pretende ganar una ventaja.

Estos puntos no se pueden fijar hasta conocer las mecánicas y las herramientas reales. No invalidan las decisiones ya tomadas.