Investigación tecnológica aplicada

CASO DE ESTUDIO

¿Puede Python competir con Unity o Unreal Engine? Este documento presenta los datos empíricos que responden esa pregunta.

26-AS3414 Identificador
75 Sesiones de playtesting
60 FPS Objetivo validado
RAD Metodología
Introducción

El problema que ModeX Arcade busca resolver

El desarrollo de videojuegos ha evolucionado hacia sistemas de alta complejidad técnica, generando la percepción generalizada de que su creación requiere dominar motores comerciales especializados como Unity o Unreal Engine, los cuales presentan curvas de aprendizaje pronunciadas que limitan la innovación en entornos académicos e iniciales.

Ante este escenario se plantea la pregunta central de investigación: ¿es técnicamente viable el desarrollo de videojuegos 2D profesionales a través del uso de Python con bibliotecas de código abierto para lograr un rendimiento óptimo?

ModeX busca validar esta viabilidad mediante el desarrollo de un sistema arcade modular con arquitectura escalable y técnicas de optimización, demostrando que lenguajes interpretados pueden democratizar el desarrollo sin sacrificar calidad.
🎮
Dimensión Teórica

Validar la viabilidad de lenguajes interpretados en aplicaciones de tiempo real mediante benchmarks reales.

💡
Dimensión Práctica

Eliminar barreras económicas y técnicas para estudiantes y desarrolladores independientes.

📐
Dimensión Metodológica

Aportar patrones arquitectónicos documentados y replicables para videojuegos 2D desarrollados en Python.

Hipótesis y Objetivos

Lo que el proyecto propuso demostrar

HIPÓTESIS
Es técnicamente viable el desarrollo de videojuegos bidimensionales de calidad profesional con Python como lenguaje base y sus bibliotecas Pygame y Arcade, alcanzando los 60 FPS sin el uso de motores comerciales, mediante técnicas de optimización como sprite batching, culling espacial y object pooling.
Objetivo General

Diseñar, implementar y validar empíricamente un sistema arcade modular compuesto por cuatro videojuegos 2D funcionales, implementados en Python mediante las bibliotecas especializadas Pygame y Arcade, aplicando principios de ingeniería de software y técnicas de optimización de rendimiento.

01
Desarrollar

Cuatro videojuegos bidimensionales con diferentes mecánicas que evidencien la versatilidad técnica de Python.

02
Diseñar

Una estructura modular que permita integrar varios juegos y maximice la reutilización de código.

03
Optimizar

El rendimiento del sistema para garantizar ejecución fluida mediante object pooling, sprite batching, culling espacial y spatial hashing.

04
Documentar

Exhaustivamente el proceso de desarrollo, decisiones arquitectónicas y soluciones técnicas, generando conocimiento transferible y replicable.

Metodología

RAD + Playtesting cuantitativo

Metodología RAD

La investigación adopta la metodología de Desarrollo Rápido de Aplicaciones (RAD), seleccionada por la naturaleza iterativa y cambiante del diseño de videojuegos. Esta metodología permite evaluar y ajustar continuamente los componentes del sistema mediante ciclos cortos de 2 semanas que producen prototipos funcionales evaluables.

Las metodologías ágiles presentan tasas de éxito del 40% frente al 15% del modelo en cascada (Mishra & Alzoubi, 2023), característica particularmente valiosa en proyectos con requisitos cambiantes como los videojuegos.

Recolección de Datos

El diseño metodológico es evaluativo-experimental con enfoque cuantitativo. Durante 75 sesiones de juego el sistema recopiló automáticamente métricas cada 2 segundos sin interferir con la experiencia del usuario.

Métricas recolectadas por sesión
FPS instantáneo, promedio, mínimo histórico
Percentil 1 y percentil 99 del FPS
Desviación estándar del FPS
Frame time en milisegundos
Consumo de memoria RAM
Datos del recolector de basura (GC)
Conteo de entidades activas
Draw calls estimados
Frecuencia de frame drops consecutivos
1
Sep – Oct 2025

ModeX v1.0 — Estructura base, módulo utils, Singleton y juego de carreras Neon Rush.

2
Oct – Nov 2025

ModeX v1.1–1.2 — Cosmic Odyssey, The Ghost Tsushima, The Past Z. Primera versión pública.

3
Dic 2025 – Ene 2026

ModeX v1.3–1.4 — Persistencia SQLite, optimizaciones globales, ventana redimensionable.

4
Feb 2026

ModeX v1.5 — 75 sesiones de playtesting, documentación técnica de 26 páginas, ejecutable .exe.

Análisis de Resultados

Los datos que validan la hipótesis

Estadísticas descriptivas del FPS instantáneo por videojuego.

Juego Media FPS Mediana FPS Desv. Est. Mín. FPS P1 (1%) P99 (99%) Frame Drops
Platformer 58.75 58.79 1.05 42.00 * 56.37 60.50 0.21%
Racing 58.10 58.10 1.20 5.60 40.00 60.50 2.90%
Fight 60.41 60.45 0.75 56.80 58.64 62.02 0.00%

* Valor mínimo de Platformer capturado durante caídas del GC (Garbage Collector).

Valores extremos de Racing (FPS 5.60 y 40.20) corresponden al momento de transición sincrónica entre niveles.

FPS Promedio por Juego

La línea discontinua indica el umbral objetivo de 60 FPS.

60 FPS
60.41
FIGHT
σ = 0.75 · 0% drops
58.75
PLATFORMER
σ = 1.05 · 0.21% drops
58.10
RACING
σ = 1.20 · 2.90% drops*
60 45 30 15 0

* Los drops del Racing se concentran exclusivamente en las transiciones de nivel (carga sincrónica de recursos). En condiciones normales, la mediana es 58.10 FPS.

Distribución FPS Instantáneo

Concentración de valores por juego. La línea discontinua marca el objetivo de 60 FPS.

60 FPS
PLATFORMER
42 – 60.5 FPS
RACING
5.6 – 60.5 FPS
FIGHT
56.8 – 62 FPS
62 60 55 50 45 40

Comparativa de Métricas Clave

FPS promedio, desviación estándar y consumo de RAM por videojuego.

Memoria RAM
PLATFORMER
50 MB
RACING
50 MB
FIGHT
50 MB

RAM constante en los 3 juegos. 0 fugas de memoria detectadas en 75 sesiones.

Desviación Estándar FPS
PLATFORMER
0.8
RACING
2.5
FIGHT
0.7

Mayor desviación en Racing atribuida exclusivamente a spikes de transición de nivel, no al juego en sí.

Evolución de Memoria
v1.2 ~425 MB
v1.6 ~245 MB
−42% de reducción total v1.2 → v1.6
Carga Computacional

Carga por juego y nivel

El incremento de 75 a 140 entidades en Racing (Nivel 1 → Nivel 2) no produce degradación del FPS en condiciones normales. La mediana se mantiene en 58–60 FPS.

Juego / Nivel Entidades Totales Draw Calls Objetos Python Activos Complejidad Visual
Platformer (Nivel 1) 40 – 80 45 – 85 ~154,500 – 156,500 Media
Racing (Nivel 1) 75 80 ~154,500 – 156,500 Media-Baja
Racing (Nivel 2) 140 145 ~228,000 – 229,800 Alta
Racing (Nivel 3) 78 83 ~301,000 Media (acumulada)
Fight 2 10 ~21,265 – 21,290 Muy Baja

Los valores de objetos Python activos incluyen estructuras internas del intérprete de Python.

Frame Time en Racing: Spikes de Transición

Las transiciones de nivel generan spikes estructurales y predecibles. El frame time normal está entre 16.67 ms y 17.5 ms (57–60 FPS).

16.67 ms (60 FPS ideal)
2,237 ms
Nivel 1→2
2,791 ms
Nivel 2→3
0 50 100 150 200 Frame Index

Los spikes son estructurales (carga sincrónica de recursos gráficos y creación del objeto pista) y no reflejan el rendimiento real del motor durante el juego. Son corregibles mediante carga asíncrona o pre-caching de niveles.

06 — Conclusiones

Hipótesis confirmada

Python es técnicamente viable para videojuegos 2D profesionales

Los datos de rendimiento de 75 sesiones demuestran que los tres juegos evaluados alcanzan FPS cercano o superior a 60 en hardware convencional (Intel Core i5 8ª gen., 8 GB RAM, gráficos integrados). Los cuatro objetivos específicos se cumplieron satisfactoriamente.

Fight — 60.41 FPS

Mayor consistencia: σ = 0.75, 0% frame drops. Rendimiento estable a lo largo de todas las sesiones.

Platformer — 58.75 FPS

P1 de 56.37 FPS confirma que el 99% de los frames se mantienen por encima de 56 FPS. Solo caídas por GC.

Racing — 58.10 FPS (mediana)

Drops atribuibles exclusivamente a transiciones de nivel (spikes estructurales). Mediana real: 58.10 FPS.

0 fugas de memoria

RAM constante en 50 MB en las 75 sesiones. Gestión manual del GC y object pooling demostraron ser efectivos.

Recomendaciones derivadas del análisis

01

Implementar carga asíncrona de recursos en el juego de Racing para eliminar congelamientos en transiciones de nivel.

02

Controlar condiciones iniciales del sistema operativo antes de las sesiones de medición para reducir la variabilidad atribuible a estados externos.

03

Extender el sistema automático de medición para identificar cuellos de botella en tiempo real y permitir mayor fluidez en la ejecución.

04

Ampliar ModeX a un quinto género para seguir poniendo a prueba los límites de la arquitectura modular en escenarios de mayor densidad computacional.

¿Quieres replicar el proyecto? Toda la arquitectura, decisiones técnicas y datos están documentados.