Штатуш апдейт

Пока выдалась по-странному свободная минутка, хочу рассказать про большой фейл с управлением приоритетами. Дело в том, что эта фигня с кубическим изменяющимя миром, похоже, вызвала у меня страшную зависимость, и мне хочется без остановки писать код. В связи с чем появились, похоже, проблемы со всем остальным, отклонения от привычных распорядков и это, в свою очередь, вызывает стресс. Не делайте так. Следуйте планам, ибо ущерб всей другой деятельности рано или поздно начинает сказываться в виде давления на психику, раздражения, депрессии.
Хотя, конечно, как некоторые говорят, это приносит дополнительный опыт, связанный с программированием и геймдевом, это не повод бросать другие проекты. Да и, к тому же, если бы у меня действительно получалось все писать в том темпе, в котором хочется, наверняка все было иначе. Но пока что у меня все перешло, сначала, к безудержному рефакторингу всего, разбиванию на кучу модулей, написание "инфраструктуры" для загрузки и запуска всего и, конечно, в этом всем немало багов появляется, которые не всегда удается быстро и легко вылавливать.
Чтобы решить проблему забрасывания всего остального, пришлось для этого проекта выделить отдельный контекст, чтобы не было лишнего соблазна вместо других вещей заниматься только этой.
В общем, на прошлой неделе я забросил почти все кроме работы и всякой самоучебы и до поздней ночи писал, отлаживал и опять писал. Чем все кончилось, я уже немного открыл в предыдущем посте. С тех пор изменилось мало, единственное, что я начал делать - все-таки добавил блокам понятия "фазового состояния", то есть "пустой, газ, жидкость или твердый", перешел в три измерения, удивился, как все стало намного медленнее из-за 3D. То есть, я уже по-настоящему перешел, со всеми вытекающими в виде увеличения числа итераций по блокам на глубину мира. Здесь, конечно, возник вопрос "что считать глубиной" и вообще, как сделать из такого параметра как "радиус" эту глубину, да так, чтобы мир оставался в виде куба из кубов, а не из параллелепипедов (для удобства). Лучшим решением, как мне показалось, будет вообще забить на "радиус" на этапе выделения блоков и просто считать все за пределами твердой части и атмосферы "пустым". Тем более что радиус, конечно же, намного меньше, чем половина длины окружности, и кроме него в нее укладывается и высота условного верхнего слоя "атмосферы", что лежит в районе линии Кармана, которая находится очень близко над поверхностью, если сравнить с радиусом самой планеты. А чтобы по пустым местам серверу не тикать, просто знать, что там ничего нет и не делать этого.
Конечно, в таком представлении сферического тела как параллелепипеда есть недостатки, но ими можно просто пренебречь для простоты (все-таки это не симулятор). Первый недостаток в том, что нарезка после развертки делает блоки растянутыми у центра шара и "сжатыми" у его краев. То есть, кубометр блока вмещает только долю кубометра реального шара, если говорить о чем-то возле центра планеты, и наоборот, если посмотреть где-то далеко от него.

Также пошла работа над клиент-серверным протоколом, и задуманная изначально модульность (то есть, возможность что-то выключить или добавить путем простого подкидывания файла с кодом), конечно, сразу потребовала синхронизации информации о том, что есть у сервера и клиента, так что на это тоже ушли часы работы. Зато я ожидаю упрощение процесса разработки в будущем, так как вместо ковыряния достаточно малого по объему кода сервера или клиента все ограничится только написанием очередного модуля, который будет дергаться клиентом, сервером, генератором мира и чем угодно еще, если оно требуется, и, конечно, содержать ресурсы вроде текстур. То есть, это возможность делать моды прямо из коробки.

Насчет того, почему блоков захотелось добавить пустых, в виде газов, жидкостей и твердого - сначала мне показалось, что было бы неплохо все-таки поиграть с возможностью плавить и испарять все что угодно, со всеми вытекающими интересностями, вроде того, что вода должна бы таять и замерзать не потому что это "холодный биом", а потому что холодно. Но, конечно, блок не должен, по-идее, сразу переходить весь в какое-то состояние (моментальное испарение на солнце кубометра воды? не, вы чо!), и об этом еще предстоит размышление. Для чего это нужно? Ну хотя-бы чтобы поиграться с настоящим "круговоротом воды", когда она появляется в атмосфере в результате нагрева водоемов, а потом выпадает в виде осадков. Правда, для этого нужна еще одна "фича" в виде состава блока. То есть, воздух это воздух, а не водяной пар, поэтому кроме обычного "воздуха" там должна быть вода, и должна пониматься такая вещь как относительная "влажность". Хотя, скорее, это должно было бы быть какое-то более широкое понятие, которое бы позволяло делать это с любым веществом (и можно было бы варить самогонку в гигантском самогонном аппарате). Но это вызывает одну опасность - стоит просто представить, сколько места в памяти и на диске может занимать один блок, у которого так много аттрибутов. И сколько времени может занимать итерация по ним. И чтобы экономить, нужно будет очень сильно снижать точность вычислений и хранимых значений. Но все-таки "химический состав блока" весьма интересная возможность, особенно если это игра про шахты и копание. Я говорю про ухудшение воздуха в замкнутых пространствах и возможность там тупо задохнуться, и эта возможность весьма важна. Да и грунтовые воды должны быть, все-таки, не в виде вкраплений наполненных водой пещер, а вытекать прямо из не слишком плотных стен. Наверное. Хотя до них еще нужно кучу всего понаписать.

В общем, похоже, нельзя считать блоки только твердыми или только жидкими. В твердых блоках может быть жидкость и она оттуда может вытечь или испариться. В атмосфере может быть водяной пар. В воде может растворяться воздух. Так что, в будущем, похоже придется вместо твердости или жидкости пойти в сторону просто "состава блока", имея в виду наличие нескольких компонентов в разном фазовом состоянии. А рендерить и извлекать основную часть поведения уже от того компонента, который преобладает. Попутно, конечно, подумав, как эти данные хранить компактно, не выделяя под каждый компонент кучу байт.
Да, еще "твердость", она же может быть разной. Это может быть цельный плотный кусок чего-то, а ведь еще "твердыми" свойствами может обладать какая-нибудь щебенка или песок. У такого рода вещей, конечно, свои особенности поведения должны быть. Не так как в Майнкрафте "должно падать вниз", а несколько более продвинуто, потому что, все-таки, мне бы хотелось подумать, как сделать так, чтобы падать вниз должно было все что угодно (и тут должны поныть любители парящих в воздухе островов). В общем, в будущем предстоит раздумье, как эффективно впихнуть в один блок все его свойства и особенности поведения. А потом - как быть и с рукотворными блоками тоже.

Но, надо двигаться постепенно, ведь это прототип. Что-то постоянно меняется и переделывается, выкидывается. Не пойдет такой подход - буду искать другой. Но количество хотелок, конечно, зашкаливает. Обычно это плохо кончается, судя по опыту летсплеев. :)