Jump to content

domob

Dev Team
  • Content Count

    207
  • Joined

  • Last visited

  • Days Won

    7

domob last won the day on May 12

domob had the most liked content!

Community Reputation

131 Excellent

4 Followers

About domob

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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.
×
×
  • 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.