crypt of decay [entries|archive|friends|userinfo]
ketmar

[ userinfo | ljr userinfo ]
[ archive | journal archive ]

а почему бы и да? [Jul. 31st, 2019|08:40 pm]
[Tags|]

я тут вспомнил про fake Duke3d-like sprite shadows от Nash, и подумал: а фигле?

подкотэ кортинко )
Link2 meows|meow!

k8vavoom обзавёлся логотипом [Jul. 29th, 2019|10:47 pm]
[Tags|]



спасибо ar888 за это.
Link15 meows|meow!

весёлые новости весёлого вавумчика (нет) [Jul. 28th, 2019|11:59 pm]
[Tags|]

экспериментально перевёл загрузку музыки и звуков полностью в задние потоки. поскольку вавумчик грузит звуки в тот момент, когда надо в первый раз прозвучать, то при HDD и холодном кэше это вполне заметно как нехуёвая такая пауза. теперь, по идее, звук хоть и запоздает, но паузы быть не должно. и с музыкой сделал то же самое. буду надеяться, что я нигде не забыл лочки.

также починил древний, унаследованый ещё от оригинала баг со слопами.

во-первых, на очень крутой слоп нельзя было забраться вообще, даже если он меньше 24 юнитов по высоте. боялся бравый десантник поскользнуться.

а во-вторых, иногда при наличии косых потолков/3дпотолков можно было тупо застрять в пустом месте под ними. потому что высота слопа бралась тупо из некоторых (x,y), и никогда не клампалась по реальной высоте сектора. то есть, если пытаться узнать высоту вне сектора, то она была совершенно кривая. в итоге игра считала, что думгай утыкается в невидимое продолжение косого потолка.

в общем, ходить по косым полам и под косыми потолками стало намного менее больно. в putrifier'е (ma_put), например, теперь даже можно выйти из стартовой трубы. там как раз очень невысокий, но очень крутой слоп. а в honte перестал застревать в коридорах.

также сделал мегахак, чтобы работало говно типа «дадим игроку как пикап RandomSpawner». штука в том, что RandomSpawner не наследник класса inventory, поэтому при попытке провернуть такую штуку движок просто падал (с диагностикой, конечно). запилил хак-проверку, и правильный выбор нормального инвентаря из того, что RandomSpawner предлагает. наверняка, в некоторых местах забыл это проверить, но по крайней мере кластерфак пытается работать, и даже не всегда падает. если бы в «проект дерьмалити» код делали не дегенеративные черви, то он бы тоже заработал (там используется такая штука для оружия).

а также скоро у k8vavoom будет официальное лого, вот!
Link35 meows|meow!

опаньки... [Jul. 6th, 2019|07:10 am]
[Tags|]

нашёл старый-старый баг (красиво посаженый лично мной почти в самом начале ковыряния в коде): ajbsp внутри себя хранит параметры splitting plane для бсп-ноды как интегеры. ойбля.

подробнее: бсп-ноды в думе хранят вершины лайндефа, который был использован для сплита. из этих вершин вавум делает плоскость, которая потом используется при обходе дерева. и всё бы хорошо, но… в оригинальном формате уровня вершины всегда имеют целочисленные координаты. а вот в UDMF координаты могут быть дробными. однако ajbsp всё равно пихает их в инты. после чего вавумчик использует эти округлённые координаты для вычисления коэффициентов уравнения плоскости, и закономерно получает поебень.

штука в том, что standalone ajbsp не умеет в UDMF, поэтому Эндрю не парился. всё остальное там даблы, а конкретно эти координаты нигде не используются всё равно, и смысла их хранить даблом не было. когда я перетаскивал ajbsp внутрь вавумчика, я не обратил внимания. то, что UDMF-карты считаются как пиздец — это я знал. но не врубался, где именно. то, что это от округлений — было ясно, но я читал код, везде даблы — и не понимал. да и вообще я не очень понимал тогда, как работает вавумов рендер.

а сегодня посмотрел внимательно — и ёлы ж ты палы, блядь! быстренько сделал даблами — и херак! UDMF-карты, которые раньше адово глючили, внезапно стали нормально рисоваться и ходиться. заодно там был ещё один мелкобаг с лишним вызовом «чистилки» дерева, которая нужна только для негл-нод. также это, скорее всего, был и источник странных багов с неправильным определением текущего субсектора (оно тоже делается по bsp).

возможно, я ещё что-то проглядел, но уже этот фикс починил овердофига.

также сделал простенькое рихтование полученых вертексов в 16.16 — возможно, это починит рандомные «прострелы» в клипере (а может и нет, хуй знает пока). в принципе, можно и более грубо рихтовать, наверное — но я не уверен.
Link8 meows|meow!

всё, спопсился, отписочка! [Jul. 2nd, 2019|01:10 am]
[Tags|]

привинтил к k8vavoom текстурированую автокарту. теперь совсем отвратительная попса. ну да, можно не включать — но я же знаю, что почти все повключают.
Link19 meows|meow!

let's make automap marks great again! [Jun. 29th, 2019|06:24 pm]
[Tags|]

мне всегда было досадно, что пометки на автокарте в думе неюзабельны почти полностью. по уму, конечно, их надо совсем переделать, чтобы можно было мышой ставить, метки им писать, двигать, сохранять, всё вот такое. но это когда-нибудь потом. а пока я их чуть-чуть улучшил, чтобы хоть как-то можно было пользоваться.

теперь есть кнопка для циклического перебора пометок, выбраную пометку можно удалить, и если не жать дальше кнопку перебора, то для новой метки заюзается то же самый слот. далеко не идеал, но всяко лучше, чем в оригинале.

когда я вернусь обратно к ботам и pathfinding, сделаю «дохуя умный компас», который сможет вести по маршруту до любой пометки.

в таком виде всё ещё херня, конечно, но хотя бы чуть более юзабельная херня.

кстати, надо их сохранять в сэйв. совсем забыл, ща допилю.
Link4 meows|meow!

свежий пятничный билд! [Jun. 28th, 2019|12:39 pm]
[Tags|]

где-то там.

по традиции — рекомендую подождать чуток: в публичных билдах часто вылазят дикие баги, которые каким-то партизанским образом пробираются на борт, и где-то там прячутся до самого отплытия.
Link14 meows|meow!

k8vavoom, хвастовство [Jun. 18th, 2019|01:20 pm]
[Tags|]

есть такая карта — vslyr1. там практически весь свет сделан поинтлайтами. чтобы примерно понять, какая БОЛЬ была в оригинале — запустите в режиме stenciled lighting, и сделайте в консольке «r_advlight_opt_scissor 0 ; gl_enable_depth_bounds 0» (не забудье потом вернуть всё в 1).

конечно, и сейчас там (на моей карте) проседает местами до 40-50 FPS. но 40-50 — это нормально играбельно. в отличие от 10-20 оригинала. особенно после того, как я починил проседание на 40 FPS (на этом конкретном значении игра начинала работать меееееедленно; потому что не надо проёбывать остаток времени на кадр, если он меньше допустимой дельты, а надо собирать в мешочек).
Link12 meows|meow!

кто с виндой — налетай [Jun. 15th, 2019|04:25 am]
[Tags|]

новый public build на думворлде.
Link26 meows|meow!

лёд тронулся, господа присяжные заседатели! [Jun. 15th, 2019|12:04 am]
[Tags|]

всё-таки пересилил себя и начал пилить подсистему профилирования. давно надо было, но ужасно неохота же: нудно это. пока уговаривал себя начать — починил кучку багов и спланировал план запила новой подсистемы полиобъектов. полезно, конечно, но профайлеры сами себя не напишут.

почему не воспользоваться внешним инструментом, и не парить мозг? потому что неудобно и не всегда доступно. кроме того, что я хочу красивые графички в рилтайме, мне нужны профили в виде удобного для обработки файла на диске, иерархическая структура счётчиков, выборочное включение/выключение любого из них (с автоматической обработкой детей), и прочие мелкие приятности. и да — внешний инструмент не всегда доступен; это можно и два раза повторить. обычный игрок не будет париться установкой девтулзов и пересборкой игры с другими флагами, если я попрошу его сделать профиль, чтобы понять, почему у него игра тормозит.

сделал в виде большого кольцевого буфера, куда профайлеры пишут инфу. манагер профайлеров разруливает регистрацию, назначение каждому порядкого номера в буфере и так далее. дёшево, сердито, не надо в начале кадра бегать циклом по всем профайлерам и просить их переинититься, а в конце бегать и собирать с каждого данные.

при запуске ребёнка автоматически запускаются все родители, при стопе ребёнка родители стопятся. конечно, поддерживается рекурсивный старт/стоп, так что если родитель до запуска ребёнка был активен — то и останется активен. таким образом каждый родитель собирает совокупное время работы всех детей, а корневой профилер — время всего кадра.

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

оверхэд на активирование/деактивирование профилера — один поход по указателю и одно условие, если профилинг неактивен. нормально, меня устраивает: это далеко не самый тормозной код в движке.

алсо, надо бы выложить очередной вендобилд перед Началом Великого Внедрежа.
Link2 meows|meow!

сенпай заметил меня! [Jun. 12th, 2019|08:46 am]
[Tags|, ]

поскольку в GPLv2 немного непонятки с тем, можно ли просто взять и апгрейднутся до GPLv3, или обязательно надо спрашивать автора — я на всякий случай и спросил. Янис не против, и вообще вполне доволен тем, что вавумчик подобрали и обогрели. не то чтобы его неодобрение меня остановило, но с одобрением всяко лучше и приятней.


p.s.: поясню. часть «or later» (на которой настаивает rms, и которую выкинул торвальдс, например) явно позволяет апгрейд без испрашивания разрешения у автора оригинала или других контрибуторов. но GPLv2 сформулирована кривовато, и есть мнение, что если не спрашивать согласия, то придётся сохранить «шапку» GPLv2, и после неё довесить «шапку» GPLv3, которая апгрейдит прошлую. а если получить согласие — то можно просто заменить. вот я и спросил — чисто для эстетики, тащемта.
Link44 meows|meow!

весёлые баги [Jun. 7th, 2019|12:19 am]
[Tags|]

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

надо сказать, что вавумчик — представитель племени «настоящего клиент-сервера», где server is The Authorithy. сам по себе клиент никаких действий не делает, даже двери не активирует: всё происходит на сервере, и присылается клиенту в виде обновлений.

поскольку слать обновления всего уровня никакого смысла нет, то вавумчик сначала опеределяет, что видит клиент. делает он это точно тем же алгоритмом, что и обычный рендер. рендер же тоже не обновляет положение вершин и текстуры, пока сегмент не попадает в камеру.

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



отгадка для табуретов типа меня. да, сетевой протокол оптимизирован. то есть, сервер шлёт клиенту что-то только если: 1) сектор видимый, и 2) у сектора что-то изменилось. второе, в нашем случае, несущественно.

теперь ситуация: видимую дверь открыли и убежали. дверь где-то там закрылась, но клиенту об этом никто не сказал, конечно. так и должно быть. потом клиент прибегает посмотреть на дверь. и…

ок, надо всё-таки догадываться, что такое «закрытая дверь» в думе. обычно это сектор, у которого высота потолка равна высоте пола. очевидно, что клипер может использовать этот факт чтобы не рендерить ничего за дверью, когда она закрыта. и использует. также очевидно, что внутренности двери (боковухи и ты пы) при этом не видно. ну, закрыта она, не видно.

всё, догадались? ну да. клиент в последний раз видел дверь открытой. прибежал — она закрыта. то есть, сектор, у которого изменилась высота (сектор двери) не видно. а поэтому никто клиенту его обновления и не посылает. не видно его — чего посылать-то? поэтому клиент видит дверь в том состоянии, в котором видел в последний раз — открытой.

почему клиент через неё пробежать тогда не может, раз она открыта? а потому что server is The Authority. поскольку я писал демку, то там нет никакого latency. и клиент пытается забежать в дверь, посылает серверу об этом инфу, и сразу получает от сервера ответ: «стой на месте, холоп!» (ну, на деле всё чуть проще, потому что при записи демки серверный и клиентский уровни совпадают, глюк видно только при проигрывании).

в общем, при построении карты видимых секторов сервер должен использовать как реальные данные с уровня, так и запомненые, и мержить обе карты. тогда в реальной карте закрытая дверь (её внутренности) не видна, а в запомненой — видна. следовательно, дверь видна, и надо послать апдейт. как только я приделал эту штуку — баг, натурально, пропал.


p.s.: а как же оригинальный вавум работал, не могли же там этого бага не заметить? хм… а там этот баг просто не проявлялся. потому что там был другой баг, в клипере, и из-за ошибок округления клипер почти никогда не клипал закрытые двери. я баг в клипере починил — и всё, чётность багов нарушилась.
Link21 meows|meow!

k8vavoom, новый билд, странные баги [Jun. 5th, 2019|01:56 pm]
[Tags|]

выпинал новый билд на dw. по ходу экспериментов с `traceBox()` обнаружил странный баг: иногда (причины пока непонятны) ajbsp создаёт BSP, которое может привести в ЕБАНОЕ НИКУДА. чего быть не должно в принципе. естественно, охуевают и трэйсер, и рендер. при этом субсекторы созданы правильно. пока что у меня подозрение, что AJBSP (который не был изначально заточен на UDMF) где-то что-то округляет зачем-то. я бы полностью переехал на ZDBSP, но с ним есть другие проблемы.

ладно, как-нибудь да решу.
Linkmeow!

дум и слопы [May. 21st, 2019|03:35 am]
[Tags|]

Кармак очень не зря не стал их делать. вот совершенно не зря. но нет: какой-то тупой мудак решил, что он дохуя умный, и давайте запилим слопы. а они совершенно не работают в думофизике. вообще.

короче, думофизика работает так: бежим строго горизонтально. пизданулись апстену? проверяем изменение высоты. если это ступенька — бежим дальше. если пизданулись башкой об потолок или высоко — всё, отбегались, начинаем слайд по стене.

видите, в чём проблема? ВСЕ перемещения СТРОГО 2д. что работает хуёво, но терпимо для случая axial planes. и тут, блядь, в комнату врывается слоп. который ни горизонтальный, ни вертикальный. что имеем в итоге? а нихуя больше не работает. и если спуск со слопа хуй с ним — тупо бежим вперёд, а там гравитация решает, то подъём — это адский пиздец адского пиздеца. потому что физон или ударяется об слоп, подпрыгивает на пиксель, ударяется, подпрыгивает — и так овердохуя раз (с соответствуюшими тормозами), или трэйс пердолит до стены конца слопа, а потом аналитически высчитываем, на сколько ящик мог подняться, и не застрял ли по дороге.

ладно, казалось бы: аналитическое решение оки-оки, не самое страшное. а вот хуй тут был! в думе НЕТ апи `traceBox()`. вообще нет. попытки ломиться вперёд всегда реально двигают mobj. собирая по дороге предметы, и активируя триггеры. поэтому хуй тебе, а не аналитика: вдруг ты по дороге застрянешь задолго до конца сектора? а всё, уже собрал и активировал. (кстати, баг с «item grabbing» — это вот оно, да, только в меньших масштабах: думчик сначала двигает ящик, потом собирает предметы, а только потом проверяет, не залип ли в стене.)

в общем, вся фигня кое-как решаема, но очень через жопу. к сожалению, просто перейти на 3d движения нельзя: во-первых, структур данных для этого не хватает (что, конечно, решаемо), а во-вторых, это окончательно доломает некоторые карты. и в нулевых — игра больше будет ощущаться думом. ну, не знаю, вот тот самый Дат Фил не такой.

впрочем, у меня есть огромное желание тупо забить на тёплый ламповый датфил. и сделать, блядь, нормально, а не кучей говнохаков.
Link4 meows|meow!

так тестировать новую бегалку интересней [May. 19th, 2019|01:33 am]
[Tags|]

вот так )
Linkmeow!

being a smartass [May. 16th, 2019|03:30 pm]
[Tags|]

потратил день на то, чтобы вспомнить, что микрооптимизации — зло. в третьекваче зачем-то сделали микрооптимизацию для дотпродуктов на axial planes при обходе BSP. ну, оно не особо надо, но раз есть — я и себе упёр. в итоге день пытался понять, почему трэйсер пропускает некоторые стены. ну, немного перестарался, добавив туда от себя потому что.

самое смешное в том, что оно, скорее всего, вообще ничего не оптимайзит. во-первых, таких специфических плоскостей не много, а во-вторых, ещё большой вопрос, что лучше: условие или дотпродукт. и в любом случае для дума того не стоит.

по дороге запилил проверку на «самый высокий пол» тоже через BSP. в оригинале для этого используется блокмап, но у меня в тестовом коде блокмапа тупо нет, а бсп есть. и, в принципе, есть мнение, что с бсп как минимум не хуже. а то и лучше.

забавно: у меня была идея аннигилировать BSP и делать как можно больше всего по блокмапу, а получается, что в итоге я аннигилирую блокмап. ой.

кстати, с новым трэйсером будет иметь смысл выделять полиобъекты в отдельные модельки со своим BSP — как сделано в кваче для всех нестатичных частей уровня. это и удобней, и более гибко в итоге. правда, для вращающихся, возможно, придётся делать какое-то шаманство типа динамических плоскостей-крышек.

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

как полагается, объём пиздеца в коде дума я недооценил — как и объём усилий, нужных для замены этого пиздеца чуть меньшим пиздецом. но пока надежда есть, и процесс движется.
Link3 meows|meow!

всё пилим, и пилим, и пилим [May. 15th, 2019|08:03 am]
[Tags|]

новый `traceBox()` потихоньку начинает становиться похож на настоящий. запилил трэйс по BSP, с корректной обработкой двусторонних проходимых лайндефов (раньше тупо проверял весь уровень — PoC жы). соответственно — теперь мы знаем субсектор, который проверяем, и можно допилить проверки пола/потолка.

трэйсер останавливается перед каждой двусторонней линией, так что можно без проблем проверить на предмет ступенек и прочих нужных вещей. хотя это я потом чуть заоптимайзю: если линия без спешыла, и aabb определённо не ударится об пол/потолок там, то нет смысла у такой линии тормозиться, чтобы потом продолжить с того же места.

почти весь код творчески переработан из q2/q3. спасибо, Кармак.

как и полагается с BSP, проверок мизер: 8-12 нод и 1-3 субсектора из почти 300 на e1m1. в принципе, блокмап тоже можно использовать, но проверок будет значительно больше (и сейчас, кстати, ситуация сильно хуже). поскольку в ближайшем будущем двигающейся не по вертикали геометрии не планируется, то пусть будет BSP. полиобъекты, правда, придётся отдельно проверять, но это фигня: их всё равно надо допиливать нормально.

ещё мне не очень нравится слайд: он тупо летит вдоль плоскости стены. будет красивей, мне кажется, если долететь только до края, и попробовать двигаться дальше в изначальном направлении. чуть сложней и некрасивей в реализации, правда. не уверен, стоит ли оно того: надо подумать.
Link30 meows|meow!

движемся к новому колдету [May. 7th, 2019|06:26 pm]
[Tags|]

идея с beveled bsp оказалась сложнее, чем думалось. штука в том, что в отличие от квачей, где мы бегаем в пустоте, окружённой солидами, в думе всё наоборот: технически мы бегаем в солиде, из которого вырезаны дырки-пустоты. это не особая проблема, но несколько геморройно выворачивать всю логику (и легко таки наебаться).

но! можно зайти с другой стороны. нам, по сути, надо определить время (и сам факт) столкновения axis-algned box и line. для чего можно надуть линию при помощи minkowski sum, и потом просто сделать рэйкаст. звучит страшно? bear with me.

за страшным «надуванием» на самом деле лежит… всё тот же старый добрый алгоритм проверки столкновений ящика и выпуклого мэша, который задан ограничивающими плоскостями. то есть, точно тот самый алгоритм, который используется в кваках (и всех прочих 3д-игрушках) для трассировки ящичков.

потому как — что такое наша линия? это дегенерировавший выпуклый мэш! он ограничен шестью плоскостями (четырьмя для линий, параллельных осям координат). поскольку линия у нас бесконечная по высоте, то достаточно создать две плоскости для самой линии, две вертикальных плоскости для ограничения линии справа и слева, и ещё две горизонтальных для верха и низа (если смотреть на линию сверху, как мы видим автомап; очевидно, что z top и z bottom плоскости не нужны, потому что мы никогда не сможем об них удариться). всё, у нас готов объём, который можно скормить совершенно стандартному алгоритму. и этот объём можно «надуть», чтобы «сдуть» ящик в точку. проблема решена.

почему так, а не более классическим путешествием по bsp, с проверкой листьев? ну, в принципе разница небольшая (санс «вывернутая логика», см. выше), но у нас, вообще-то, 2д чертёж. который вдобавок разложен в блокмапе. то есть, мы можем собирать линии и предметы одновременно, тупо шагая по блокмапу, и проверяя столкновения со всем собраным. тем более, что предметы отлично обрабатываются точно тем же алгоритмом, потому что это всё те же самые шесть плоскостей. и 3д-полы тоже, потому что… да-да, те же самые шесть плоскостей. и обычные полы с потолками, потому что… опять две ограничивающие плоскости. и всё это отлично работает для 3д-пути, хотя карта и 2д. и ещё у нас есть нормаль точки столкновения, так что можно сделать слайд. да, имеем небольшой оверхэд, но зато единообразный код для всего (одна функция свипа), и никаких дополнительных данных хранить не надо (все нужные плоскости игра уже посчитала и использует в других местах, а недостающие — тупо axis-aligned, и создаются даже без дот-продукта).

на самом деле это открывает и другие интересные возможности. например, проверка столкновений с md2/md3 моделями не просто по bounding box, а по их конкретной форме (строим для них бсп при загрузке, докидывем axial planes — бинго!), полиобъекты любой сложности и ориентации, в том числе ограниченые сверху и снизу, автоматическая обработка слопов… и всё это одним и тем же кодом. ну не прелесть ли?

ах, да. вращающиеся/движущиеся полидвери и прочие сложные штуки, которые должны отталкивать игрока — это снова таки всё тот же код. нам без разницы, считать ли время до столкновения, или минимально необходимое усилие для выталкивания одного объекта из другого: алгоритм может посчитать и это.

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

а ещё трэйсер отлично пригодится в создании navigational meshes для ботов: наконец-то можно будет надёжно определить, можно ли из одной точки субсектора попасть в другую. можно делать сложно, но можно и просто: каждый субсектор — нода. проверяем, можно ли (с учётом слайдов и прыжков) дойти из центра одного субсектора до центра другого — и вуаля: готова инфа по проходимости., даже с примерной оценкой стоимости. потом a-star, твики навигации — опа, вполне разумно бегающие боты без вручную расставленых вэйпоинтов.

тут очень кстати «вывернутая логика» дума: в ку3 приходилось делать сложные вычисления, чтобы построить карту «пустот», а в думе субсекторы уже предоставляют эту карту, и каждый субсектор гарантировано выпуклый. are we cool yet? ain't it cool?
Link6 meows|meow!

пока часы двенадцать бьют... [Apr. 30th, 2019|08:02 am]
[Tags|]

ну, не двенадцать, четверо только. и не часы, а боты. а так-то всё ок.

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

в движке, оказывается, наглухо нет функции: «а можно ли пройти из точки а в точку б?» только куча говнокода (ещё от кармака осталась), которая, собственно, идёт. и то частично — волл слайд надо потом делать отдельно. что не очень помогает в построении вэйпоинтов, должен сказать.

то есть, боты всё ещё выглядят как пьяная поняша, которая пытается прискакать первой в заезде «формула 1», но теперь это одноглазая поняша, а не слепая. правда, всё равно без мозгов.
Link18 meows|meow!

карты, карты, карты, стволы [Apr. 19th, 2019|12:46 am]
[Tags|, ]

скриншотики
подкотэ )
Link5 meows|meow!

navigation
[ viewing | 40 entries back ]
[ go | earlier/later ]