Traducción asistida por máquina; los nombres de los objetos del juego pueden permanecer en inglés.
Prepara un informe breve con versión, pasos mínimos y capturas claras, y distingue los errores de las opiniones sobre el equilibrio.
Comienza con un problema
Un informe de error útil describe un fallo único con suficiente claridad para que otra persona pueda reproducirlo. Empieza con la acción y el resultado: abrir un menú en particular oculta el cursor, por ejemplo, o cargar una partida coloca al personaje debajo del suelo. Evita comenzar con varios párrafos sobre todo el juego. La persona que lee necesita saber qué reproducir.
Separa un fallo técnico de una preferencia. Un botón que no hace nada, un objetivo que no avanza y un medidor de supervivencia que se siente demasiado exigente son diferentes tipos de comentarios. Todos pueden valer la pena reportarse, pero necesitan evidencia distinta. Una queja de equilibrio debe explicar la experiencia que se desea; un informe de error debe explicar el comportamiento esperado y lo que ocurrió en su lugar.
Elige el destino del informe según la capa que falla
Una misión del juego, un problema con la compra desde el lanzador y un fallo en la instalación del controlador gráfico requieren equipos de soporte diferentes. Describe la capa que está fallando antes de elegir un destino. Si el juego funciona pero un objetivo no avanza, comienza con el canal de reporte del desarrollador. Si la tienda no puede completar una descarga, comienza con el soporte de la plataforma.
Para un posible problema del controlador gráfico, el proveedor de hardware puede necesitar un informe separado. AMD ofrece una Herramienta de Informe de Errores que recopila detalles del sistema y acepta pasos de reproducción y archivos adjuntos. Esa herramienta envía la información a AMD; no es un sustituto de informar al desarrollador del juego sobre un problema de misión o de partida guardada. Úsala cuando la evidencia o las indicaciones de soporte apunten a la capa de gráficos o del sistema.
Evita publicar informes idénticos y extensos en todas partes sin contexto. Si hay dos equipos de soporte involucrados, explica por qué y conserva sus identificadores de caso por separado en privado. Una referencia cruzada concisa puede evitar trabajo duplicado, mientras que un volcado público de todos los correos electrónicos y archivos adjuntos puede exponer información sin ayudar a nadie a entender el límite técnico.
Crea un título que pueda encontrarse más tarde
Un buen título combina el síntoma visible con el desencadenante. Por ejemplo, “el cursor del menú desaparece después de conectar un accesorio de vuelo” es más fácil de reconocer que “por favor arreglen el juego”. Incluye una versión solo cuando la hayas verificado. No pongas una teoría no probada en el título como si fuera un hecho establecido.
Para un informe de misión, usa el objetivo visible o el nombre del objeto y señala el fallo. Evita los spoilers en el título cuando el canal de informes permita marcar spoilers o dar una descripción más neutral. Puedes poner los detalles necesarios del progreso en el cuerpo del mensaje para las personas que investiguen el problema.
Busca los términos clave antes de publicar. Si encuentras un informe existente que coincida con el mismo desencadenante, compara su versión y resultado. Añade tus pruebas allí cuando sea apropiado en lugar de crear otro hilo casi idéntico. Si tu reproducción difiere materialmente, explica la diferencia. Síntomas similares pueden tener causas distintas, así que no fusiones automáticamente informes no relacionados ni insistas en que cada nueva observación requiera una conversación completamente separada.
Escribe los resultados esperados y reales como un par.
El resultado esperado debe provenir de una instrucción de interfaz, comportamiento previo normal o una regla clara del juego, no solo de lo que desearías que ocurriera. Si no estás seguro de si el comportamiento es intencionado, formula el informe como una pregunta y explica la ambigüedad. Esto deja espacio para clarificaciones sin debilitar la utilidad de tu observación.
El resultado real debe describir lo que aparece en pantalla o qué entradas siguen siendo posibles. El texto objetivo permanece sin cambios después de esta interacción es más útil que la misión está completamente rota. Si aún puedes moverte, abrir menús o cargar otra sesión, incluye esa información; esto distingue un bloqueo de progreso de una congelación de la aplicación.
Mantén el par cerca en el informe. Un lector no debería necesitar reconstruir la acción esperada a partir de varios párrafos de historia. Continúa con los pasos de reproducción y luego contexto opcional. Este orden facilita escanear el informe y permite al investigador probar la afirmación central antes de considerar detalles menos ciertos.
Distingue una reproducción de un diario de ruta.
Un diario de ruta registra todo lo que hiciste. Una reproducción contiene la secuencia mínima necesaria para desencadenar el problema. Comienza con tu diario si eso es todo lo que tienes, luego identifica qué pasos son definitivamente necesarios, posiblemente relevantes o simplemente ocurrieron antes. No borres el contexto incierto; muévelo a una nota separada.
Si las pruebas son seguras, varía un requisito previo sospechoso. Por ejemplo, compara la interacción antes y después de conectar un accesorio opcional, o compara una sesión afectada con otra existente. No empieces una nueva campaña ni sacrifiques progreso valioso únicamente para producir un informe más limpio. Un estado guardado puede ser un mejor punto de partida que reproducir horas de acciones.
Sé explícito cuando tu reproducción dependa de una sesión particular que no puedes reducir más. El investigador puede necesitar esa sesión en lugar de una ruta escrita más larga. Consérvala, describe los pasos inmediatos después de cargarla y proporciónala de forma privada cuando se solicite. Esto mantiene el informe práctico incluso cuando el desencadenante subyacente ocurrió mucho antes de la falla visible.
Informa la frecuencia sin exagerar la confianza
Usa observaciones que puedas contar o describir. Decir que el problema ocurrió en dos cargas consecutivas es más claro que decir siempre está roto. Decir que el problema ocurrió una vez después de una sesión larga es más claro que decir que se bloquea aleatoriamente todo el tiempo. No necesitas una muestra grande para enviar un informe útil, pero sí necesitas indicar lo que realmente observaste.
Si un intento posterior funciona, agrega ese resultado. El comportamiento intermitente es información valiosa, especialmente cuando difiere según la sesión, ubicación o dispositivo conectado. No ocultes un intento exitoso porque te preocupe que haga parecer menos creíble el problema original. El objetivo es ayudar a identificar las condiciones, no ganar una discusión sobre si el juego es bueno.
Cuando otro jugador informa un resultado diferente, compara el contexto en lugar de tratarlo como una contradicción. Puede que tengan una construcción, ruta, configuración de entrada o estado guardado diferente. Pide los detalles relevantes y mantiene tu propio informe específico. Un desacuerdo entre dos configuraciones documentadas puede proporcionar una pista útil; un intercambio de afirmaciones universales rara vez lo hace.
Prepara capturas de pantalla y grabaciones con un propósito
Steam documenta su función de captura de pantalla y el requisito de la superposición para esa función. Si tu método de captura configurado funciona, úsalo para mostrar el error o la interfaz relevante. Un fallo de captura es un problema aparte; aún puedes describir el síntoma o usar otro método de captura ordinario disponible en tu computadora.
Antes de grabar, decide qué necesita ver el espectador: el estado inicial, la secuencia de entrada y el resultado. Un clip corto con esos elementos es más fácil de inspeccionar que varios minutos de juego no relacionado. Si el error desaparece rápidamente, una grabación puede ayudar a preservar su redacción exacta sin repetir intentos arriesgados.
Revisa el archivo antes de compartirlo. Verifica que el texto sea legible y que la evidencia realmente muestre el problema reportado. Elimina contenido privado de escritorio no relacionado de la copia compartida, mientras conservas el original si el soporte más tarde necesita contexto. No agregues ediciones que oscurezcan el orden de acciones o hagan que intentos separados parezcan continuos. La evidencia clara debe reducir la incertidumbre, no crear una historia más convincente pero engañosa.
Usa los archivos adjuntos y diagnósticos con moderación
Más datos no son automáticamente mejores. Comienza con la información que coincide con el problema: detalles del dispositivo para la entrada, modo de pantalla para la resolución, objetivo y sesión para la progresión. Si el soporte solicita registros o una exportación de diagnóstico, proporciona el material solicitado y etiqueta la hora del evento. Evita subir una carpeta de usuario completa como un atajo.
La herramienta de informes de AMD ofrece una copia local de la información enviada y un campo de historial de controladores. Esas funciones ilustran hábitos útiles incluso fuera de esa herramienta: conserva tu propio informe y registra si el problema apareció solo después de un cambio de software. Este artículo no afirma que cada fallo necesite un informe de AMD ni que la herramienta pueda diagnosticar hardware que no sea AMD.
Para cualquier archivo adjunto privado, verifica el canal de recepción y los permisos de acceso. Comparte solo con el destinatario de soporte previsto y evita enlaces públicos cuando un archivo pueda contener información personal. Mantén la evidencia original sin cambios y envía una copia. Si un equipo de soporte solicita un formato diferente, anota esa solicitud para que puedas distinguir su requerimiento de diagnóstico de una solución alternativa encontrada en otro lugar.
Haz seguimiento con un resultado, no solo con otra queja
Cuando el soporte sugiera una prueba, informe la versión inicial, el paso realizado y el resultado. Si el síntoma cambia, describa cómo. Llegar al menú pero aún fallar al cargar es un resultado diferente de fallar antes de que se abra la ventana. Estas distinciones permiten que el investigador decida si la siguiente pregunta pertenece al mismo camino de falla.
Si una actualización resuelve el problema, indique qué actualización y cómo lo comprobó. Si persiste, proporcione la misma reproducción mínima en la nueva versión en lugar de reescribir toda la historia. Mantenga la evidencia anterior disponible para que se pueda comparar el cambio.
Si ya no tiene la sesión afectada o no puede repetir el problema, indique esa limitación. No invente una reproducción limpia para mantener el informe activo. Una nota de cierre veraz ayuda a los futuros lectores a comprender cuánto se verificó. También preserva la confianza en la información útil que ya contribuyó, incluso cuando la investigación termina sin una explicación definitiva del evento original.
Registre la secuencia más pequeña confiable
Escriba la condición inicial, luego las acciones en orden. Incluya solo los pasos que importan para la falla. Si no sabe si un evento anterior es relevante, ponga una breve nota de contexto en lugar de enterrar la reproducción dentro de una cuenta completa de su sesión de juego.
Intente la secuencia nuevamente solo cuando hacerlo no ponga en riesgo un progreso importante. Si sucede dos veces desde el mismo estado, indíquelo. Si sucedió una vez y no puede reproducirlo, diga eso en su lugar. Un informe honesto de una sola vez es más útil que una afirmación confiada de que todos los jugadores encontrarán el mismo problema.
Incluya la versión, la tienda y la información relevante del dispositivo. Para un problema de entrada, nombre el controlador y otros accesorios conectados. Para un problema de pantalla, registre la resolución seleccionada y lo que el juego muestra realmente. Para un problema de misión, indique el objetivo visible y la interacción que no logró avanzar.
Verifique si hay una nota de desarrollador correspondiente
Lea los anuncios oficiales recientes antes de presentar un informe duplicado. Una solución conocida puede ahorrarle tiempo si la instalación está desactualizada, y un problema conocido puede ya tener un formato de diagnóstico solicitado. Si el problema persiste después de la actualización relevante, menciónelo explícitamente y describa su nueva prueba.
Las notas del 4 de septiembre dirigen a los jugadores que experimentan guardados al caer a través del mundo para que info@breathedge.com. Conserva la sesión afectada y proporciónala de forma privada cuando se solicite. Para otros síntomas, inspecciona el centro de discusión oficial para ver las instrucciones actuales adecuadas; un contacto para un problema reportado no reemplaza todas las demás rutas de soporte.
Adjuntar pruebas que respondan a una pregunta
Una captura de pantalla debe mostrar claramente la interfaz o error relevante. Una grabación corta debe comenzar lo suficientemente pronto para mostrar la acción que lo desencadena y detenerse una vez que el resultado sea visible. Ninguno de los dos necesita todo tu escritorio, la página de la cuenta o una conversación no relacionada. Revisa el archivo adjunto antes de publicarlo.
Conserva el archivo original al preparar una imagen recortada. Si el soporte necesita más contexto más adelante, puedes proporcionarlo sin intentar recrear el problema. Para registros y archivos, inspecciona el contenido y comparte solo lo solicitado. Nunca incluyas contraseñas, archivos de autenticación ni carpetas personales no relacionadas en un informe público.
Cuando describas un error, conserva su texto exacto. Cuando describas una teoría, etiquétala como teoría. Decir que un problema comenzó después de conectar un controlador es una observación; decir que el controlador definitivamente corrompió la partida es una afirmación causal que necesita pruebas mucho más sólidas.
Cierra el ciclo tras una respuesta
Si un paso solicitado funciona, informa del resultado y de la versión utilizada. Si no funciona, indica qué cambió y qué se mantuvo igual. Esto permite al desarrollador distinguir una mejora parcial de ningún efecto y ayuda a otros lectores a evitar repetir un camino fallido.
Mantén los comentarios de seguimiento en la misma discusión siempre que sea posible. Iniciar un nuevo hilo para cada intento separa la evidencia y dificulta la comprensión de la historia. Una breve nota final identificando la actualización funcional o la reproducción restante es valiosa para el siguiente jugador que busque el mismo síntoma.
Guarda una copia final del título del informe, la fecha y la versión probada en tus propias notas. Si el mismo síntoma regresa meses después, ese registro te permite describirlo como una posible recurrencia con antecedentes conocidos en lugar de partir de un recuerdo vago. Enlaza la discusión anterior y explica qué se ha observado recientemente.
Si descubres que tu informe usó la versión incorrecta del juego, corríjelo explícitamente. Dejar la afirmación antigua sin calificar puede engañar a los jugadores que luego buscan problemas conocidos en esa versión.
Fuentes y verificación
Este artículo combina hechos citados con consejos editoriales prácticos. Sigue la versión y las notas de incertidumbre antes de aplicar una ruta más antigua.
