TL:DR

Hive Gaming Services would benefit the Hive community by streamlining the game and app development process for non-web-based projects while also making Hive a compelling third-party tool for developers' next projects. We want to make it so that Hive offers developers all the benefits Valve's Steam offers without network lock-in or high-percentage losses.

What we're building:

A Native Hive SDK for modern game engines
Demos and tutorials for these SDKs
Two showcase products: Angular Velocity (think Frisbee in space esports game), and Thicket (think Valve's Steam, but for Hive, using the SDK we are creating)

What we're giving back:

Rewards for gamedevs on Hive regardless to what they use (manually curated)
Contests that encourage and reward creative contributions on Hive

What we hope to achieve:

We plan to establish a standard for games on Hive that exceeds the expectations of what it is to be a "Block Chain Game" and what this blockchain can do for the developers of games in any genre with any monetization model.

Vote for it Here

Justification

Hive has great potential, but very few full stack approaches to app development exist outside of the web. Millions of dollars are spent on the gaming and associated industries regularly, and with the right tools Hive could be the backbone for many indie developers. NFTs and Tokenization are just two pieces of the puzzle. We aim to be the rest.

Furthermore, game engines like Godot and Unity can be used to create compelling applications and could lead to a new class of mobile and desktop applications that can give users a more engaging experience with the same level of security that we expect.

Problems

This proposal aims to solve several bottle necks that developers may face when creating games or applications that exist outside of the browser, but are still connected to or adhere to web3 concepts. The list below shouldn't be considered an exhaustive list, but may be exhausting to read through, so skip to the solution if even one of the highlighted sections appeals to you.

Games

Most if not all gaming initiatives revolve around two aspects of game development:

Tokenization of the internal economy
User ownership of in-game purchases (NFTs)

Though important, the truth is that both of these concepts are late stage development tasks that require a large amount of overhead and infrastructure. This discourages many developers from using blockchain technologies, especially when established gaming services offer much more and a more traditional solution to the above.

NFT Interoperability

One of the promises of NFTs when they were first introduced was that, once you purchased said NFT, it was yours, and you could use it in any application/game that supported NFTs. However, this is not how it plays out in the real world. The NFTs we create for one service or app are NOT compatible with another because, in the end, the blockchain only stores the record that shows that the user HAS the right to use it wherever and however, but it does not in anyway give developers a bridge to use the data referred to in the NFT anywhere else but in the app that it was designed for. (This is one reason the low hanging fruit of the NFT world are pictures because at least those have built in inter-op.)

Non-Public Off Chain Data

All non-text data is stored off chain. Even though this is known and expected, a problem arises because the location of this media is often shared in a completely public manner. This is fine for most content, but if you are a game developer or a content creator who wants to have exclusive rights to the distribution of content, you are faced with a web3 dilemma. There are ways to lock down the ability to play content that someone downloads off the internet (more of that infrastructure that needs to be built into the game), but music, videos, images, etc. can all be scraped and collected, making a barrier for some content. Though only tangentially connected to the gaming services, the issue still presents itself and has been a pain point in our experience.

Personal Ownership

One of the most exciting ideas in the web3 sphere is the idea that the creator of the content owns the content and have rights to it, and through NFTs they share certain rights to those who purchase the NFT. This creates a two-edged sword for the owner as they now have to ensure the availability of the content, which leads many to give away even more rights to their content to the sites that host it for them. This basically means that beyond the NFT (just the receipt of ownership) there is little to no change from existing solutions. Wherever you upload your content, it's stored by the content provider as long as they see fit, and can delete it based on any criteria they deem worthy. Of course, IPFS is used to combat this in some regards, but creates the need for the end user to host an IPFS node on their hardware or buy services that do that for them, thus circling back to the original issue.

NOTE: We are hopeful that the SPK network will streamline the IPFS node issue, and we look forward to working with them on this issue

Closed Development and Centralized

Back to game development (we are a game studio, after all). Most gaming services on the market today are closed source and centralized, in that you cannot run a steam node on your personal server to handle traffic, you can't tailor it to your needs, and, most importantly, you can't ask for a new service or feature to be added. Likewise, if you sign up for one of these services (no matter the company) there is a wall that surrounds you and locks you into that environment. This is the same bargain that content creators make when they post to YouTube or other sites. Yes, the data is being hosted, the servers are being allocated, and all you have to do is pay the price, but the cost is not merely monetary.

Solutions

These serve as a brief overview of what we intend to create in answer to the above issues:

NOTE: For all solutions, the goal is to be as close to the chain as possible (no secondary stores of information). This won't be possible for all features, so where secondary services are required we will first evaluate what has been created for Hive first before creating our own solutions.

Security: There will also be a strict adherence to the documented "best practices" when it comes to transactions that will be handled locally within the engine. Any stored information (wallets) will be encrypted and optional. The use of HiveAuth will be implemented for untrusted devices and those that trust no one.

Video Games
We plan to create a full SDK for the big three engines used by most indie developers. This plugin will allow local RX and TX services in line with hive-js, beem, and others, and written in that engine's native plugin architecture (basically, a hive library written in C++). This would be fabulous for non-game applications but will also include:

1: One-to-one parity with services offered by Valve's Steam, such as--

Chat

Achievements

App Registration

Sales

Analytics

Cloud Saves

2: General game server and server network functions (tools to help users and servers find servers and users)

NFT Interoperability

All NFTs or media used within the toolkit will have a definition for each type of media they are offering as sharable. The format of this definition will include all relevant functions or features of the NFT type. In practice, each NFT created using the toolkit will have the origin and a predefined (by developer) set of functions and abilities for that NFT. This way, any third party application that wants to use the NFT in their game will have what they need to use it in their software. This will be discussed in depth as things progress.

Non-Public Off Chain Data and Personal Ownership

IPFS can't solve everything. For those things it cannot solve, our toolkit will allow P2P file sharing with ownership and privacy in mind. We will work with other projects that have similar goals and, where the ideas align, we will be happy to collaborate.

Closed Development and Centralized

All features above, including those not clearly defined, will be discussed and debated in the open as much as possible. Our lead developer, @bflanagin, has a good track record of publishing development logs for the projects he is working on. We also plan to have this project in github and released with a permissive license.

Who is Rhema Games?

Our current team consists of--

Benjamin Flanagin: @bflanagin (Project Lead)
Ben is a long time app and game developer, as well as an opensource advocate. He has been active on the Hive blockchain since the fork from STEEM and was active on STEEM for some time, as well. He has a proven track record of creating innovative approaches to issues and has created a number of applications and games that utilized the blockchain. This proposal is a revitalization project for OpenSeed and HoneyComb. You can find out more about his projects by checking out his blog, as well as @openseed and @v-entertainment.

Kalyn Flanagin: @kalynflanagin (Creative Lead)
Kalyn is an accomplished writer and teacher, and good at practically anything she puts her mind to. She is primarily in charge of the look of things and story, but will guide UX decisions as well.

Liam Flanagin: @liamflanagin (Junior Game Developer)
Liam is our in-house QA team member who is working on his own game. He will help guide the plugin designs to make sure we're not too technical or confusing for the target audience.

What We're Asking For

We're asking for a year's worth of runway to create professional-grade tools and examples for others to follow, totaling 95,000 HBD (261HBD daily) which will break down into the following budget lines:

$70,000 HBD in compensation for the team
$25,000 for servers and other hardware requirements. (This is a very liberal estimate, savings will go toward continued development.)

All lines are to be consider "best of our knowledge" estimates. Our plan is to be well on our way to profitability by the end of the funding period with the buffer to help us afford unforeseen set backs.

Road Map

Dec 1, 2023 to Nov 30, 2024 (Covered by your support)

Native SDK
First 3 months)

"Raw" connection to Hive using C++ (should be enough for most apps and interfaces)
Finalizing services and how they will interact with the chain
Local game services added to the plugin
Demos showing off the new interface
Tutorials explaining how to use the SDK in various projects
Integration with HiveAuth

Server Side (Layer 1.5)
First 6 months

HGS server node for non-chain actions

Game
Last 3 months

Playable early demo released as a Hive exclusive
Full integration with the SDK (of course)

App
Last 3 months

Full Hive fronted capabilities with game engine flair (No, we don't know what that means either, at least not yet.)

FAQ

What game engines will you support?

We plan to support Godot, Unreal, and Unity, though any game engine with plugin support will be considered after the project's targets have been reached.
What game engine will you support first?

We plan to support Godot first as it is the preferred engine of Rhema Games (and there aren't any blockchain integrations for it yet, to the best of our knowledge).
Why did you add non-game stuff to your proposal?

As mentioned before (briefly), we plan on creating a complete solution for game developers to use Hive and, more than that, a complete interface for gamers to find, download, and post about these games--assuming the developers decided to distributed on the platform, that is.
What Happens if you don't get funding?

We love Hive and plan to continue using it as our social media platform for all public relations and want to use it for more, but without funding everything becomes "as time and resources allow," which prolongs the creation of the tools.
Can I Help?

We're only asking for enough runway for one full-time employee, but we would love your input! As for other game developers, we would love to get your insight into what you need so we know the tools we are creating match the expectations of the community.