Проект Lost Lands

[MageNuada]

Sagrer, а у тебя есть какие-то идеи, предложения?) Делись давай.=)

[Sagrer]

Sagrer, а у тебя есть какие-то идеи, предложения?) Делись давай.=)

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

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

не соглашусь насчёт кода и нервов - ибо все потоки можно тупо пустить хоть даже через одну единственную критическую секцию для работы с данными и оно будет работать. Как оно будет тормозить это уже другой вопрос но работать будет, с минимумом кода, просто и понятно. А чтобы организовать это же в одном потоке... я вот такие хрени рисую пачками:
https://plus.google.com/photos/102937512215...304213929589266

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

Более того,  скипты ПЗ - это не сервер. В сингловых скриптах,  как ты прекрасно знаешь, запущены сотни процедур одновременно. В таких условиях затраты на переключение контекстов для такого числа потоков будут огромны.

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

[Demoth]

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

[Bargest]

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

... и тогда мы получим практически тот же однопоточный скрипт: все потоки будут ждать, пока выполняется один поток. При этом запросто можно "забыть" (или не догадаться) обернуть что-то важное в критическую секцию и все будет слетать в прямой зависимости от прогноза погоды на Марсе в каждую 7ю пятницу третьего високосного года. И сиди отлавливай такой баг.
А в случае использования одного потока все тупо и элементарно: создать общую глобальную очередь с таймером и добавлять туда то, что надо выполнить, а в главном цикле просто делать
while (queue.getTop().timer == 0)
{
script.exec(queue.getTop().code);
queue.deQueue();
}
Собственно, ПЗшка примерно так и делает.
Сам интерпретатор там тоже убогий до невозможности и портирование его не должно составлять никаких проблем.

[Sagrer]

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

А в случае использования одного потока все тупо и элементарно: создать общую глобальную очередь с таймером и добавлять туда то, что надо выполнить, а в главном цикле просто делать
while (queue.getTop().timer == 0)
{
script.exec(queue.getTop().code);
queue.deQueue();
}

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

[Bargest]

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

1) Движок работает практически в одном потоке. Другие потоки на движке и скриптах никак не сказываются.
2) Никакие условия ему проверять не надо. Все "условия" проверяются уже на уровне скрипта, когда скрипт оживает после очередного слипа.
3) Все, что ему надо - перед входом в описанный цикл каждую итерацию главного цикла программы (или каждую миллисекунду - не суть) уменьшать у всех в очереди значение timer (или увеличивать глобальное время, после чего сравнивать время в цикле с этой переменной).
Поэтому модель элементарная: Sleep() взводит timer в текущем скрипте, KillScript выносит из очереди. Каждую итерацию ПЗшки по очереди запускаются все скрипты, у которых дотикал таймер. Эти скрипты сами чекают всякие нужные им условия и делают действия. Когда все дотикавшие до нуля скрипты отработали, весь движок пзшки переходит к следующей своей итерации. Всё.

[Sagrer]

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

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

[GetClooSet]

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

Теперь вы знаете секрет обуздания интерации! Ура 3-ое! :lol:

[Bargest]

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

В итоге получится что просто написанный однопоточник получится тоже не сильно скоростным и оптимальным, как и просто написанный многопоточник, а чем больше усложнять тем веселее будет схема взаимодействий )
[right][snapback]41774[/snapback][/right]

Скрипт пз так и делает.
И да, он ни разу не является оптимальным и скоростным, это скорее образец тупейшей реализации скрипта без включения мозга вообще.
А введение многопоточности усложнит систему (тыкать критические секции на каждом шагу), нагрузит систему постоянными переключениями контекста (что само по себе не быстро) и может вызвать неожиданные сторонние эффекты (если нивал затачивал скрипты на строго последовательную работу; и нет гарантий, что ВСЕ скрипты написаны так, что будут работать в многопоточном режиме). Поэтому если цель - подгружать скрипты оригинальной пз, то единственно верне решение - сделать всю логику скрипта в точном соответствии с пзшной. А новые скрипты можно делать на адекватном стандартном движке, как Нуада делает сейчас, если я правильно понял.

[MageNuada]

https://goo.gl/hJ05bO - как когда-то обещал - выкладываю экспортёр анимаций.

[MageNuada]

Изменено описание темы.

[Freeman13]

Заяц за несколько ударов поломал мне все доспехи.

Понимаю, что это демка, но количество багов на 1 мин. игрового времени просто зашкаливает!) Есть ли смысл сообщать о них?

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

[MageNuada]

Да, о багах надо сообщать. О большинстве я знаю, но вдруг что-то упустил.)

[Freeman13]

1. Вылетела игра, когда копался в настройках (по-моему - теней).
2. В настройках стоит "бег по умолчанию", при этом персонаж не всегда бежит по умолчанию.
3. Обнаглевшие зайцы (дают сдачу).
4. Все доспехи ломаются после нескольких тычек.
5. Дошёл до ближайшей указанной точки на карте у Посёлка, засчитался квест, выдался следующий "Удачная охота", дальше не понятно, что делать. Точек на карте нет, описаний миссии нет.
6. В инвентаре у палаша описан урон как "дробящий", а не "рубящий".
7. В окне просмотра персонажа, если его крутить стрелками, то он крутится очень медленно.
8. Сагрил кабанов, так они за мной еле плелись, я ползком мог от них уйти. Даже сначала не понял, что они сагрились.
9. Боевая музыка включается только где-то через минуту после начала боя.
10. И, наконец, когда добил третьего кабана, игра вылетела.

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

[Рицарь]

Вопрос относительно сюжета он будет связан с Ат-Зако?Или же будет другая история не связанная с ним, и что насчет аллодов вы добавите еще 1 какой-то или не будете их трогать, а еще что то в плане механики игры что нового будет?

[Poplanu]

111

Добавил: Poplanu [mergetime]1449943040[/mergetime]
Очень люблю ПЗ и по сюжету и по игровой механике. Мне кажется потенциал игры совершенно не раскрыт. Я хочу помочь вам!!! skype - Poplanu666 можно здась ответить

[sharabdin]

Друзья!!! а почему не на Unity тогда можно было бы играть нетолько на Windows и MAc но и на Linux , очень хотелось бы увидеть порт на Linux

Добавил: sharabdin [mergetime]1450269013[/mergetime]
Кстати ПЗ мне нравится именно игровой механикой а Аллоды атмосферой, я немогу найти не одну игру чтобы было бы как в ПЗ подкрался ударил со спины в голову ,вставил броню из чертежей одного матерьяла ,отбил руку нападающему что тот начал промахиваться, вот что я люблю в ней.

[MageNuada]

Потому что unity - *овно.

З.Ы. Да простит меня Джет за ругательство.

[MageNuada]

Проекту нужна помощь художника/дизайнера уровней(в таком случае должен уметь пользоваться пэинтом и обладать терпением), который знает, что такое карта высот(height map) для террейна. Есть одна небольшая, но интересная задача.