Here is a piece of C++ code that seems very peculiar. For some strange reason, sorting the data miraculously makes the code almost six times faster.
#include <algorithm>
#include <ctime>
#include <iostream>
int main()
{
// Generate data
const unsigned arraySize = 32768;
int data[arr...
At the start of the game, the formation doesn't exist at all and must be formed. Even if the two pixels are very close to each other, the formation hasn't formed until they end their moves in the right spot.
I think we can start to piece together some rules of movement, so the "leader" bot has fewer decisions to make, and the follower bot can think more on its own.
1) Never move into a square where the enemy can capture you next turn. 2) If you can, always capture an enemy. 3) If the target (how do we pick a target?) is directly above or below, then move directly up or down.
4) If the target is displaced horizontally and vertically, but the vertical distance is greater, then you move diagonally towards it, so that you will eventually be vertically aligned.
The basic idea is to determine where the formation is (rather than where the bot is), which ways are safe for the formation to move, and then for the two bots to figure out where they need to go to make that happen.
Since I only have a single bot right now, I can't really work on that yet.
topx/topy contain the old location, while ntopx/ntopy contain the new location, so dx and dy are the relative location of the enemy from the possible future location of the bot.
So how was this working again? Are we having it so that both bots use the same logic, and whichever bot moves first decides where to move and the other one follows?
It should now determine which moves are captures, and make a capturing move if one is available. although some captures are not effective because it would be the bottom bot making the capture.
The most original idea is that of a "preference" array. Depending on the condition, we can set different preferences, which are checked, in order, and the first safe move is performed.
Hm... I hadn't thought about that... I had this phase where I tried to have a few instructions to make one-liners easier, e.g. q for be like ? but skips two (e.g. when you want to tack :n afterwards)
Ahaha branch 3 eh... hm...
@PhiNotPi btw is (Math.floor(move / 256)) + 1; just a temporary thing?
Q currently pops the top of the stack and jumps that much if the one below that is zero
Having said that even though a lot of instructions are done, I get the feeling I'll change a lot of things around soon so that's why I haven't been posting any answers with it yet :P
Quine Creator
quinecode-challenge
The program F is in language A. F takes a program in language B as input. Lets call this program G. F outputs a program in language B. Lets call this program O. O Takes some input and for some values it will be a quine and for others it will run G.
The exact v...
Build a steady brick wall
code-golf
A brick wall is a rectangle made of horizontal 1*n bricks stacked in rows. Here's a wall of height 4 and width 8:
[______][______]
[__][____][__][]
[][______][____]
[____][______][]
It's made of bricks of sizes
4 4
2 3 2 1
1 4 3
3 4 1
This wall is u...
well you use subset sum to figure out how you can distribute the bricks across rows of equal length. and then you check the permutations of those partitions for validity.
given a partition you can probably also do better than checking all permutations by building a graph of allowed adjacent rows and finding a Hamiltonian path... this problem is definitely NP complete, so it'll be horribly inefficient anyway
The second block should always just follow the first block. I'm assuming that when the first block makes the decision, the resulting square is always safe for the second block.
Theoretically if they ever do get out of formation (e.g. after first block moves or by some weird bug) then the blocks should just do what they do at the start, i.e. try to match up again
I got a new bug on our hands. In the battle currently running. the formation is aligned directly above an enemy, but moves up-right instead of straight down.
The bottom bot switches position (the lines in the last message) and since it's out of formation it tries to get back into position, using the updated position as its target square
Sometimes, I play code-golf or quine, and I find an answer more than once, for two different languages. (I know popularity-contest dosen't count.) Can I post another answer, assuming that the rules of the contest don't say otherwise?
btw one of the bugs was selfsafe[j] += ((Math.abs(newx - x) + Math.abs(newy - y)) -(Math.abs(newx - targetx) + Math.abs(newy - targety))) + 2;, which should have been more like x - targetx and y - targety for the first two
(basically I was trying to pick the move which would get the block closest to its target)
Actually... I probably don't even need the first bit...
Here is a piece of C++ code that seems very peculiar. For some strange reason, sorting the data miraculously makes the code almost six times faster.
#include <algorithm>
#include <ctime>
#include <iostream>
int main()
{
// Generate data
const unsigned arraySize = 32768;
int data[arr...
Quine Creator
quinecode-challenge
The program F is in language A. F takes a program in language B as input. Lets call this program G. F outputs a program in language B. Lets call this program O. O Takes some input and for some values it will be a quine and for others it will run G.
The exact v...
Build a steady brick wall
code-golf
A brick wall is a rectangle made of horizontal 1*n bricks stacked in rows. Here's a wall of height 4 and width 8:
[______][______]
[__][____][__][]
[][______][____]
[____][______][]
It's made of bricks of sizes
4 4
2 3 2 1
1 4 3
3 4 1
This wall is u...
Sometimes, I play code-golf or quine, and I find an answer more than once, for two different languages. (I know popularity-contest dosen't count.) Can I post another answer, assuming that the rules of the contest don't say otherwise?
Red Team Chat for Pixel Team Battlebots
Red Team Chat for Pixel Team Battlebots
