Войти
ПрограммированиеФорумОбщее

AngelScript (комментарии) (4 стр)

Страницы: 13 4 5 612 Следующая »
#45
22:26, 3 ноя. 2011

3eR0.1ive
> Правка: Править сообщения не хорошо
Убрал дубль.
Вот сейчас два сообщения подряд от меня. это не хорошо.


#46
22:33, 3 ноя. 2011

@!!ex
О Хоспади! (с)
Уважаемый, вы вообще читаете что я пишу?

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

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

#47
22:35, 3 ноя. 2011

facepalm.jpg
Очень аргументированная дискуссия получилась. :)
Лан, пойду поищу кого нибудь кто имеет практический опыт реализации подобных вещей для продолжения дискуссии, а то тупо как-то.

#48
22:41, 3 ноя. 2011

@!!ex
> Лан, пойду поищу кого нибудь кто имеет практический опыт реализации подобных
> вещей для продолжения дискуссии, а то тупо как-то.
щенок. Извини если обидел суровой реальностью =)

#49
22:45, 3 ноя. 2011

@!!ex
> Очень аргументированная дискуссия получилась. :)
Ну у тебя тоже аргументированно

> Ты не прав. Нет здесь ничего разумного.
И далее кто кому что должен, без скромного IMHO

All
Давайте ближе к теме: AS vs скриптовый язык номер раз.

#50
22:47, 3 ноя. 2011

3eR0.1ive
> щенок.
Вы тоже демонстрируете свой возраст

#51
22:52, 3 ноя. 2011

eagle
> Давайте ближе к теме: AS vs скриптовый язык номер раз.
Подогреваешь)

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

eagle
> Вы тоже демонстрируете свой возраст
Просто мемного погорячился, бывает.

#52
22:58, 3 ноя. 2011

eagle
> Ну у тебя тоже аргументированно
Я привел конкретный пример, привел конкретное решение. Объяснил почему так, а не по другому. Предложил привести другой вариант решения, чтобы сравнить и понять плюсы и минусы обеих. Даже не знаю что можно еще тут было сделать.

#53
23:11, 3 ноя. 2011

@!!ex
MoveTo можно вынести в скрипты, это добавит универсальности. Например, если скриптер захочет чтобы NPC летал.
Ничего не мешает сделать эту прослойку не на уровне нативного кода, а на уровне скриптов. Просто реализовать ее на момент разработки движка и поставлять в уже готовом виде.
Скриптер не увидит разницы, и так и так будет NPC.MoveTo(). Просто в твоем варианте MoveTo - железная реализация, а в моем - на уровне скриптов.

#54
23:19, 3 ноя. 2011

Sam86
Я уже говорил: можно весь код движка вынести в скрипты.
Есть у на спроект, где из-за универсальности через скрипты приходится управлять анимациями, модельками и т.п.
В этой ситуации MoveTo полностью на уровне скриптов реализуется.
Но там движок универсальный. И самое понятие NPC на уровне движка значительно более абстрактное.
ПРи этом у нас есть менее универсальный подход, с MoveTo на уровне движка.

И вот с MoveTo на уровне движка справлялсь девушка моделлер, не программист ни разу. ДОстаточно спокойно делала играбельные сюжеты.
Сейчас универсальные скрипты, с доступам к куче всяких внутренностей. Пишут скрипты программисты, весьма не глупые. Моделлеры туда даже не суются сейчас.
По сути получилось, что мы просто вынесли кусок движка в скрипты: нате, делайте что хотите.
В нормальных, игровых проектах так делать плохо и не нужно. Страшно представить, к чему бы свелись моды к ВарКрафт 3, если бы модеры оперировали не высокоуровневыми сущностями, а задачали детально поведение каждого объекта.

#55
23:30, 3 ноя. 2011

Расскажу негативный пример использования скриптов (LUA). Задача далека от геймдева, но показательна.
Разработали систему моделирования движения БПЛА (самолет такой небольшой). Вся математика и логика системы управления была вынесена в скрипт.
Предполагалось, что заказчику это позволит довольно гибко имитировать различные варианты (обратные связи)
системы управления и передаточные коэффициенты.
По факту оказалось, что у заказчика нет специалистов (или у специалистов нет времени), чтобы разобраться с загадочным названием LUA.
Время и деньги на интеграцию потрачены, заказчик не доволен, переписали на С++ (только не говорите, что это проблема заказчика или согласования ТЗ, в ТЗ была прописана возможность гибкой настройки системы управления)

Основной вопрос: Как определить тот слой, который отделяет нативный код от скрипта? Или перефразируя: У меня есть задача, для ее решения нужен скрипт
или нет? Можно ли выделить характерные признаки, без формализации задачи, когда скрипт даст бонус? Или все индивидуально?

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

#56
23:46, 3 ноя. 2011

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

А насчет "программисты не пожелали изучить инструмент" - это скорее проблема программистов заказчика, а не ваша.

#57
23:58, 3 ноя. 2011

@!!ex
> А насчет "программисты не пожелали изучить инструмент" - это скорее проблема
> программистов заказчика, а не ваша.
Не программисты, а специалисты (по системам управления). Одна из задач скриптов (как я наивно думал) позволить людям далеким от программирования управлять поведением приложения. В моем случае оказалось специалистам проще работать с программистами, чем со скриптами.

#58
0:00, 4 ноя. 2011

eagle
> В моем случае оказалось специалистам проще работать с программистами, чем со скриптами.
Может, просто не состряпали подходящий dsl?

#59
0:23, 4 ноя. 2011

RPGman
> Может, просто не состряпали подходящий dsl?
LUA - серьезный проект с обширной документацией или самопальный синтаксис предметного DSL?
Но основным аргументом было отсутствие конкретных наработок.

Страницы: 13 4 5 612 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.