Show HN: Boardzilla, un framework web para crear juegos de mesa

 (boardzilla.io)
3 puntos por GN⁺ 2024-01-30 | 1 comentarios | Compartir por WhatsApp
  • Boardzilla es un framework que busca reducir la barrera de entrada para crear juegos de mesa digitales, permitiendo jugarlos y desarrollarlos desde el navegador
  • El objetivo es que los desarrolladores puedan expresar las reglas del juego, mientras que los jugadores revisan las opciones posibles mediante una interfaz simple
  • Entre los juegos de ejemplo publicados están 7 Wonders Duel, Cursed, Dyngus Day, 27Panic, Hearts, Hex, Power Grid, Skirma y Stunt Kites
  • La cantidad de jugadores compatible varía según el juego, desde 1 hasta 4; 7 Wonders Duel, Hex y Skirma son para 2 jugadores, y Hearts es para 4
  • Quienes quieran crear su propio juego de mesa pueden comenzar el desarrollo con la documentación y la página de introducción disponibles

Lo que ofrece Boardzilla

  • Boardzilla es un entorno web para crear juegos de mesa digitales con facilidad
  • Permite jugar y desarrollar juegos de mesa dentro del navegador
  • Está diseñado para facilitar la expresión de las reglas del juego y ofrecer a los jugadores las opciones posibles mediante una interfaz simple

Ejemplos de juegos jugables

Cómo empezar a desarrollar

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-30
Comentarios de Hacker News

  • No creo que el mensaje más llamativo en la landing page deba ser un llamado a “unirse a Discord”
    Primero deberían verse los ejemplos y los enlaces al código fuente/la documentación. En proyectos así, cuando se enfatiza demasiado “únete a Discord”, en lo personal más bien me genera rechazo. Dudo ser el único

    • A mí me pasa lo mismo
      De verdad detesto Discord cuando se usa para algo más que una plataforma de comunicación casual entre amigos. Pero la gente tiende a usar Discord como plataforma principal no solo para preguntas de soporte, sino hasta para la documentación. La calidad de búsqueda es mala y los motores de búsqueda ni siquiera lo indexan, así que cuando necesitas encontrar una solución, es de lo peor

  • Se ve bien. Tiene un alcance funcional amplio y seguramente muchas partes móviles, así que debió haber sido bastante trabajo. Al menos, da gusto ver que existe un motor de juego enfocado en juegos de mesa y no solo en el renderizado en sí
    Dicho eso, como alguien que hizo juegos de cartas y de dados con juego en línea usando puro HTML/JavaScript, todavía no me queda claro cómo tendría que reproducir lo mismo con este sistema. Por la documentación, sí soporta cartas, y las abstracciones parecen lo bastante generales como para adaptarse a distintos juegos, pero un tutorial paso a paso ayudaría muchísimo. Entiendo por qué eligieron abstracciones como Actions, Flows, selections, conditions y prompts, pero si no veo cómo se ensamblan en la práctica, me cuesta imaginar en qué punto tendría que cambiar lo que quiero modificar. Personalmente, sin un tutorial me sería difícil avanzar mucho

    • En el contexto de juegos de mesa físicos, la clave parece basarse en dos clases principales. La estructura maneja Piece, es decir, cosas que están en la mano o se mueven entre Player y se colocan sobre espacios (Space) de la mesa
      Las cartas y los dados se definen heredando de Piece, los jugadores heredan de Player, y también se puede tener algo como un repartidor que administre el mazo como otro Player. Luego solo hay que pensar cómo colocar en el tablero las instancias de Space que exigen las reglas. Las reglas van dentro de una instancia de la clase Game, y ahí existe el concepto de acciones, que son instancias de la clase Action. Estas acciones reciben argumentos que definen prompts para el usuario, condiciones de ejecución válidas y efectos de ejecución. Fuera de eso, hay bastantes funciones de conveniencia esperables para buscar piezas, compararlas y demás, y el resto depende de la lógica del juego. Por los ejemplos, también parece haber funciones para filtrar Space y Piece, así que da la impresión de que se puede construir la lógica de UI con rapidez
    • Quiero ampliar más la documentación, pero toma bastante tiempo. Entiendo que incluso un juego que parece simple puede sentirse abrumador al traducirlo a una API formalizada. No sé si sirva de referencia, pero tengo grabado un video creando parte de un juego
      https://docs.boardzilla.io/game/creating-a-game

  • Sería mejor no ponerle *Zilla al nombre del proyecto. Se sabe que los dueños de los derechos de Godzilla rastrean activamente a quienes intentan usar el sufijo “Zilla”. Mozilla también aprendió la lección hace mucho y tuvo que llegar a un acuerdo por separado

    • No tenía ni idea. También tengo preparados algunos otros nombres de dominio bastante buenos, así que quizá ya sea momento de tomar una decisión
    • No veo cómo esto se relaciona aunque sea un poco con Godzilla o sus derechos. No tiene nada que ver con un monstruo nuclear gigante
      El único caso de marca en el que Toho perdió fue contra una empresa de bolsas de basura llamada ‘trashzilla’, y una de las razones fue que no representaba un riesgo para los intereses comerciales de Toho. Edit: no había visto el logo. Eso sí que definitivamente podría ser un problema
    • Esto sí me sorprende bastante. No sabía que el copyright de *Zilla fuera tan agresivo
    • Meta también hace valer agresivamente sus marcas contra quienes intentan registrar marcas que terminan en ‘book’
    • Revzilla y Partzilla también pasaron por una larga disputa legal por el uso de nombres *zilla

  • Así que usan TypeScript + CSS. Esperaba que el servidor para la lógica del juego soportara Python. El momento es bueno, pero los desarrolladores y publishers que usaban BGA están inquietos por el modelo de negocio de Asmodee
    El stack de BGA Studio es JS/CSS + PHP (cliente y servidor) + MySQL [0]
    Yucata.de usa JS + HTML + .NET 4.5 en el servidor [1]
    TTS usaba Lua, pero al revisarlo me pareció peculiar y limitado. No es orientado a objetos, y no entiendo por qué elegir un lenguaje no orientado a objetos para juegos de mesa. También es útil la reseña de sitios/frameworks de 2021, “VassalEngine: Survey of other boardgame software” [2]
    Sería realmente genial si pudieran integrarse con Python en el servidor
    [0]: https://boardgamearena.com/doc/Studio
    [1]: https://www.yucata.de/en/FAQ#t17
    [2]: https://forum.vassalengine.org/t/survey-of-other-boardgame-s...

    • Sobre eso de “por qué elegir un lenguaje no orientado a objetos para juegos de mesa”, Lua históricamente ha sido una opción bastante popular entre desarrolladores de juegos. Una de las razones es que es fácil embeberlo como lenguaje de scripting dentro de un juego
      También es posible hacer programación orientada a objetos sin clases [0]. Y esperar que un desarrollador porte y mantenga todo el proyecto en Python solo porque no quiere aprender un lenguaje nuevo es demasiado pedir
      [0]: https://en.wikipedia.org/wiki/Lua_(programming_language)#Obj...
    • La razón por la que el servidor no es Python es que en boardzilla no representan el juego dos veces, una para cliente y otra para servidor. En cambio, se escribe una sola vez en TypeScript, y ese código se usa realmente tanto en el servidor como en el cliente. El cliente funciona como el servidor, solo que sin información oculta
    • Me da curiosidad por qué quieres tanto Python en el backend. TypeScript es una elección bastante lógica porque corre en el backend y en varios frontends. Puede usarse no solo en la web, sino también en motores de juego como Unity. Y el sistema de tipos también es mejor que el de Python
    • Me da curiosidad cuál es el modelo de negocio de Asmodee y qué tiene que ver eso con BGA
    • TypeScript en sí no tiene problema, pero me preocupa la parte de React. ¿No querrías algo más ligero como Svelte, Marko o Solid para un frontend de juegos?

  • Bien. Tengo muchísimos prototipos de juegos de mesa que algún día me gustaría convertir en juegos web, así que alguna vez escribí un poco de funciones de librería genéricas para crear juegos de mesa: generación de cuadrículas, tiradas de dados personalizadas, robar cartas, funciones de torneo, pruebas que muestran varios escenarios, y unas cuantas cosas más. Pero me quedé ahí, y como lo compagino con otros proyectos, parece poco probable que tenga tiempo de hacerlo bien. Tendré que ver qué tan fácil es usar esta librería
    Coincido en que aprender la plataforma BGA es bastante doloroso. 1) quedas atado a la plataforma y no puedes publicar el juego en otro lado, 2) todo es PHP y ya no me entusiasma mucho usarlo, y 3) la documentación está dispersa en varios lugares e incluso incluye presentaciones de PowerPoint

  • Si buscas algo de más bajo nivel, puedo recomendar boardgame.io
    [1] https://boardgame.io/

    • boardgame.io también es muy recomendable. Nicolo es realmente amable y muy servicial. También vale la pena revisar su otro proyecto, https://boardgamelab.app/

  • Este campo es realmente difícil. Creo que para tener éxito necesitas un juego que pegue de inmediato, o hacer un enorme esfuerzo de comunidad para reunir jugadores todos los días durante todo un año
    Probé suerte con https://acos.games al principio, cuando casi no había alternativas a BGA. Todavía sigo desarrollándolo por detrás cuando me aburro. El mayor fracaso fue la UI/UX. A la gente no le interesa tanto la tecnología genial escondida detrás

    • Se ve muy bien hecho. La documentación también está muy bien escrita. No tengo una necesidad inmediata de usarlo, pero incluso solo leer la documentación para ver qué es posible me resultó interesante. La funcionalidad de manejo de estado y reproducción de partidas se ve genial. Yo también estoy armando mi propio paquete de juegos, y solo pensar en hacer el sistema lo bastante flexible para que otros puedan integrarlo ya se siente como una tarea enorme. Es impresionante el trabajo invertido

  • Se ve muy bien, y felicidades por el lanzamiento
    Puede ser excelente para desarrollar prototipos, pero para crear una alternativa a BGA probablemente necesitarías obtener permiso de los publishers para implementar y distribuir sus juegos. BGA es tan grande y además pertenece a Asmodee que no parece fácil. Ojalá me equivoque

    • No soy experto legal, pero parece que las mecánicas de juego no están protegidas por derechos de autor, siempre y cuando no uses las mismas imágenes de cartas/tablero ni copies el reglamento textualmente
      “En resumen, los nombres y logos pueden protegerse como marcas, y el arte tiene copyright (incluido potencialmente el tablero como obra artística). Las mecánicas, procedimientos y reglas no pueden protegerse con copyright. Por eso existen clones de Monopoly/Scrabble.”
      https://www.reddit.com/r/gamedev/comments/10f2nov/comment/j4...
      Aquí hacen referencia a este video de YouTube
      https://www.youtube.com/watch?v=iZQJQYqhAgY
    • Coincido por completo en que Asmodee, en la práctica, ha impedido que entre al mercado competencia real. En vez de competir de frente con BGA, tengo la idea de mirar juegos más pequeños de publishers indie. No sé qué tan viable sea, pero tampoco tengo muy claro qué otra cosa hacer

  • Se ve realmente genial. Tengo ganas de probarlo personalmente
    Me alegra ver que tiene el comando de flujo everyPlayer, que permite acciones simultáneas. Es una función que faltaba en otros frameworks de juegos de mesa que he usado
    [1]: https://docs.boardzilla.io/game/flow#everyplayer

  • Todos los juegos de ejemplo están dando error
    Object.hasOwn is not a function. (In 'Object.hasOwn(e,A.from)', 'Object.hasOwn' is undefined)
    El rastreo de pila es el siguiente
    su@https://www.boardzilla.io/build/_shared/chunk-ZEYFFM3P.js:16:114536
    Fs@https://www.boardzilla.io/build/_shared/chunk-QNN53S6I.js:9:128279
    Ch@https://www.boardzilla.io/build/_shared/chunk-QNN53S6I.js:11:180657
    Parece que hace falta un polyfill

    • Ya agregué el polyfill. Avísame si se corrigió
    • Voy a agregar el polyfill pronto