− Скрыть
icelex
> по поводу похож - не похож, то вон куча RPG похожи на диаблу 1 , и что все
> равно хорошо продаются, добавляют новые фичи и тд
Я не только про игровую механику, но и про второстепенные фичи, и про искусственные ограничения. Их тоже зачем-то повторяют. Например:
1. Кому реально сдался этот бесконечный мир? Скажем так: в Майнкрафте знание о бесконечности мира компенсирует в глазах игрока общую однообразность этого мира. Типа «путь пейзажик унылый, но зато он бесконечный, что есть круто». Если отказаться от бесконечности и генерировать просто достаточно большой мир заранее, то у генератора будет гораздо большая свобода манёвра. Можно будет создавать более детализированный сложный/реалистичный ландшафт и декорации. Явно видный шум Перлина уже подзаколебал.
2. Лава. С чего-то взяли, что в игре обязательно должна быть лава. Кто её вообще хоть раз в жизни видел, и почему не нефть, например? Нефть в стеклянной баночке я в школе видел, лаву ― нет.
3. Квадратно-гнездовые деревья. Почему нельзя сделать нормальные, пусть стилизованные деревья, а надо лепить их из блоков? Слишком трудно, лень или потому что так в Майнкрафте?
4. Снова пиксель-арт. Возьмите нормальную текстуру, не тайлите в каждом блоке, а растяните по ширине на несколько блоков ― выглядеть будет охренительно. У Нотча пиксель-арт ― визитная карточка, он ещё на атрибутике зарабатывает. А зачем в клонах этот стиль повторять чуть ли не один в один с точностью до пикселя?
5. Почему бы не сделать нормальную физику, чтобы висящие в воздухе блоки наконец попадали? Или бросил что-нибудь с горы, оно покатилось, упало, ещё покатилось и остановилось. Я знаю, почему: потому что в Майнкрафте нечего бросить с горы, там все предметы ― маленькие квадратные иконки, они не могут кататься. Поэтому у нас физики тоже не будет.
6. Почти все клоны лезут в ММО, чтобы народ мог сообща построить очередного циклопа Церетелли. А недоделанный режим survival, на который Нотч забил болт, никого не интересует, хотя многим игрокам именно он и интересен.
alexzzzzzzzz
ого, спасибо, я такого не заметил. Как странно, почему квадрат всех освещенных пикселей повернут на 45* ? Хотя самые яркие точки - на осях-диагоналях..
Jarro
> Хотя самые яркие точки - на осях-диагоналях..
Не-а. По главным осям яркость света ослабевает как 10-9-8-7-6-5..., а по диагоналям как 10-8-6-4...
Как вы такое изображение получили ? :)
Ну я имел ввиду диагонали квадрата (т.е. то, что и вы), охватывающего часть плоскости с осветленными кубами. Относительно осей x,y он повернут на 45*.
Было б круто если выложили описание алгоритма расчета света.
Jarro
> Как вы такое изображение получили ? :)
> Ну я имел ввиду диагонали квадрата (т.е. то, что и вы), охватывающего часть
> плоскости с осветленными кубами. Относительно осей x,y он повернут на 45*.
Я, похоже, не понимаю, о чём речь.
Вот снова этот факел, снятый в Майнкрафте, вид сверху:
Свет распространяется только по направлениям вдоль главных осей, в данном случае это вверх/вниз, влево/вправо. Чтобы попасть на диагональ, свету надо пройти больший путь, чем при движении просто вдоль осей, поэтому оси получаются светлее, а диагонали темнее.
SCat
> Было б круто если выложили описание алгоритма расчета света.
Там ничего особенного. Есть два типа света: солнечный и искусственный (факелы, костры, лампы и пр.) Заводим два массива (по размеру как массив блоков), которые будут хранить значения освещённости для каждого блока. Первый будем заполнять светом от солнца, второй ― от искусственных источников.
Считаем солнечный свет:
1. Заполняем массив нулями.
2. В каждой колонке идём сверху вниз и заполняем ячейки максимальным значением света (MAX), пока не упрёмся в непрозрачный блок.
3. Ещё раз проходим сверху вниз и у всех ячеек, только что заполненных значением MAX, проверяем их соседей по горизонтали. Если соседняя ячейка прозрачная и её значение освещённости меньше MAX-1, то вписываем туда MAX-1 и проверяем уже её соседей по всем шести направлениям. Если соседняя ячейка прозрачная и её значение освещённости меньше MAX-2, то вписываем туда MAX-2 и проверяем её соседей по всем шести направлениям. Т.е. рекурсивно перемещаемся по соседним ячейкам, с каждым шагом уменьшая значение яркости на единицу, пока не дойдём до нуля.
Считаем искусственный свет:
1. Заполняем массив нулями.
2. В центральную ячейку, в которой стоит источник, заносим яркость этого источника (MAX) и проверяем её соседей по всем шести направлениям. Если соседняя ячейка прозрачная и её значение освещённости меньше MAX-1, то вписываем туда MAX-1 и проверяем уже её соседей по всем шести направлениям. И так далее рекурсивно по тому же принципу, что для солнца.
--
Потом, когда генерируем геометрию, пользуемся этими двумя массивами для определения цветов граней. Например, если мы добавляем в меш верхнюю грань блока с координатами [x, y, z], то её цвет будет определяться значением освещённости из ячейки на один блок выше данного, т.е. элементом [x, y+1, z].
Можно использовать единый массив освещённости и для солнца, и для других источников, но не стоит, потому что со сменой времени суток яркость солнца меняется, а яркость, скажем, факелов, остаётся постоянной. Лучше хранить свет от солнца и от других источников отдельно друг от друга и смешивать только в шейдере. Тогда можно будет менять яркость солнца, не пересчитывая постоянно массивы освещённости и не перестраивая заново меши (в ранних версиях Майнкрафта было видно, как все чанки медленно перестраиваются заново в процессе восхода и заката солнца).
Лично я использую четыре независимых канала освещения: один для солнца и три для RGB-компонент света от других источников. Когда присваиваю цвета вершинам мешей, то RGB-каналы идут в RGB, а солнце идёт вместо альфы. Потом в шейдере их смешиваю.
Вот ещё небольшая темка про освещение: http://blokworld.forumotion.co.uk/t6-lighting-technique
И ещё темка побольше про всё сразу: http://forum.unity3d.com/threads/63149-After-playing-minecraft... (три точки в конце ― это часть ссылки)
Тут ещё была ссылка на блог Sea Of Memes, я его читал. Сложилось впечатление, что чувак делает сам не знает что, первым пришедшим в голову способом. Из полезного нашёл мысли по поводу полупрозрачных блоков (записи 16, 19, 20).
alexzzzz
Супер, спасибо !
Если для хранения блоков использовать отдельный массив блоков для каждого чанка, то при расчёте освещения будут проблемы с обработкой пограничных блоков. Будет много дополнительных проверок на выход за пределы чанка. И при постройке геометрии эти проверки крайних блоков тоже будут нужны. Майнкрафт и большинство клонов хранят блоки именно так, по отдельному массиву в каждом чанке.
Если под блоки завести единый большой массив, то проверки не потребуются. Работать будет быстрее и, самое главное, код станет проще, компактнее и намного читаемее.
--
Ещё один момент, который лучше осознать как можно раньше: считать освещённость можно только для тех чанков, которые уже заполнены блоками, и все соседи которых (в том числе по-диагонали) тоже обязательно уже заполнены блоками. Иначе расчёт выйдет неправильный. И создавать геометрию можно только для тех чанков, для которых уже просчитано освещение, и для соседей которых тоже обязательно уже просчитано освещение. Иначе граничные блоки чанка могут оказаться неправильно освещены.
=A=L=X=
> > Может поможет http://www.sea-of-memes.com/LetsCode1/LetsCode1.html
> Вот сразу от себя уже странное из выстраданного вижу - тут предлагается батчи
> составлять по текстурам. Однако вспоминая крохотные и одинаковые размером
> текстурки майнкрафта сдаётся мне намного более оптимальный способ - сделать
> атлас из квадратных текстур и батч строить один просто манипулируя текстурными
> координатами. Разве не?
Не помню, что там было в блоге, но решая использовать атласы, ты автоматически лишаешься возможности использовать текстуры высокого разрешения. Если чанки делать размером по-горизонтали 32x32 блока, то даже если вообще не батчить, в результате будет сотни три drawcalls. Если игра не для айФона, то вполне терпимо, имхо. Я вообще почти ничего не батчу, технически не могу, и в среднем выходит 250..500 drawcalls и fps в диапазоне 300..500. Компьютер, правда, довольно шустрый, на старых интеловских встроенных «видеокартах» тормозит.
alexzzzz
> Если под блоки завести единый большой массив, то проверки не потребуются.
> Работать будет быстрее и, самое главное, код станет проще, компактнее и намного
> читаемее.
А как же Paging ?
SCat
> А как же Paging ?
Если имеется ввиду загрузка/сохранение чанков, то когда надо чанк сохранить, просто из большого массива копируешь нужную информацию во временный маленький массив (размером под один чанк), отправляешь в фоновый поток и пусть оно там сохраняется на диск. Во время загрузки заполняешь данными с диска временный массив, и когда всё готово, вставляешь его содержимое в большой.
Если имеется ввиду скроллирование единого большого массива при перемещении игрока по миру, то его не надо скроллировать. Нужно сделать его циклическим. Т.е. если есть двумерный массив размером 512x512, то чтобы при попытке обратиться в элементу [512, 520] нас заворачивало на [0, 8]:
Block GetBlock(int wx, int wy, int wz)
{
int x = wx % WIDTH;
int y = wy % HEIGHT;
int z = wz % WIDTH;
return data[x,y,z];
}
Как-то рисовал pdf'ку:
https://skydrive.live.com/redir?resid=D42713A2C49773E7!195
(парсер ― лох)
Я вот тоже задумал свой майнкрафт сделать)
Пока встретились только две проблемы.
1) В каком виде хранить карту.
Как писал alexzzzz можно двумя способами.
для хранения блоков использовать отдельный массив блоков для каждого чанка, то при расчёте освещения будут проблемы с обработкой пограничных блоков. Будет много дополнительных проверок на выход за пределы чанка.
Эти проверки ничего не отнимут. Ибо крайних блоков не много.
Я делаю так: если индекс в пределах чанка, то возвращаю блок, если за пределами, то ищу соседний чанк и из него беру блок.
Конечно пройти циклом по всей карте стало немного сложнее.
Если под блоки завести единый большой массив, то проверки не потребуются. Работать будет быстрее и, самое главное, код станет проще, компактнее и намного читаемее.
Я от этого способа и отказался потому, что код стал не читабельным т.к. приходилось вместе с созданием новых чанков проверять и увеличивать еще массив блоков. И этот массив будет содержать много пустого места и тратить много памяти.
2) когда строишь крайний чанк, то у него по бокам строятся стены. А когда рядом достраиваешь еще соседний чанк, то эта стена скрывается и получается, что ты ее зря построил.
Вроде и не так страшно, но этих не видимых фейсов получается больше, чем видимых фейсов. А ведь на них тратиться время и память( И получается, что строительство новых чанков - дело медленное.
Как тут лучше решить я еще не придумал. Буду рад вашим мнениям.
Конечно, если заранее сгенерировать всю карту, то такой проблемы бы не было.
alexzzzz
> Нужно сделать его циклическим
т.е когда вышли за пределы, выгружаем предыдущий и загружаем новый (где позиция [0, 8]) ?
alexzzzz
> https://skydrive.live.com/redir?resid=D42713A2C49773E7!195
служба не работает (
Тема в архиве.
