^{Esta es una traduccion de la propuesta que puedes ver en este enlace}

RESUMEN

Hive Gaming Services beneficiaría a la comunidad Hive agilizando el proceso de desarrollo de juegos y aplicaciones para proyectos no basados en la web, al tiempo que convertiría a Hive en una atractiva herramienta de terceros para los próximos proyectos de los desarrolladores. Queremos que Hive ofrezca a los desarrolladores todas las ventajas que ofrece Steam, de Valve, sin bloqueo de red ni pérdidas de alto porcentaje.

Lo que estamos construyendo:

1. Un SDK nativo de Hive para motores de juego modernos
2. Demostraciones y tutoriales para estos SDK
3. Dos productos de muestra: Angular Velocity (piensa en un juego de esports de Frisbee en el espacio), y Thicket (piensa en Steam de Valve, pero para Hive, usando el SDK que estamos creando)

Lo que estamos devolviendo:

1. Recompensas para los desarrolladores de juegos en Hive, independientemente de lo que utilicen (seleccionadas manualmente).
2. Concursos que fomenten y recompensen las contribuciones creativas en Hive.

Lo que esperamos conseguir:

Planeamos establecer un estándar para los juegos en Hive que supere las expectativas de lo que es ser un "Block Chain Game" y lo que este blockchain puede hacer por los desarrolladores de juegos de cualquier género con cualquier modelo de monetización.

Vota aquí

---

Justificación

Hive tiene un gran potencial, pero existen muy pocos enfoques de pila completa para el desarrollo de aplicaciones fuera de la web. Se gastan millones de dólares en la industria del videojuego y las industrias asociadas con regularidad, y con las herramientas adecuadas Hive podría ser la columna vertebral para muchos desarrolladores indie. Las NFT y la tokenización son sólo dos piezas del rompecabezas. Nuestro objetivo es ser el resto.

Además, motores de juego como Godot y Unity pueden utilizarse para crear aplicaciones atractivas y podrían dar lugar a una nueva clase de aplicaciones móviles y de escritorio que pueden ofrecer a los usuarios una experiencia más atractiva con el mismo nivel de seguridad que esperamos.

Problemas

Esta propuesta pretende resolver varios cuellos de botella a los que pueden enfrentarse los desarrolladores a la hora de crear juegos o aplicaciones que existan fuera del navegador, pero que sigan conectados o se adhieran a los conceptos de web3. La siguiente lista no debe considerarse exhaustiva, pero puede resultar agotadora de leer, así que pasa a la solución si alguna de las secciones resaltadas te resulta atractiva.

---

• Juegos

La mayoría de las iniciativas de juegos, si no todas, giran en torno a dos aspectos del desarrollo de juegos:

1. Tokenización de la economía interna
2. Propiedad del usuario de las compras dentro del juego (NFT)

Aunque importantes, lo cierto es que ambos conceptos son tareas de desarrollo de última fase que requieren una gran cantidad de gastos generales e infraestructura. Esto disuade a muchos desarrolladores de utilizar tecnologías blockchain, especialmente cuando los servicios de juego establecidos ofrecen mucho más y una solución más tradicional a lo anterior.

---

• Interoperabilidad de las NFT

Una de las promesas de las NFT cuando se introdujeron por primera vez era que, una vez que comprabas dicha NFT, era tuya y podías utilizarla en cualquier aplicación/juego que admitiera NFT. Sin embargo, en el mundo real no es así. Los NFTs que creamos para un servicio o app NO son compatibles con otro porque, al final, el blockchain sólo almacena el registro que muestra que el usuario TIENE derecho a usarlo donde sea y como sea, pero de ninguna manera da a los desarrolladores un puente para usar los datos referidos en el NFT en cualquier otro lugar que no sea la app para la que fue diseñado. (Este es uno de los motivos por los que las fotos son la fruta más asequible del mundo de los NFT, ya que, al menos, tienen una interoperabilidad incorporada).

---

• Datos no públicos fuera de la cadena

Todos los datos no textuales se almacenan fuera de la cadena. Aunque esto es conocido y esperado, surge un problema porque la ubicación de estos medios a menudo se comparte de forma totalmente pública. Esto está bien para la mayoría de los contenidos, pero si eres un desarrollador de juegos o un creador de contenidos que quiere tener derechos exclusivos sobre la distribución de contenidos, te enfrentas a un dilema web3. Hay formas de bloquear la capacidad de reproducir contenidos que alguien se descarga de Internet (más infraestructura que debe incorporarse al juego), pero la música, los vídeos, las imágenes, etc., se pueden extraer y recopilar, lo que supone una barrera para algunos contenidos. Aunque sólo está relacionado tangencialmente con los servicios de juego, el problema sigue presente y ha sido un punto de dolor en nuestra experiencia.

---

• Propiedad personal

Una de las ideas más apasionantes en el ámbito de web3 es la de que el creador del contenido es el propietario del mismo y tiene derechos sobre él, y a través de las NFT comparte ciertos derechos con quienes compran la NFT. Esto crea un arma de doble filo para el propietario, ya que ahora tiene que garantizar la disponibilidad del contenido, lo que lleva a muchos a ceder aún más derechos sobre su contenido a los sitios que lo alojan para ellos. Esto significa básicamente que más allá de la NFT (sólo la recepción de la propiedad) hay poco o ningún cambio con respecto a las soluciones existentes. Dondequiera que subas tus contenidos, éstos son almacenados por el proveedor de contenidos durante el tiempo que estime oportuno, y puede eliminarlos en función de los criterios que considere oportunos. Por supuesto, IPFS se utiliza para combatir esto en algunos aspectos, pero crea la necesidad de que el usuario final aloje un nodo IPFS en su hardware o compre servicios que lo hagan por ellos, volviendo así al problema original.

NOTA: Esperamos que la red SPK agilice el tema de los nodos IPFS, y estamos deseando trabajar con ellos en este asunto.

---

• Desarrollo cerrado y centralizado

Volviendo al desarrollo de juegos (al fin y al cabo, somos un estudio de juegos). La mayoría de los servicios de juegos del mercado actual son de código cerrado y centralizados, en el sentido de que no puedes ejecutar un nodo steam en tu servidor personal para gestionar el tráfico, no puedes adaptarlo a tus necesidades y, lo que es más importante, no puedes pedir que se añada un nuevo servicio o característica. Asimismo, si te das de alta en uno de estos servicios (no importa la empresa) hay un muro que te rodea y te encierra en ese entorno. Es el mismo trato que hacen los creadores de contenidos cuando publican en YouTube u otros sitios. Sí, se alojan los datos, se asignan los servidores y lo único que hay que hacer es pagar el precio, pero el coste no es meramente monetario.

---

Soluciones

Éstas sirven como breve resumen de lo que pretendemos crear en respuesta a los problemas anteriores:

NOTA: Para todas las soluciones, el objetivo es estar lo más cerca posible de la cadena (sin almacenes secundarios de información). Esto no será posible para todas las funciones, por lo que cuando se requieran servicios secundarios evaluaremos primero lo que se ha creado para Hive antes de crear nuestras propias soluciones.

Seguridad: También habrá una estricta adhesión a las "mejores prácticas" documentadas cuando se trate de transacciones que se gestionarán localmente dentro del motor. Cualquier información almacenada (monederos) será encriptada y opcional. Se implementará el uso de HiveAuth para los dispositivos en los que no se confía y aquellos en los que no se confía en nadie.

• Videojuegos

Planeamos crear un SDK completo para los tres grandes motores utilizados por la mayoría de los desarrolladores independientes. Este plugin permitirá servicios locales RX y TX en línea con hive-js, beem, y otros, y escrito en la arquitectura nativa de plugin de ese motor (básicamente, una librería hive escrita en C++). Esto sería fabuloso para aplicaciones no relacionadas con juegos, pero también incluirá:

1: Paridad uno a uno con los servicios ofrecidos por Steam de Valve, tales como...

• Chat
• Logros
• Registro de aplicaciones
• Ventas
• Analítica
• Guardar en la nube

2: Funciones generales del servidor de juegos y de la red de servidores (herramientas para ayudar a usuarios y servidores a encontrar servidores y usuarios)

---

• Interoperabilidad de NFT

Todas las NFT o soportes utilizados dentro del conjunto de herramientas tendrán una definición para cada tipo de soporte que ofrezcan como compartible. El formato de esta definición incluirá todas las funciones o características relevantes del tipo de NFT. En la práctica, cada NFT creado utilizando el toolkit tendrá el origen y un conjunto predefinido (por el desarrollador) de funciones y habilidades para ese NFT. De esta forma, cualquier aplicación de terceros que quiera utilizar la NFT en su juego tendrá lo que necesita para utilizarla en su software. Esta cuestión se tratará en profundidad a medida que avancen las cosas.

• Datos no públicos fuera de la cadena y propiedad personal

El IPFS no puede resolverlo todo. Para aquellas cosas que no puede resolver, nuestro conjunto de herramientas permitirá compartir archivos P2P teniendo en cuenta la propiedad y la privacidad. Trabajaremos con otros proyectos que tengan objetivos similares y, cuando las ideas coincidan, estaremos encantados de colaborar.

• Desarrollo cerrado y centralizado

Todas las características anteriores, incluidas las que no están claramente definidas, se discutirán y debatirán en abierto en la medida de lo posible. Nuestro desarrollador principal, @bflanagin, tiene un buen historial de publicación de registros de desarrollo de los proyectos en los que está trabajando. También planeamos tener este proyecto en github y liberarlo con una licencia permisiva.

---

¿Quién es Rhema Games?

Nuestro equipo actual está formado por

• Benjamin Flanagin: @bflanagin (Jefe de proyecto)
  Ben es un desarrollador de aplicaciones y juegos desde hace mucho tiempo, así como un defensor del código abierto. Ha estado activo en la cadena de bloques Hive desde la bifurcación de STEEM y también estuvo activo en STEEM durante algún tiempo. Tiene un historial probado en la creación de enfoques innovadores a los problemas y ha creado una serie de aplicaciones y juegos que utilizan la blockchain. Esta propuesta es un proyecto de revitalización de OpenSeed y HoneyComb. Puedes saber más sobre sus proyectos consultando su blog, así como @openseed y @v-entertainment.

• Kalyn Flanagin: @kalynflanagin (Responsable creativa)
  Kalyn es una escritora y profesora consumada, y es buena en prácticamente cualquier cosa que se proponga. Se encarga principalmente del aspecto y la historia, pero también orienta las decisiones de UX.

• Liam Flanagin: @liamflanagin (Desarrollador de juegos junior)
  Liam es un miembro de nuestro equipo interno de control de calidad que está trabajando en su propio juego. Ayudará a guiar los diseños de los plugins para asegurarse de que no son demasiado técnicos o confusos para el público objetivo.

Lo que pedimos

Estamos pidiendo un año de pasarela para crear herramientas y ejemplos de calidad profesional para que otros los sigan, por un total de 95,000 HBD (261HBD diarios) que se desglosarán en las siguientes líneas presupuestarias:

70,000 $ HBD en compensación para el equipo
25,000 dólares para servidores y otros requisitos de hardware. (Esta es una estimación muy liberal, los ahorros se destinarán al desarrollo continuado).

Todas las líneas deben considerarse estimaciones "según nuestro leal saber y entender". Nuestro plan es alcanzar la rentabilidad al final del periodo de financiación, con un margen que nos ayude a hacer frente a contratiempos imprevistos.

Hoja de ruta

Del 1 de diciembre de 2023 al 30 de noviembre de 2024 (cubierto por su apoyo)

SDK nativo
Primeros 3 meses)

• Conexión "en bruto" a Hive usando C++ (debería ser suficiente para la mayoría de las aplicaciones e interfaces)
• Finalización de los servicios y cómo interactuarán con la cadena
• Servicios de juego locales añadidos al plugin
• Demostraciones de la nueva interfaz
• Tutoriales explicando cómo utilizar el SDK en varios proyectos
• Integración con HiveAuth

Lado del servidor (Capa 1.5)
Primeros 6 meses

• Nodo servidor HGS para acciones no relacionadas con la cadena

Juego
Últimos 3 meses

• Lanzamiento de la primera demo jugable como exclusiva de Hive
• Integración completa con el SDK (por supuesto)

Aplicación
Últimos 3 meses

• Capacidades completas de Hive con estilo de motor de juegos (No, tampoco sabemos lo que eso significa, al menos no todavía).

---

PREGUNTAS FRECUENTES

• ¿Qué motores de juego son compatibles?

Planeamos soportar Godot, Unreal, y Unity, aunque cualquier motor de juego con soporte de plugin será considerado después de que los objetivos del proyecto hayan sido alcanzados.

• ¿Qué motor de juego será compatible en primer lugar?

En primer lugar, Godot, ya que es el motor preferido de Rhema Games (y, por lo que sabemos, aún no hay ninguna integración de blockchain para él).

• ¿Por qué habéis añadido cosas no relacionadas con el juego a vuestra propuesta?

Como hemos mencionado antes (brevemente), planeamos crear una solución completa para que los desarrolladores de juegos utilicen Hive y, más que eso, una interfaz completa para que los jugadores encuentren, descarguen y publiquen sobre estos juegos, suponiendo que los desarrolladores decidan distribuir en la plataforma, claro.

• ¿Qué pasa si no consigues financiación?

Nos encanta Hive y pensamos seguir utilizándola como nuestra plataforma de medios sociales para todas las relaciones públicas, y queremos usarla para más cosas, pero sin financiación todo se convierte en "según lo permitan el tiempo y los recursos", lo que prolonga la creación de las herramientas.

• ¿Puedo ayudar?

Sólo pedimos pista suficiente para un empleado a tiempo completo, ¡pero nos encantaría contar con tu aportación! En cuanto a otros desarrolladores de juegos, nos encantaría que nos dierais vuestra opinión sobre lo que necesitáis para saber que las herramientas que estamos creando se ajustan a las expectativas de la comunidad.

Votalo Aqui

Translation provided by @cocacolaron