Cómo TeK Construyó RaftDedicatedServer (RDS) y Por Qué Funciona en HolyHosting

Raft nunca fue diseñado para tener servers dedicados. Ese hueco es exactamente lo que TeK decidió llenar. El resultado es RaftDedicatedServer, mejor conocido como RDS, y ha transformado la manera en que las comunidades corren Raft multiplayer. La conversación con TeK cubrió cómo empezó el proyecto, lo que se necesitó para arrancar a Steam del stack de networking, y por qué la mayoría de sus servicios ahora corren en HolyHosting.

De dónde viene RDS

TeK no se propuso escribir software de server. Quería hospedar minigames y eventos de roleplay en Raft. El problema fue que no existía un server dedicado real, y la solución oficial requería una segunda licencia de Raft solo para mantener vivo el proceso del host. Para un proyecto comunitario, eso era inviable.

"Al principio, quería crear un server de minigames y un server de roleplay en Raft, pero no había server dedicado, así que no tuve otra opción que hacer el mío. Hospedar un server de Raft habría requerido una segunda copia de Raft. Entonces, decidimos hacer nuestra propia NetworkingLayer eliminando Steam para que los usuarios pudieran hospedar un server sin necesitar una segunda key de Raft."

En resumen, RDS existe porque la alternativa era cinta adhesiva.

Sacar a Steam de la ecuación

La parte más difícil del proyecto fue el networking. Raft estaba pegado al sistema de relay de Steam. Quitar eso implicó hacer ingeniería inversa de cómo Steam movía los paquetes entre jugadores y reconstruir el pipeline sobre TCP/IP plano. TeK le llama a esto RaftTCP, o RTCP.

El beneficio es directo. Los jugadores se conectan directamente al server usando paquetes raw en lugar de rebotar a través de los intermediarios de Steam. Menos hops, menor latencia, menos desconexiones misteriosas.

El lado del gameplay fue igual de incómodo. Raft asume que alguien en el lobby es el host. Cuando reemplazas ese rol con un server headless, algunas mecánicas se vuelven extrañas.

"Tuvimos que asegurarnos de que el juego funcionara como debía en términos de gameplay cuando no había host. Como dormir, por ejemplo. En el juego base de Raft, todos los jugadores necesitan dormir en el server, pero el server, que es un jugador oculto, nunca duerme."

Esos son el tipo de bugs que solo aparecen una vez que ya entregaste el resto del sistema.

Lo que TeK realmente disfruta construir

Al preguntarle sobre su parte favorita del proyecto, la respuesta no fue el trabajo profundo de networking. Fue la capa superior.

"Crear los sistemas de frontend para hacerle la vida más fácil al dueño del server: permisos, ranks, plugins, soporte fácil para mods, comandos de chat. Y la primera vez que RDS realmente funcionó sin Steam fue un gran momento."

Ese tipo de tooling es lo que separa a un binario funcional de algo que los operadores realmente quieren ejecutar durante años.

Hacia dónde se dirige RDS

La hoja de ruta a largo plazo es estabilidad, performance, y un empuje hacia un modelo server-authoritative para que los jugadores no puedan editar su inventario o posición desde el client-side. Ya hay un anticheat ligero implementado, pero la autoridad completa requiere una reescritura más profunda del networking de Raft, el mismo muro que TeK tuvo que escalar en la primera pasada.

Por qué HolyHosting

HolyHosting contactó a TeK primero. Él no había escuchado de la marca y estaba cauteloso con un contacto en frío. Las reuniones cambiaron eso rápidamente.

"Descubrí a su increíble equipo. Los devs fueron muy amables durante nuestras reuniones, e implementar RDS en HolyHosting fue muy fácil. Ahora, ejecuto la mayoría de mis servicios usando servers de HolyHosting y recomiendo a mis usuarios usarlos en lugar de self-hostear nuestro software."

Algunos puntos específicos salieron a relucir más de una vez.

Funciones del panel. Los operadores pueden ver a cada jugador que se ha conectado, programar tareas recurrentes, ver la consola, enviar comandos, y monitorear el uso de recursos desde una sola pantalla. Para un admin de comunidad que no quiere vivir en SSH, eso importa.

Soporte de Proton. Self-hostear RDS en Linux es posible pero doloroso. HolyHosting escribió código propietario para ejecutar RDS a través de Proton y mejoró el performance general en el proceso. TeK no pudo reproducir ese resultado en su propio setup.

Instalaciones de un solo clic. Este es el feedback que TeK escucha más de su comunidad. Levantar RDS en una box de Linux nueva requiere conocimientos reales de sysadmin. En HolyHosting, compras el plan, haces clic en instalar, y el server está corriendo. Las license keys se manejan automáticamente a través del panel.

Lecciones aprendidas

Al preguntarle qué haría diferente, TeK fue directo.

"Si tuviera que empezar todo de nuevo, probablemente habría ido con HolyHosting primero en lugar de perder horas en cosas de Linux para hacerlo funcionar parcialmente. Sus talentosos expertos en Linux también me ayudaron a configurar todo lo necesario en mi propio server."

Cerró con una nota sobre hacia dónde va la asociación.

"HolyHosting es uno de los únicos proveedores con los que estoy feliz de trabajar. Sus equipos realmente se sienten profesionales. Saben lo que están haciendo, y saben de lo que están hablando. En el futuro, definitivamente espero ofrecerles software de server dedicado para nuevos juegos."

¿Buscas levantar tu propio server dedicado de Raft, o tienes curiosidad sobre cómo funciona RDS bajo el capó? Nuestro equipo de soporte está disponible 24/7/365 para ayudarte con lo que necesites.