Эпическое чтиво, уже который день вечерами читаю оригинал статьи. Я конечно имею не настолько длинный и тесный опыт с Bevy и Rust в разрезе геймдева, но меня посещали все те же мысли, что автора, каждый раз, когда я пытался в Amethyst или Bevy, особенно в плане того, что ты безальтернативно должен оставаться в парадигме ECS, а не прибегать к нему только, когда тебе кажется это необходимым.
Еще в оригинальной статье есть интересный поинт про hot-reload (эта часть перевода еще не дошла до той части), о котором я не задумывался - что, даже если тебе кажется, что тебе не так уж и нужен hot-reload для разработки игры, то это значит, что ты просто не имел опыта быть в цикле разработки, где есть hot-reload, и что это в какой-то мере game-changer, потому что ты на лету можешь творить такую дичь о которой и не мечтал при привычном пайплайне "внес изменения -> пересобрался -> запустился -> проверил -> повторяем по-кругу до потери пульса"
Вайбер, внезапно, используется повсеместно на Балканах вместо WhatsApp или Telegam. Банки, магазины и курьеры также будут писать вам в вайбер, если знают ваш номер телефона.
Ну и к другим мессенджерам они относятся примерно так же, как вы относитесь к Вайберу. Так что все еще зависит от контекста и географии.
А еще в вайбере есть встроенный переводчик сообщений, что порой действительно сподручно
Если честно, я было начал с "клонировать", но быстро стушевался, потому что когда увидел на русском много слов "клонировать, клонировать", мне показалось, что я сумасшедший ученый, клонирующий людей. Насчет общепринятости в русском языке тоже засомневался, "копировать" выглядело более приемлемым.
В общем, если отвечать на вопрос "в чем проблема?", то скорее всего во мне)
Это видео я тоже смотрел, но решил, что переведу только про Arc. Так что если у вас есть желание перевести видео про &Option<T>, то я не стою на вашем пути)
Но ведь в Rust move-семантика вшита в язык по дефолту. А статья вовсе не про то как замувить, а про то как дешево копировать. Ну и последняя глава как раз про Box<str> для тех, кто хочет мувить
Я дико извиняюсь, но в моей статье ничего такого, о чем вы говорите, нет. В ней есть только то, что я написал. Ни про три эвристики, ни тем более про алгоритм поиска со звездочкой в ней нет ни слова.
Более того, в статье в Википедии, откуда мое изображение перерисовано, тоже речь идет не про три эвристики и алгоритм *, а только лишь про природу Манхэттенского расстояния, о чем и я вторю своими словами и своими руками (в случае периначенного изображения)
Извиняюсь за недоразумение, подписал изображение во избежание путаницы.
Про "от балды" правда не понял - изображение ровно такое, какое должно быть, и абзацем ниже про него все расписано. И про то, что это Манхэттен; и про то, что пути разные, но расстояние по факту одно и то же - 12 клеток, можете сами посчитать, там 12. Где что чему не соответствует-то? Каким метрикам из статьи?
А, я понял. У подхода есть одна серьезная проблема: не будут поддерживаться дробные числа - C++ не позволит енуму иметь float-значение. А это значит, что, например, два примера из моей статьи - и было бы невозможно построить с помощью такой функции. К тому же консистентность рушится еще и по причине метрики Чебышева, которая вообще и надо закреплять за ним какое-то спец-значение.
У меня витала в голове идея подобного рода - ведь я как-то сгенерировал для примеров карты с и ? Я эту реализацию писал на GDScript, но если транслировать мой код в C++, то используются две функции, которые можно заоверлоадить. Пример требует С++20 и выше из-за double в качестве non-type template parameter:
#include <iostream>
enum class SpaceMetric
{
Euqlid,
Manhattan,
Chebyshev
};
struct Point
{
double x;
double y;
};
template <double ORDER>
double distance(Point a, Point b)
{
return pow(pow(abs(b.x - a.x), ORDER) + pow(abs(b.y - a.y), ORDER), 1 / ORDER);
}
template <SpaceMetric METRIC>
double distance(Point a, Point b)
{
if constexpr (METRIC == SpaceMetric::Manhattan)
{
return abs(b.x - a.x) + abs(b.y - a.y);
}
else if constexpr (METRIC == SpaceMetric::Chebyshev)
{
return std::max(abs(b.x - a.x), abs(b.y - a.y));
}
else
{
return sqrt(pow(b.x - a.x, 2) + pow(b.y - a.y, 2));
}
}
int main()
{
Point a{ 0, 0 };
Point b{ 3, 4 };
const double euclid = distance<SpaceMetric::Euqlid>(a, b);
const double manhattan = distance<SpaceMetric::Manhattan>(a, b);
const double chebyshev = distance<SpaceMetric::Chebyshev>(a, b);
const double order1_5 = distance<1.5>(a, b);
const double order0_5 = distance<0.5>(a, b);
for (const auto& val : { euclid, manhattan, chebyshev, order1_5, order0_5 }) {
std::cout << val << std::endl;
/*
prints
5
7
4
5.58425
13.9282
*/
}
}
Таким образом мы сели ровно на оба стульчика:
Там где можем использовать именные версии, там используем enum. Тут же покрыт неудобный Чебышев;
Ухх, хорошо разложили, нужно опробовать этот подход, ибо он хотя бы действительно понятный в отличие от того же Форчуна. Кажется, теперь я знаю, чем занять ум в свободное от всего время :)
Если вы про цветастые примеры для одних и тех же десяти точек, то каждая картинка внизу подписана. Разве нет? У меня и в мобильной версии и на ПК видно.
А если конкретно про примеры нашей игры, то я всю статью читателям уши жужжу про Манхэттенскую метрику ()
Непредсказуемостью жизни) Вон сегодня многие мигрируют с Unity на Godot (самый громкий пример - Road to Vostok), завтра я захочу влететь в новый проект чужой проект со своим движком со своими старыми наработками. Но если наработки будут слишком сильно и специфично завязаны на движок, то влететь-то я захочу, но не смогу.
Так зачем же себя огрничивать в большей степени, чем в меньшей?
Поинт про коннекторы действительно хороший. У нас были заготовки для road connector'ов и их было строго ограниченное количество:
под углом 90 градусов
под углом 45 градусов
под углом 180 градусов (крч просто прямая)
Все для того, чтобы четко соответствовать стилистике биомов, которые тоже состоят из строго вертикальных, горизонтальных и диагональных в 45 градусов линий.
И тут то, о чем вы говорите, действительно расцвело бы пышным цветом - POI по идее могли бы быть расставлены только ограниченными конфигурациями в пространстве, и мы бы наверное померли придумывать, как их генерировать.
Так что, пожалуй, вы правы - лучше начать с дороги, а не наоборот.
Оу, был бы рад почитать в комментариях что-то интересное или дополняющее по теме от ваших коллег! Наверняка у них есть свои лайфхаки, секретики и боль по генерации карты, которые можно оставить для потомков
Эпическое чтиво, уже который день вечерами читаю оригинал статьи. Я конечно имею не настолько длинный и тесный опыт с Bevy и Rust в разрезе геймдева, но меня посещали все те же мысли, что автора, каждый раз, когда я пытался в Amethyst или Bevy, особенно в плане того, что ты безальтернативно должен оставаться в парадигме ECS, а не прибегать к нему только, когда тебе кажется это необходимым.
Еще в оригинальной статье есть интересный поинт про hot-reload (эта часть перевода еще не дошла до той части), о котором я не задумывался - что, даже если тебе кажется, что тебе не так уж и нужен hot-reload для разработки игры, то это значит, что ты просто не имел опыта быть в цикле разработки, где есть hot-reload, и что это в какой-то мере game-changer, потому что ты на лету можешь творить такую дичь о которой и не мечтал при привычном пайплайне "внес изменения -> пересобрался -> запустился -> проверил -> повторяем по-кругу до потери пульса"
Вайбер, внезапно, используется повсеместно на Балканах вместо WhatsApp или Telegam. Банки, магазины и курьеры также будут писать вам в вайбер, если знают ваш номер телефона.
Ну и к другим мессенджерам они относятся примерно так же, как вы относитесь к Вайберу. Так что все еще зависит от контекста и географии.
А еще в вайбере есть встроенный переводчик сообщений, что порой действительно сподручно
Извиняюсь за некропост, но как в итоге прогресс? Ссылка нынче ведет на 404
На расте писать так же занимательно, как продираться сквозь спойлеры в вашей статье :)
А если серьезно, спасибо за ряд любопытных ссылок и источников — я как раз из разряда тех, которые:
поэтому некотрые материалы схоронил себе на изучение
извините
Если честно, я было начал с "клонировать", но быстро стушевался, потому что когда увидел на русском много слов "клонировать, клонировать", мне показалось, что я сумасшедший ученый, клонирующий людей. Насчет общепринятости в русском языке тоже засомневался, "копировать" выглядело более приемлемым.
В общем, если отвечать на вопрос "в чем проблема?", то скорее всего во мне)
Это видео я тоже смотрел, но решил, что переведу только про
Arc. Так что если у вас есть желание перевести видео про&Option<T>, то я не стою на вашем пути)Но ведь в Rust move-семантика вшита в язык по дефолту. А статья вовсе не про то как замувить, а про то как дешево копировать. Ну и последняя глава как раз про
Box<str>для тех, кто хочет мувитьНо ведь автор упоминает
Здорово) Добавил в вишлист! Приятно видеть, что кто-то довел до конца безумие с рандомной генерацией. А на каком движке разрабатываете?
Я дико извиняюсь, но в моей статье ничего такого, о чем вы говорите, нет. В ней есть только то, что я написал. Ни про три эвристики, ни тем более про алгоритм поиска со звездочкой в ней нет ни слова.
Более того, в статье в Википедии, откуда мое изображение перерисовано, тоже речь идет не про три эвристики и алгоритм *, а только лишь про природу Манхэттенского расстояния, о чем и я вторю своими словами и своими руками (в случае периначенного изображения)
Извиняюсь за недоразумение, подписал изображение во избежание путаницы.
Про "от балды" правда не понял - изображение ровно такое, какое должно быть, и абзацем ниже про него все расписано. И про то, что это Манхэттен; и про то, что пути разные, но расстояние по факту одно и то же - 12 клеток, можете сами посчитать, там 12. Где что чему не соответствует-то? Каким метрикам из статьи?
А, я понял. У подхода есть одна серьезная проблема: не будут поддерживаться дробные числа - C++ не позволит енуму иметь float-значение. А это значит, что, например, два примера из моей статьи -
и 
было бы невозможно построить с помощью такой функции. К тому же консистентность рушится еще и по причине метрики Чебышева, которая вообще 
и надо закреплять за ним какое-то спец-значение.
У меня витала в голове идея подобного рода - ведь я как-то сгенерировал для примеров карты с
и 
? Я эту реализацию писал на GDScript, но если транслировать мой код в C++, то используются две функции, которые можно заоверлоадить. Пример требует С++20 и выше из-за double в качестве non-type template parameter:
Таким образом мы сели ровно на оба стульчика:
Там где можем использовать именные версии, там используем enum. Тут же покрыт неудобный Чебышев;
Для нонейм метрик используем в шаблоне double
Ухх, хорошо разложили, нужно опробовать этот подход, ибо он хотя бы действительно понятный в отличие от того же Форчуна. Кажется, теперь я знаю, чем занять ум в свободное от всего время :)
Спасибо! Вы очень даже правы. В нашей команде есть один существенный минус - геймдизайнеры из нас никакие, поэтому мы страдаем, чем можем :)
А на каком примере из кучи в статье? :)
Если вы про цветастые примеры для одних и тех же десяти точек, то каждая картинка внизу подписана. Разве нет? У меня и в мобильной версии и на ПК видно.
А если конкретно про примеры нашей игры, то я всю статью читателям уши жужжу про Манхэттенскую метрику (
)
Непредсказуемостью жизни) Вон сегодня многие мигрируют с Unity на Godot (самый громкий пример - Road to Vostok), завтра я захочу влететь в новый проект чужой проект со своим движком со своими старыми наработками. Но если наработки будут слишком сильно и специфично завязаны на движок, то влететь-то я захочу, но не смогу.
Так зачем же себя огрничивать в большей степени, чем в меньшей?
Спасибо!
А что кастовать будем? Я вот предпочел просто скатиться "дефолтную" Евклидову метрику, если в функцию скормлена какая-то белиберда.
Поинт про коннекторы действительно хороший. У нас были заготовки для road connector'ов и их было строго ограниченное количество:
под углом 90 градусов
под углом 45 градусов
под углом 180 градусов (крч просто прямая)
Все для того, чтобы четко соответствовать стилистике биомов, которые тоже состоят из строго вертикальных, горизонтальных и диагональных в 45 градусов линий.
И тут то, о чем вы говорите, действительно расцвело бы пышным цветом - POI по идее могли бы быть расставлены только ограниченными конфигурациями в пространстве, и мы бы наверное померли придумывать, как их генерировать.
Так что, пожалуй, вы правы - лучше начать с дороги, а не наоборот.
Оу, был бы рад почитать в комментариях что-то интересное или дополняющее по теме от ваших коллег! Наверняка у них есть свои лайфхаки, секретики и боль по генерации карты, которые можно оставить для потомков