Jump to content

domob

Dev Team
  • Content Count

    207
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by domob

  1. domob

    HUC delisted

    I still hold some HUC (and plan to keep on holding, of course, as this is a really pioneering project). But if you want to buy some, we could do an OTC deal as well (just message me if you are interested).
  2. Yes exactly, they are modelled after payment channels. However, one key difference is exactly this "proving that your opponent stopped responding". With payment channels, you circumvent this issue by simply allowing anyone to just settle the current state at any time. That is also the approach taken e.g. by Ethersips. I've not yet seen anyone else who actually goes for "complex" games where you can't simply determine an intermediate payout.
  3. What you are talking about is the situation that Alice (actually for a variety of reasons) might just stop responding to Bob (or might refuse to send a next valid move). That's the core issue solved by game channels. Basically, Bob would then post the state of the game on chain, and through that prove that he won (but read the paper if you are interested in the details).
  4. I've also just very recently started working on game channels (finally!). Together with the core framework, we will build a battleships-like game as the tech demo / initial example. For that, we also use hash commitments to ensure provably fair gameplay without the need of any central servers. You can find some preliminary informations about how that game will work exactly in our repository. (This is still heavy under development, though.) In general, hash commitments work very well to do all kinds of things between a known set of players (e.g. a game channel game). For determining random events in a full game world (like disasters in Huntercoin), however, things look a bit different. I've recently written a paper about that as well, using an entirely different approach.
  5. That is a very good question. In some sense, you are right that you have to design games in such a way that it is ok for everyone to have all the information. However, there are still ways to implement hidden information. For instance, using a "commit / reveal" scheme. For instance, you may want to give players the ability to set "traps" on a hidden location on the map that then attack someone who comes close. You can implement that by having players publish a (salted) hash of the location when they set the trap; this ensures the data is "fixed", but the location itself cannot be determined from it. Then if someone gets in range, they can publish the preimage (real location), and it can be verified that it matches indeed the hash they published previously (so they are not claiming a trap to be in a wrong spot). This is of course a very basic design, but you can build more sophisticated game features with this (or similar) concepts as well.
  6. It is, they use the same underlying pubkey hash and just have a differing base58check version. You can use the script in contrib/namecoin/convertAddress.py to do the conversion. Also, contrib/xaya/huc-snapshot contains some data for the snapshot.
  7. So far, I don't know anything about that Godot engine (@RyuMaster Gorskov). But one thing to note is that with Xaya, you typically build the backend and frontend of your game separately. The backend part, which is handling the blockchain and using libxayagame, corresponds to the server of a centralised game. So when people talk about "game engines", then what they typically are up to is the frontend. That, however, can be built in whatever framework you want anyway, and has no need to use libxayagame itself. My (uninformed) guess here is that the situation is different with Enjin, as they don't really have a proper blockchain backend at all, and their integration is mostly about just using blockchain assets in a centralised game / displaying them in the frontend.
  8. Indeed it is. I do not know the reason for this particular event, but we discussed in the team internally and will try to find more miners interested in SHA256-d merged mining. Especially from my point of view, that is a much higher priority than working on the GPU mining aspects.
  9. I'm not aware of any discussion, but yes, it matters. Names in Namecoin are just arrays of bytes. Xaya mostly inherits that, except that it only allows certain byte strings (for instance, they must be valid UTF-8).
  10. Yes, that's a bug in the example (although one in Namecoin). So ideally file an issue on the Namecoin Github (https://github.com/namecoin/namecoin-core).
  11. Great! Do let me / us know if you have any more questions, we're certainly happy to get more people building on Xaya!
  12. For doing an online game, I would write the backend / game-state processor in C++ just as in the "SQLite Hello World" tutorial. You can then run that on your server (but everyone who wants to verify themselves and be "fully decentralised" could run it themselves locally). The main difficulty with doing a game fully online is that you need a wallet in the user's browser, basically the equivalent of MetaMask.
  13. It is nice to hear you want to try your hands on a Xaya game - that is highly appreciated! Be sure to first read our tutorials and other documentation, for instance "SQLite Hello World" one. And don't hesitate to ask more questions as you go along! Also, you can take a look at our xid repository, which implements a simple but full-fledged game. I'm not exactly sure what you mean with your server/client question. You do not need any servers at all, as every node in the network (with the full XAYA blockchain) can compute the game state for themselves as well as handle all reorgs. But you may want to design your game locally in a client/server fashion, where the game backend provides a local server (built with libxayagame) and the frontend / UI talks to it. Calculating the damage and doing all other things will be done in your game logic's "update callback" - that is explained in the tutorials.
  14. Are you starting xayad manually in a terminal window? You can just start it with the "-daemon" flag, then it detaches immediately and you can close the terminal. Or you can use "xayad &", which has the same effect (and also works with the Qt).
  15. domob

    Xaya Rich List

    The RPC shows the actual amount of coins in circulation, by going through the UTXO set. So it would show if people created coins out of thin air.
  16. Also if you are on GNU/Linux, probably you can just install "libprotobuf-dev" and "protobuf-compiler" through your package manager. At least on Debian Stretch that works perfectly for me.
  17. Yes sure, you need to set those "-zmq..." arguments. What I meant is that it doesn't matter what ports you choose in them, as games should detect that automatically.
  18. Even if the ports are different then games should still work fine - they should not use fixed ports but call "getzmqnotifications" to find out which ports to connect. libxayagame-based games do that - I don't know about TreatFighter. But I think we mentioned "getzmqnotifications" in some discussions with Trickyfast, so I think they also do it.
  19. ZMQ is automatically compiled in if found, but the notifications need to be enabled at runtime. You need to pass flags like "-zmqpubgameblocks=tcp://127.0.0.1:28555" for that; this is the flag needed for other games like Taurion and SME, I don't actually know exactly which notifications you need for Treat Fighter. You can run "getzmqnotifications" to see which ones are enabled at runtime. The trackedgames options can be modified at runtime using the "trackedgames" RPC method, so games can automatically enable/disable themselves as needed. Again, I know for sure that Taurion and SME do this (as well as other libxayagame-based games), but I don't know about Treat Fighter.
  20. -rpcwallet is for specifying the wallet with xaya-cli. To load it with xayad or in xaya.conf, the option is just -wallet=game.dat.
  21. In fact, that is actually the default mode for libxayagame. You don't need any threading for it at all - if you use it in the simplest way, it basically gives you an RPC server that maintains and provides the game state. All that threading stuff is only needed if you want to run that in addition to your frontend in the same binary (so that you can run the RPC server on one thread and query it from another).
  22. If you want just the backend directly in C++, so no Unity/frontend/C#, then you can actually just look at the Mover code itself in the libxayagame repository. It is not as simple as a game could possibly be, but I think it should be fairly easy to use as a template and for reading some code.
  23. Perhaps the transaction was not shown as "unconfirmed" but "conflicted" in the wallet (because the input coins were invalid anyway, either as orphaned mining rewards or double spent coins). In that case, you do see the transaction in your wallet, but the coins are not actually allocated. Still it is nice that you were able to clean it up! I'm sorry to hear that you didn't get as many coins as you thought, though.
  24. The Huntercoin snapshot was done based on balances on the blockchain. If your coins were on Poloniex, then they were likely moved (by Poloniex) from your deposit address to some of their internal wallets, and their wallet addresses are where the snapshot CHI have been sent. It was said at the time and many times since then - the only way to really control your coins and be sure to get your CHI was to hold the Huntercoin yourself. With coins held on Poloniex, it is up to them to distribute the CHI. So far they always promised to do that, but we have no control over if/when they really do it. The best you can do is to open a support ticket with them and ask about it - the CHI have been sent to their addresses already quite some time ago, so they just need to distribute them now.
  25. No, unfortunatley the txid is not enough - I need the full raw transaction. You can get it by sending "gettransaction TXID" with xaya-cli or the Qt console. Alternatively, you can copy it from the transaction list of the Qt wallet.
×
×
  • Create New...

Important Information

Your use of this site is governed by our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.