Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

А также про ООП, про как заниматься моддингом и его устарелости неустарелости,  кто как его себе представляет и т.д.  В общем, для много слов "обо всем". Что в более специализированные темы не лезет, но поговорить давно хотелось и хочется.

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[Serge! 127]

@Malandrinus, У меня почти на все Ваши тезисы есть мои аргументы. Но, развивать их здесь особого желания нет. Если же у Вас таковое появится, то предлагаю через ЛС.

А то как получается: Я  вам вопрос про конкретные ссылки на вашу же цитату, а Вы мне обратно - "Создаёшь секцию сталкера,..." и т.д. Таким макаром можно гонять "шарик налево - шарик направо" до посинения.

Изменено 4 Сентября 2016 пользователем Serge!

[Malandrinus 611]

 

 

предлагаю через ЛС.

Не хотелось бы уходить от формата публичного обсуждения.

 

 

 

А то как получается: Я вам вопрос про конкретные ссылки на вашу же цитату, а Вы мне обратно - "Создаёшь секцию сталкера,..."

Этого не понял. Я дал вполне конкретный ответ на конкретный вопрос. Я только не понял, какие ссылки нужны. На что ссылки?

[Serge! 127]

@Malandrinus, Разве это не Вы написали: "Сталкеры без скриптовой обвязки полностью работоспособны."? Вот я и попросил ссылку на этот продукт, чтобы самому убедиться в этом. Лично мне, да ещё в Сталкере, это очень сомнительно.

 

 

Не хотелось бы уходить от формата публичного обсуждения.

Как скажите, если сможете гарантировать, что куратор этой темы не даст мне очередной нагоняй за словоблудие. Вы же Личность, а я обычный пользователь со всеми вытекающими из правил форума последствиями. Это, увы, реалии жизни и мне приходится с ними считаться.

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

Murarius, а про что интересно "все это"? Просто для ориентации разговора.

Но, если Вы даёте мне карт-бланш, то как только движок (опять движок) форума позволит мне создать новую публикацию, я постараюсь пройтись по всем 9-ти пунктам моего оппонента.

Изменено 4 Сентября 2016 пользователем Serge!

[Malandrinus 611]

 

 

Разве это не Вы написали: "Сталкеры без скриптовой обвязки полностью работоспособны."? Вот я и попросил ссылку на этот продукт,

"Продукта" нет. Я просто знаю, о чём говорю, поскольку когда-то проделывал подобные эксперименты. Возможно знающие билдоводы назовут билд, где ещё нет скриптов, но присутствует симуляция. Ориентировочно должен быть за 2004 год. Возможно и нет такого в публичном доступе.

 

 

 

чтобы самому убедиться в этом. Лично мне, да ещё в Сталкере, это очень сомнительно.

Я написал, что конкретно надо сделать, чтобы в этом убедиться. Верить мне на слово или нет, дело конечно хозяйское.

 

 

 

за словоблудие.

Это тема специально для словоблудия. Курилка же.

 

 

 

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

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

 

ЗЫ: Куда-то не туда разговор пошёл. Опять про меня. Да что же это такое?!

[Murarius 10 101]

 

 

постараюсь пройтись по всем 9-ти пунктам моего оппонента

Да, будь так любезен. Только без переходов на личности, пожалуйста. А то за тобой, я знаю, не заржавеет.

[CRAZY_STALKER666 36]

Прикольный балаган тут развели . Внесу свою лепту.

 

Когда я только познакомился со Сталкером, и решил что-нибудь да переделать, более-менее серьезные вещи реализовались именно скриптами.

И да они простые и интуитивно понятные. Чего не скажешь об исходниках движка. Понять C++ гораздо сложнее, чем скрипты(лично мне по крайней мере).

Да и выбирая между visual studio и блокнотом для меня выбор был очевиден.

Отсюда делаю вывод - копошиться в движке весело, но с базовыми знаниями языка мало что ты там сделаешь. Я считаю, что Lua - проще.

 

Другое дело оптимизация - нет, вы серьезно? ТЧ прекрасно идет на моем калькуляторе, даже при довольной приличной нагрузке на биндер сталкера.

И никаких проблем. Благо сталкер не surva..um чтобы дико лагать даже на минималках. Вот .

[SkyLoader 53]

 

 

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

Соглашусь, что не нормально. Я думаю, что стОит в движок перенести основные вещи вроде управления анимациями и скриптовые схемы поведения сталкеров, а также логику с пстором, но биндеры оставить. Все-таки не каждый с исходниками работать умеет, а со скриптами работает большее количество человек.

[Dennis_Chikin 3 658]

Вообще-то даже в операционных системах, если они вменяемые, идешь в /src, вносишь желаемые изменения, делаешь make biuldkernel && make installkernel, и получаешь новое ядро. Порою даже перезаппускаться после этого не надо - kldload достаточно.

 

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

 

 

Но, да, для винды, студии, и конкретно сталкера искать легких путей - запрещено религией.

Изменено 4 Сентября 2016 пользователем Dennis_Chikin

[UnLoaded 313]

 

 

Понять C++ гораздо сложнее, чем скрипты(лично мне по крайней мере).

А как по мне, то язык программирования C++ ни чем не сложнее  языка программирования Lua. А ты похоже имел в виду не сложность самого языка, а нехилый объем WinAPI\MFC\DirectX, для которых мелкософт принял C++ в качестве основного языка программирования.

[Malandrinus 611]

биндеры оставить

 

Так и кто возражает? Даже применительно к сюжетным задачам у биндера есть применение: собирать там всякую статистику, регистрировать какие-то события и т.п. Главное, чтобы скрипты оставались в рамках разумного объёма и сложности.

 

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

 

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

 

Ещё по поводу расширений вообще. А кто сказал, что расширения обязательно надо делать на Lua? Примерно похожую архитектуру, с биндерами и прочим, можно реализовать в виде dll-плагинов на C++. Одним из таких плагинов может быть добавление скриптовой модели, потенциально произвольной, т.е. можно добавить Lua, а можно, например, Python. В проекте OpenXRay сделали одно изменение, которое мне очень понравилось, вынесли скриптовый экспорт из методов классов в глобальную функцию. Не знаю, зачем они это сделали, но я вижу это как шаг к тому, чтобы отделить движок от скриптов вообще. При такой архитектуре если нужны скрипты - добавляем нужный плагин и используем, не нужны - не добавляем.

[Карлан 1 049]

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

 

По поводу логики, очевидных подводных камней не так много, и я тоже поддерживаю инициативу перенести хотя бы скрипты серии state_* в движок (я не видел чтобы их когда-то трогали без воздействия на исходники), оставив лишь какую-то возможность дополнять дату, чтобы можно было скриптовать новые анимации. По поводу всего остального, мне кажется тут невероятные объемы, нужно разбираться как все незадействованные схемы работают в движке, и их доделывать попутно линкуя со всем что есть из биндера, ну тут ладно, недолго, но вот сами схемы это конечно тяжело на мой взгляд. А все эти xr_logic, xr_walker это все мишура, надстройки, а кастом дата это вообще ничто, не вижу смысла тратить на это время чтобы в движок унести. Да и перенеся все в движок получается уже сталкерский биндер то и не нужен. Взглянуть можно на ту же реализацию выдачи тайника (скрипты) и трансферинга инфо (движок), ну вот например как это все можно просто сделать, не логика, но принцип околопроходящий. Все эти биндеры их можно упаковать, так как они будут нужны только для ивентов, которые в свою очередь по нашей задумке УЖЕ в движке. Далее покатится мартышкин труд с этими всеми дополнительными универсальными схемами которые пишутся с незапамятных и отлаживаются по сей день, чтобы их подключить их надо будет линковать с теми что уже в движке написаны, и я не думаю что предоставив такую реализацию все люди которые скриптуют логику ринутся ее писать уже на исходниках, так что инструмент линковки какой-никакой придется оставлять. Ну это так, мое поверхностное дилетантское, я в логике то как свинья в цитрусах.

 

По поводу GUI, тут на самом деле я бы вообще весь экспорт зарезал, он попросту не нужен, по поводу выноса в отдельную либу - тут как удобнее, раньше я поддерживал это, но сейчас пообвык и на самом деле уже все равно. Меню - отдельный разговор, как-раз помоему в личке я тебе рассказывал, что там проблемные места есть и в движке, то есть его нужно переделывать в самом движке и уносить все что есть в движок, причем это как-раз не трудно, если начать переделывать все классы которые предполагались разрабами только для меню как я тут уже где-то высказывался. Далее унести все меню в движок. Я оговорюсь, что рассматриваю наш проект на ТЧ, остается только нумпад и параметры стволов, последние это вообще цирк, остается первая, наверное ты прав в предположении, что людям скриптовавшим логику как-то ограниченно давали исходники, так как нумпад абсолютно явно привязан к логике, и на каком-нибудь ActorUse это все успешно зарубается в скриптах и уносится окончательно в движок. Вот тут уже финита, можно вырезать весь экспорт GUI. Делов тут я думаю ну за недельку я думаю определенно можно это все сделать. Далее все упирается просто в кривой интерфейс сохранения, сделайте мне нормальное сохранение и я вам в движке что угодно наверстаю.

 

По поводу статистики, ее в движке также можно прекрасно собрать, там даже удобнее. Посмотри в тот же game_stats, ну кому это и куда? Статистика может понадобится там для отладки геймплея, для античита или чего-то подобного, ну так в движке то куда проще везде все собирать, собираем в массив (с++), потом этот массив когда надо закидываем на стек и дело в шляпе. Пишем все прямо в актора, он в оффлайне не бывает.

[Expropriator 2 118]

Есть ли мысли по внедрению полноценного класса авто, в сетевую игру?  А то я вас не понимаю.

Замечено, что сервер не хочет воспринимать МП актёра внутри авто.

[Dennis_Chikin 3 658]

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

[Expropriator 2 118]

@Dennis_Chikin, а я наоборот вижу этот двиг как раз в открытой, бесплатной, сетевой игре. У этого движка в одно-пользовательских инди-играх нет будущего. Моды да, а игры делать - смыла нет.

[TIGER_VLAD 361]

Раз такая пьянка пошла)) Скину видео по поводу  :

 

 

Еще на

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

Я с этим тоже согласен, что расширять функционал скриптами намного проще.

Изменено 4 Сентября 2016 пользователем TIGER_VLAD

[-StalkMen- 159]

@Дизель,

Сесть в машину в мп - пара строк в коде.

Ну а дальше синхронизацию и прочие потраха пилить.

[Malandrinus 611]

@TIGER_VLAD,

Для начала, что там Ясенев говорит до этого, к скриптам как таковым не относится. Он просто объясняет суть используемого AI, а именно метод GOAP, т.е. планировщиков таких специальных. Далее он действительно говорит о скриптах, но тут не надо забывать, что неявно при этом подразумевается, что движок закрыт. На момент интервью, если я правильно понял, ещё даже ТЧ не вышел. А так всё сказанное в равной степени можно применить к расширению, написанному непосредственно на С++. В целом смысл его речи сводится к тому, что можно написать дополнительную схему, которая по некоему условию перехватит управление уже имеющейся схемы. Внутри движка схемы выстроены по определённым приоритетам, внешние скриптовые аналогично выстроены по приоритетам (и забивают внутренние практически полностью, так что мы их и не видим почти никогда).

 

 

а дальше синхронизацию и прочие потраха пилить

Ну да, самую малость остаётся =)

 

 

а я наоборот вижу этот двиг как раз в открытой, бесплатной, сетевой игре. У этого движка в одно-пользовательских инди-играх нет будущего.

 

Я вижу здесь вилку решений. Можно попытаться сделать из X-Ray сетевой шутер с открытым миром наподобие того же Сурвариума, но тогда придётся пожертвовать сингловыми фичами, в частности монстрами с приличным AI. В подтверждение я напомню, что ребята из Vostok Games только-только выпустили бета-версию с мобами для пострелушек. Это коммерческая контора, с мотивированными опытными разрабами, которые ничем другим не занимаются, и у них после многих лет разработки до монстров ещё даже близко руки не дошли. Так что лучшее, на что может рассчитывать в таком варианте X-Ray - это просто сетевые пострелушки между игроками, ну может удастся когда-нибудь сталкеров запилить.

 

Второй вариант: пожертвовать сетью и всем, что с ней связано. Уменьшить сложность и повысить эффективность движка за счёт этого. Двигать дальше как приемлемый сингловый открытый движок.

 

Это конечно вообще при условии, что X-Ray кому-то ещё нужен.

 

 

По поводу статистики, ее в движке также можно прекрасно собрать

 

Я имел в виду другую статистику. Что-то нужное для сюжета. Техническую разумеется надо собирать внутри движка.

[SkyLoader 53]

 

 

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

Сетевую составляющую в отличии от сингловой надо постоянно поддерживать. Не забываем про читерство, ресинки и про сервера. Любой апдейт античита спустя время снова сойдет на нет из-за новых читов. Один проект работает над "сетевой игрой", этого вполне достаточно.

 

 

 

Второй вариант: пожертвовать сетью и всем, что с ней связано. Уменьшить сложность и повысить эффективность движка за счёт этого. Двигать дальше как приемлемый сингловый открытый движок.

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

 

 

 

Это конечно вообще при условии, что X-Ray кому-то ещё нужен.

Тоже, кстати, один из не маловажных вопросов.

[Malandrinus 611]

 

 

можно ли очередь сообщений обрабатывать в отдельном потоке? Скажем так, некий задел на многопоточность.

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

 

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

 

Другой момент, что на обработчики сетевых сообщений приходится совершенно малая часть нагрузки. Львиная доля приходится на: рендер, шедулер (апдейты, если по простому), вообще обработчики колбека on_frame (одним из которых является и шедулер).

 

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

[-StalkMen- 159]

 

 

вызвать скриптовый колбек одновременно из двух потоков.

Ну а зачем сразу размахиваться на неблокирующие алгоритмы
Асинхронная физика
Асинхронный рендер
Асинхронный поиск пути

не?