Search
Welcome Developers!
We have some exciting new features coming to the Open Platform schemas. We believe this special parameter will be helpful to all game developers and Efinity developers out there utilising Efinity and the Open Platform to develop their games and projects.
We’re talking about the continueOnFailure parameter and we’ll explain why this is important and one-of-a-kind.
But first, you’re probably wondering what is the Open Platform API? Let’s get started!
The Open Platform is, at least for now, the codename for Enjin Platform 2.0.
The Open Platform will eventually be a platform and GraphQL-based API that can interact with not only Efinity but also Ethereum to create tokens and collections, manage token transfers, and a few other features like wallet management and data indexing.
Beyond support for different networks, there is one other significant feature to the Open Platform: it's completely open-sourced. A developer’s dream.
Here’s a quick refresher in diagram form
Now that you’re familiar and at ease with the Open Platform, let’s move on to the new feature: continueOnFailure, and why this is important for any game developer looking to develop on Efinity.
When we say that this feature is a game changer, we mean it, simply because it provides an economic relief when dealing with fated-to-fail transactions on the blockchain. And we all know how much we dislike failed on-chain transactions.
To provide some context, let’s walk through a story, from the perspective of a developer to better understand how this feature works.
Steve (the name of our fictional blockchain game developer) is used to minting thousands upon thousands of NFTs on the Ethereum chain and is always double-checking all transaction parameters before sending them to the blockchain.
When creating a token, setting the metadata for NFTs, and/or transferring NFTs to multiple users with in-game events, sometimes, he may make a mistake when he’s not using his magnifying glass to ensure that all parameters sent by his users are correct.
Without checking, one of the calls could fail in the blockchain, (a very common problem on legacy Ethereum platforms), resulting in a failed transaction, draining his transaction fees and slowing down the automation aspect of his game. Players are then dissatisfied because they wouldn’t have received their NFTs or in-game items if one of the parameters of the transaction did not meet all of the blockchain’s requirements.
This can be a real pain and game developers shouldn’t have to deal with it. We strive to make tools as easy to use as possible for end users and game developers.
This can only truly happen within a fun gaming environment.
To address this issue and make the lives of our game developers easier, the Open Platform team developed the continueOnFailure feature. This translates into an API argument that can be added to API calls for batch transactions, allowing the API to execute all possible calls on the blockchain while excluding any failing events.
This makes it possible for blockchain game developers to build a robust batch transactions integration that will seek all failed events from a successful transaction and allow you to repeat such failed parameters without having to send the successful ones again.
This feature is exclusive to the Open Platform and Efinity, and is not available on Ethereum. Making development integrations easier by day when using The Open Platform API.
If you’re a game developer working on an Ethereum DApp, project, or a game, and you encounter failed transactions (likely due to gas fluctuations), your entire transaction can fail and no longer send, causing the flow of transaction(s) to break, forcing you to resync nonce, and re-send your transactions. This is inefficient for game developers who want to properly develop their game mechanics.
On all batch transactions in the Open Platform, the continueOnFailure argument is set to false by default, but it can be set to true as shown below:
To demonstrate exactly what we are seeing above, the BatchTransfer request is performing a transfer of two different NFTs (tokenId: 57005 and 5050) to the same receiving address in the same transaction.
At the bottom, we can see that the parameter ContinueOnFailure is set to true, allowing the ContinueOnFailure argument to work as expected and allow the transaction to complete based on the correct blockchain parameters (even if one of the parameters such as one of the token ID of one of the NFTs is not correct).
To put things in context, we’ve also created this diagram that shows how the continueOnFailure argument works from a high-level perspective.
As previously stated, this feature is exclusive to Efinity, which means that it’s not possible to achieve the exact same results on any other existing blockchain. This parameter also shows that a failed transaction on other blockchains would still result in network fees being deducted (see Scenario “A” in the diagram).
With Efinity and the continueOnFailure feature, the transaction is still executed with the correct parameters, but the incorrect parameter is highlighted, allowing you to send another transaction without worrying about successful transactions. Saving you a lot of time, dev resources, and money on both your back-end integration and the blockchain itself in terms of the network fees (see Scenario “B” in the diagram).
Using the Open Platform, this feature can be extended to any batch event on the Efinity blockchain, such as batchTransfer, batchMint, and batchSetAttribute. The world is your oyster.
Here are a few key points to recap our post in an easy-to-understand way:
If you’re interested in learning more about everything in this post, check out the following links, (we think they will help you):
