Comments 15
столкнулся как то с тем, что у многих фкнкций, здоровье и т.п. изменения типа минмакс. т.е. мы всегда присваиваем. вне зависимости поменялось значение или нет. и все варианты отладки в тулсете плохо подходят. нужны кондишенейбл бряки, что в коде.
значит такие программисты писали
это функции. функция это то что всегда возвращает рузультат. описываются декларативно и не программистами. например функции minmax, clamp, lerp и все такое. програмисты не пишут абилки, эффекты и функции изменения параметров статов сущностей.
Это нормальная практика, использовть одну строку, вместо 5 строк if/else.
Тут другой вопрос, почему переменныке не обернули в getter/setter, который скипнет модификацию, если значение не поменялось.
А еще на setter можно брекпоинт поставить и логи в нем напечатать.
Современные дебагеры могут на breakpoint ставить свою проверку и свой скрипт. Т.е. зачастую можно отследить, менялось ли значение, не влезая в код самой проги (актуально, когда перекомпиляция или повторный запуск занимает много времени и требует усилий... Если писать юнит–тесты – надобность в этом сильно уменьшается).
логировать - состояние, статусы, если рпг система все получения еффектов, и наверно чтобы была возможность отключать еффекты
есть еще приколы, помимо поиска пути есть еще высота(она частично физика тоесть коллизия с террейном, тут тоже логировать наверно)
тоесть вы наверно о том случае кто именно отнял здоровье во время Н, при состоянии и статусе П
там же касания могут быть по обьему, в случае получения урона от абилки, еще нюанс, как происходит выбор цели, в одном случае в лог попадает выбранная цель и если игрок наносит урон цели, цель включает состояния,берет в таргет игрока - лог, урон получается -лог, когда детектится или нет урон-лог, смотря какая система - рпг или нет
а если игрок не выбирает, а сразу пускает луч, ну тоже самое таргет, урон, цель взяла в таргет игрока, пустила урон
тоесть нужна система логирования
система боя - потомучто если будет больше 1 нанесения урона надо по очереди наверно их обрабатывать, потом надо как-то убегать тоесть отводить/завершать бой, в том числе и абилками(абилки тоже система)
тоесть это общение обьектов в зависимости от их состояний при взаимодействии
тоесть должна быть приписка по получению урона, урона бывает разный от луча или по истечению времени луч, или физическое касание, но если физическое касание у обьекта, который летит от которого будет получен урон, есть обьект, который изменил своё состояние из-за взаимодействия, соотв по лучу видно обьект такой-то, статусы такие-то завершения нету, значит они покачто взаимодействуют
это конечные автоматы, луч или обьект это как передатчик сообщения для взаимодействия
хорошо более наглядный пример, при прыжке(или при появлении задали высоту 1000 юнитов) кто отнимает высоту у обьекта при падении до уровня высоты
и второй случай, в графе, в мире -+- +++, при нахождении пути мы опираемся на высоту найденную или произойдёт фикс высоты при опр случаях, в идеале граф хранит высоту, но нужна корректировка например будет
и следующий пример при переходе из карты в карту пещеры, там поидее теже ситуации
Статья - роскошь!
у движка должно быть отделено, что движок(вот например как блендере есть отделение и раздел конфигураций, можно и через lua того же добиться(1)), а что запущено аля плейгроунд(редактирование IDE в игре визуальный с возможностью сохранения конфигурации на основе версии движка), имгуй - надо заменить на свой интерфейс плейграунда, тоесть это тестовый билд как раз, есть еще gdb -help, lldb -help
вот ваш код для дебагинга это функционал той части того плейграунда специального
чтобы дизасемблировать свой же код можно просто скомпилировать с флагом -S
1-это нужно для того, чтобы дебажить то что на выбранном уровне и только из этих обьектов, зачем например дебажить отрисовку и всю низкую ситуацию, а это приводит к дебагу типа данных и его состояний только и всего (тоесть это уже движок с каким-нибудь lua rtti)
Я правильно понял что Вы описываете систему, где движок и "плейграунд" (редактор на базе движка) разделены по слоям, с возможностью отладки через gdb/lldb, кастомным интерфейсом вместо ImGui, и использованием Lua для настройки и рефлексии — то есть речь о модульной архитектуре с возможностью сериализации отдельных компонентов? В теории всё верно, на практике зависит от того как развивался движок
да, только это проще можно сделать чем в той таблице какую вы показывали - там всё переусложнено
вот движок варкрафта даёт интерфейс lua
получается дебаг почти в игре в процессе прям
пример блендера, дизайнер не имеет доступ к отрисовке, к апи, он имеет доступ только к УГО и дебажит по своему
тоесть поставили свет, террейн, сказали прилепай, далее поставили камеру, нажали кнопку произошел конфиг, я так себе представляю, и далее при запуске от конфига запустилась сцена, которую выставил дизайнер, и при сейве произошла подготовка манифеста грубо говоря(тоесть альфа билд)
rttr что-то этим можно сделать, что-то от lua получается
А можно переформулировать этот текст? К сожалению, я ничего не понял :(
ну дизайнер не должен иметь доступ к апи отрисовки, он имеет доступ только к компонентам образно, подготовленным в движке или зарегестрированными самим дизайнером
тоесть вопрос как проверить функционал портала? лезть в дебагер если можно в игре проверить на манекене
поэтому мы делаем ту вьюшку окно(пример UCR1lHrfxY01XYSoVJJAi-xQ) и прочее, манифест это просто манифестация записи конфигурации и компановка обьектов в образе, тоесть внешний клиент для запуска
манифест это простейшая компановка образа по типу как в яве, есть и лучше подходы, если формат у студии свой имеется
За статью спасибо! Как-то раньше не задумывался как это реализовано, хотя буквально на прошлом курсе ВУЗа про регистры отладки в учебнике сказано было только, что они есть и сколько их))
P.S. не сочтите за тошноту - "страндартному" (чуть-чуть ошибка)
Тут возможно два варианта
А первый вариант как то реализуется без Trap Flag?
Сам себе breakpoint