MetaNeuroPlanet

Me comuniqué con Boz tan pronto como me enteré del anuncio del final de la vida útil de Echo. Hemos estado en discusiones similares en el pasado, pensé que era un error no mantener Oculus Rooms corriendo y portando a Quest, y pensé que era un error abandonar todo el contenido de GearVR/Go cuando mi capa de emulación funcionaba para al menos una buena parte de las cosas. Yo creo en salvarlo todo.

Incluso si solo hay diez mil usuarios activos, se debe evitar destruir ese valor de usuario si es posible. Su empresa sufre más daño cuando le quita algo querido a un usuario de lo que gana en beneficio al proporcionar algo igualmente valioso para ellos o para otros. El valor del usuario es mi punto de conversación número uno, pero el “enfoque” también es bastante alto, y el costo de oportunidad es algo real.

Creo que es probable que haya un grado de razonamiento motivado internamente que incline la mesa hacia “simplemente mátalo”, pero es difícil argumentar a favor de alternativas, y Pensé que la declaración de Boz era honesta y verdadera. Boz dio luz verde para lanzar la compilación raíz de Oculus Go por la que había agitado durante mucho tiempo, pero después de ver cuánto esfuerzo interno se necesitó para que esto sucediera, casi me siento mal por eso. Las limitaciones son diferentes en una empresa del tamaño de Meta.

Puedo hacer un caso para varias opciones posibles:

Caiga a un soporte absolutamente mínimo. Ponga a un solo desarrollador a cargo de mantenerlo y hacer lo que pueda con la comunidad. En Id Software, tuvimos a una persona administrando Quake Live durante mucho tiempo, y creo que fue lo correcto. Es casi seguro que esto no “ganaría” en un análisis de costo-beneficio para Echo, pero mucha gente gasta en cosas peores y, a pesar de que siempre insisto en la eficiencia, lo consideraría justificado por los intangibles.

Escindir el proyecto. Sugerí que deberían ver si alguien en el equipo quería dejar Meta y hacerse cargo del proyecto. Los miembros del equipo pueden ver los paneles y hacer una evaluación sobre si existe algún camino viable para que el juego sea compatible con un solo desarrollador. Puede haber personas internamente que piensen que el desarrollo del juego ha sido mal administrado y que existe la posibilidad de un renacimiento si se toman decisiones diferentes. Sugerí que ofrecieran vender los derechos por $10k. Meta pagó muchos millones de dólares para adquirir Ready at Dawn, por lo que sería una píldora amarga de tragar, pero aún así sería un bien neto para la realidad virtual. Desafortunadamente, el proceso para escindir algo está lejos de ser simple en Meta e involucra mucha supervisión gubernamental en este punto.

Un problema con ambas opciones es que puede que nadie con las habilidades esté interesado en hacerlo. Scuidar un producto a través de sus años crepusculares no es el libro de jugadas para el avance de la carrera de gran tecnología. El desarrollador de juegos tiene una multitud diferente, pero hay muchos incentivos una vez que estás dentro de Meta que comienzan a cambiar la forma de pensar de las personas.

Podrían pegarle una pancarta “sin soporte” y simplemente dejar que siga funcionando hasta que algo muera, en lugar de matarlo explícitamente. A medida que las cosas se pudren, habrá más y más peticiones y agitación para que un solo ingeniero entre para hacer una pequeña solución simple para lo que sea que se rompa, y podría terminar siendo más una animosidad neta que simplemente matarlo limpiamente.

Código abierto del proyecto. Esto funcionaría como un buen ejemplo para desarrolladores, aunque el código base de Echo es muy diferente al de Unity, donde trabajan la mayoría de los desarrolladores de realidad virtual. Nunca miré la base de código de Echo, pero la mayoría de las bases de código comerciales grandes tienen varias cosas que tienen licencia, en lugar de propiedad, por lo que solucionarlas puede ser una tarea de ingeniería importante, y perder algo puede tener repercusiones legales, por lo que incluso publicar una el volcado parcial no funcional es peligroso.

Un pequeño desarrollador puede, en teoría, sólo smarque un encabezado de comentario de licencia en todos los archivos y lance el proyecto en GitHub, pero esto rara vez sucede (¡para mi tristeza!). El esfuerzo de hacerlo en el Meta, con todas las revisiones legales y técnicas, es mucho mayor, y los peligros son mucho mayores.

Si bien este es principalmente un problema comercial, todavía hay jugadas técnicas que pueden ayudar en el futuro, y animo a todos, dentro y fuera de Meta, a pensar en ellas:

“Mantener las cosas vivas requiere trabajo” es cierto en algún nivel, pero es posible construir sistemas que funcionen intactos durante años y funcionen bien después de un reinicio. El valor predeterminado hoy puede ser un lío distribuido de espaguetis, pero esa es una elección. Un sistema que ha estado funcionando durante años puede tomar el camino de evolucionar hacia una mayor solidez cada vez que se manifiesta un problema.

Todos los juegos deben asegurarse de que aún funcionen en algún nivel sin el soporte del servidor central. Incluso cuando no se tienen en cuenta las preocupaciones sobre el final de la vida, es valioso poder trabajar cuando Internet no funciona. Si puede admitir algún nivel de juego LAN para un juego multijugador, la puerta está al menos abierta para que las personas escriban proxies en el futuro. La opción de admitir servidores administrados por usuarios puede ahorrar costos de hospedaje y también abre varias vías creativas para la comunidad.

Sea disciplinado con sus procesos de construcción y lo que pone en su árbol de código fuente, para que al menos exista la posibilidad de hacer que el proyecto sea de código abierto. Piense dos veces antes de agregar dependencias que no puede redistribuir, y considere probar con versiones eliminadas de las cosas que usa. No haga cosas en su código que no serían aceptables para todo el mundo. La mayor parte del desarrollo de juegos es una carrera de pánico para hacer que las cosas dejen de desmoronarse el tiempo suficiente para enviarse, por lo que puede ser difícil dedicar tiempo a la ingeniería de software fundamental, pero hay una satisfacción en ello, y puede dar sus frutos con una etapa final menos problemática. desarrollo.