XimikS, я не состою в команде разработчиков, так что все вышесказанное это исключительно мое
личное мнение, а CLR тут никаким боком не упал (уж лучше Java тогда - благо поддержку огра в
сети для нее где-то видел)

MOGRE и OgreDotNet

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

я и не говорил про машинный =О у clr есть IL, тот самый "внутренний ассемблероподобный язык". Хотя возможно, я тут не особо вшарил)

XimikS, мы же не можем взять виртуальную машину Microsoft .Net. Она для наших целей не подойдет, а писать свою для чужого языка тяжелее.

Зачем эти ограничения? Почему просто не оставить это на совести мапмейкера? Сделал 2гб карту, захостил, человек заходит, видит, что 2гб - ливает. Проблема автора. То же самое и с игроками, если ты сделал аос 32х32 игрока, в которую играть нормально можно только от 20х20, т.к. огромные размер карты обязывает, то это проблема тоже автора.

По поводу скрипт-языка для карт: все-таки я за Jass + vJass.. возможен вариант с оптимизацией - vJass родной ООП для карт, а Jass для совместимости, так же как любой другой - переводится в vJass.. чтобы поддержка ООП была родной, а не изворотами транслятора (как щас сделано в JNGP).. тогда существующие исходники карт будут пахать без изменения, а новые тоже в таком же духе писать, но скорость по-выше... хотя всеравно это дело надо транслировать в байт-код - опять таки как сделать чтобы байт-код был изначально ООП? Опять извороты какие-то, в результате все равно код превратиться в набор ассемблероподобных конструкций.. Если без трансляции, интрепретировать налету - тут уж тоже не выйдет ООП сделать родным.. Разьве только на Сpp писать карты и запускать их выполнение за счет либы рунтайма)) А че это идея - код пишем на любом ООП языке (например vJass), при загрузке карты двиг транслирует это дело в Сpp потом собирает DLL, подгружает ее и запускает уже машинный код на выполнение.. Безопасность можно обеспечить т.к. код пишется на нашем языке и ограничены конструкции, а на выходе Сpp только безопасные нами написанные правила перевода)) Вобщем я считаю это возможным вариантом ускорения работы карт, загружатся они будут дольше т.к. надо нашу карту открыть, оттранслировать в Сpp силами движка, собрать DLL силами транслятора и линкера открытого, подгрузить DLL, настроить все.. подготовка долгая, но во время работы будет нативный код машины выполняться не виртуальной! а нашего компа.

Как идея? Предлагаю прикинуть и написать тестовую прогу транслирующую vJass в C++ (по сути там мало что переводить надо), а потом собирающую из нее DLL.. замерить время (на любой карте с открытым исходником) и тогда решить включать такую штуку в двиг или нет

Получается надо делать jass машину и еще компилятор встроенный. Получаются даже не карты а эдак мини плагины.

NCrashed добавил:
возможно даже это выход

NCrashed добавил:
Alex_Hell, хм, можешь собрать информацию о открытых компиляторах, линкерах для этих целей?

NCrashed, нафига Jass машина? Я говорю транслятор vJass >> Cpp писать нам, там простая таблица замены одной конструкции vJass на Cpp... аллокации ресурсов, создание объектов и т.д. все ложится на плечи движка в любом случае.. Cpp >> DLL открытый взять.. DLL взаимодействует с двигом.. Работы тут не больше чем полностью виртуальную машину написать.. Хотя вирт медленнее, а тут нативный код.

Вобщем я напишу на днях прогу трансляции vJass >> Cpp, заюзаю MS транслятор + линкер для перевода в DLL, замерю время.. Потом поищу открытые трансляторы Cpp

Alex_Hell, если получится, будет прекрасно

То что касается плагинов для ввода нативок - не убедил.. Основные структуры данных типа списков динамических, очередей, деревьев поиска и т.д. а также алгоритмы сортировки, поиска и т.д. реализовать в движке надо, этого будет достаточно для многих карт.. Если что-то свое захочется сделать - на основе все тех же структур данных и алгоритмов можно сделать другие, тот же самый список с пропусками на ссылке реализуется масивом списков + алгоритмы работы с ним.. И тут опять же скорость будет больше т.к. мапмейкер напишет эту структуру данных а она оттранслируется в Cpp, а не интерпретировать будет - вот тебе и выход.. никакие нативки внедрять не надо, все только силами движка.. хотя надо подумать, возможно всетаки дать возможность писать плагины на специальном языке, с ограниченным набором конструкций, но ни как не давать DLL в виде плагина)) Плагин опять таки будет оттранслирован в DLL только на машине конечного юзера и сохранится там, а распространяться только в виде исходника

Ок, для карт это подходит, компиляция будет недолгой, но компиляция плагинов может затянутся (тот же mpq плагин компилится около минуты). Для плагинов зачем спец. язык? Можно распространять и C++ код, а потом компилить его.
Нативки. Сторонний плагин добавляет, например новый инвертарь с новыми объектами. Для работы с этим инвертарем нужны новые функции, если не делать их нативками, то нужна возможность вызова функций из плагинов (что по сути все равно нативка).

NCrashed добавил:
Многие плагины будут юзать же не только stdlib, iostream, т.е. придется таскать все зависимости с собой.

NCrashed, когда нам расскажут о физике которую вы планируете сделать в движке и какие аниммации понадобятся в моделях для этого?

12ого

NCrashed:

Можно сделать так: если у игрока нету карты, то он не заходит в комнату, а открывается окошко, предлагающее скачать карту (там и размер и список плагинов показывается) из этого окошка карта скачивается С САЙТА (никак не с хоста =) ), а потом происходит коннект к руме.

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

Alex_Hell добавил:
Плагины действительно могут долго компилиться, но это единовременная операция.. ну подождет юзер некоторое время.. возможно в фоновом режиме поставить с низким приоритетом процесса.. На счет спец. языка плагинов - чисто безопасность.. Хотя может и не надо, а дать возможность писать уже на Сpp с использованием определенных интерфейсов, но опять же распространять в виде исходника, а не DLL надо.. и опять же перед компиляцией надо проверить все ли правильно разраб в этом плагине написал и не написал ли чего лишнего (формат винта) ))) тоесть опять же это равноценно своему формату файла.. не чистый Сpp а его подмножество - точнее тока его синтаксис с нашими функциями (методами)

Alex_Hell добавил:
Что касается примера с инвентарем - не вижу смысла там писать нативки.. Как уже сказали возможность создания своего интерфейса пользователя должна быть вшита в движок.. Юзер в визуальном редакторе натаскивает кнопки, окошки, вешает на них события, вызывающие наши скрипт-функции.. Все это дело сохраняется в XML-подобный файл в карту, в скрипте карты пишем эту функции обработчики событий (нажатия мыши, наведение мыши) и вызываем опять же встроенные нативки создания на экране текста с описанием, изменением картинки в области экрана (нашем кустомном эжлементе управления)..

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

прикрутить битторрент протокол для передачи файлов достаточно просто на самом деле

Jass -> C++ ->DLL это мягко говоря извращение, хотя идея достаточно оригинальная

дать возможность писать код карты на С++ это провально и смертельно с точки зрения безопасности, в каком бы виде ни распространялись исходники

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

prog, на счет безопасности все уже написали: пишем на vJass (я предложил) скрипт карты, он транслируется в Сpp по строгим правилам.. Плагины (если будут) на Сpp подобном языке, но позволяющем вызывать ограниченное кол-во функций (методов) т.е. если в файле чтото не то - оно не скомпилируется.. политика - разрешено только то что явно разрешено, тоесть список разрешенных конструкций будет проверяться.. Могу на спор, когда напишу прогу трансляции, ты попробуешь туда вставить любую некорректную конструкцию и ниче не скомпилится.. Тоесть если внимательно прочитать и подумать о написанном ранее ты поймеш, что от Cpp тут только название, Cpp идентичен vJass, Java и чему угодно другому, немного с различным синтаксисом.. Но функционал ведь не Cpp шный а именно нашего движка

Насчет плагинов предлагаю делать через DLL с помощью интерфейсов, через которые можно бы было получать информацию об игровых объектах. Вообще любой плгин, не зависимо где он используется всегда устанавливается на страх и риск пользователя. Разве в других программах нельзя написать плагин-троян или кейлогер. К тому же RtC или JNPG?

alexprey добавил:
Alex_Hell:

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

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

alexprey, вот для безопасности я и предложил не DLL юзать, а исходниками распространять плагины.. В DLL чето можно вставить не безопасное, а в исходник уже ничего лишнего не вставишь, потому что он не выполняется, он проверяется и транслируется в DLL..
А если DLL то тут же появятся одни трояны)) вседозволенность == провал, ограниченность != провал

Тем более каким образом КПД упадет? Хоть ты пишешь исходник он преобразуется в DLL, хоть ты сразу DLL-плагин распространяешь - результат одинаковый, но безопасности больше..

Вот пример плагина, которому необходимо добавлять нативки. От главного типа handle наследуется и создается класс камеры наблюдения, состоящий из двух частей: камера и поверхность (модель и что то еще) на которую будет идти рендеринг картинки с камеры. Как тут обойтись одними только скриптами и без функций Огра?
Другой пример, плагин для работы с изоповерхностями, составляющиеся по трехмерной карте (для жидкостей нужно например). Тут мало того, что нужно юзать огр, но и шейдер надо подключить. А как маперу создать лужу воды, с нативкой намного проще.
Еще пример, плагин, дающий возможность динамически изменять геометрию моделей (делать вмятины на броне).

Как маперу кроме нативок дать доступ к этим плагинам?

Еще для всех таких плагинов нужен довольно широкий доступ к движку и для их компиляции нужны какие либо сторонние библиотеки. Это будет как в текущей индустрии опен сорса: скачал систему, так, а для нее нужно выкачать такие такие то зависимости, а то не скомпилится, причем не все они нужны для конечного dll.

А как ты собираешь ограничивать??? Указывая дозволенные функции или наоборот запретные? + как собираетесь писать компилятор?

alexprey добавил:
Ну я надеюсь будут плагины, которые будут добавлять нативки в jass.
Все давно еще хотел высказаться насчет lua и остального. Зачем переходить с jass?? К нему все так привыкли. И так мало кто используется jass на сайте, новички робко его опасаются. Или вообще предлагаю сделать как настройку, где будут варианты на каком языке будешь писать: lua,c,jass и т.д.

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

NCrashed добавил:
alexprey, забудьте сейчас про луа и другие языки. Jass, cJass, вот текущая цель, если реализовать его грамотно, никакие луа не понадобятся