7:23 AM
Interesting. You might need to define hexagonal wrapping, as there are more ways than the obvious one you get with a square grid. Also my leaning would be towards a shorter memory string but no strong preference
See Hexagony for a hexagonal shaped border to the grid, with 3 directions to wrap
Another option is a rhombus shaped border to the grid, like a square grid leaning over, with 2 directions to wrap (more similar to square grid wrapping and probably more intuitive for most people, but less in the spirit of hexagons...)
Also hexagons make me think of bees, if you wanted a slightly different but related theme to reduce to chance of duplicate voters

7:52 AM
To illustrate the long term difference between 3 way hexagon wrapping and 2 way rhombus wrapping, start on one cell and walk in a straight line. With hexagon wrapping you follow the same kind of path whichever of the 6 directions you choose. With rhombus wrapping you will get different path lengths in different directions
No wait, I think I'm wrong.
Some useful bits scattered among interesting bits in 20 Fun Grid Facts (Hex Grids)
I need to think more about hex grids before I can pretend to give advice...

8:30 AM
Actually ignore the reference to Hexagony - that has a wrapping model that isn't unique, and uses the state of the program to decide which cell to wrap to when there is ambiguity.
Another possibility would be to not have wrapping, and have a border of inaccessible cells so ants can tell when they are at an edge. Could even have a randomly chosen shape for the border in that case, so you never know until a game starts what shape the arena will be

9:00 AM
@trichoplax Interesring pieces of advice. I was initially thinking of a rhombus-shaped grid. I believe wrapping is universal there. As @dzaima pointed out, though, a hexagonal grid may be annoying to work with, reducing accessibility, which is required for this sort of challenge. I'm not convinced yet, however, so I'll keep all of this in mind.
I'm not sure about the non-wrapping of the arena.This might be a good idea, though I would add obstacles to random places in the arena if I were to go with non-wrapping. Thinking of "arena is an island, obstacles are lakes".

9:27 AM
@Alion you should really be careful on how difficult you make it for entries to be systematic & pattern-based, as we don't want an easy win for LS

@dzaima Ah, good point. The limitations aren't only technical ones - but also how far people are willing to push their ideas...
I mean, with memory you can probably overcome any challenge - as long as you're persistent enough...

3 hours later…
12:05 PM
Yes I am very much in favour of keeping it open to many people to make quick entries
I think some of the complex entries in KotHs only happen because that person was hooked in by being able to make a quick simple entry first

@trichoplax Well, I was dragged in because I saw something that hadn't been done that could maybe somehow work. IMO having many very different things able to win is very important too

12:31 PM
@Alion random idea: to fix the inconvenienciness of a hexagonal grid, maybe do something with the edges?
ooh, how about being able to build walls (maybe colored?) that you can't get over without destroying them?

12:48 PM
okay im making a hexagon playground for myself. Hexagons are fun :p

@dzaima Would you be able to see walls only around your cell? If so, it doesn't really add much gameplay, if not, it won't feel slick and will be hard to work with... if you're talking about edge-walls, that is.

@Alion hmm, the amount of walls seen is a good question.

Seeing more than 6 walls will feel clunky, I'm pretty sure...
Unless we see 12 walls? So, between every visible cell?

I had an idea of completely forgetting the ground colors and just have edges but the question of edges seen plus the clunkiness of viewing that make it not feel like that good of an idea

1:16 PM
@dzaima oh yes multiple possible approaches too. I love the idea of a contest being open ended and evolving over time

I just realized that BH would very much be feasible over there, as one can track the general shape of the blob (and correct it). Memory is great!
I'll apply the corrections to that challenge when I have the time. I still have to decide on the food being added over time...

1:47 PM
I thought about it some. I want to have wrapping and no obstacles. Even though these challenges wouldn't single-handedly make some ideas impossible, they'd definitely be annoying to overcome and wouldn't contribute much to the gameplay. I also don't think adding food over time is a good idea, though I'd love to see some more discussion about this.

1:58 PM

2:08 PM
@dzaima Looks pretty, but I don't know what you wanted to achieve...

@Alion I wanted to make a hexagonal grid and thought that I needed to rotate every hexagon by X degrees :p

Hmm. I wonder how wrong could a team-based Formic go...

2:49 PM
o.O fake rails wouldn't be a problem in your koth :D

@dzaima How so?
Ah, I see.
If you want, you can check out a slightly updated post. I've thrown in a couple of new ideas up for discussion as well.

IMO message sending around is too powerful. Maybe something like a public broadcast to all ants in some range (including enemies)?
ooh, maybe make every ant recieve messages at their turn, and if multiple are in range then choose a random one (aka speaking over the others)

3:04 PM
@dzaima Well, it isn't that powerful. You may just use memory to pass messages around anyway. Public broadcast has the same problems as public memory - edit wars.
Here, you can use more and more complex tactics. Over there, you could just change the format of stored/sent messages.

@Alion wait, a worker can modify anothers memory?
@Alion and oh yeah, edit wars..

@dzaima No, it cannot modify memory, but it can access it.

@Alion oh right

Modifying another's memory could be useful if used in conjunction with requiring a whole turn to change someone's memory (own included), but I feel like that's less intuitive and more prone to errors..

mhm

3:11 PM
Most intuitive would be to have a memory object, that you can modify even during your turn (so no returning another string every turn), but then you can't really limit how much space it uses.
Unless you can, and I don't know about it.

2 hours later…
5:19 PM
Anything using more than a few bits of memory, whether modifiable by an adversary or not, will make it hard to cache moves.

5:29 PM
@GNiklasch Yep - this challenge can't have any caching, unfortunately...
I took some precautions, though I don't know if it will be enough to prevent tournament times from being insane...
All serious entries will want to track time, anyway, so caching flies out the window right there.

6:22 PM
If it runs too slowly, then I may be too old to participate in earnest. (I go back to the days of punched cards... ;) )

6:33 PM
I'm leaning towards a 2 player KotH next for that reason. It would be great if a new player only needed to be played against all the existing players individually, rather than playing them all against each other all over again
Then the time taken to run a tournament should scale roughly with N, rather than N squared
Actually I think all against all tournaments scale somewhere between N^2 and N!

@trichoplax All players have to play against all other players, though. That's literally N^2...
Nonetheless, it's worse when multiple players participate.
Oh, silly. I thought N! was just the end of sentence with an exclamation mark. Whoops.

I'm too confused to work it out, but agreed it gets worse fast
Yes I really should use code formatting to make clear whether it's `N!` or `N`!
My underlying thinking was that although the overall time to score N players scales with N^2, most of those games will already have been played and recorded when a new player arrives, so only the N extra games need be run to determine the new leaderboard
(if games are all 2 player)

Oh, mhm. Updating the leaderboard gets easier.

I still love the idea of multiplayer KotHs, I'm just tempted to take a break and make "just" a 2 player one next...
Possibly Flit

6:47 PM
@trichoplax Do you have a particular KotH in mind? Or just generally a 2-player?

I'm down as well.

If I decide to make Flit 2 player, then that. Otherwise something else for now and 4 player Flit later

Flit?

ty
Also, just pushed some fixes to Vampire so I can swap over to updating Glider again. I've got some other tweaks I didn't push only because I'm not sure about them, but I want to be able to validate Glider changes against a reasonably robust version of Vampire

Tuesday's tournament has Glider in joint first with Lightspeed, 13.16 to 13.31 respectively
847 games in so far, which seems fast, even though it's on Firefox which I expected to run slower than Chromium
Oh wait I missed a day in my calculation...

Slightly mad because can't C++ and time limit is super low. I'll get my ass handed to me if I write it in C#...

Over 3 minutes per game on Firefox
@Alion Nim compiles to C++...

Woah, what is this sorcery... Good read, I'll check it out later.

6:57 PM
Writability of Python, speed of C++

I broke Flit

What difficulty level?
They are all beatable, but only the first should be that beatable :P

Oh, no, it didn't break, it just threw a spinning mouse at me for a bit. I thought it froze
(there's difficulty levels?)

This was my experiment with an interface you have to play with to find out what things do

oh I see

7:00 PM
If I make it a KotH I'll be much more explicit

I actually have written a bot in C++ (not for any challenge, though). The syntax haunts me, though... If I can make equivalent-speed code without worrying about 20+ years worth of tacked-on features, then oh boy...
I'll try rewriting that bot in Nim when I have some time, you might've just made my life a lot better @trichoplax.

I really liked Nim because I knew Python first. If you're already used to whitespace scoping it should be easy to pick up. There were things that threw me though, like passing arrays defaulting to by value when I was used to by reference in Python. You can still say explicitly though so it was fine

7:19 PM
Aaaand I beat the hardest difficulty Flit ai

:)
I'm not yet sure whether more interesting strategies will emerge playing 2 player or 4 player, but I'm leaning towards making it 2 player for the KotH just so the tournaments can finish sooner
The rules are not quite the same for the human playable version. There you win if you gain 48 or if your opponent cannot move
I still need to settle on a useful winning criterion for the KotH. What I have at the moment is needlessly complex
If you find the top difficulty level too easy you can try to see how few enemy pieces you can have when you win...
I really want to see what interesting strategies a KotH throws up though.

I've got one that, when used by a lowly human like myself, with no lookahead, wins >50% against the best AI. Should be fun with some lookahead...

I mean, I could, but I don't have a decent early-game strategy and only figured out the late game strategy on the fly

Yeah, I personally think this will make a more interesting KotH than a human played game. It was designed with bots in mind...
It's playable on mobile if you want to play as a human though...

@trichoplax Do you think the spec "ready enough" to start writing a bot already?

7:30 PM
Flit? It's definitely going to change, but probably not a great deal. I'll probably go with 2 players, a significantly larger board than the 12x12 human version, and a winning criterion that allows for stalemate (where both players can survive indefinitely) probably giving both players zero in that case
There's a good chance I won't go with JavaScript though.
I originally wanted it to be language agnostic but running tournaments for months has made me lean more towards fast tournaments, so I might pick a fast but accessible language if I can settle on one

Language agnostic doesn't actually sound too bad for this type of KotH... and it won't be slow, right?

Interacting with other languages using STDIN/STDOUT is slower than having the players all in one program that doesn't need to communicate outside itself
Also, I have to compile an arbitrary number of different languages that I don't read or write. That's why a JavaScript KotH worked so well for my first attempt

@trichoplax If you're allowing 50ms per move, then I don't think it's going to be a problem. On PC, at least, I measured inter-language latencies via `STDIN/STDOUT` to be around 0.02-0.1 ms with Python, Java, C# and C++.
@trichoplax That, however, might be a problem...

Yes that timing is to allow plenty of time for a language agnostic version running on 1 raspberry pi per player. I'd make it less for a language specific one
The other thing about a language agnostic KotH is that players can take up resources while it's not their turn. My original solution to that was to give each player its own raspberry pi. The simpler solution was to use JavaScript functions...

7:49 PM
Haha

I still like the idea of a raspberry pi per player though. As long as I can get it automated to run a whole tournament without attention

mhm

3 hours later…
10:41 PM
Having the submissions communicate with the controller via shared memory-mapped regions would theoretically be faster than sending through files/pipes/sockets, but the details would get hairy really quickly
For a more language-agnostic option, I suggest retrofitting the javascript koth framework with webassembly calling powers

Argh, I started a tournament 2 hours ago with some improvements to Highway, but my PC locked up mere seconds after I left, and I noticed just now...

doh