- 01Primero distinga el tipo de falla
- 02Registre la última acción normal
- 03Preserva el contexto útil
- 04Usa Enviar comentarios (Give Feedback) cuando abra el juego
Basado en las fuentes enlazadas y el análisis original. No se afirma que haya hecho pruebas de juego de primera mano.
Localizado a partir de la edición de investigación en inglés; los nombres propios del juego se mantienen para la búsqueda.
Lo que el desarrollador ha recomendado realmente
Un hilo de Steam del 5 de septiembre informa bloqueos del juego seguidos de reinicios completos del sistema. El editor pidió al jugador que usara Enviar comentarios (Give Feedback) en el juego para poder enviar los registros, e incluir una dirección de contacto para seguimiento. El desarrollador Danga sugirió Gráficos bajos, que desactiva la niebla volumétrica, como una forma posible de reducir el problema. La respuesta mencionó un caso previo relacionado con posibles limitaciones de calor o energía, no un diagnóstico confirmado para todos los jugadores.
Use esas declaraciones en su ámbito adecuado. Low es una configuración documentada para probar si el juego es lo suficientemente estable como para llegar a su menú. Enviar comentarios (Give Feedback) es la ruta de informe admitida mencionada en la discusión. Ninguna de las declaraciones prueba que todos los bloqueos tengan una causa común, que su hardware esté defectuoso o que una reparación particular resolverá el problema.
Esta página proporciona un flujo de trabajo original para describir la falla y recopilar el contexto útil. No afirma haber reproducido el bloqueo ni haber examinado sus registros. El objetivo es preservar lo que ocurrió, realizar un pequeño número de verificaciones apropiadas y dar a soporte un informe que pueda investigar sin requerirle adivinar la causa interna.
Primero distinga el tipo de falla
Un juego que se cierra al escritorio es diferente de una imagen congelada, un error del sistema operativo o que la computadora se reinicie. Registre qué evento ocurrió. Si apareció un mensaje de error, copie su redacción exacta o captúrelo cuando sea posible. Si no hubo mensaje, diga eso en lugar de inventar uno a partir de un informe similar en línea.
También note si el audio continuó, si el juego aún respondía a los comandos, y si el sistema operativo siguió siendo utilizable. Estas son observaciones, no diagnósticos. Ayudan a separar el cierre de un proceso del juego de una interrupción más amplia del sistema. Una descripción amplia como todo se bloqueó deja sin resolver esas distinciones importantes.
Si toda la computadora se reinicia o apaga repetidamente, deje de provocar la condición repetidamente como una prueba del juego. Preserve la información que ya tiene y busque soporte apropiado del sistema o dispositivo así como reporte el contexto del juego. Un reinicio no es un problema normal de tasa de cuadros, y este artículo no debe usarse como sustituto de la evaluación de hardware.
Registre la última acción normal
Escribe lo que estabas haciendo justo antes del fallo. Incluye el nombre de la cámara o sala, si estabas cargando, abriendo un menú, moviéndote o realizando una interacción concreta de puzle, y aproximadamente cuánto tiempo llevaba la sesión. Una duración aproximada es útil cuando está claramente etiquetada como aproximada.
Evita convertir la última acción en una causa prematuramente. Un accidente tras entrar en una sala no prueba que la habitación lo haya causado. Aun así, ese momento da al desarrollador un punto de partida. El informe más sólido describe la secuencia de forma clara y deja margen para la investigación en lugar de nombrar un defecto del motor o una fuga de memoria sin pruebas.
Si el fallo ha ocurrido más de una vez, compara los eventos. ¿Fueron en la misma escena, tras una duración similar o durante actividades diferentes? Indica el número de sucesos que realmente observaste. No escribas siempre si ocurrió dos veces bajo condiciones que no hayas comparado completamente.
Preserva el contexto útil
Registra la tienda física, la demo o la entrada completa del juego, el sistema operativo, el dispositivo gráfico, el procesador, la memoria y cualquier información local de compilación que exponga el cliente. Estos detalles ayudan al desarrollador a relacionar el informe con un entorno. Si un campo es desconocido, déjalo desconocido hasta que puedas comprobarlo en lugar de adivinar por la marca del ordenador.
Incluye el preset gráfico y cualquier valor de configuración relevante que hayas cambiado. Un informe hecho tras experimentar debería indicar qué configuración estaba activa en el momento del fallo. De lo contrario, el soporte puede interpretar tus ajustes actuales como los que generaron el evento original, aunque sean diferentes.
Mantén una línea temporal corta si haces varias comprobaciones. Puede decir que el primer fallo ocurrió en un preset, luego actualizaste el juego y un intento posterior se comportó de forma diferente. El orden importa porque muestra qué cambios precedieron a qué observaciones. Una lista de todos los ajustes que has probado no proporciona la misma información.
Usa Enviar comentarios (Give Feedback) cuando abra el juego
Si puedes llegar al juego y a su opción de feedback, usa la ruta que mencionó el editor. Explica el tipo de fallo, la última acción normal y el entorno. El editor dice que la ruta de feedback envia logs que pueden ayudar. No asumas que los logs por sí solos explican tu intención o el momento exacto en que notaste el problema.
Incluye una dirección de contacto si quieres un seguimiento, como se solicita en la respuesta de soporte. Mantén el informe centrado en el problema y evita añadir información personal no relacionada. Un detalle de contacto útil ayuda al desarrollador a solicitar una observación adicional específica sin que tengas que publicar esa información en una discusión pública.
Si el problema es una pausa repetible en lugar de un bloqueo, el hilo de rendimiento separado solicita comentarios mientras ocurre la demora. Para un bloqueo que ya ha cerrado el juego, explica ese momento cuando lo vuelvas a abrir. No afirmes que se adjuntó un registro anterior a menos que la interfaz de comentarios o el desarrollador lo confirmen.
Si el juego no puede llegar a su menú
para explicar que la ruta de informe dentro del juego no está disponible. Indica si el juego falla antes de que aparezca una ventana, durante la carga o después de llegar a la pantalla de título. Esas etapas son más útiles que la frase única no se inicia.
Comienza con un informe conciso y la información que puedas verificar. No adjuntes todos los archivos de la instalación ni envíes un archivo grande de datos del sistema no relacionados. Espera a que se solicite material adicional específico cuando los archivos o rutas necesarios no estén documentados. Las fuentes investigadas no establecen un registro o ruta de guardado minorista actual para copiar aquí.
Si una tienda muestra un error, conserva ese mensaje por separado de cualquier error del juego. Un problema de descarga faltante o del cliente puede ocurrir antes de que se ejecute el proceso del juego. Nombrar la capa donde aparece la falla ayuda a evitar tratar un problema de instalación en la tienda como si fuera un bloqueo del motor de rompecabezas.
Verifica si hay una actualización del juego disponible
Usa el mecanismo de actualización normal de la tienda y deja que las descargas pendientes o la instalación finalicen antes de comparar el comportamiento. Esta es una práctica general de soporte, no evidencia de que una actualización específica de He Who Watches solucione tu bloqueo. Registra si había una actualización disponible y si el síntoma cambió posteriormente.
No asumas que el anuncio más reciente describe todos los cambios de la versión local, y no inventes un número de versión a partir de la fecha. Si el cliente expone un identificador, úsalo. De lo contrario, proporciona la fecha de actualización y la tienda que realmente puedes ver. La información incompleta precisa es preferible a una etiqueta que el soporte no pueda verificar.
Una actualización que cambia rompecabezas o texto del menú no debe anunciarse como una solución de bloqueo a menos que el desarrollador lo diga o una observación cuidadosamente descrita respalde el resultado más específico en tu máquina. Mantén la cuestión de la actualización de la instalación separada de la pregunta de si el problema se ha resuelto.
Prueba Solo Bajo como comparación controlada
La sugerencia del desarrollador de gráficos bajos es una prueba pequeña razonable si el juego sigue siendo lo suficientemente estable para usar. Anota la configuración previa, selecciona Bajo y regresa al juego normal o a una escena comparable corta. Registra si el síntoma original regresa. No reinicies repetidamente el sistema únicamente para comparar configuraciones.
Si Low ayuda, describa el resultado como una solución temporal local bajo las condiciones observadas. No necesita inferir si la niebla, la carga, el calor u otro factor lo explican. El desarrollador puede usar el cambio en el comportamiento sin que usted proporcione un diagnóstico especulativo de hardware.
Si Low no ayuda, eso también es información útil. Inclúyalo en el informe con el tipo de fallo y su momento. Una prueba negativa no significa que la sugerencia del desarrollador fuera irracional; significa que su caso necesita más evidencia. Evite probar muchos ajustes no relacionados después de que la primera comparación enfocada haya fallado.
Verifique los archivos Steam cuando el síntoma lo indique.
Valve documenta una verificación de archivos a través del área de Propiedades y Archivos Instalados de la biblioteca Steam del juego. Esto puede ser apropiado para archivos instalados que falten o estén dañados. Es una solución general de problemas de Steam, no una solución demostrada para el problema de reinicio reportado de este juego. Use la interfaz del cliente en lugar de eliminar manualmente el contenido de la instalación.
Deje que la verificación termine y tome nota de lo que informa el cliente. Si se recuperan archivos, registre ese hecho sin asumir que prueba que causaron la falla. Luego, compare el síntoma original bajo un inicio normal. Si nada cambia, incluya ese resultado en las notas de soporte en lugar de ejecutar la verificación indefinidamente.
No confunda la verificación de la instalación con la validación de su progreso en el rompecabezas. No establece una solución a una sala ni prueba que un antiguo recorrido de instrucciones deba coincidir con una nueva disposición. Mantenga la verificación vinculada a síntomas técnicos como archivos faltantes o fallos de inicio, donde tiene un propósito claro.
Evite suposiciones destructivas.
Las respuestas disponibles del desarrollador no instruyen a los jugadores a borrar partidas guardadas, eliminar carpetas de configuración, editar el registro o usar comandos de lanzamiento no documentados. No haga de esas acciones la respuesta predeterminada ante un fallo incierto. Pueden borrar un estado útil o crear un segundo problema sin explicar el primero.
De manera similar, no desactive protecciones del sistema ni descargue un solucionador de terceros porque un resultado de búsqueda prometa una solución universal. Use el juego, la tienda y los canales de soporte del dispositivo relevantes para el fallo observado. Una instrucción verificada y específica es más útil que un procedimiento dramático sin conexión clara con el síntoma.
Si el soporte solicita posteriormente un archivo o cambio específico, mantenga un registro de la instrucción y conserve los datos relevantes según corresponda. El objetivo no es evitar todos los cambios. Es realizar cambios por una razón establecida y mantener suficiente contexto para determinar si ayudaron.
Capture un ejemplo pequeño y significativo.
Si se puede observar el fallo sin provocar un evento del sistema peligroso o disruptivo, una breve grabación o captura de pantalla puede aclarar el informe. Muestra el mensaje de error o la acción que precede inmediatamente al problema. Explica lo que el espectador debería notar. Una sesión larga sin anotaciones puede ocultar el momento relevante.
Mantén el contenido privado del escritorio fuera de la captura y marca el material de final de juego al compartirlo públicamente. A menudo puedes mostrar el comportamiento técnico sin revelar una ruta secreta completa. Si la escena en sí es un spoiler, dilo antes de la imagen o video en lugar de poner la respuesta en el título.
No afirmes que una reproducción es mínima a menos que realmente lo hayas reducido. Está bien decir que observaste el fallo después de varias acciones y no sabes cuál es importante. Esa honestidad evita que el soporte asuma que un solo input visible es el desencadenante completo.
Escribe el comportamiento esperado y el comportamiento real por separado
El comportamiento esperado describe lo que pensabas que debería suceder: la sala debería cargarse, el menú debería cerrarse o el juego debería permanecer abierto después de un movimiento ordinario. El comportamiento real describe el fallo visible. Mantenerlos separados hace que el informe sea comprensible incluso si el desarrollador no comparte tu interpretación del estado del rompecabezas.
Cuando la expectativa proviene de una guía, incluye el enlace y la fecha. Una discrepancia con la disposición antigua de una sala puede ser un problema de versión en lugar de un fallo. Cuando la expectativa es un comportamiento básico de la aplicación, dilo claramente. No es necesario adornar un informe sencillo con terminología técnica que no puedas fundamentar.
Agrega lo que intentaste y el resultado de cada paso. "Juego actualizado, todavía se cierra al cargar" es útil. "Lo intenté todo" no lo es. Una lista concisa de verificaciones reales ahorra tiempo al mostrar qué comparaciones obvias ya están completas y cuáles siguen sin probar.
Da seguimiento con nueva evidencia
Si el desarrollador pide una prueba o registro en particular, responde directamente a esa solicitud. Mantén la referencia del informe original para que la nueva información se mantenga conectada al mismo problema. Iniciar varios hilos no relacionados puede dividir el contexto y dificultar ver cómo cambió el comportamiento con el tiempo.
Si el problema se detiene después de un cambio, informa qué cambió y cuánto tiempo o bajo qué condiciones lo has probado desde entonces. Evita declarar una solución universal después de un solo inicio exitoso. Una declaración más específica de que el juego ha completado varias sesiones normales en baja es tanto útil como honesta si eso es lo que observaste.
Si regresa, actualiza la misma explicación del problema con las nuevas condiciones. Una recurrencia no borra la mejora anterior; añade información sobre sus límites. Esa distinción puede ayudar a ayudar a identificar si el cambio redujo la frecuencia, afectó solo a una escena o no estaba relacionado.
Decide cuándo dejar de hacer pruebas
Una vez que tengas una descripción clara del fallo, detalles básicos del entorno y los resultados de unas pocas comprobaciones adecuadas, envía el informe. No necesitas diagnosticar el juego tú mismo antes de pedir ayuda. Más pruebas solo merecen la pena cuando responden a una pregunta pendiente específica o siguen una instrucción relevante.
Si la máquina en sí es inestable, prioriza ese problema general y evita los lanzamientos repetidos que lo desencadenan. Si el juego solo se cierra pero tu sistema es utilizable, conserva el informe y espera a un siguiente paso específico en lugar de reemplazar la instalación repetidamente. La respuesta debería encajar con el fallo que realmente tienes.
Un buen informe es una pequeña prueba: qué ocurrió, dónde, bajo qué configuración y qué cambió cuando intentaste un paso documentado. Eso es suficiente para iniciar una investigación productiva mientras se mantienen fuera de camino especulaciones, ajustes no relacionados y cambios innecesarios en archivos.
Convierte un informe vago en uno accionable
Un informe que dice que el juego se cierra a veces deja varias preguntas esenciales sin respuesta. Puedes mejorarlo sin especulaciones técnicas añadiendo el tipo de fallo, la fase de juego, la frecuencia aproximada y la última acción normal. Por ejemplo, distingue un retorno al escritorio durante la carga de un reinicio completo del sistema tras una sesión larga. Estos son patrones de informe, no eventos que se afirma que ocurrieron en tu máquina.
Luego añade el entorno y el pequeño conjunto de comprobaciones que realmente completaste. Indica si usaste el juego completo o la demo, qué tienda lo proporcionó y qué preajuste gráfico estaba activo. Si probaste la verificación Baja o Steam, informa el resultado de cada uno por separado. No escribas que todas las correcciones fallaron cuando solo hiciste una comprobación.
Explica si el comportamiento es repetible bajo una secuencia conocida o simplemente recurrente a lo largo del tiempo. Un fallo repetible da al soporte una secuencia para intentar. Un fallo recurrente sigue siendo importante, pero su desencadenante sigue siendo incierto. Etiquetar la diferencia ayuda al desarrollador a decidir si pide una reproducción, registros o más información sobre la sesión.
Si hay un mensaje de error disponible, conserva su redacción exacta en lugar de parafrasearlo en una causa. Un código desconocido puede ser más útil para el soporte que un resumen confiado que diga que significa un problema gráfico. Si no capturaste el mensaje, indícalo y describe lo que recuerdas sin inventar el detalle que falta.
Termina con el estado actual. ¿Puedes iniciar el juego ahora? ¿El problema persiste después de la comparación de configuraciones documentadas? ¿Es accesible la ruta de retroalimentación dentro del juego? Estas respuestas le dicen al soporte qué tipo de siguiente paso puedes realizar realmente. Solicitar enviar desde el menú no es útil si tu informe ya explica que el menú nunca aparece.
Mantén el informe original y los seguimientos posteriores conectados. Cuando llegue una nueva observación, añádela con su fecha y condiciones en lugar de reescribir el pasado como si supieras la causa desde el principio. Eso preserva la secuencia útil de la investigación: síntoma, comprobación, resultado y la siguiente pregunta. También facilita evaluar honestamente un cambio exitoso más adelante.
El informe mejorado no necesita ser largo. Necesita exponer los hechos que a veces estaban ocultos entre palabras. Un alcance claro y algunos detalles observados pueden ahorrar más tiempo que una página de explicaciones del motor adivinadas, y dan al desarrollador una base sólida para solicitar la siguiente pieza de evidencia.