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.
Vote for it Here
Ha! Well that's what I get for using the scheduled post feature. For those who read it all, this is the post we're going to use for our proposal. I'm powering down some of my HP to have the HBD to run this proposal the full year. Feel free to follow this account for updates!
Congratulations @rhemagames! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)
Your next target is to reach 50 replies.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out our last posts:
The Hive.Pizza team manually curated this post.
You can now send $PIZZA tips in Discord via tip.cc!
I support this proposal, I agree that it's important to support games beyond the web. And the assessment of what NFTs and IPFS can do is realistic. But are you sure the scope is feasible? Feature parity with Steam is a lot to achieve for a one-family team.
Thanks, for your support!
I don't deny that the work will be difficult to complete, and as the clock ticks down with our proposal under the funding threshold it will become harder. We had planned to hire more people after the funding was secured, especially in regards to the game and app. That may have to wait a little longer now, but it's still being considered.
About the SDK and Services: I plan on taking a 80/20 approach when prioritizing features so if a few things are left after the funding round is over the project should be far enough along to support most developers. I've also worked on several projects with similar goals (just using different methodology) in the past so we're not starting from scratch intellectually which should lesson the time required for each feature.
Unfortunately we may have to revisit the proposal as time goes on and remove some of the stretch goals or at least extend the timeline of release if funding doesn't materialize, but hopefully it wont come to that.
I understand paying the team a daily amount for the dev work. I don't see the justification for additional funds for savings and for staking. The team members can take their cut of their wages and save or stake it on their individual accounts as they wish or they can cash them out. Pretty sure any of the major curators would be glad to help with curation if that's the concern.
That's a fair point and we could reconsider the other amounts, and redistribute that as compensation.
Our primary concern when setting the savings amount was to give the company a buffer on both ends of the campaign, and if possible, give a true 12 months of development regardless to when we get past the return threshold.
As far as Staking we're using this account as the primary for the company at large, and having more stake means we have more options down the road. We do hope that several curators join us in helping game developers get better traction, but we can't be certain of that.
To put things another way, this account is our primary "business" account and we are setting it up like you would any business with a plan to continue it's growth outside of those that work for it. It may not be the most logical way to do things, but we felt that it made the most sense for what we are planning to accomplish, both now and in the future.
What you're really talking about is having an operations/emergency fund of 3 months, which is the right move for business continuity. I think you should just restructure the funds, calculate the 3 months straight, add it, add realistic infrastructure costs, and remove the 100 HBD a day to savings and the 116 HBD to HP.
You're right that would read better, Will get to it this evening. Thanks!