ColorFighter - C ++ - ăn một vài con én cho bữa sáng
CHỈNH SỬA
- làm sạch mã
- thêm một tối ưu hóa đơn giản nhưng hiệu quả
- đã thêm một số hình ảnh động GIF
Chúa tôi ghét rắn (chỉ giả vờ rằng chúng là nhện, Indy)
Thật ra tôi yêu Python. Tôi ước mình bớt đi một cậu bé lười biếng và bắt đầu học nó đúng cách, thế thôi.
Tất cả điều này đã được nói, tôi đã phải vật lộn với phiên bản 64 bit của con rắn này để khiến Thẩm phán hoạt động. Làm cho PIL hoạt động với phiên bản 64 bit của Python trong Win7 đòi hỏi sự kiên nhẫn hơn tôi sẵn sàng dành cho thử thách này, vì vậy cuối cùng tôi đã chuyển (đau đớn) sang phiên bản Win32.
Ngoài ra, Thẩm phán có xu hướng sụp đổ tồi tệ khi bot quá chậm để phản hồi.
Không hiểu biết về Python, tôi đã không sửa nó, nhưng nó phải làm với việc đọc một câu trả lời trống sau khi hết thời gian trên stdin.
Một cải tiến nhỏ sẽ là đưa đầu ra stderr vào một tệp cho mỗi bot. Điều đó sẽ dễ dàng truy tìm để gỡ lỗi sau khi chết.
Ngoại trừ những vấn đề nhỏ này, tôi thấy Thẩm phán rất đơn giản và dễ sử dụng.
Kudos cho một thách thức sáng tạo và vui vẻ.
Mật mã
#define _CRT_SECURE_NO_WARNINGS // prevents Microsoft from croaking about the safety of scanf. Since every rabid Russian hacker and his dog are welcome to try and overflow my buffers, I could not care less.
#include "lodepng.h"
#include <vector>
#include <deque>
#include <iostream>
#include <sstream>
#include <cassert> // paranoid android
#include <cstdint> // fixed size types
#include <algorithm> // min max
using namespace std;
// ============================================================================
// The less painful way I found to teach C++ how to handle png images
// ============================================================================
typedef unsigned tRGB;
#define RGB(r,g,b) (((r) << 16) | ((g) << 8) | (b))
class tRawImage {
public:
unsigned w, h;
tRawImage(unsigned w=0, unsigned h=0) : w(w), h(h), data(w*h * 4, 0) {}
void read(const char* filename) { unsigned res = lodepng::decode(data, w, h, filename); assert(!res); }
void write(const char * filename)
{
std::vector<unsigned char> png;
unsigned res = lodepng::encode(png, data, w, h, LCT_RGBA); assert(!res);
lodepng::save_file(png, filename);
}
tRGB get_pixel(int x, int y) const
{
size_t base = raw_index(x,y);
return RGB(data[base], data[base + 1], data[base + 2]);
}
void set_pixel(int x, int y, tRGB color)
{
size_t base = raw_index(x, y);
data[base+0] = (color >> 16) & 0xFF;
data[base+1] = (color >> 8) & 0xFF;
data[base+2] = (color >> 0) & 0xFF;
data[base+3] = 0xFF; // alpha
}
private:
vector<unsigned char> data;
void bound_check(unsigned x, unsigned y) const { assert(x < w && y < h); }
size_t raw_index(unsigned x, unsigned y) const { bound_check(x, y); return 4 * (y * w + x); }
};
// ============================================================================
// coordinates
// ============================================================================
typedef int16_t tCoord;
struct tPoint {
tCoord x, y;
tPoint operator+ (const tPoint & p) const { return { x + p.x, y + p.y }; }
};
typedef deque<tPoint> tPointList;
// ============================================================================
// command line and input parsing
// (in a nice airtight bag to contain the stench of C++ string handling)
// ============================================================================
enum tCommand {
c_quit,
c_update,
c_play,
};
class tParser {
public:
tRGB color;
tPointList points;
tRGB read_color(const char * s)
{
int r, g, b;
sscanf(s, "(%d,%d,%d)", &r, &g, &b);
return RGB(r, g, b);
}
tCommand command(void)
{
string line;
getline(cin, line);
string cmd = get_token(line);
points.clear();
if (cmd == "exit") return c_quit;
if (cmd == "pick") return c_play;
// even more convoluted and ugly than the LEFT$s and RIGHT$s of Apple ][ basic...
if (cmd != "colour")
{
cerr << "unknown command '" << cmd << "'\n";
exit(0);
}
assert(cmd == "colour");
color = read_color(get_token(line).c_str());
get_token(line); // skip "chose"
while (line != "")
{
string coords = get_token(line);
int x = atoi(get_token(coords, ',').c_str());
int y = atoi(coords.c_str());
points.push_back({ x, y });
}
return c_update;
}
private:
// even more verbose and inefficient than setting up an ADA rendezvous...
string get_token(string& s, char delimiter = ' ')
{
size_t pos = 0;
string token;
if ((pos = s.find(delimiter)) != string::npos)
{
token = s.substr(0, pos);
s.erase(0, pos + 1);
return token;
}
token = s; s.clear(); return token;
}
};
// ============================================================================
// pathing
// ============================================================================
class tPather {
public:
tPather(tRawImage image, tRGB own_color)
: arena(image)
, w(image.w)
, h(image.h)
, own_color(own_color)
, enemy_threat(false)
{
// extract colored pixels and own color areas
tPointList own_pixels;
color_plane[neutral].resize(w*h, false);
color_plane[enemies].resize(w*h, false);
for (size_t x = 0; x != w; x++)
for (size_t y = 0; y != h; y++)
{
tRGB color = image.get_pixel(x, y);
if (color == col_white) continue;
plane_set(neutral, x, y);
if (color == own_color) own_pixels.push_back({ x, y }); // fill the frontier with all points of our color
}
// compute initial frontier
for (tPoint pixel : own_pixels)
for (tPoint n : neighbour)
{
tPoint pos = pixel + n;
if (!in_picture(pos)) continue;
if (image.get_pixel(pos.x, pos.y) == col_white)
{
frontier.push_back(pixel);
break;
}
}
}
tPointList search(size_t pixels_required)
{
// flood fill the arena, starting from our current frontier
tPointList result;
tPlane closed;
static tCandidate pool[max_size*max_size]; // fastest possible garbage collection
size_t alloc;
static tCandidate* border[max_size*max_size]; // a FIFO that beats a deque anytime
size_t head, tail;
static vector<tDistance>distance(w*h); // distance map to be flooded
size_t filling_pixels = 0; // end of game optimization
get_more_results:
// ready the distance map for filling
distance.assign(w*h, distance_max);
// seed our flood fill with the frontier
alloc = head = tail = 0;
for (tPoint pos : frontier)
{
border[tail++] = new (&pool[alloc++]) tCandidate (pos);
}
// set already explored points
closed = color_plane[neutral]; // that's one huge copy
// add current result
for (tPoint pos : result)
{
border[tail++] = new (&pool[alloc++]) tCandidate(pos);
closed[raw_index(pos)] = true;
}
// let's floooooood!!!!
while (tail > head && pixels_required > filling_pixels)
{
tCandidate& candidate = *border[head++];
tDistance dist = candidate.distance;
distance[raw_index(candidate.pos)] = dist++;
for (tPoint n : neighbour)
{
tPoint pos = candidate.pos + n;
if (!in_picture (pos)) continue;
size_t index = raw_index(pos);
if (closed[index]) continue;
if (color_plane[enemies][index])
{
if (dist == (distance_initial + 1)) continue; // already near an enemy pixel
// reached the nearest enemy pixel
static tPoint trail[max_size * max_size / 2]; // dimensioned as a 1 pixel wide spiral across the whole map
size_t trail_size = 0;
// walk back toward the frontier
tPoint walker = candidate.pos;
tDistance cur_d = dist;
while (cur_d > distance_initial)
{
trail[trail_size++] = walker;
tPoint next_n;
for (tPoint n : neighbour)
{
tPoint next = walker + n;
if (!in_picture(next)) continue;
tDistance prev_d = distance[raw_index(next)];
if (prev_d < cur_d)
{
cur_d = prev_d;
next_n = n;
}
}
walker = walker + next_n;
}
// collect our precious new pixels
if (trail_size > 0)
{
while (trail_size > 0)
{
if (pixels_required-- == 0) return result; // ;!; <-- BRUTAL EXIT
tPoint pos = trail[--trail_size];
result.push_back (pos);
}
goto get_more_results; // I could have done a loop, but I did not bother to. Booooh!!!
}
continue;
}
// on to the next neighbour
closed[index] = true;
border[tail++] = new (&pool[alloc++]) tCandidate(pos, dist);
if (!enemy_threat) filling_pixels++;
}
}
// if all enemies have been surrounded, top up result with the first points of our flood fill
if (enemy_threat) enemy_threat = pixels_required == 0;
tPathIndex i = frontier.size() + result.size();
while (pixels_required--) result.push_back(pool[i++].pos);
return result;
}
// tidy up our map and frontier while other bots are thinking
void validate(tPointList moves)
{
// report new points
for (tPoint pos : moves)
{
frontier.push_back(pos);
color_plane[neutral][raw_index(pos)] = true;
}
// remove surrounded points from frontier
for (auto it = frontier.begin(); it != frontier.end();)
{
bool in_frontier = false;
for (tPoint n : neighbour)
{
tPoint pos = *it + n;
if (!in_picture(pos)) continue;
if (!(color_plane[neutral][raw_index(pos)] || color_plane[enemies][raw_index(pos)]))
{
in_frontier = true;
break;
}
}
if (!in_frontier) it = frontier.erase(it); else ++it; // the magic way of deleting an element without wrecking your iterator
}
}
// handle enemy move notifications
void update(tRGB color, tPointList points)
{
assert(color != own_color);
// plot enemy moves
enemy_threat = true;
for (tPoint p : points) plane_set(enemies, p);
// important optimization here :
/*
* Stop 1 pixel away from the enemy to avoid wasting moves in dogfights.
* Better let the enemy gain a few more pixels inside the surrounded region
* and use our precious moves to get closer to the next threat.
*/
for (tPoint p : points) for (tPoint n : neighbour) plane_set(enemies, p+n);
// if a new enemy is detected, gather its initial pixels
for (tRGB enemy : known_enemies) if (color == enemy) return;
known_enemies.push_back(color);
tPointList start_areas = scan_color(color);
for (tPoint p : start_areas) plane_set(enemies, p);
}
private:
typedef uint16_t tPathIndex;
typedef uint16_t tDistance;
static const tDistance distance_max = 0xFFFF;
static const tDistance distance_initial = 0;
struct tCandidate {
tPoint pos;
tDistance distance;
tCandidate(){} // must avoid doing anything in this constructor, or pathing will slow to a crawl
tCandidate(tPoint pos, tDistance distance = distance_initial) : pos(pos), distance(distance) {}
};
// neighbourhood of a pixel
static const tPoint neighbour[4];
// dimensions
tCoord w, h;
static const size_t max_size = 1000;
// colors lookup
const tRGB col_white = RGB(0xFF, 0xFF, 0xFF);
const tRGB col_black = RGB(0x00, 0x00, 0x00);
tRGB own_color;
const tRawImage arena;
tPointList scan_color(tRGB color)
{
tPointList res;
for (size_t x = 0; x != w; x++)
for (size_t y = 0; y != h; y++)
{
if (arena.get_pixel(x, y) == color) res.push_back({ x, y });
}
return res;
}
// color planes
typedef vector<bool> tPlane;
tPlane color_plane[2];
const size_t neutral = 0;
const size_t enemies = 1;
bool plane_get(size_t player, tPoint p) { return plane_get(player, p.x, p.y); }
bool plane_get(size_t player, size_t x, size_t y) { return in_picture(x, y) ? color_plane[player][raw_index(x, y)] : false; }
void plane_set(size_t player, tPoint p) { plane_set(player, p.x, p.y); }
void plane_set(size_t player, size_t x, size_t y) { if (in_picture(x, y)) color_plane[player][raw_index(x, y)] = true; }
bool in_picture(tPoint p) { return in_picture(p.x, p.y); }
bool in_picture(int x, int y) { return x >= 0 && x < w && y >= 0 && y < h; }
size_t raw_index(tPoint p) { return raw_index(p.x, p.y); }
size_t raw_index(size_t x, size_t y) { return y*w + x; }
// frontier
tPointList frontier;
// register enemies when they show up
vector<tRGB>known_enemies;
// end of game optimization
bool enemy_threat;
};
// small neighbourhood
const tPoint tPather::neighbour[4] = { { -1, 0 }, { 1, 0 }, { 0, -1 }, { 0, 1 } };
// ============================================================================
// main class
// ============================================================================
class tGame {
public:
tGame(tRawImage image, tRGB color, size_t num_pixels)
: own_color(color)
, response_len(num_pixels)
, pather(image, color)
{}
void main_loop(void)
{
// grab an initial answer in case we're playing first
tPointList moves = pather.search(response_len);
for (;;)
{
ostringstream answer;
size_t num_points;
tPointList played;
switch (parser.command())
{
case c_quit:
return;
case c_play:
// play as many pixels as possible
if (moves.size() < response_len) moves = pather.search(response_len);
num_points = min(moves.size(), response_len);
for (size_t i = 0; i != num_points; i++)
{
answer << moves[0].x << ',' << moves[0].y;
if (i != num_points - 1) answer << ' '; // STL had more important things to do these last 30 years than implement an implode/explode feature, but you can write your own custom version with exception safety and in-place construction. It's a bit of work, but thanks to C++ inherent genericity you will be able to extend it to giraffes and hippos with a very manageable amount of code refactoring. It's not anyone's language, your C++, eh. Just try to implode hippos in Python. Hah!
played.push_back(moves[0]);
moves.pop_front();
}
cout << answer.str() << '\n';
// now that we managed to print a list of points to stdout, we just need to cleanup the mess
pather.validate(played);
break;
case c_update:
if (parser.color == own_color) continue; // hopefully we kept track of these already
pather.update(parser.color, parser.points);
moves = pather.search(response_len); // get cracking
break;
}
}
}
private:
tParser parser;
tRGB own_color;
size_t response_len;
tPather pather;
};
void main(int argc, char * argv[])
{
// process command line
tRawImage raw_image; raw_image.read (argv[1]);
tRGB my_color = tParser().read_color(argv[2]);
int num_pixels = atoi (argv[3]);
// init and run
tGame game (raw_image, my_color, num_pixels);
game.main_loop();
}
Xây dựng thực thi
Tôi đã sử dụng LODEpng.cpp và LODEpng.h để đọc hình ảnh png.
Về cách dễ nhất tôi tìm thấy để dạy ngôn ngữ C ++ chậm phát triển này cách đọc một bức tranh mà không phải xây dựng nửa tá thư viện.
Chỉ cần biên dịch và liên kết LODEpng.cpp cùng với chính và Bob là chú của bạn.
Tôi đã biên dịch với MSVC2013, nhưng vì tôi chỉ sử dụng một vài thùng chứa cơ bản STL (deque và vectơ), nên nó có thể hoạt động với gcc (nếu bạn may mắn).
Nếu không, tôi có thể thử bản dựng MinGW, nhưng thật lòng tôi đang mệt mỏi với các vấn đề về tính di động của C ++.
Tôi đã thực hiện khá nhiều C / C ++ di động trong những ngày của mình (trên các trình biên dịch kỳ lạ cho các bộ xử lý 8 đến 32 bit khác nhau cũng như SunOS, Windows từ 3.11 cho đến Vista và Linux từ khi còn nhỏ cho đến ngựa vằn Ubuntu hay bất cứ điều gì, vì vậy tôi nghĩ Tôi có một ý tưởng khá hay về ý nghĩa của tính di động), nhưng tại thời điểm đó, nó không yêu cầu ghi nhớ (hoặc khám phá) vô số sự khác biệt giữa cách diễn giải của GNU và Microsoft về thông số kỹ thuật khó hiểu và khó hiểu của quái vật STL.
Kết quả chống lại Swallower
Làm thế nào nó hoạt động
Tại cốt lõi, đây là một con đường tràn ngập vũ phu đơn giản.
Đường biên của màu của người chơi (tức là các pixel có ít nhất một hàng xóm trắng) được sử dụng làm hạt giống để thực hiện thuật toán ngập khoảng cách cổ điển.
Khi một điểm đạt đến độ sáng của màu kẻ thù, một đường lùi được tính toán để tạo ra một chuỗi pixel di chuyển về phía điểm địch gần nhất.
Quá trình được lặp lại cho đến khi đủ điểm được thu thập để đáp ứng độ dài mong muốn.
Sự lặp lại này rất tốn kém, đặc biệt là khi chiến đấu gần kẻ thù.
Mỗi khi tìm thấy một chuỗi pixel dẫn từ biên giới đến pixel đối phương (và chúng tôi cần nhiều điểm hơn để hoàn thành câu trả lời), lấp đầy lũ được làm lại từ đầu, với đường dẫn mới được thêm vào biên giới. Điều đó có nghĩa là bạn có thể phải thực hiện 5 lần lấp đầy lũ trở lên để có câu trả lời 10 pixel.
Nếu không thể tiếp cận được nhiều pixel đối phương hơn, hàng xóm tùy ý của các pixel biên giới sẽ được chọn.
Thuật toán phá hủy một vùng lũ khá kém hiệu quả, nhưng điều này chỉ xảy ra sau khi kết quả của trò chơi đã được quyết định (tức là không có lãnh thổ trung lập nào để đấu tranh).
Tôi đã tối ưu hóa nó để Thẩm phán không mất nhiều thời gian để lấp đầy bản đồ một khi cuộc thi đã được giải quyết. Ở trạng thái hiện tại, thời gian thực hiện là không đáng kể so với chính Thẩm phán.
Vì màu sắc của kẻ thù không được biết đến khi bắt đầu, hình ảnh đấu trường ban đầu được lưu giữ để sao chép khu vực bắt đầu của kẻ thù khi nó di chuyển lần đầu tiên.
Nếu mã phát đầu tiên, nó sẽ chỉ lấp đầy một vài pixel tùy ý.
Điều này làm cho thuật toán có khả năng chiến đấu với số lượng đối thủ tùy ý và thậm chí có thể có những đối thủ mới đến một thời điểm ngẫu nhiên hoặc màu sắc xuất hiện mà không có khu vực bắt đầu (mặc dù điều này hoàn toàn không có sử dụng thực tế).
Xử lý kẻ thù trên cơ sở màu mỗi màu cũng sẽ cho phép có hai trường hợp bot hợp tác (sử dụng tọa độ pixel để vượt qua dấu hiệu nhận dạng bí mật).
Nghe có vẻ vui, có lẽ tôi sẽ thử nó :).
Đường dẫn nặng tính toán được thực hiện ngay khi có dữ liệu mới (sau thông báo di chuyển) và một số tối ưu hóa (cập nhật biên giới) được thực hiện ngay sau khi phản hồi được đưa ra (để thực hiện càng nhiều tính toán càng tốt trong các bot khác ).
Ở đây một lần nữa, có thể có nhiều cách để làm những điều tinh tế hơn nếu có nhiều hơn 1 đối thủ (như hủy bỏ tính toán nếu có dữ liệu mới), nhưng với bất kỳ giá nào tôi cũng không thấy cần đa nhiệm ở đâu, miễn là thuật toán được có thể làm việc trên tải đầy đủ.
Vấn đề hiệu năng
Tất cả điều này không thể hoạt động mà không truy cập dữ liệu nhanh (và sức mạnh tính toán nhiều hơn toàn bộ chương trình Appolo, tức là PC trung bình của bạn khi được sử dụng để làm nhiều hơn là đăng một vài tweet).
Tốc độ phụ thuộc rất nhiều vào trình biên dịch. Thông thường GNU đánh bại Microsoft với tỷ lệ 30% (đó là con số kỳ diệu mà tôi nhận thấy trên 3 thách thức mã liên quan đến đường dẫn khác), nhưng tất nhiên số dặm này có thể khác nhau.
Mã ở trạng thái hiện tại của nó hầu như không bị đổ mồ hôi trên đấu trường 4. Máy đo tốc độ Windows báo cáo mức sử dụng CPU khoảng 4 đến 7%, do đó, nó có thể đối phó với bản đồ 1000x1000 trong giới hạn thời gian phản hồi 100ms.
Trọng tâm của mọi thuật toán đường dẫn là một FIFO (có thể được chia theo tỷ lệ, mặc dù không phải trong trường hợp đó), do đó đòi hỏi phân bổ phần tử nhanh.
Vì OP bắt buộc đặt giới hạn cho kích thước đấu trường, tôi đã thực hiện một số phép toán và thấy rằng các cấu trúc dữ liệu cố định có kích thước tối đa (tức là 1.000.000 pixel) sẽ không tiêu thụ nhiều hơn vài chục megabyte, mà PC trung bình của bạn ăn vào bữa sáng.
Thật vậy, dưới Win7 và được biên dịch với MSVC 2013, mã tiêu thụ khoảng 14Mb trên đấu trường 4, trong khi hai luồng của Swallower đang sử dụng hơn 20Mb.
Tôi đã bắt đầu với các bộ chứa STL để tạo mẫu dễ dàng hơn, nhưng STL làm cho mã thậm chí ít đọc hơn, vì tôi không muốn tạo một lớp để gói từng dữ liệu để che giấu sự che giấu đi (cho dù đó là do tôi không có khả năng đối phó với STL được để lại cho sự đánh giá cao của người đọc).
Bất kể, kết quả rất chậm chạp đến mức ban đầu tôi nghĩ rằng tôi đang xây dựng một phiên bản gỡ lỗi do nhầm lẫn.
Tôi cho rằng điều này một phần là do việc triển khai STL của Microsoft cực kỳ kém (ví dụ, vectơ và bitcoin thực hiện kiểm tra ràng buộc hoặc các hoạt động crypic khác trên toán tử [], vi phạm trực tiếp thông số kỹ thuật) và một phần do thiết kế STL chinh no.
Tôi có thể đối phó với các vấn đề về cú pháp và tính di động (ví dụ Microsoft vs GNU) nếu các màn trình diễn ở đó, nhưng điều này chắc chắn không phải là trường hợp.
Ví dụ, dequevốn đã chậm, vì nó xáo trộn rất nhiều dữ liệu sổ sách xung quanh chờ đợi dịp để thực hiện thay đổi kích thước siêu thông minh của nó, về điều mà tôi không thể quan tâm.
Chắc chắn tôi có thể đã triển khai một cấp phát tùy chỉnh và phân bổ các bit mẫu tùy chỉnh khác, nhưng một mình phân bổ tùy chỉnh tốn vài trăm dòng mã và phần tốt hơn trong một ngày để kiểm tra, với hàng tá giao diện mà nó phải thực hiện, trong khi một cấu trúc tương đương thủ công là khoảng 0 dòng mã (mặc dù nguy hiểm hơn, nhưng thuật toán sẽ không hoạt động nếu tôi không biết - hoặc nghĩ rằng tôi biết - dù sao tôi cũng đang làm gì).
Vì vậy, cuối cùng tôi đã giữ các thùng chứa STL trong các phần không quan trọng của mã, và xây dựng bộ cấp phát tàn bạo của riêng tôi và FIFO với hai mảng khoảng năm 1970 và ba quần short không dấu.
Nuốt nuốt
Như tác giả của nó đã xác nhận, các mẫu thất thường của Swallower là do độ trễ giữa các thông báo di chuyển của kẻ thù và các bản cập nhật từ chuỗi đường dẫn.
Máy đo lưu lượng hệ thống cho thấy rõ ràng đường dẫn tiêu thụ CPU 100% mọi lúc và các mẫu hình răng cưa có xu hướng xuất hiện khi trọng tâm của cuộc chiến chuyển sang một khu vực mới. Điều này cũng khá rõ ràng với các hình ảnh động.
Tối ưu hóa đơn giản nhưng hiệu quả
Sau khi xem các trận đấu chó hoành tráng giữa Swallower và máy bay chiến đấu của tôi, tôi nhớ một câu nói cũ từ trò chơi cờ vây: phòng thủ cận cảnh, nhưng tấn công từ xa.
Có sự khôn ngoan trong đó. Nếu bạn cố gắng bám lấy đối thủ của mình quá nhiều, bạn sẽ lãng phí những bước đi quý giá khi cố gắng chặn từng con đường có thể. Ngược lại, nếu bạn chỉ cách một pixel, bạn có thể sẽ tránh lấp đầy những khoảng trống nhỏ sẽ thu được rất ít và sử dụng các bước di chuyển của mình để chống lại các mối đe dọa quan trọng hơn.
Để thực hiện ý tưởng này, tôi chỉ cần mở rộng các bước di chuyển của kẻ thù (đánh dấu 4 hàng xóm của mỗi lần di chuyển là pixel của kẻ thù).
Điều này ngăn thuật toán đường dẫn cách xa biên giới của kẻ thù một pixel, cho phép máy bay chiến đấu của tôi hoạt động xung quanh một kẻ thù mà không bị vướng vào quá nhiều trận đấu chó.
Bạn có thể thấy sự cải thiện
(mặc dù tất cả các lần chạy đều không thành công, bạn có thể nhận thấy các phác thảo mượt mà hơn nhiều):
