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
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
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
@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".
@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
@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.
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
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.
@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.
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..
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.
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!
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
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
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
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.
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
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++.
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...
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
Formic Functions
Formic Functions