Jump to content

domob

Dev Team
  • Content Count

    217
  • Joined

  • Last visited

  • Days Won

    10

domob last won the day on September 15

domob had the most liked content!

Community Reputation

135 Excellent

4 Followers

About domob

Recent Profile Visitors

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

  1. The frontend is, but the GSP can be run on Linux and has been like that forever (actually that's how I do development myself).
  2. It is the Taurion tech demo competition.
  3. Hm, that sounds strange. Xaya Core should certainly support tracking more than one game, and in your situation, the second move should come with game-block-attach json secondgame. There's also a regtest that verifies exactly this, IIRC. So it "should" work. If it doesn't, then please open an issue on our Github.
  4. As with Bitcoin and most other blockchains, miners can freely choose what to include and not to include in their blocks. So in theory, someone could send transactions without any CHI attached and get the mined, e.g. by paying the miners out-of-band (maybe with BTC or fiat), or by including some game-coin transaction to them instead of CHI. But I think there are strong reasons why that is not going to happen any time soon (nor will it happen with Ethereum): A game would need to be really popular for that to happen, because the miners themselves need to run the GSP for it and also be interested enough in it to actually accept payment in the game coin directly. While not impossible, that's certainly extra effort for them (much more than simply running Xaya Core on their system). Paying in game coins is likely a lot less efficient than paying transaction fees in CHI, since the latter is "better integrated" with the core blockchain and transaction structure. So accepting fees in game coins will likely increase transaction size and thus reduce the number of fee-paying transactions that miners could get into their block. Not just miners matter, but also relaying nodes. So unless either a large fraction of the network runs a modified client that accepts game coins for fees or users submit their transactions directly to miners, transactions won't even make it to miners if they do not pay CHI. For the first case, we would again need a hugely popular game as well as most people messing around with their Xaya Core installation, which seems even more unlikely than a miner doing it. For the second case, people also would need to spend a non-trivial amount of effort to figure out who the miners are that accept their game coins and how to submit moves to them directly. Even if some miners accept fees in game coins and you would eventually get your move confirmed, most likely it will take longer than if you paid CHI (unless 100% of miners accept the game coin, which seems impossible in practice). So you are at a disadvantage. With all those disadvantages, I simply do not see why people and miners would bother. If they have / earn game coins and want to cover fees with them, they can instead just sell them for CHI anyway and then use CHI. All those technical aspects aside, it seems that your main concern here is about the potential for CHI to increase in value due to demand. To be honest, I think that for that topic, usage of game coins for transaction fees is a very theoretical thought for now. 99.999% of CHI demand and potential price increase is likely just speculation - and if games are doing well, then that is a good first step independently of how those games actually use CHI.
  5. I've never used Docker myself before, but that sounds like a useful feature!
  6. I think this question mixes up a couple of things. First, for this question, it does not matter whether games run in game channels or not. Second, you always need CHI in order to pay transaction fees, register accounts and do other things on the core blockchain. The actual use of currency in a game is a bit more nuanced. The main thing to keep in mind here is that the Xaya model does not allow game logic to affect the movement of CHI (the reason being that this in turn allows vastly better scalability to complex games than e.g. Ethereum). This means that games can very well use CHI in the sense that they react to voluntary movement of CHI; an example is Treatfighter, where you can by crystals for CHI - but in principle the whole game would work without crystals at all, and with payments being done directly in CHI. Where this does not work is things like betting on the outcome of a game or for instance SME, because there the result of some game computation may require that e.g. the loser sends some money to the winner, or the club pays for player wages; and this has to be done even if the user does not explicitly sign a transaction moving CHI. In that cases, you need to use an in-game currency instead. An exchange could certainly list an in-game currency (e.g. SME coins) directly if they wish, but you will still always need CHI to pay for the core blockchain features (e.g. tx fees). Also, it will be possible to trade game assets in a trustless and decentralised way against CHI, so that there will be a natural tendency to have CHI as "base currency" for all game-asset markets on Xaya.
  7. The initial version will be for desktop only. But we are definitely thinking about Android support, and already have most bits and pieces ready to support mobile gameplay as well - it just needs to be put together and polished. So Android / mobile support will definitely come at a not-so-distant time in the future as well.
  8. That is very strange. As far as I know, xayad should not give you any error of that kind; if anything, then xaya-cli or your JSON-RPC client should. So you run the xayad command, and that error gets printed? What does your debug.log file (in the Xaya data directory) show?
  9. Does the Mac package not contain xaya-cli? @snailbrain - I think it should (if it doesn't already). But yeah, as you said, you can use the wallet console to send commands as well. What command are you trying to send when you get that error?
  10. Yes, these payments are the "fees" for creating characters in Taurion. Those fees go to the team, in order to fund further development - thus they are paid to the premine address (which is a secure, multisig shared address between us).
  11. 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).
  12. 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.
  13. 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).
  14. 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.
  15. 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.
×
×
  • 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.