The game is a simple turn based economic business simulation game, like "Lemonade Stand" or "Dope Wars" or "Pizza Tycoon" or others from that era of games. It is currently in development, written as a light client targeting a komodo smart chain. The light client uses electrum client to sign the transaction and an explorer to fetch utxos & broadcast the signed transaction.
I asked Verus lead dev Mike T about the future of PBaaS light mode support in discord, to which he gave helpful responses that were encouraging to consider the future for supporting my game effort on a Verus chain as well.
Electrum will work for a PBaaS chain, but is insufficient to make decent apps that use even a medium amount of Verus features. We are moving to a Verus extended BitCore server for lite mode functions and deprecating ElectrumX for foundation or recommended use. The next update of Verus Mobile will be the first on the new interface, which enables it to access all of the new APIs, smart transaction capabilities, DeFi, etc., as well as information needed for z-transaction support in light mode, though to move z-transactions away from lightwalletd requires additional work. A new version of Verus Mobile with this interface is near ready, and has only been waiting for some authentication and ID provisioning protocol improvements that are coming along nicely.https://discord.com/channels/444621794964537354/449638035999686677/1026638568065609778
So, whatever I created on a Komodo Smart Chain will likely work without any changes on a Verus PBaaS chain. Further, I asked about the bitcore wallet server that Verus is moving towards to support more of the Verus enhanced functions relating to the bitcore-server.
We have Verus enhanced servers in the VerusCoin repos. They have Verus capabilities exposed, and there are much more advanced enhancements in progress that will be pushed to the VerusCoin repos before PBaaS. As a dev, it should be obvious from the changes we already made, how it will work. Non-Verus or generic repos won’t support Verus capabilities any more than Electrum.https://discord.com/channels/444621794964537354/449638035999686677/1028678720103399494
For the moment, and things to watch are still in the rpc client, as Mike mentioned here
So, it turns out that right now, we're using the Verus version of bitcoind-rpc. We plan to cover it with a Bitcore caching layer, but the full API will be exposed via that server. Here is the current version being used in testing, and it will be updated with new functions before release: https://github.com/miketout/bitcoind-rpchttps://discord.com/channels/444621794964537354/449638035999686677/1028847703913938944
I first looked at the Verus enhanced, then looked at Mike's fork of new development he has made.
Then in Mike's branch some simple rewiring of the existing methods call specs, by loading it with a no-wallet by default object - a method of enhancing an existing library I enjoy, which was used to disable zCash parameters requirement on public-only smart chains.
The subtle differences between the
apisWithWallet is clever, for instance Verus Identity method, getIdentity has different parameters passed to it whether there is a wallet loaded or not. Handy to know for the future.
Then we start to see the Verus enhancements come into the bitcoind-rpc library. In particular, the apisWithWallet have some of the cool features Verus DeFi offers - defining a currency & blockchain identity to name a couple.
The remainder of the commits didn't seem too interesting, with the addition of a httpserver for comms.
This then showed up in a transaction on the PBaaS testnet VRSCTEST, showing that there's a new dimension of supporting game functions that can be used, to make compelling economic simulation games on Verus!
The explorer also supports nodejs v9, compared to the original komodo explorer that is supported with node version 4. The Tokel explorer also supports enhancements for displaying NFT information, but these have not been investigated yet.