Платформа: fork 188 revision of public repository https://xp-dev.com/svn/xray/trunk Версия: 1.2 Преамбула Прежде чем начать описывать, сразу укажу, что данный материал был готов более чем полгода назад, и, фактически пылился все это время. Очередным консилиумом было решено подчистить хвосты и выложить текущую версию. Наиболее важные участки текста я буду помечать зеленым(важно) или синим(очень важно!) цветом.
Что это? Это рефакторинг-проект, который нацелен на переработку ресурсов игры, в частности и кода. Добавляет множество систем, функций и исправлений. Мы искренне надеемся, что каждый для себя найдет что-то полезное, для этого все и затевалось. Текущая версия проекта представляет собой практически законченную, по нашему мнению, техническую базу, которую мы разрабатываем для себя, и которой мы не против поделится со всеми :). Будем категорически рады увидеть единомышленников. Какова цель проекта? Изначальная идея состояла в том, чтобы вычистить мусор, оптимизировать код и написать все популярные модули и системы по новым правилам с использованием новых возможностей (читай исходников). Сейчас же произошла небольшая коррекция, теперь мы хотим продемонстрировать всем людям, которые еще не перешли на исходники или скептически к ним относятся, тот факт, что не стоит боятся чего-то нового, игра никак не меняется, зато существенно расширяются возможности, можно сказать до бесконечности. Мы пытаемся создать удобный и, что главнее, стабильный инструмент, где не нужно дополнительно возится что-то настраивая или адаптируя. Обобщая, на сегодняшний день готова такая лаконичная платформа для любых разработок, в которую уже интегрирован весь необходимый инструментарий. Исходя из этого, скептически настроенные люди могут просто взять и попробовать что-то создать на этой основе без лишнего ущерба для своего времени. В итоге, если хотя бы у нескольких людей с помощью этого проекта чаша весов склонится в сторону использования исходников, то проект был создан не зря. Каковы промежуточные результаты? На данный момент нам удалось сократить количество скриптов более чем в три раза по сравнению с оригиналом (140(+6) против 441). Переработано большое количество кода, вычищен мусор, оптимизированы многие участки, исправлена масса ошибок, но несмотря на это работы еще очень много. Новых игровых особенностей мы пока не вносили, так как чтобы их создавать нужно отточить рабочую платформу, созданием которой мы сейчас и заняты, а она включает не только системы вроде таймеров, хранилищ, дебагового функционала, но еще и оригинальный код, который относится к сюжету или игровым особенностям. Он также линкуется и перерабатывается с новым стилем скриптового кода. Также мы стараемся постоянно повышать качество скриптового кода, следовать канонам Lua, а также затруднительные участки оптимизировать с помощью движка, чего мы добились - показывают замеры. Также не малую часть работы занимает и переработка конфигов, так как там тоже скопилось достаточное количество мусора, а работать с конфигами очень тяжело. Переработка кода и файлов идет постепенно, в отличии от скриптов, процесс достаточно емкий по времени и требует большого опыта. Почему в файлах две системы событий? Я объясню почему. Все системы, которые присутствуют в проекте написаны своими руками и сторонние системы не использовались, почему? Потому что мы хотим на 100% владеть пониманием тех систем, с которыми работаем, а это возможно только при личной разработке (или более длительному пониманию кода сторонних авторов). Вернемся к событиям. Они введены только для поддержки работы таймеров, разработка под основную систему событий не была завершена и обкатана в свое время, поэтому было принято решение взять ту систему, которая понятна и стабильна, и, самое главное, о которой можно напрямую спросить автора. Наконец, если разработка под основную систему событий будет доделана, то текущее положение вещей будет переделано. В любом случае волноваться не стоит, здесь абсолютно ничего страшного нет. Высока-ли модульность в скриптах? На наш взгляд мы продвинулись до достаточного уровня, чтобы отдельные системы, даже те, которые работают с объектами, можно было безболезненно включать и отключать путем добавления или удаления файлов. С помощью новой системы сохранения появилась абсолютная совместимость сейвов, и все модули (скрипты), в которых предусмотрена опциональность можно удалять в любой момент (а по умолчанию это абсолютно все скрипты), так как их данные хранятся не в net_packet. Более того, система сохранения сама вычистит данные этого модуля, если он был удален безвозвратно(!). Как это? Это значит, что вы этот модуль больше никогда не добавите к скриптам, а если вы хотите удалить какую-то систему лишь на время (но сохранить все ее данные), то и это тоже возможно. Таким образом, например, вам не нравится работа какой-либо опциональной системы (в которой что-либо сохраняется) на определенном этапе игры, у нас вы можете отключить эту систему на время, пройти без ее участия этот этап игры, а затем снова ее активировать, и все ее прежние данные никуда не потеряются. Весь предыдущий опыт комьюнити, вроде изолированного создания какой-то системы под дебагом у нас тоже присутствует. Почему не присутствует обновленный LuaJIT? Любой, кто подключал обновленный LuaJIT сталкивался с проблемами измененного алгоритма работы некоторых lua-функий. Поскольку луа – табличный язык, а проблемы встречаются именно там, то очевидно, что оригинальный сталкерский код не рассчитан на измененную работу функций, и отсюда начинались различные баги. Выход есть, это проверка и корректировка всех скриптов, но сразу заметим, что задача это довольно трудоемкая и мы от ее выполнения отказались. Но(!), я готов дать движок с новым LuaJIT именно для тех, кто захочет этим заняться, и если ваша работа увенчается успехом, то по крайней мере мы своим составом объявим вам благодарность, так как обновленный функционал открывает совершенно новые горизонты (см. документацию LuaJIT). Почему нет документации ко всем системам? Написание документации дело не быстрое, а без гарантий интереса к проекту не видим смысла расписывать принципы работы. В самих скриптах все достаточно подробно и понятно (на наш взгляд) отражено в комментариях. Если к системам проекта будет проявлен интерес, то руководства будут написаны. Какие дополнения есть для диалогов? Начнем, пожалуй, с главного. Мы переделали кеширование диалогов при старте игры, а точнее вырезали его вообще, и теперь любой диалог, любой граф и вся его начинка строится при непосредственном обращении к нему (при юзе персонажа, например), что это дает? Во-первых, с этим исправлением появляется смысл у динамичных диалогов, то есть они становятся действительно динамичными (и если в ветвлениях есть рандом, то он будет отрабатывать постоянно, ранее это было невозможно), а во-вторых появляется возможность строить графы диалогов прямо по ходу игры (даже не перезагружая игру вы можете постоянно перестраивать граф диалога), единственное нужно будет заранее зарегистрировать диалог, регистрация была оставлена для контроля, то есть набор диалогов по-прежнему статичен. Также мы задумались как можно дать функции диалога больше информации, рассматривался парсер и какая-то дополнительная информация. Выбор сделан в пользу второго, так как первое выглядит довольно громоздко, а информацию несет практически туже самую. Итого мы добавили в функции прекондишнов текст фразы, из него можно без труда понять где мы находимся, что сказал персонаж и что нам нужно сделать исходя из этого. В скриптовое получение фразы текст, разумеется, не передается, так как он вам известен заранее. Почему ГГ так быстро устает? (или подобный вопрос) Баланс никак не настраивался, сделаны такие грубые зарубки, из которых в дальнейшем возможно будет сделано что-то интересное. Если вы заметите какие-то сильные перегибы в балансе, то указывайте пожалуйста вкупе с вашим вариантом настройки этих параметров баланса. Корень зла зарыт в переработке различных расчетов прямо в движке, и чтобы эти обновленные формулы заставить качественно работать придется переработать довольно большую часть конфигов, поскольку в коллективе нет тех, кто мог бы этим заниматься, то это действо растянется надолго. Как пользоваться рюкзаком? Смотрите соответствующие видео на канале (ключевое слово - backpack). Под некоторыми видео существует подробное описание, которое ответит на большинство вопросов, остальные можно задать здесь. Стоит сразу предупредить, что данная система имеет ряд некритичных багов, о которых все-же стоит сообщать и вам, так как не исключено, что мы не увидели все недочеты. YouTube-каналы разработчиков (не все материалы относятся к данному проекту): https://www.youtube....Malandrinus2010 https://www.youtube....IuY3d_-LACuMerA Для более полного понимания давайте сразу продемонстрирую главный файл документации по движку:http://pastebin.com/FK0Wc3Nd
Предустановленной игры не требуется. Порядок установки предельно прост, нужно скачать архив с любого предложенного сервера, и далее распаковать его содержимое в любое удобное место. Повторю, никакие сторонние файлы сборке для работы не требуются, в архиве находится самодостаточная игра.
Bug report:
При запуске игры в той папке, куда вы распаковали архив, появится папка userdata/logs, в которой содержатся все логи. При скриптовом вылете обязательно отправлять сейв и лог (описатель ошибки вам подскажет), при движковом вылете прикладывать ко всему еще и минидамп (если таковой имеется). Также регулярно проверяйте папку с логом, и если в файле collect_info.log появится какая-либо информация – отправьте этот файл нам!
Использовать можно всем как угодно. Кто хочет присоединится к разработке - пишите. Каких-то рамок к набору нет, приглашаем всех желающих. Альтернативный вариант - с кем-то объединится. Ссылки: YandexDisk(~2.5Gb)
Проект разрабатывают: C.I.U. (Lua, LUA C API), Nazgool (Lua), Malandrinus (Lua, C++) Я постарался подробно раскрыть суть и идею проекта, но, возможно, я чего-то не учел и у стороннего человека возникнут какие-то вопросы. Я абсолютно спокойно к этому отношусь и постараюсь подробно и доступно ответить на все возникшие вопросы. Будем признательны тем, кто будет искать недочеты в коде, тестировать или просто вносить какие-то свои пожелания по дальнейшему развитию. С большим вниманием будем относится к пожеланиям тех людей, которые будут пробовать что-то мастерить на этой основе, я уверен, с вашей помощью мы ее сделаем только лучше!
Конечно извините, но как это запустить? Написано в шапке что: Предустановленной игры не требуется. Порядок установки предельно прост, нужно скачать архив с любого предложенного сервера, и далее распаковать его содержимое в любое удобное место. Повторю, никакие сторонние файлы сборке для работы не требуются, в архиве находится самодостаточная игра. [08.09.16 02:56:17.482] WARNING: CLocatorAPI::check_for_file not found file d:\prosectors\gamedata\config\system.ltx in files list (size = 27279)
Сообщение отредактировал alex5773 - Четверг, 08.09.2016, 14:39
Странно что написали в шапке Предустановленной игры не требуется. Порядок установки предельно прост, нужно скачать архив с любого предложенного сервера, и далее распаковать его содержимое в любое удобное место. Повторю, никакие сторонние файлы сборке для работы не требуются, в архиве находится самодостаточная игра. Вот это вот действительно странно...
alex5773, на текущий момент (момент релиза) я принял решение изменить политику дропа и разветвить сборку на два направления - игровая и сборка для разработчиков. Архив из шапки является основной массой для обоих этих сборок. Я считаю, что заставлять пользователя два раза выкачивать полный вес мода это не правильно. Далее будут два архива по 200Mb (на текущий момент). На мой взгляд это рационально и прагматично. Именно поэтому тема размещена в "разработках", элементарная логика.
jein, я не Пан Ги Мун и следить за кучей форумов не смогу, в итоге, определенно, останется какой-то один форум, если у проекта не добавится "говорящих голов".
По поводу фризов, это очень объемный и большой вопрос, но спасибо за него. Проблема уходит в фундаментальные принципы работы движка, мы достаточно долго обсуждали эту тему, далее были практические попытки (не сделать это, а хотя бы что-то прокопать в этом направлении, так как повторю, объем работы колоссальный), но по скольку проект разрабатывался закрыто, к какому-то положительному началу это не привело и привести не могло по определению. По избавлению фризов есть один единственно верный путь, но он достаточно долог и тернист (и справедливости ради отмечу, что избавление от фризов это лишь малая часть пользы от этой кампании). Есть конечно и элементарные алгоритмические ошибки как в скриптах, так и в некоторых местах движка которые отягчают проблему, но избавившись от них принципиально ничего не изменится, это все мишура. Эта работа не для троих человек, вот я о чем хочу сказать, а мы стараемся все же ношу по себе брать. Пока я с уверенностью могу сказать, что в данном проекте в долгосрочной перспективе реальной переработки этой части движка не будет, по крайней мере нынешним составом, это просто невозможно.
Конечно на месте. У меня конфиги и скрипты не на месте Их попросту вообще нет Распаковал всё gamedata.db*, а там не оказалось папки конфиг и папки скрипт. Ну и допустим ui_icon_equipment.dds нет в текстурах. Искал именно его, чтоб посмотреть что там. такое ощущение что тут файлы которые не изменялись, а которые изменялись, забыли доложить
alex5773, на текущий момент (момент релиза) я принял решение изменить политику дропа и разветвить сборку на два направления - игровая и сборка для разработчиков. Архив из шапки является основной массой для обоих этих сборок. Я считаю, что заставлять пользователя два раза выкачивать полный вес мода это не правильно. Далее будут два архива по 200Mb (на текущий момент). На мой взгляд это рационально и прагматично. Именно поэтому тема размещена в "разработках", элементарная логика.
Далее будут два архива по 200Mb (на текущий момент).
Правильно ли я понимаю, что эти архивы по 200 мб тоже будут разработкой, и не будут подлежать для игры? Или всё же скачав эти архивы можно будет запустить игру?
Добавлено (08.09.2016, 01:41) --------------------------------------------- Ну будем ждать тогда те недостающие 200 мб.
Проблема уходит в фундаментальные принципы работы движка
Вы имеете ввиду синхронизацию серверной части и клиентской? Так как пока объект находиться в оффлайне он "живёт" только на стороне сервера, а при переходе в онлайн, он должен появиться и у клиента.
ЦитатаCIU ()
По избавлению фризов есть один единственно верный путь, но он достаточно долог и тернист
А попытаться прикрутить костыли? Например отложенный переход в онлайн, если к примеру в радиус а-лайфа попадает 10-ть НПС то спавнить их по одиночке.
Сообщение отредактировал jein - Четверг, 08.09.2016, 02:17
Правильно ли я понимаю, что эти архивы по 200 мб тоже будут разработкой, и не будут подлежать для игры? Или всё же скачав эти архивы можно будет запустить игру?
Неправильно. Это будет полноценная игра но с разным потенциалом, в игроков будут закладываться эксперименты и отключатся дебаг, в разработчиков будет заложена та сборка, на которой работаем мы за исключением полигонов непосредственно каждого из разработчиков.
Цитатаjein ()
Вы имеете ввиду синхронизацию серверной части и клиентской?
Именно! Только здесь уместнее употребить слово рассинхронизация.
Цитатаjein ()
А попытаться прикрутить костыли? Например отложенный переход в онлайн, если к примеру в радиус а-лайфа попадает 10-ть НПС то спавнить их по одиночке.
Как я уже сказал выше - это все мишура. Реальной пользы на самом деле не так много, можете проверить. Ну а дыр здесь можно привести не одну и не две. Самое банальное - возьмите зверюшку и похватайте на апдейте ее разными схемами, мне в свое время уже туториальная плоть показала чем это может закончится. На этот вопрос нужно смотреть несколько шире.
мы хотим продемонстрировать всем людям, которые еще не перешли на исходники или скептически к ним относятся, тот факт, что не стоит боятся чего-то нового
Впервые слышу о такой фобии - использовать исходники движка)) Учитывая также то, что в некоммерческих проектах никаких проблем с этим нет.
Впервые слышу о такой фобии - использовать исходники движка)) Учитывая также то, что в некоммерческих проектах никаких проблем с этим нет.
Тут я к сожалению знаю о чем говорю. Я состоял в команде, которая разрабатывает (по моему до сих пор) мод на 4 патче, когда выложили исходники я потихоньку на них перекочевал, настоятельно рекомендовал лидеру хотя бы попробовать на них поработать, чтобы решить портировать проект на них или нет, на что получил однозначный категорический отказ с невнятными аргументами. Также встречал людей на форумах, где они были крайне скептически к этому настроены, вот тут я и пытаюсь донести уже готовую платформу, где на исходниках реализованы несколько интересных вещей (как демонстрация возможностей) и созданы все необходимые системы, чтобы дать понять что страшного тут ничего нет, и это определенно шаг вперед. Также хочется привлечь людей из других сфер, так как у нас просто на все времени не хватит, а для многих вещей уже заложена реализация, но она связана там с моделями или с чем-то еще, то есть нереализованных идей тоже хватает. Сделать можно очень много интересного даже на ТЧ, но многое закладывается и в другие компоненты, текстуры, модели, анимации, шейдеры и так далее. Я как-то пытался это все подтянуть, но производительность труда невообразимо снизилась, поэтому я решил сконцентрировать все силы только на коде, а будут люди - займемся и другим, не проблема.
SkyLoader, мне не нравится механика оружия в ЗП. Это единственная причина. На ЗП техническая составляющая гораздо лучше, и там действительно новые вещи реализуются немного проще, возможно поэтому на ЗП уже сделали (по части движка) многое из того, до чего на ТЧ еще плыть и плыть. На ЗП у нас тоже есть много практического опыта, там результаты даже по клиент-серверу куда продуктивнее, но это все вовсе не к делу. В обозримом будущем к ЗП проект никакого отношения иметь не будет.
function delete(CTexture*); function find(string); function reload(CTexture*); function get_name(CTexture*); function unload(CTexture*); function cast_texture(lua_State*); function get_surface(); function load(CTexture*); function set_name(CTexture*, string);