Proyecto CornerBoyz

01La apuesta

Pokémon GO probó que la gente camina por un juego. Minecraft probó que la gente construye para siempre. Nadie ha juntado las dos cosas y sobrevivido: Minecraft Earth se lanzó en octubre de 2019, superó 1,4 millones de descargas en su primera semana y cerró el 30 de junio de 2021. CornerBoyz existe si y solo si resuelve lo que ese cierre dejó abierto.

Qué es

Una app móvil de mundo persistente. Al abrirla, el juego genera el terreno voxelizado de donde estás — elevación real, agua real, edificios reales, bioma según la cobertura del suelo real — y lo presenta en dos modos: un mapa isométrico de bloques (el modo por defecto, barato en batería) y un modo cámara que ancla ese mundo sobre lo que ves. El jugador recolecta recursos caminando, gana tokens a diario, compra parcelas ligadas a coordenadas reales y construye sobre ellas.

Los tres pilares

1. El mundo ya está ahí. No es un mapa temático encima de la ciudad: es la ciudad, traducida a bloques, con la misma altura de cerro y la misma curva de río. Ese es el gancho de la primera sesión y no lo tiene nadie.
2. Lo que construyes se queda. La construcción persistente y visible por otros es lo que convierte una novedad en un hábito. Minecraft Earth no tenía esto: las buildplates eran privadas y portátiles, así que el mundo real nunca cambiaba.
3. La tierra es escasa y es tuya. La propiedad real de parcelas — con registro en cadena — le da a la exploración un objetivo económico y no solo coleccionista.

Qué NO es

• No es una app que "escanea tu casa y la convierte en Minecraft". La cámara del teléfono no puede reconstruir tu barrio en tiempo real; el mundo viene de datos geoespaciales y la cámara solo lo ancla. Distinguir esto desde el día uno evita prometer lo imposible.
• No es play-to-earn. La tesis económica es "poseer y construir", no "rendir". Ver §09.
• No es multijugador en tiempo real con física compartida. Es un mundo compartido con edición asíncrona y autoritativa en servidor.

Sesión objetivo

6–10minutos, 2–3 veces al día. La AR es un pico de 30–90 s dentro de eso, no el bucle.

Bloque

1 m³Escala 1:1 con el mundo. Un jugador de 1,8 m mide ~2 bloques, como en Minecraft.

Parcela base

307 m²Celda H3 de resolución 12. Del tamaño de un lote urbano típico.

Coste de acuñar

~US$0,001Por parcela, con NFT comprimidos en Solana a escala de millón.

02Los doce huecos: lo que falta en el concepto

Pediste que revise qué falta. Esto es la respuesta corta, ordenada por cuánto puede matar el proyecto. Cada uno se desarrolla en su sección.

03Fantasía del jugador y bucle de juego

La frase que el jugador le dice a un amigo

"Mi barrio existe dentro del juego. Ese cerro es ese cerro. Y la esquina donde está el kiosco ahora es mi fortaleza."

Todo lo que no sirva a esa frase es candidato a recortarse.

Bucle por escalas de tiempo

Qué añade CornerBoyz sobre Minecraft, concretamente

Pediste "similar a Minecraft pero con más funciones". El "más" tiene que venir de lo que solo el mundo real permite, no de más bloques:

• Recursos con geología real — la cobertura del suelo y la elevación determinan qué se mina donde: arcilla junto a los ríos, piedra en pendiente, madera según el tipo de vegetación real.
• Clima real como mecánica — lluvia real hace crecer cultivos; el viento real mueve molinos; la noche real trae criaturas. Se enchufa a una API meteorológica por celda.
• Altitud como progresión — construir por encima de tu altura de terreno cuesta más; las cumbres son objetivos.
• Oficios sociales — el Cartógrafo revela celdas para otros, el Comerciante mueve recursos entre zonas, el Guardián protege parcelas ajenas. Roles que solo tienen sentido con geografía compartida.
• Rutas — caminos construidos entre parcelas que dan bonificación de movimiento a todos. Infraestructura colectiva.

Salir del barrio: el aeropuerto

Un juego de ubicación tiene un problema estructural: tu mundo es el radio que caminás, y ese radio es chico. Si el juego se queda ahí, se agota; si permite teletransporte libre, nadie camina más y el bucle central muere. Es el error exacto que hay que no cometer.

La solución del prototipo: separar los permisos, no los mundos. El viaje existe, cuesta y tiene una puerta física.

Los cuatro elementos que hacen que funcione, y ninguno es opcional:

1. El aeropuerto es un lugar del mundo, con pista y torre de control. Hay que caminar hasta ahí. No se viaja desde un menú, y eso mantiene el caminar dentro del bucle incluso cuando lo que querés es irte.
2. El pasaje se paga por distancia real — haversine sobre las coordenadas de los dos lugares. Cruzar el país cuesta el doble que ir al pueblo de al lado. Viajar es una decisión económica, y el CANDY del pasaje se destruye: es un sumidero que crece con la movilidad de la población (§09).
3. El mapa de calor es el motor de descubrimiento. Cada barrio aparece en su posición geográfica real, con la gente que está jugando ahí ahora y las parcelas ya tomadas. Es lo que convierte "hay más mundo" en "quiero ir ahí": la información sobre dónde está la actividad es la que genera el viaje.
4. Los recursos y el reclamo de tierra nueva quedan atados al GPS real. Esta es la regla que sostiene todo lo demás. Si volar sirviera para farmear, el juego se convierte en un simulador de menús.

Frenos que evitan que el viaje degenere: enfriamiento entre vuelos, pasaje a mitad de precio para volver a tu barrio de origen (nadie tiene que quedar varado lejos de su casa por falta de saldo), e impuesto global — se cobra de todas tus parcelas en cualquier barrio, así que irte no libera de lo que compraste, mientras el rendimiento sigue pagando solo lo que visitás.

En el prototipo cada barrio es su propia grilla con su semilla. En el producto tiene que ser un solo mundo indexado por celdas H3, donde "tu barrio" son simplemente las celdas cerca de tu GPS y los lugares del prototipo pasan a ser regiones del mismo mundo (§06).

04Nacer: identidad y creación de personaje

Pediste que el usuario "nazca" y elija datos básicos de quién es. Vale la pena tratarlo como un momento con peso narrativo, porque es también el momento donde se fija el dato más importante del jugador: su coordenada de origen.

El flujo de nacimiento

1. Paso 01DespertarPantalla negra, la voz del mundo, permiso de ubicación. La primera imagen es tu propia calle en bloques.
2. Paso 02OrigenLa celda donde abrís la app por primera vez queda como Hogar. Permanente, con una mudanza gratis al año.
3. Paso 03Quién sosNombre, avatar de bloques modular, y linaje generado desde tu semilla.
4. Paso 04OficioUno de cinco. Reversible con coste. Define el árbol de recetas inicial.
5. Paso 05Primera obraEl juego te da 64 bloques y te pide plantar una baliza. Tu parcela de origen es gratis.

Los datos que elige el jugador

05Generar el mundo con la geografía correcta

Esta es la parte técnicamente más difícil y la que define el producto. La regla: el mundo se genera de forma determinista en el servidor a partir de datos geoespaciales, se cachea como chunks de voxels y se sirve al cliente. Nunca se genera en el cliente, porque dos jugadores en la misma esquina deben ver exactamente lo mismo.

Tubería de generación

1. FuenteDatos crudosDEM global, huellas de edificios, cobertura del suelo, agua y vías. Todo en almacenamiento propio, no en API de terceros por petición.
2. PreprocesoNormalizarDEM a COG remuestreado, huellas y vías a GeoParquet, cobertura a un ráster de clase de bioma. Trabajo por lotes, offline.
3. VoxelizarChunk builderPor cada chunk pedido: muestrea altura, aplica bioma, extruye edificios, corta agua y caminos. Salida comprimida.
4. SembrarDetalle proceduralÁrboles, minerales, cuevas y estructuras con ruido sembrado por hash(versión · id_chunk). Reproducible bit a bit.
5. ServirCaché + deltaEl cliente pide el chunk base (cacheado en CDN) y por separado el delta de ediciones de jugadores. Se fusionan en el dispositivo.

Fuentes de datos: lo verificado

Escala, chunks y volumen de datos

• 1 bloque = 1 m³. Un DEM de 30 m interpolado a 1 m da laderas suaves y algo blandas; se compensa con terrazas de ruido sembrado para que se lea como Minecraft y no como una manta.
• Chunk = 16 × 16 × 256 bloques, como Bedrock. 65 536 voxels por chunk; con paleta por chunk y codificación por longitud de tramo, un chunk urbano típico comprime a 2–8 KB.
• Presupuesto por km²: ~3 900 chunks → 8–30 MB por kilómetro cuadrado según densidad urbana. Una sesión de radio 300 m toca ~1 100 chunks ≈ 2–9 MB. Aceptable con caché agresiva; hay que medirlo en el prototipo.
• Malla: greedy meshing por chunk con caras ocluidas descartadas, dos niveles de detalle (bloques completos a <120 m, silueta simplificada más allá).

06Parcelas, grilla y propiedad

Dos grillas, no una

Aquí hay una trampa de ingeniería que conviene ver antes: los hexágonos no embaldosan con cubos. Los sistemas de indexación geoespacial modernos son hexagonales (H3) porque los vecinos están todos a la misma distancia — ideal para adyacencia de propiedad. Pero los voxels son cúbicos. No se puede usar la misma grilla para las dos cosas.

Diseño: la propiedad se registra en celdas H3; los bloques viven en una grilla cartesiana local (ENU métrica por región). Un voxel pertenece a la parcela cuyo polígono H3 contiene su centro. La verificación de permiso de construcción es un point-in-cell, que en H3 es una función de hash, no una consulta geométrica: barato y exacto.

Jerarquía de celdas

La alternativa es S2, que es cuadrangular y por tanto encaja mejor con voxels: nivel 19 = 309,27 m² (casi idéntico a H3 res 12), nivel 20 = 77,32 m², nivel 22 = 4,83 m². Recomendación: H3, por adyacencia uniforme (clave para mecánicas de vecindad y expansión) y porque existe h3-pg para indexar directo en PostGIS. Se documenta S2 como plan B si la unión hexágono/cubo da problemas visuales en el prototipo.

07Cámara, AR y anclaje al mundo

Aquí hay que ser preciso, porque el concepto dice "la cámara leyendo el ambiente y ubicando la locación". Conviene separar lo que la tecnología hace hoy de lo que suena bien.

Lo que sí puede hacer la cámara, hoy

Está disponible para Android nativo, iOS, Unity vía AR Foundation y Unreal, con cobertura en casi todos los países, salvo un pequeño conjunto de dispositivos compatibles con ARCore que no soportan la API. La documentación consultada no publica precios ni cuotas concretas — remite a apartados por plataforma. Hay que confirmar cuotas y coste antes de comprometer el diseño.

Pero nada de eso llega al navegador. Esta tabla describe lo que existe en una app nativa, y la decisión de hacer la versión web primero la pone entera fuera de alcance. Es el precio principal de esa decisión y conviene verlo sin adornos.

Qué queda en la web

Estas capacidades no pudieron verificarse en fuente primaria en esta sesión — la búsqueda web estaba bloqueada. Es lo primero que hay que comprobar en la fase 0, con un dispositivo real y no con documentación.

Lo que la cámara NO puede hacer

• No reconstruye tu barrio. El escaneo del teléfono cubre metros, no manzanas, y tarda minutos. El mundo tiene que venir de datos geoespaciales; la cámara solo lo alinea.
• No funciona bien en interiores ni de noche. El VPS depende de imágenes de calle diurnas. Un jugador en su living a las 23:00 no localiza.
• No tolera sesiones largas. Cámara + GPS + render de voxels es el peor caso térmico del teléfono.

08Construir sobre lugares reales

Esta sección es donde el proyecto se gana o se pierde la aprobación de las tiendas y la paz con el mundo físico. Es contenido generado por usuarios, superpuesto a domicilios reales, y visible para desconocidos.

Reglas de construcción

• Se construye solo en celdas propias, alquiladas o con permiso explícito del dueño.
• Altura máxima = altura del terreno + 16 bloques en residencial, +48 en la sede de guilda de un barrio. Evita torres que tapen el mapa.
• No se construye sobre calzada, vía férrea, agua navegable ni huella de edificio — se deriva de la capa de vías y edificios, y además protege al jugador de pararse en la calle.
• Colocar bloques requiere presencia física en la celda o adyacente (res 12). Editar a distancia es solo para demoler lo propio.

Visibilidad escalonada

No todo lo construido es público de inmediato. Es el mecanismo de moderación más eficaz y el más barato:

1. Nivel 01PrivadaSolo el autor la ve. Instantáneo, sin revisión. La mayoría del contenido se queda aquí.
2. Nivel 02VecinalVisible para quien pise el barrio (res 9). Filtro automático + reputación del autor.
3. Nivel 03PúblicaVisible en el mapa global y en la web. Requiere revisión: automática si la reputación es alta, humana si no.
4. Nivel 04DestacadaPromocionada por el juego. Revisión humana obligatoria, siempre.

Zonas de exclusión y derecho del propietario

Pokémon GO acumuló demandas de propietarios y ordenanzas municipales por convocar jugadores a propiedad privada y a parques. Vender la propiedad virtual de un domicilio real es más agresivo que poner un PokéStop enfrente. Hay que construir esto antes de abrir:

09Economía, tokens y tierra en cadena

Elegiste economía on-chain real. Es viable, y es la parte del proyecto con más formas de fallar. Esta sección está escrita para minimizar esas formas.

Dos monedas, y una sola es vendible

El punto entero de esta separación: el grifo diario paga en CANDY, no en CORNER. El jugador siente que gana algo cada día, y el token con precio de mercado no se inunda. Un grifo diario que emite el token vendible es el mecanismo exacto que destruyó a Axie Infinity y a StepN: la emisión creció con los jugadores, la demanda dependía de que entraran jugadores nuevos, y cuando dejaron de entrar el precio colapsó y el juego con él.

Grifos y sumideros

La regla operativa: la emisión neta de CANDY por jugador activo tiene que ser negativa en el percentil 50 y ligeramente positiva en el percentil 90. El jugador medio gasta lo que gana; el jugador dedicado acumula despacio. Esto se instrumenta desde la alfa y se ajusta cada temporada; sin ese telemetría, la economía se diseña a ciegas.

La tierra como activo

• Acuñación diferida. Nada se acuña hasta que alguien reclama. El registro autoritativo de propiedad es el servidor; la cadena es el registro público y portable.
• Coste verificado. Con NFT comprimidos en Solana (Metaplex Bubblegum), el coste por pieza a escala es de 0,000005312 SOL por 1 M de piezas y 0,000027222 SOL a 10 000. A escala de millón, del orden de un décimo de centavo de dólar por parcela. Eso hace viable un mundo con millones de celdas acuñadas. La contrapartida es que la lectura depende de un indexador (DAS API), así que hay que operar o contratar uno.
• Cartera invisible. El jugador nunca ve una frase semilla. Cartera embebida por passkey, gas patrocinado, y la palabra "cripto" fuera de la interfaz de juego. Si el onboarding requiere entender una cadena, el juego pierde al 95 % de su audiencia.
• Impuesto en vez de especulación pura. El impuesto de tenencia semanal, combinado con el requisito de visita física para el rendimiento, hace que acumular parcelas sin jugar sea una pérdida. Es la defensa principal contra que la tierra la compre entera un fondo el primer día.

10El muro de las tiendas

Decisión tomada: se lanza en web. No hay app, y por lo tanto no hay muro. Esta sección se conserva por dos razones: porque el muro reaparece entero en la fase 4, cuando llegue el cliente nativo (§07, §12); y porque el texto de Apple es lo que hay que releer el día que iOS vuelva a la mesa.

"Si querés desbloquear funciones o funcionalidad dentro de tu app… tenés que usar compra dentro de la app. Las apps no pueden usar sus propios mecanismos para desbloquear contenido o funcionalidad, como claves de licencia, marcadores de realidad aumentada, códigos QR, criptomonedas y carteras de criptomonedas, etc."

App Review Guidelines · 3.1.1 · traducción del texto original consultado en sep 2026

"Las apps pueden usar compra dentro de la app para vender y vender servicios relacionados con tokens no fungibles (NFT), como acuñación, listado y transferencia. Las apps pueden permitir que los usuarios vean sus propios NFT, siempre que la titularidad del NFT no desbloquee funciones o funcionalidad dentro de la app. Las apps pueden permitir explorar colecciones de NFT de otros, siempre que, salvo en las apps de la tienda de Estados Unidos, no incluyan botones, enlaces externos u otras llamadas a la acción que dirijan a mecanismos de compra distintos de la compra dentro de la app."

App Review Guidelines · 3.1.1, apartado NFT · traducción del texto original consultado en sep 2026

Leído contra el concepto original: "compro una parcela con tokens y eso me habilita a construir ahí" es titularidad de NFT que desbloquea funcionalidad. Tal como estaba, no pasaba revisión en iOS. Las tres salidas que quedaban dentro de iOS — el NFT como certificado sin poder, todo vendido por compra dentro de la app, o juego y mercado separados — obligaban a torcer la mecánica central. La cuarta salida era no lanzar en iOS, y es la que se eligió.

11Multijugador, densidad y trampas

Modelo de red

• Servidor autoritativo, edición asíncrona. No hay física compartida en tiempo real. Colocar un bloque es una petición validada (¿es tu celda? ¿estás ahí? ¿tenés el recurso? ¿respeta la altura?) que produce un evento en el registro de la celda.
• Presencia en tiempo real ligera: posiciones aproximadas de jugadores cercanos vía WebSocket, agregadas a res 13 y con desfase deliberado, para no revelar la ubicación exacta de nadie.
• Resolución de conflictos: por celda, orden por marca de tiempo del servidor, con la última edición ganando y un historial de 30 días para revertir vandalismo.

12Arquitectura técnica

Cliente web (fases 0–3)

• TypeScript + Three.js sobre WebGL2, con ruta a WebGPU donde esté disponible. Render de voxels propio: greedy meshing por chunk, atlas de texturas único, iluminación por vértice precalculada en el servidor y enviada con el chunk.
• El mallado va en Web Workers, y la geometría vuelve al hilo principal como ArrayBuffer transferible, sin copia. Esto no es optimización prematura: es la diferencia entre 60 fps y un juego que tironea. Decodificación del formato de chunk en WebAssembly (Rust) si el perfilado lo pide.
• Presión de recolector de basura: arreglos tipados preasignados y reservas de objetos para todo lo que se crea por fotograma. Es el fallo de rendimiento clásico de un voxel en el navegador y hay que diseñarlo desde el principio, no arreglarlo después.
• PWA instalable: service worker para el casco de la app, y caché de chunks en el sistema de archivos privado del origen (OPFS) o IndexedDB, con presupuesto configurable — por defecto 300 MB — y purga por distancia al hogar. Pedir almacenamiento persistente con navigator.storage.persist(), porque si no el navegador puede vaciar la caché sin avisar.
• La interfaz va aparte del render. El HUD y los menús en el framework que quieras; el bucle de render nunca dentro del ciclo de vida de ese framework. Mezclarlos es la fuente número uno de caídas de fotogramas en juegos web.
• Sesión en primer plano. No hay GPS en segundo plano: watchPosition se suspende con la pestaña oculta o la pantalla bloqueada. Se compensa con la API de bloqueo de pantalla durante una sesión activa, la API de visibilidad de página para pausar limpio, y un diseño de juego que no dependa de que la app corra en el bolsillo.
• Modo sin conexión: mundo cacheado navegable, ediciones en cola local, reconciliación al reconectar.

Cliente nativo (fase 4, cuando se enciende el dinero real)

• Unity 6 + AR Foundation con ARCore Geospatial, Android. Recupera VPS, anclas de terreno y azotea, oclusión con fachadas, GPS en segundo plano, notificaciones y — lo decisivo — atestación de dispositivo por Play Integrity.
• Comparte el mismo backend, el mismo formato de chunk y el mismo registro de celdas que la web. El formato de chunk y la API se diseñan desde el día uno para servir a los dos clientes, para que la app sea un cliente más y no un proyecto nuevo.

Servicios

Tubería de datos geoespaciales

• DEM Copernicus a GeoTIFF en la nube, remuestreado y en mosaico por región.
• Overture / OSM en GeoParquet, consultado con DuckDB para extracción por región; teselas vectoriales propias con planetiler servidas como PMTiles.
• WorldCover a un ráster de clase de bioma de un byte por píxel, alineado con la grilla de chunks.
• Todo preprocesado por región y versionado. Ninguna llamada a API de terceros en la ruta caliente del jugador.

13Identidad visual

Lila y amarillo fosforescente. La pareja es fuerte y funciona a favor del concepto: el lila es el mundo (cielo crepuscular, sombra, atmósfera) y el amarillo fosforescente es la interfaz y la energía (lo que brilla, lo que se puede tocar, lo que es tuyo).

Reglas que hacen que la pareja funcione

• El fósforo cambia de trabajo según el fondo. Sobre claro es un resaltador: relleno amarillo con texto oscuro encima. Sobre oscuro es luz: texto y trazo amarillos que brillan. Nunca amarillo fosforescente como texto sobre blanco — no se lee.
• Un solo acento por pantalla. El lila estructura; el fósforo señala exactamente una cosa: lo que es tuyo, o lo que hay que tocar ahora.
• Sin esquinas redondeadas. Los cantos son rectos o achaflanados a 45°. Es la firma de un juego de bloques y separa el producto del aspecto de app genérica.
• El neutro tiene sesgo violeta. Los grises puros al lado del lila se ven sucios; un neutro con una gota del acento se ve elegido.
• Tipografía: una angular y chaflanada para títulos y HUD (aquí, Chakra Petch), una humanista técnica para texto (IBM Plex Sans) y su monoespaciada hermana para coordenadas, ids de celda y cifras (IBM Plex Mono). Las coordenadas y las cantidades siempre en cifras tabulares.
• El mundo se ve neutro; la interfaz es la que tiene color. Si el terreno de bloques también fuera lila y amarillo, no se distinguiría qué es jugable. La geografía usa la paleta de su bioma real; la marca vive en el HUD.

14Roadmap por fases

Cada fase tiene una puerta de decisión con un criterio medible. Si no se pasa la puerta, no se avanza: se arregla o se cierra. La fase 0 existe para descubrir en ocho semanas, y no en dos años, si el producto es posible.

15Riesgos

Sobre el proveedor de anclaje, un dato de contexto: Niantic Spatial — heredera de la plataforma que sostenía Lightship — presenta hoy sus productos como Reconstruct, Localize, Understand y Capture, orientados a máquinas y a clientes empresariales, con precios "consultar con ventas" y un programa de socios. No es una plataforma de autoservicio para estudios pequeños. Es una razón concreta para no atar el juego a un solo proveedor.

16Métricas

Estrella polar

Bloques colocados por jugador activo semanal, en celdas visitadas físicamente. Combina las tres cosas que hacen único al producto: construir, volver, y estar realmente ahí. Es difícil de inflar y baja inmediatamente cuando el juego pierde alma.

17Fuentes y estado de verificación

Honestidad sobre la investigación: en esta sesión la búsqueda web estaba bloqueada, así que se consultaron fuentes primarias directamente por URL. Lo verificado está marcado en el texto con cifras concretas. Lo no verificado está señalado explícitamente y no debería llevarse a una decisión sin comprobarlo.

Verificado en fuente primaria

• Tipos de ancla, VPS, Streetscape Geometry, plataformas y cobertura de la API geoespacial de ARCore. Sin precios publicados en la página consultada.
• Copernicus DEM: GLO-30 y GLO-90, exactitudes vertical y horizontal, cobertura, licencia libre.
• Overture Maps buildings: 2 500 M de edificios, fuentes que combina, atributo de altura, exclusión de ≥900 m, licencia ODbL.
• Tabla de resoluciones de H3 y estadísticas de celdas de S2, con áreas medias y recuentos.
• Metaplex Bubblegum: coste por NFT comprimido de 0,000027222 SOL a 10 000 piezas y 0,000005312 SOL a 1 M; dependencia del indexador DAS.
• Guidelines de revisión de Apple 3.1.1, incluido el apartado de NFT, 3.1.5(b), 3.1.3(e) y 5.1.5.
• Google Play: exigencia de divulgar probabilidades en mecanismos de objetos aleatorios de pago.
• MiCA: categorías de token y fechas de aplicación por fases (30/06/2024 y 30/12/2024).
• Minecraft Earth: fechas, 1,4 M de descargas la primera semana, uso de OpenStreetMap, cierre el 30/06/2021.
• Niantic Spatial: catálogo actual de productos y modelo de "consultar con ventas".

Pendiente de verificar antes de decidir

• Capacidades de WebXR en Chrome Android: disponibilidad de immersive-ar, módulo de profundidad, y comportamiento real del GPS con la pestaña oculta o la pantalla bloqueada. Toda la tabla de §07 sobre la web es de conocimiento previo, no verificada aquí. Es lo primero de la fase 0, y se comprueba con teléfonos, no leyendo.
• Rendimiento real de un mundo de voxels en el navegador en un teléfono de gama media de tres años: fotogramas por segundo, memoria, batería y temperatura. Determina si el modo Mapa es jugable en web.
• Política de Google Play sobre activos digitales tokenizados y NFT — no se localizó el texto vigente. Deja de ser bloqueante hasta la fase 4, pero hay que tenerlo resuelto antes de comprometer el cliente nativo.
• Pasarelas de pago que acepten venta de activos digitales con mercado secundario, en la jurisdicción de la empresa.
• Precios y cuotas de la API geoespacial de ARCore y de las teselas 3D fotorrealistas de Google, si se usaran.
• Términos actuales de Google Open Buildings y Microsoft Building Footprints, si se toma el camino B de §05.
• Situación de Lightship ARDK y 8th Wall para terceros tras la reorganización de Niantic.
• Tratamiento de los NFT bajo MiCA y exenciones aplicables a activos de juego.
• Casos concretos de Pokémon GO sobre propiedad privada y sus resultados, para calibrar §08.

URLs consultadas

• developers.google.com/ar/develop/geospatial
• nianticspatial.com
• h3geo.org · tabla de resoluciones
• s2geometry.io · estadísticas de celdas
• docs.overturemaps.org · buildings
• dataspace.copernicus.eu · COP-DEM
• metaplex.com · Bubblegum
• developer.apple.com · App Review Guidelines
• support.google.com · Play · pagos
• Markets in Crypto-Assets (MiCA)
• Minecraft Earth

18Estado del prototipo

Además de este documento existe un prototipo jugable en el navegador: un solo archivo HTML, sin dependencias ni build, con dos renderers en canvas 2D (mapa isométrico y primera persona). No es la arquitectura del producto — es la prueba de que la escala, la jugabilidad y la economía cierran. Esta sección dice qué está construido, qué se verificó y qué no.

Construido y verificado con tests automáticos

Construido pero nunca verificado: necesita dos personas

Cinco sistemas usan estado compartido en tiempo real y no se pueden probar desde una sola sesión. Están escritos, revisados y con las protecciones de carrera puestas, pero hasta que dos personas abran el mismo enlace no hay evidencia de que funcionen:

1. Registro de tierras exclusivo — cada parcela es un documento reservado con un lease, así que dos personas no pueden tomar la misma.
2. Mercado entre jugadores — publicar, comprar y que el vendedor cobre el neto. La comisión se quema.
3. Venta y alquiler de parcelas — cambio de dueño en el registro, y el inquilino puede construir mientras dure.
4. Precios de referencia — promedio móvil de las ventas reales.
5. Jugadores en vivo y calor por barrio — verse mutuamente moverse, y los contadores del mapa de calor.

El paquete de entrega trae el plan de prueba de dos personas paso por paso. Es lo primero que hay que correr.

Lo que el prototipo no es

• El mundo es un heightmap — una altura y un material por columna. Por construcción no puede tener interiores, cuevas ni voladizos. El producto necesita un motor de voxels real, y esa decisión cambia el formato de guardado, la red y el renderer.
• El terreno no usa datos reales — es ruido determinista a partir de coordenadas reales, no elevación ni edificios importados (§05).
• La capa de cámara no está anclada — no hay VPS en el navegador. Es una demo visual, no AR (§07).
• La contabilidad vive en el cliente — la circulación de CANDY es autodeclarada, no auditada. En el producto tiene que ser doble entrada del lado del servidor (§12).
• Cada barrio es su propio mundo, no una Tierra indexada por celdas (§06).
• No hay precio por zona — toda parcela libre cuesta lo mismo, esté en el centro o en la cordillera. Es la brecha económica más grande que queda abierta.

Orden de trabajo recomendado

1. Correr el plan de dos personas y cerrar lo que falle. Sin eso no se sabe si la economía compartida funciona.
2. Resolver las tres decisiones de negocio abiertas: licencia de datos (§05), motor de retención (§03) y adquisición del jugador (§04).
3. Decidir el motor de voxels y el índice geoespacial único antes de escribir una línea del cliente de producción.
4. Recién entonces, fase 0 del roadmap (§14).