Solicitar proyecto

La división

T2 Studios

T2 Studios es nuestra división especializada en desarrollo y servicios para proyectos de Minecraft. Diseñamos, configuramos y optimizamos servidores, networks y sistemas personalizados, combinando experiencia técnica con creatividad.

Trabajamos igual con quien abre su primer servidor que con quien ya tiene una comunidad y necesita que la infraestructura le siga el ritmo.

Solicitar un proyectoVer servicios
t2 — flujo de proyecto
Cómo se ve un proyecto desde dentrot2 plan --project mi-servidorObjetivos, público y alcance definidosArquitectura: proxy + 3 instanciast2 build --systems core,ranks,economyCompilando sistemas propiosIntegrando permisos y economíat2 profile --reportPerfilado de TPS y memoriat2 deploy --env productionProyecto listo para producción

Disciplinas

Cuatro cosas que hacemos bien

Un servidor sólido necesita las cuatro. Cojear en una se nota en las otras tres.

  • Arquitectura

    Decidimos cómo se reparte el proyecto entre instancias, qué comparten y qué no. Es la decisión que más caro sale cambiar después.

  • Desarrollo

    Plugins y mecánicas escritas en Java sobre la API del core. Código versionado, documentado y pensado para que otro pueda tocarlo.

  • Rendimiento

    Perfilamos antes y después. Si un cambio no se nota en las métricas, no es una optimización: es una opinión.

  • Contenido

    Modelos, items y resource packs propios cuando el proyecto necesita una identidad visual que no venga de serie.

Proceso

Cómo llega un proyecto a producción

Siete fases. Ninguna es opcional, aunque el peso de cada una cambie según el tamaño del proyecto.

  1. 01

    Idea

    Entendemos el proyecto y sus objetivos.

    Antes de proponer nada preguntamos: a quién va dirigido, qué modalidad, qué presupuesto y qué equipo hay detrás. La mitad de los problemas técnicos de un servidor nacen aquí.

    EntregableObjetivos y alcance inicial por escrito

  2. 02

    Planificación

    Definimos arquitectura, funcionalidades y alcance.

    Decidimos core, versión, estructura de la network, qué se resuelve con plugins existentes y qué hay que desarrollar. También lo que queda fuera, que suele ser lo más importante.

    EntregableArquitectura, stack y plan de entregas

  3. 03

    Desarrollo

    Construimos los sistemas necesarios.

    Escribimos los plugins y las mecánicas propias del proyecto, con la API adecuada y pensando en que otra persona pueda mantenerlo después.

    EntregableSistemas funcionales y versionados

  4. 04

    Configuración

    Integramos plugins, servicios e infraestructura.

    Permisos, economía, bases de datos, proxy, mundos y todo el conjunto de plugins ajustado y coherente entre sí, no cada uno por su lado.

    EntregableServidor integrado y coherente

  5. 05

    Optimización

    Probamos rendimiento, estabilidad y compatibilidad.

    Medimos antes de tocar. Perfilamos TPS, memoria y carga de chunks, corregimos los cuellos de botella reales y verificamos el comportamiento con jugadores concurrentes.

    EntregableInforme de rendimiento y ajustes aplicados

  6. 06

    Lanzamiento

    Preparamos el proyecto para producción.

    Backups, permisos finales, revisión de seguridad, checklist de apertura y acompañamiento durante las primeras horas, que es cuando todo se pone a prueba.

    EntregableServidor en producción y documentación de entrega

  7. 07

    Soporte

    Continuamos con mantenimiento y evolución.

    El servidor sigue vivo: actualizaciones, nuevas mecánicas, ajustes de balance y corrección de lo que aparezca con jugadores reales dentro.

    EntregableAcompañamiento continuo y mejoras planificadas

Realidad

Tres ideas que cuestan caras

No lo decimos para vender más trabajo, sino porque son los tres motivos por los que más veces nos llaman a arreglar algo.

  • «Con instalar unos plugins vale»

    Funciona hasta que dos plugins compiten por lo mismo, la economía se descontrola o el servidor no aguanta la primera avalancha de jugadores.

  • «Ya lo optimizaremos cuando haya gente»

    Cuando hay gente ya no se puede parar el servidor a reestructurarlo. El rendimiento se decide en la arquitectura, no al final.

  • «El servidor está terminado el día que abre»

    El día que abre es cuando empiezan a aparecer los casos que nadie había probado. Por eso el soporte forma parte del trabajo.

Criterio

Cómo tomamos decisiones

Cuando hay que elegir entre dos caminos razonables, estos son los criterios que usamos para desempatar.

  • Decir que no también es parte del trabajo

    Si una idea va a hundir el rendimiento o el presupuesto, lo decimos antes de empezar y proponemos una alternativa.

  • Nada sin medir

    Las afirmaciones sobre rendimiento se sostienen con perfilado. Si no lo hemos medido, no lo prometemos.

  • El proyecto es del cliente

    Entregamos configuración y código documentados. Nadie debería quedar atado a nosotros para poder seguir.

  • Construir para mantener

    Preferimos una solución algo más lenta de escribir y mucho más fácil de mantener seis meses después.

Cuéntanos qué quieres construir

Da igual en qué fase estés: idea sin forma, servidor a medio montar o proyecto en marcha que necesita mantenimiento.

Solicitar un proyectoVer servicios