Show HN: War on Ether | Hacker News Reader

Show HN: War on Ether

waronether.com

76 pointskobigurk36 comments

One of the toughest onboarding ever.

I read the text and I have no idea of what to do. Tried to click around, nothing. Tried to click on the example link and got a Firefox download dialog

    You have chosen to open:
    waronether_player_example.sol
    which is: BIN file (1.8 KB)
    etc

Going back to step 1:

> First, create a bot contract having an "execute" function which the game contract will run each round:

How to do it?

There's some prerequisite of knowing how Ethereum works and how to work with smart contracts at this point. There's room for more explanations for the public which is not that involved in Ethereum.

I realized that after reading the comments on HN, but the web page doesn't contain the word Ethereum. I think it should go into the very first line of the instructions.

Ether is a pretty generic term and I was setting up some IP addresses when I checked that site. I was primed for a different context :-)

Heh. Good point.

The word "Ethereum" could appear somewhere on the webpage, if that's the case. That might be a step in the right direction.

I mean, expecting prerequisite knowledge is one thing. Expecting your audience to be telepathic is another.

Now I really want distributed corewars. Can we do that? I mean, if Etherium can back this sort of grid, and the contract interpreted redcode at %ip (to use at&t syntax: I don't think redcode has a notation for the instruction pointer) in the grid, and increment %ip (unless it's a jump, obviously), than we could probably get the MARS spec running. The only trouble would be ensuring the contract actually was a valid interpreter, and loading the data in the address space to begin with.

Or I could be totally wrong. I don't really know etherium that well.

Interesting. I'll admit, my original goal was that the bots' code could also be overwritten by others, but that's not possible per the spec:

9.4.3. Jump Destination Validity. We previously used D as the function to determine the set of valid jump destinations given the code that is being run. We define this as any position in the code occupied by a JUMPDEST instruction. All such positions must be on valid instruction boundaries, rather than sitting in the data portion of PUSH operations and must appear within the explicitly defined portion of the code (rather than in the implicitly defined STOP operations that trail it).

I didn't consider implementing another spec though. Theoretically, should be possible, but I'll have to think about it some more!

Basically, all that's required for writing a MARS implementation is:

-Writing a Redcode assembler

-A contiguous address space of up to 8000 units, with circular memory (i.e all addresses are computed mod the size of the address space.), and a segregated, program-specfic address space (typically 1/16 the size of the full address space), if you're implementing ICWS '94

-Writing an actual Redcode VM, with support for all 16 (7168, actually, counting the different addressing modes) instructions, and process queues for each program.

Notably, all instructions take up one slot in RAM, and take one cycle to execute, after which control is passed to the program which has executed least recently, specifically the process in the program's process queue that has run least recently.

Finally, all assembled programs must be inserted into ram, and the emulator is started.

See, not hard at all!

No, seriously.

If you're interested, the ICWS '94 draft (ICWS died before it was ratified, but it remains the most popular dialect available today) is available at http://corewar.co.uk/standards/icws94.htm. A. K. Dewdney's orginal articles in Scientific American describe the origins of the language, as well as the oldest dialect of Redcode, if you're interested in implementing that, as wellas describing the basics of how to play. They're also just cool reads. They can be found at http://www.koth.org/info/akdewdney/. Dewdney's Corewars guidelines, from '84, are also of interest http://corewar.co.uk/standards/cwg.txt. The Corewar wikipedia article is also informative.

Finally, http://corewar.co.uk, and http://koth.org have links to a wide variety of resources about the game.

You're better off using Ethereum to keep records of matches and leave computing the results to computers that don't charge per opcode. It's fairly expensive now, but that could be reasonably priced in a couple years with plans to change up Ethereum's architecture to a tree of progressively lighter-weight blockchains (Sharding).

Is this supposed to be a game?

Why would anyone pay $11 to play something so poorly documented with almost no fun factor?

It's a common theme in the ethereum world that you pay a bit here and there. Factors:

- it's ok as it establishes Ether as a real "currency" that is being used to pay for stuff

- greed is considered okay

- the presence of intermediate tokens like casino chips or video game currency makes it easier to spend money (unless you deliberately rephrase it as something like "$11")

Usually fees are there for a reason, in this case it's part of the game (and the fun) as the fee goes into the prize fund.

In the "ethereum world" most of the community doesn't actually care too much about the currency aspect, it's the least interesting aspect of what you can do with Ethereum.

True enough on documentation. To be clear, you aren't supposed to join THIS game, it's a test network. You're supposed to either run an instance of this game yourself (and change parameters like the registration fee).

I'm also considering running an instance myself on the live network with different parameters (larger board, different fee).

>You're supposed to either run an instance of this game yourself

How is this different than hosting your own game server without a blockchain?

He means deploying to a public blockchain. You can then play this with your friend or someone else. It's different from running a game server since the contract will enforce the rules of the game, while if you control your own game server you can temper with it.

Using gas as a gameplay mechanic is such an obvious idea in hindsight. It's a glimpse into what "blockchain-native" games could become in the future. Apologies if this is a well-known trend and I'm just now learning about it, but I think it's pretty cool, and it's neat to see how this game implements it.

Yeah, because real gamers want to PAY for every move. Right.

That's going to be true of any game built on Ethereum. Might as well make it integral to the game.

That's what I'm saying. Games-on-blockchain are a completely non-starter.

The concept is fine as long as the transaction fee is low enough. The current minimum "gas" fee on Ethereum is something like a half-penny per transaction. That may indeed be too high for practical everyday gaming. But what if the transaction fee drops to a hundredth or thousandth of a penny? What if the rest of the game is otherwise free code on the blockchain, and you don't have to drop $60 for the privilege to play? Then the proposition is not so outrageous.

It wasn't so long ago that subscription gaming like World of Warcraft was a non-starter, or mobile micro-transaction gaming was a non-starter, but then both those concepts went on to dominate. There are many possible futures in which blockchain gaming could become viable. It's still early days for the tech. Much is in flux. None of us can be sure how it's going to play out.

> But what if the transaction fee drops to a hundredth or thousandth of a penny?

That can never happen. Not unless the miners are willing to lose their asses off. Bandwidth, storage, CPU etc are not free, and blockchain tech is extraordinarily gluttonous for all of those things relative to transaction volume.

Interesting, but very light on documentation. Can the bots even find out how much gas they have available?

Author here. True enough on documentation. About the specific question - they can calculate it from their number of tiles and the bonus for each tile. THAT will require tracking it or scanning for it, which costs some gas too :-)

I'm not very familiar with Ethereum. Can the players always see the code of the other player?

Can you explain the map?

The registration fee is 1 ETH ($11 currently)?

What does claimTile() do exactly?

Of course!

The map shows the current state of the game board - one color for each player for his owned tiles. The tiles with * are "life tiles" - you receive them when the game starts and they grant you a greater bonus, so there's an incentive to destory the enemy's life tiles first.

As each participant in the network sees the entire blockchain, the players can see the "compiled code", essentially the EVM opcodes, but only after all the players already committed to the hash of their code and new players can't commit anymore. This is a "commit-reveal" method that allows the game creator to accept registrations for a specific bot without actually revealing the player's code beforehand.

The registration fee is indeed 1 ETH at the moment, but that's a placeholder. The winner gets almost all the pool of registration fees (winning a game with 5 players = 4.5 ETH).

claimTile is the API exposed to the bot contracts - it's a way for them to change the board state to signify they own the tile. Of course, as every operation, it costs some gas. So you can have a strategy of claiming as many as possible by using only claimTile, but you could also seek enemy tiles and claim them. It's a trade-off of gas.

The bots can also examine the entire board (but that's something that consumes gas)?

If you run claimTile() on an enemy tile that is alive, it dies?

Calling move() will try to move a cell that is alive - can i only move the "alive" part of the cell into a cell that I claimed first using claimTile()?

The game ends after 10 rounds - the number of actions per round is only limited by available gas?

You are running the game on a test chain right now so there is no real ethereum (=money) involved yet?

- Yes, can examine and consumes gas.

- It becomes your tile.

- You can move only "life tiles", those with an asteriks, the 5 you have been allocated.

- Limited by the gas you have been allocated at this round. Careful, though, if you exceed the amount of gas allocated, your actions are reverted. 10 rounds is more of an example. An actual game would have more I believe.

- Test chain indeed. No money involved.

It's not clear what the rules are. What do you start with? What moves are legal?

Sounds very go-like to me.

3/3 comments on documentation ;-)

I will make that more clear on the site, but meanwhile: You start with 5 life tiles which grant you a larger gas bonus. Then, as the bot, you have an API to claim a tile, move your position (your life tiles) and to see the board state. You have to utilize the gas you are allocated smartly in order to eventually control more tiles than your enemies.

Okay, it seems like knowing how much gas each API call uses is rather critical to deciding on a strategy. Shouldn't that be documented?

(At first I thought "gas" was just an in-game resource. Didn't realize it was literally Ethereum gas.)

Core Wars meets distributed computing, looks cool. Why 1 ether/bot?

The fee goes into a prize pool, the winner bot wins the prize.

Sounds like illegal gambling.

Sounds more like a 'game of skill'[0] than draftkings for example.

[0]http://www.legalsportsreport.com/9022/fantasy-sports-or-gamb...

There is no luck involved beyond the starting position from what I can tell. It's more a game of (programming) skill.

Reply on news.ycombinator.com