I'm trying to decide how complex I want the "bot language" to be.
I think the "strategy spectrum" for the game is pretty clear cut: either the best strategy is to have the bot-program only 1 token long and update it every turn, or spend your first several turns building up a long program that is left running.
The original game resolved this by having two bots, forcing players to either 1) write programs that can be run for multiple turns, or 2) only actively play with a single bot.
Okay, change of terminology: "program" refers to the thing users write, "instruction list" denotes the series of token the bot performs.
I guessed those from the spec but I wasn't sure enough to assume I was right. Might be worth stating explicitly in the spec.
Sounds good to me. What more complex features were you considering? I'm guessing you don't want much in the way of control flow if the instruction list has to terminate for each turn?
I remember the discussion about how long an instruction list to use for the original Code Bots. I think being able to have multiple copies of the same program that would mutually repair was relevant to that choice, but here bots can only be controlled by other bots, and no instructions will ever be overwritten, so the number can be even more arbitrary...
@El'endiaStarman Yes it sounds like. So I was trying to think what other more complex features might be interesting, if control flow is ruled out.
We have a few people working on KotH servers. At some point, we're gonna hit critical mass with those and all the KotHs in the Sandbox will get posted. :P
@PhiNotPi The only more complex feature that comes to mind is a command to sacrifice a crystal. Perhaps only one command can be added per turn, but additional commands can be added at the cost of one sacrificed crystal each. So you decide whether to hoard crystals to get a high score or spend some on getting an advantage. Just a thought - personally I'd go with keeping it as simple as possible and seeing what strategies emerge from that.
@ChrisJester-Young Really, PPCG just needs one platform that can run arbitrary code in (almost) all of the languages safely. You could run KotHs and do fastest-code, and you could implement automatic checking of test cases for code-golf challenges.
A lot of KoTHs seem to have a very short time limit per turn, allowing huge numbers of turns in a game. I've tended to assume this for my own ideas, but now you mention it, it would be interesting to see a KoTH with a game that has a much longer time limit, as long as the game isn't subject to exhaustive brute force.
Parse a quaternion into a list
code-golf parsing
This challenge is fairly simple: parse a string form of a quaternion (ex. "1+2i-3j-4k") into a list/array (ex. [1 2 -3 -4]). However, the quaternion string can be formatted in many different ways...
It may be normal: 1+2i-3j-4k
It may have mi...
imagine one of the codebots challenges running at one turn per second, forever, on a large toroidal playing field. any time a new player joins, the field expands and some copies of that new bot are added.
@trichoplax you didn't submit emails for moves, you submitted a whole self-contained bot/entry once and let it run indefinitely
I mean, it would have been neat to have ai players in some of them, but the ones I really liked were too complex for an ai player to fully grasp or compete in.
however, there are a lot of old pbem bot games that could easily be ppcg koth tournaments
@trichoplax I was considering some kind of conditional statement, like "skip next instruction if there's an object in front of you". Maybe also some kind of jump, like "jump to the command after the next HALT token" which would allow for more complex programs.
@PhiNotPi I suppose it depends how much you want the game to be about the bots fending for themselves, and how much you want the bot controllers to intervene. Do you want to limit the processing capabilities of the bots to force the controllers to do most of the work, or have bots that only need occasional tweaking (if any)?
@mınxomaτ what do you mean? that's how I'm planning to implement lambdas in Cheddar, though I've never seen this sort of syntax for lambdas which is why I'm wondering if it's actually a good idea
@Downgoat This is a traditional function: (a, b) { return a+b }, and that is an expression body: (a, b) => a+b. An example for a language that uses expr. bodies is C#6
In C#, every function that can be expressed in one single expression can be converted to an expression body. I wouldn't use EBs for more than one expressions, since they become unreadable.
Case in point, here's an EB that got out of hand (It's recursive, too :D) :
Cheddar will have hopefully improved expression body syntax. It's pretty much like a mix between traditional syntax except where function is ->, and expression bodies
@Downgoat Well, keep in mind the above is just one expression (a big, recursive ternary condition to be precise). There's just no EOL significance in C#.