Sobre nosotros

es un estudio de juegos pequeño e independiente con una larga memoria. La página “Acerca de nosotros” que estás leyendo es la original: una instantánea de principios de la década de 2000, cuando el estudio eran dos personas, una oficina en casa compartida y la creencia obstinada de que se podían crear juegos reales sin un editor pisándote la nuca.

La hemos mantenido prácticamente intacta porque es honesta sobre de dónde venimos y porque las personas que aparecen en ella siguen siendo las personas que hacen los juegos. Lo que sigue es esa misma página, ampliada: quiénes somos, qué hacemos realmente, cómo trabajamos y por qué un estudio que comenzó con C++ y DirectX en una PlayStation 2 terminó lanzando juegos HTML5 y adaptaciones de juegos de mesa.

Conclusiones clave

• Massively Fun es un estudio independiente de dos personas fundado y dirigido por Stephen y Angela Wilkinson, que opera desde mediados de la década de 1990.
• La trayectoria de Stephen es la ingeniería profesional de consolas y PC: C++, DirectX y títulos lanzados en hardware de la era PS/2, Xbox y GameCube.
• La trayectoria de Angela abarca Java, C++, ASP y Delphi, además del trabajo mucho más difícil de administrar el hogar que mantiene vivo el estudio.
• La producción del estudio ha evolucionado con la industria: desde trabajos nativos para consolas hasta juegos HTML5/JavaScript basados en el navegador y adaptaciones digitales de juegos de mesa físicos.
• Construimos en incrementos pequeños y entregables, y consideramos que “terminado y lanzado” es más valioso que “ambicioso e inacabado”.
• Todo lo que hay aquí (reseñas, descargas, notas de desarrollo) proviene de personas que realmente crean juegos, no de una granja de contenido.

Quiénes somos

Stephen Wilkinson — Ingeniero de Software Sr. Stephen pasó años como ingeniero de juegos profesional, sobre todo en Paradigm Entertainment, una empresa de Infogrames, trabajando en títulos de consola durante la generación PS2/Xbox/GameCube. Esa es la época en la que “lanzar un juego” significaba ajustarse a un presupuesto de memoria fijo, ajustar manualmente un renderizador y depurar en kits de desarrollo que costaban más que un automóvil. Se graduó en 1987 de la Duncan High School en Duncan, Oklahoma, lo que te indica que ha estado escribiendo software durante mucho tiempo y que llegó a los juegos por la misma ruta que muchos de nosotros: curiosidad, una computadora en casa y demasiadas noches en vela.

Sus habilidades declaradas son las que importan para este estudio: escribir juegos de computadora, C++, DirectX y desarrollo de consolas en PS/2, Xbox y un poco de GameCube. En la práctica, eso significa que se siente cómodo en todo el stack, desde la gestión de la memoria y el renderizado hasta los sistemas de juego y las herramientas.

Angela Wilkinson — La madre de Arthur y programadora en espera. El título oficial de Angela la subestima. Su conjunto de herramientas incluye Java, C++, ASP y Delphi, además de lo que la página original llama “Mom 1.0”, el sistema operativo que en realidad mantiene en funcionamiento un estudio de dos personas. Cualquiera que haya intentado crear juegos con una familia sabe que el segundo trabajo es el más difícil, y que un estudio sin alguien que gestione la logística, los horarios y la moral no lanza nada.

Su lista de favoritos es breve y reveladora: Arthur (y Stephen). Ese es todo el estudio en una sola línea.

Relacionado: Unity Asset Store — Arte, herramientas y plantillas listas para usar que se incluyen directamente en tu proyecto de Unity.

Lo que realmente construimos

El catálogo de Massively Fun abarca algunos tipos distintos de trabajo, y vale la pena ser explícitos al respecto porque “estudio independiente” puede significar casi cualquier cosa.

• Juegos HTML5/JavaScript originales. Títulos diseñados primero para el navegador, creados para ejecutarse sin complementos, sin instalación y sin un controlador de acceso de tienda. Este es el núcleo moderno de lo que hacemos.
• Adaptaciones digitales de juegos de mesa. Nuestro trabajo más conocido en este espacio es Catan World, una versión digital del Catan de Klaus Teuber; un juego cuyas reglas son simples de enunciar y realmente difíciles de implementar correctamente, porque toda la experiencia depende del orden de los turnos, el intercambio de recursos y la negociación social entre los jugadores.
• Juegos pequeños y precisos de estilo arcade. Fast Iron y Word² entran en esta categoría: bucles cerrados, sesiones rápidas y mecánicas que puedes explicar en una frase pero que pasas semanas afinando.
• Reseñas y comentarios. Jugamos mucho y escribimos sobre ello. Las reseñas en este sitio provienen de desarrolladores activos, lo que cambia lo que notamos: tendemos a preocuparnos tanto por los sistemas, la sensación y la ejecución técnica como por la presentación.

Esa mezcla no es accidental. Refleja una estrategia deliberada: mantener el alcance de cualquier proyecto lo suficientemente pequeño como para que dos personas puedan terminarlo, y mantener varios tipos diferentes de proyectos en marcha para que el estudio no dependa del éxito de un solo título.

Cómo llegamos aquí: de DirectX al navegador

La página original de Acerca de nosotros es una cápsula del tiempo de un momento específico en el desarrollo de juegos. A finales de los 90 y principios de los 2000, si querías crear un juego, lo escribías en C o C++ contra un SDK de plataforma —DirectX en Windows, o las bibliotecas propietarias de una consola— y lo lanzabas en medio físico a través de un editor. Paradigm Entertainment era exactamente ese tipo de estudio, y trabajar allí significaba aprender la disciplina del desarrollo de consolas: hardware fijo, plazos estrictos, requisitos de certificación y ninguna posibilidad de aplicar parches después del lanzamiento.

Si estás de compras: Construct 3 — Motor HTML5 sin código basado en navegador que exporta a la web, dispositivos móviles y computadoras de escritorio.

La web cambió la economía de todo eso. Cuando los navegadores obtuvieron un lienzo 2D real y, más tarde, WebGL, fue posible lanzar un juego a cualquier persona con una URL.

Sin editor, sin disco, sin cola de certificación. Las concesiones son reales: renuncias al acceso directo al hardware, luchas contra las peculiaridades del navegador y no puedes asumir una tasa de fotogramas constante, pero la ventaja es que un equipo de dos personas puede llegar a jugadores de todo el mundo desde el primer día.

Ese cambio es la razón por la que el centro de gravedad de Massively Fun se trasladó a HTML5 y JavaScript. Los hábitos de ingeniería del trabajo con consolas no desaparecieron; simplemente se aplicaron a un objetivo diferente. La disciplina de memoria, los bucles de actualización deterministas y el perfilado cuidadoso son tan importantes en un navegador como lo eran en un devkit.

Cómo trabajamos

Los estudios de dos personas viven o mueren según su proceso, y el nuestro se basa en unos pocos principios que han sobrevivido al contacto con la realidad.

Lanzamientos pequeños, lanzamientos frecuentes. Un juego que existe y es jugable supera a un juego que es teóricamente mejor pero está inacabado. Definimos el alcance según lo que dos personas pueden completar y luego recortamos hasta que encaje.

Prototipar primero la parte arriesgada. Si una mecánica podría no ser divertida, construimos la versión más fea posible antes de crear cualquier arte o interfaz de usuario. La mayoría de las ideas mueren aquí, y ese es el punto.

Relacionado: Amazon: Game Dev Books & Gear — Libros de programación de juegos, teclados mecánicos, monitores y hardware de escritorio de desarrollo..

Mantener la cadena de herramientas aburrida. Para el trabajo en HTML5, eso generalmente significa una base de código JavaScript/TypeScript, un enfoque de renderizado ligero (Canvas puro o WebGL, o una biblioteca pequeña en lugar de un motor pesado) y Node.js para scripts de compilación, canalizaciones de activos y servidores de desarrollo locales. Las herramientas aburridas significan menos sorpresas y menos tiempo dedicado a depurar las herramientas en lugar del juego.

Probar en el peor dispositivo que puedas encontrar. Los juegos de navegador se ejecutan en todo, desde una computadora de escritorio de alta gama hasta un teléfono de hace cinco años. Si aguanta en el objetivo más lento, aguanta en todas partes.

Escribirlo todo. Las notas de desarrollo y las reseñas no son marketing: son nuestra forma de pensar. Explicar una decisión de diseño en prosa es una de las formas más rápidas de descubrir que es una mala decisión.

Nuestra elección: Udemy Game Development Courses — Cursos bajo demanda que cubren Unity, Unreal, C++, C# y programación de sombreadores.

Elegir una pila tecnológica: cómo decidimos

Una de las preguntas más comunes que recibimos de los desarrolladores aficionados es “¿con qué debería construir?”. No existe una respuesta universal, pero sí un proceso de decisión. Así es, aproximadamente, cómo lo pensamos.

Consideración	Inclinarse hacia Canvas/WebGL puro + JS/TS	Inclinarse hacia un motor completo (p. ej., Godot, Unity o un motor JS)
Tamaño del equipo	1–2 personas que prefieren el control	Equipos más grandes o artistas que necesitan editores
Tipo de juego	2D, arcade, puzles, ports de juegos de mesa	3D, con mucha física, grafos de escena complejos
Objetivo	Primero el navegador, carga rápida, descarga pequeña	Multiplataforma, incluyendo consolas/escritorio
Tus puntos fuertes	Disfrutas de los sistemas y el control de bajo nivel	Prefieres dedicar tiempo al contenido y al diseño
Presupuesto de tiempo	Puedes permitirte construir algunas herramientas	Necesitas un editor y una canalización de activos ahora

La advertencia honesta: los motores te ahorran un tiempo enorme en renderizado, física y gestión de activos, pero también imponen su propia arquitectura y sus propios errores. Crear el tuyo propio te da control total y responsabilidad total.

Para un estudio de dos personas que lanza juegos de navegador, un camino intermedio —una pequeña biblioteca de renderizado más tu propia lógica de juego— suele ser la decisión correcta. Para el primer proyecto de un aficionado, un motor es casi siempre la ruta más rápida hacia algo jugable.

Si quieres profundizar en los estándares y plataformas involucradas, los MDN Web Docs on the Canvas API son la referencia canónica para el renderizado 2D en el navegador, y la especificación WebGL mantenida por el Khronos Group cubre la ruta acelerada por GPU. Para la parte de juegos de mesa de nuestro trabajo, el sitio oficial de Catan es la fuente autorizada sobre el juego que adaptamos.

Control de movimiento y otros experimentos

Parte de la historia del estudio involucra plataformas de control de movimiento: la ola de entrada basada en cámaras y sensores que llegó con la era de la Wii y el Kinect. El control de movimiento es un problema de diseño genuinamente interesante porque elimina la capa de abstracción de un botón. Los jugadores esperan que el juego comprenda su cuerpo, y normalmente no lo hace, al menos no con precisión.

Las lecciones prácticas de ese trabajo se trasladan a todo lo demás que hacemos:

• La latencia es el enemigo. Cualquier esquema de entrada con un retraso notable se siente roto, sin importar cuán ingeniosa sea la mecánica.
• Diseñar para el sensor que tienes, no para el que quieres. Si la cámara solo puede detectar de manera confiable el movimiento bruto, crea un juego sobre el movimiento bruto.
• Proporcionar siempre una alternativa. Tanto la accesibilidad como la confiabilidad exigen que un juego sea jugable sin el dispositivo de entrada exótico.

Esos principios se aplican igualmente a los controles táctiles de un teléfono, que es el problema del control de movimiento de la era HTML5.

La gente detrás de los juegos

Vale la pena repetirlo claramente, porque es lo que distingue a un estudio como este de un sitio de contenido: los nombres en esta página son las personas que escriben el código, ajustan las mecánicas y juegan los juegos que reseñamos. La lista de favoritos de Stephen —Final Fantasy Tactics Advance, The Lord of the Rings: The Two Towers en PS2, Fire Emblem, Call of Duty y un elenco rotativo de otros— es la lista de un desarrollador activo. Tiene un peso fuerte en juegos impulsados por sistemas con una progresión profunda, que es exactamente el tipo de diseño que recompensa la mentalidad de ingeniería.

La lista de Angela es de una sola línea y lo dice todo: Arthur y Stephen. Un estudio es un hogar antes que un negocio, y este siempre ha sido ambas cosas.

Preguntas frecuentes

¿Quién dirige Massively Fun?

Massively Fun está dirigido por Stephen y Angela Wilkinson, un equipo de dos personas. Stephen se encarga de la mayor parte de la ingeniería, basándose en una trayectoria profesional en el desarrollo para consolas y PC, mientras que Angela contribuye con la programación en Java, C++, ASP y Delphi, además de gestionar el hogar que hace posible el estudio.

¿Qué juegos ha creado Massively Fun?

El catálogo del estudio incluye títulos originales en HTML5/JavaScript como Word² y Fast Iron, además de Catan World, una adaptación digital del juego de mesa Catan. El estudio también publica reseñas y comentarios sobre los juegos que juega.

¿Qué tecnologías utiliza el estudio?

Históricamente, C++ y DirectX para el trabajo en consolas y PC, incluyendo el desarrollo de la era de PS/2, Xbox y GameCube. Hoy en día, el enfoque es HTML5 y JavaScript para juegos de navegador, con Node.js para herramientas y flujos de trabajo de compilación (build pipelines), y Java, C++, ASP y Delphi presentes en la experiencia más amplia del equipo.

¿Puedo contratar a Massively Fun o colaborar?

El sitio siempre ha sido una página de estudio personal en lugar de el escaparate de una agencia, por lo que no hay una lista formal de servicios. La mejor vía para colaborar o hacer preguntas es comunicarse a través de la dirección de contacto publicada en el sitio.

¿Sigue siendo precisa la página original de “Acerca de nosotros”?

Sí; las biografías, habilidades y favoritos originales se conservan aquí porque siguen siendo ciertos. Las personas, sus trayectorias y sus gustos no han cambiado; lo que ha cambiado es la plataforma para la que construye el estudio y el tamaño del catálogo.

¿Qué consejo tienes para los desarrolladores de juegos aficionados?

Empieza con algo más pequeño de lo que creas necesario, crea un prototipo de la mecánica arriesgada antes de construir cualquier otra cosa y elige un stack tecnológico basado en el tamaño de tu equipo y el tipo de juego, en lugar de lo que esté de moda. Lanzar un solo juego pequeño y terminado te enseña más que comenzar cinco ambiciosos.