Crucible was built on a personal thesis that this metaverse we are all starting to see take shape is far too important to get wrong.
It is something that should belong to everyone.
We existed in ideas and theory for 2 years while the world caught up and now that it has, I have gotten us extremely focused on creating some tangibility in a product that simplifies complexity and creates a familiar on-ramp to this idea of the Open Metaverse.
A few key entities we’re coordinating around:
SSI, Game Engines, Game Makers, End Users
We had undergone a 6 week strategy exercise which led into a 8-12 week development roadmap. Assumptions were made, timeline drawn up, user stories detailed, and we were eager to get our hands dirty.
“Less talk, more code!” was the cry of the team.
Crucible’s first, in a suite of products & tooling is an Unreal Engine SDK called Emergence.
Self Sovereign Identity (SSI) Standard
As with every web3 project, the starting place is authentication. With decentralized identity management being one of Crucible’s core tenets, SSI was the foundation we were going to build on. Putting power back into the hands of the user and giving them the digital sovereignty to decide what they wanted to do with their lives.
This is where we encountered our first roadblock.
We assumed we would use an SSI service such as Cheqd or Evernym, but to our surprise, none of these libraries were actually production-ready.
This was a huge blow. After some back and forth, we decided that we would do a wallet login for the time being until the SSI technology was ready for us to use. We are currently in early test groups with all of the top SSI providers, and are vetting other more open source approaches of building with the standards natively.
SSI has never had a gaming use case, so this is all new ground being broken and there are many external dependencies.
About DIDs
One of the core components of DIDs is authentication. Any person or institution can be a DID, and that will be represented as a DID URL, which should point to a DID document. This document is basically a standard that tells other DIDs how to communicate with your DID.
The authentication verification relationship is used to specify how the DID subject is expected to be authenticated, for purposes such as logging into a website or engaging in any sort of challenge-response protocol.
Our authentication method is EVM based (requesting a signature from the user’s wallet); so our best fit for a DID method is: uport-project/ethr-did-registry: Ethereum registry for ERC-1056 ethr did methods
This is how a DID URL would look like: did:ethr:0x{EVM-publicAddress}
We are still looking into SSI technology and considering what would be the best use case for us; do we want to offer game publishers the ability to become VC’s verifiers? Or should we also focus on the issuance side?
Proposed Solution
For now, this is the stack that we have in mind:
VCs schemas handling: Serto (formerly uPort)
VCs issuance and verification tools: Veramo
DID Method: ether-did-registry
VCs storage: Emergence’s vault (local encrypted storage)
Some ideas have arisen regarding this big module:
Is there going to be a list of trusted issuers of credentials? Who and how will this be handled in the future?
Can or should we mix ENS domains with ethr DID methods? For us, it would be a perfect mix for identity.
Our preferred use cases: Age verification?
Avatar
We had originally planned to have our own avatar creation module, where users could create their own custom avatars for each persona. We were in talks with our close friend Mao, the founder of Reblika, about which attributes we were going to make available to the user to customize. We envisioned something similar to the Meta Human Creator along with custom curated clothing from the likes of Marvelous Designer or The Fabricant.
Though, the more we met and discussed this, the more we felt like we should stick to the core use case of our tooling – being an agent to the Open Metaverse. There are already avatar creation software players out there and an explosion of avatar NFTs that users will likely want to import and use in Emergence. This is first and foremost about simplifying and making web3 familiar for game developers, most of which will have their own assets and avatars.
So we thought through other possible solutions:
Would we enable users to import avatars?
What would this look like in the future when these avatars would be expected to move around in the Open Metaverse?
Would we only allow image uploads?
What about entire rigs?
What would this mean for interoperability within Unreal and in our future expansion to other game engines?
What if we generated a limited number of our own avatar supply to generate demand and reward early adopters?
Would 10,000 suffice?
What if each avatar came with a backstory?
Would we allow users to pick avatars or simply claim a random one?
Would we allow them to customize the avatar they picked?
Here’s a snippet of one of our meetings where we discussed these possibilities:
https://drive.google.com/file/d/1KC2Tf7yZYb4mdts8EsWdNEzDtAE3g1JN/view?usp=sharing
Long story short, we went from Avatar Creation Module » Generating 10,000 avatars for the first Emergence users to claim » to finally settling on simply letting game developers themselves upload avatar PFPs through Postman.
We wanted to make this first version as simple as we could so as to get it published, shipped and into the hands of real game developers to get their feedback - which is most important at this stage.
So game devs, as of now, you are in full control of avatars.
EVM Integration Solutions
Another problem we had to solve was how Emergence was going to communicate with the EVM compatible blockchains - we are focused on Polygon first.
Based on our research we narrowed down our options to 3:
We found it interesting that there was no EVM integration library in C++, which is what we needed in order to build on Unreal. So our very own “@monkjuice” took this question to the community on Stack Exchange and discovered that there just was not enough interest at the moment for there to be a library. That’s how early we are.
Once again, we ran a jam session where we initially decided to build our very own C++ native solution, but after some deliberation - and by that I mean a couple of weeks of research, meetings and coding - we have decided to once again take the more simple route and utilise the Nethereum library.
The native C++ solution is on the roadmap for early next year, once we have more validation and developer traction.
Security
One of our main concerns was the lack of proper key handling with both EtherLinker and NEthereum; because we do not have an injectable wallet for desktop applications.
After some thought, we found a secure way of establishing a connection between a Desktop Game and a user’s wallet: WalletConnect
So we went ahead and mixed NEthereum and WalletConnect libraries into a singleton to give Game developers the option to handle EVM type requests in a secure manner. (Signing messages and approving transactions)
We have provided a WalletConnect authentication flow through UE4 blueprints, and we are handling the interaction between the client and the wallet through plugin files.
Off-chain services
Not everything can live on a public ledger; both for performance and usability reasons. And that’s why we are developing Emergence’s off-chain services. It allows for easy interoperability between games, giving users the possibility to use the same user profile (authenticated under an EVM wallet) across different games and giving game developers convenient tools for accessing both off-chain and on-chain data; for example through an Ethereum Indexer, which allows powerful and fast queries for on-chain information, about NFTs, ERC20 tokens, and so on.
The offchain services will include the following modules:
Persona service: Create user profiles under an EVM address (includes avatar/pfp system for game devs)
Notifications service: Handle push notifications
Connections service: Add/remove explore other personas from your connections list
Messaging service: We are still researching if XMTP or Matrix.org is the best decentralized solution for in-game messaging through wallet-based authentication.
Feeds service: User managed content through connections
Inventory service: EVM indexer of useful information for easily querying NFTs, ERC20 tokens, etc about a given address.
All these services, including the WalletConnect authentication can be easily accessed through our Emergence UI, which is included in the plugin.
Current architecture
Docker, Debugger and Dynamo Difficulties
We encountered issues with Docker on our local development environment. We created Docker containers for each of the Lambda functions we needed to run. With growing backend code comes a growing number of containers on our local machines – which started to slow our local environment down. Since this is a local problem and everything is working on staging as it should, we bit the bullet and continued our work. Now that we have our first milestone reached, we are planning a fix where we will potentially add a command to execute APIs individually, as most of the time we do not need all 11 APIs working at the same time. We are also thinking of implementing a cache config for Docker. But all this will be added to the effort for the next milestone.
We also encountered some problems with our debugger tool, which made life quite miserable when something did not work, as we would have to painstakingly read through code, line by line to find the issue. We are unsure yet what the issue is yet, but in this next phase of hardening, we want to get this fixed.
An issue arose with our DynamoDB on staging where we were not able to make complex queries to our database as we did not have our indexes configured. This cost us some time as well, but once we had all our indexes properly configured, we were able to start writing all the queries we needed.
Alpha Test
We spent three weeks doing iterations of testing and fixing anything and everything we could find or break. Everything from inserting loading buttons, inserting missing icons, making sure created avatars were automatically made the active persona, enabling alphabetical characters from other common languages and redesigning what should happen with personas that use the maximum length name of 30 characters.
We are extremely happy with the progress we made during this 3 week phase as the plugin is a lot more robust now than it was when we first started. The testing also paved the way for us to properly write up developer documentation, internal READMEs and record a feature walkthrough video.
Emergence SDK (UE4) Feature Walkthrough v1
Year’s End
We have reached our first milestone, which was to release a primitive version of Emergence and get it into the hands of our closed network of game developers. It is limited. It is a little bit clunky. But it works, and it is a tangible first step toward unfolding the grander vision.
Here’s what Emergence can do today:
WalletConnect authentication
Read wallet balance from any EVM network
Request messages to sign with WalletConnect Compatible wallets
Smart contract interaction (custom and pre-loaded smart contracts) [Alpha feature in development]
Access to Emergence’s off-chain services through wallet-based authentication (signed message token)
Manage Personas
Here is what is in the immediate pipeline:
Both server and client-side tools for smart contracts interactions
Creation and management of in-game EVM wallets (Desktop wallet)
SSI, DID, VC’s tools for game publishers and end-users
Inventory service (Ethereum Indexer public API)
Solana support (EVM for Solana is on the testnet)
Polkadot support (EVM for Polkadot via Moonbeam)
Unity support
Multi-platform support
Decentralized and encrypted messaging with EVM-wallet authentication
Next Steps
I want to say thank you to everyone for the continued trust in me and my team, this has not always been an easy journey but it’s worthwhile. I am feeling grateful.
Syntax // Error will continue next year for Season One - where we move developer traction further and create our own test world. We will use all of that to keep iterating the product tooling and features, harden the code and create compatibility on other engines, other ledgers and the web.
I hope you all have a great holiday season with your families and friends. Try to unplug from this 24/7 metaverse cycle and remember what’s most important.
Thank you for being a part of this, I can’t wait to keep building.
Ryan Gill
Founder & CEO
very promising project. I will follow the development. Good luck