Halite Home

Some ideas for Halite v 2.0


In no particular order, some ideas zanier than others :evergreen_tree: :rainbow:

  • **Edit-added ** version 2 uses a liquid metaphor rather than salt crystals, and is called H2O. Version 3 uses a superfluid metaphor, is called H3.

Serious suggestions :

  • Time travel: every bot has a token where they can, only once in the game, roll the entire game back to a frame of their choice (i can imagine this one will be super fun / super infuriating)

  • Co-opting enemy bots to your control ie, an enemy, if taken over, diligently continues to convert cells to your control, via their algo. you never see their code but you do benefit from it. (this could also be super fun / super infuiriating)

  • Bots can save state between games, and thus learn

  • A better ranking algorithm than trueskill Please :slight_smile:

  • Toroidal boundary conditions are used to ensure every player is exactly the same distance from every other player (topologists- will this limit the players to 4? i think we can do 6)

  • Fault-tolerance : bots might not do what you want them to do . Maybe some environment cells cause your bots to go random , like laughing gas.

  • Improvements to the environment and infrastructure : faster engine, players can query their own history of score and rank and also get a quick rundown of who they tend to win and lose against (i know these can be done, albeit laboriously. it would be super cool to have them in the default tools)

... your ideas here ...


The restricted computation time is extremely limiting for ML bots, in my opinion. It essentially precludes a number of very interesting approaches using ensembles, which is a shame. I'd love to see this lifted in version 2.0, so ML bots can really thrive.


Agreed. This turned out to be very limiting.


@JWGS1, I partly agree. There must be some practical limit, to prevent games dragging on for days and to disincentivise bad behavior. I think the solution for H20 will be a combination of
* making the calculation engine faster
* choosing a ranking algorithm that converges faster and thus requires fewer games
* increasing the turn limit by a small constant factor at most, say 2x

But, now that the competition is over, maybe there will be a small pocket of experiments with the format, including no time limit games.


I agree. To clarify, I'd like to see the computation limit extended, but it must certainly be limited.


I think the 15 seconds CPU time for init and 1 second CPU time per player were good limits, though maybe 2 seconds per round might have been nice for the ML bots. Too much more and I think people wouldn't be optimizing their code to be less CPU intensive.

The main issue I think was just that the CPU time was unpredictable and was based on how much CPU time your opponents used.

Looking at some of my timeout logs I think they may have used 1500ms rather than 1 second for timeouts on the official servers, which would mean you could time out in 6 player games in 250ms if everyone used their full 250ms in a round.

But I'm also not expecting a Halite v2.0 with the same type of game since everyone is making their code available. Otherwise we'll see a ton of clones of the V1.0 best bots and anyone who doesn't use one of the existing bots as their starting point would be at a huge disadvantage. I think that would discourage a lot of new players.


Agreed. I'd like to see some radically fun new twists (Time Travel ! Mindcontrol bots!) , maybe simpler core rules to compensate if this slows things down.


@cdurbin suggested over here, team-based halite:


In my opinion, 1-2 seconds is not enough for ML bots (particularly ensembles). When it comes to ML bots, it's not really an issue of optimising CPU time - just generating predictions for more than one pre-trained model will exceed 1-2s (unless the models are extremely small).


I shouldn't claim to know anything about what makes sense for an ML bot. I was thinking more for our hand-coded algorithm bots.

What do you think would have been good limits?


I had another thought. As we were getting to the end of the competition there was a lot of focus on the non-aggression pact. It became too important a strategy to try to implement a top bot without it.

One of the really negative side effects of this is that games took much longer, which in turn meant more resources required to play fewer games.

It would be good to introduce a rule that encouraged attacking enemy players sooner. I think that kind of gameplay is more fun and would prevent this max turn games where everyone just stacks strength until the last couple of rounds before the game ends.

I'm not exactly sure how you would encourage it - here's a few half baked ideas:

  1. The production of tiles occupied by an enemy at any point in the game are worth double or triple to anyone but the original owner
  2. Some bonus to the production of all of your tiles based on how many enemies you eliminated
  3. Max strength for tiles previously owned by a different player increases to 512.
  4. Some penalty to max strength or tile production for tiles only owned by you or based on how long you've owned that tile (I can't really think of a good design for this).

Let me know if you guys have any other ideas that would encourage more attacking and faster gameplay.


@cdurbin #4 is good, you could have some sort of negative exponential decay : production = p0 * exp-k(turn - turn0) , where turn0 was the last time you took over that tile. (thus, allows some churn where you lose and then regain tiles).


I'd say the way to encourage attacking other players, is to simply change the way the game is scored. That is also more transparent and easier to implement.

So just introduce a killcount: The number of enemy sites you've killed.

Final score is your territory multiplied with your kill count. In this way, players who don't attack at all, will have a zero score.


A simple (?) change that may introduce a large change in gameplay would be to allow diagonal moves.


I'd really like to be able to compete as a team. I have at least one other from my organization that would likely compete if we could team up. I'm also organizer of a Meetup, and forming groups would likely bring more people in.