Сообщение от Doc
Как я уже неоднократно писал в асечке - с синхронизацией двух абсолютно разных клиентов(в данном случае стандартный вар3 и ваш клиент) у вас ничего не получится. Обратной совместимости не будет. Т.к. вы не сможете с абсолютной точностью скопировать алгоритмы вк3, да вы и не хотите этого + разная скорость работы + как сказал тоадкоп, вам придется скопировать все баги вк3 в ваш опенваркрафт и еще куча проблем, так что совместимость вы не реализуете, я уверен.

я это еще раньше говорил, но не подтвердил свои слова аргументами.

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

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

1. С открытым исходным кодом - надо ясно дело, да и т.к. движок самописный близы ниче против не будут иметь, разьве только по сеттингу вара? надо думать..
2. С полной совместимостью со старым движком - не нужно как уже сказали
3. С адекватной встроенной физикой - возможно дать возможность подключить плагин отдельно физический, который будет на события реагировать определенные (которые движок выдает), а если мапмейкер не сделал такой - будет использовать стандартный вшитый в движок механизм
4. С возможностью создания плагинов для движка - Вообще механизм плагинов представляю себе как возможность замены поведения по-умолчанию: т.е. мапмейкер в свою карту вставляет уникальный GUID плагина, и разрабатывает карту с его учетом; при запуске карты двиг: для каждого указанного плагина проверяется - если еще не установлен плагин - качает с сайта где все плагины мейкеры будут размещать.. если плагин уже поставлен в папку с игрой - ок... если плагин для какого-то действия не назначен - используется поведение движка по-умолчанию..

5. С убранными багами и ограничениями старого движка вара - баги? какие? я чето не замечал багов в варике)) Ограничения - не слишком сильно убирать, всетаки не просто так они были придуманы.. в принципе на размер карты можно снять ограничение вообще т.к. инет быстрый.. а вот на кол-во игроков - 12 это много, так не часто даже в карты играют.. ради командной игры делать больше? не уследишь за всеми.. ради какой-нить MMORPG - ну не знаю, для нее вообще еще и сервак надо делать, да и надо профи чтобы смогли сделать не лагучую графику для многих юнитов + работу по сети для многих игроков
6. С мультиформатной поддержкой моделей - не надо.. формат должен быть стандартным для данной игры, а в него сделать конвертер из всех других форматов (как отдельная прога а не вшито в в движок)
7. С поддержкой старого формата карт .w3x а также стандартного (и JNGP) редактора - старые карты однозначно надо поддерживать, соответственно раз плагины назначаются разрабом карты - все будет ОК
8. С поддержкой модифицированного .w3x, который позволяет добавлять более 16 тайлов и тп. - предлагаю изменить для него расширение, ну и структура файлов там будет дополненной, это и описание плагинов к скачиванию, и как уже говорил изменение интерфейса в игре, и сами плагины вшиты если не распространенные
9. С улучшением графики, освещение, тени, все возможности движка Ogre - это одна из ключевых возможностей)) Графический двиг вара уже старый, нужен новый, но обязательно не лагучий, чтоб поддерживал качественные модели в больших кол-вах на экране
10. С встроенной поддержкой Jass, cJass и увеличенной памятью для джазз машины - а как без Jass карты то писать? vJass, cJass - просто переводить его в обычный Jass на этапе сохранения карты как щас делает JNGP - тоесть тут ниче придумывать не надо, только свою Jass-машину)) Желательно не лагучую.. и говорили что в байт-код переводить - желательно реализовать - для прироста производительности.. возможно даже на этапе инициализации карты..
11. C поддержкой Lua, который постепенно будет заменять Jass в новых картах - не вижу смысла, если все можно написать на Jass, в который будут вшиты новые нативки.. Может расскажете зачем?
12. Модульный принцип, описанный в 1м посте... Список стандартных плагинов - и так будет вшито в движок, это уже не плагины.. Список возможных кастомных плагинов - какие-то я описал выше, что касается возможностей "новой рассы" - думаю двиг должен поддерживать такое по-умолчанию, тоесть опять же в архив карты кидаешь файл описания новой расы и все пашет)) даже кнопочка выбора новой расы есть при старте игры)) А вот то, что по "добовлять свои native функции в движок" - какие функции например вы хотите внедрять? Не представляю.. Движок должен быть написан оптимально, с поддержкой структур данных и алгоритмов, которыми могут пользоваться мапмейкеры, обращаясь к Jass-функциям и все.. что еще внедрять? Да даже если дать возможность внедрять любые DLL плагины - дыра в безопасности..
13. Кстати все что касается защиты карты от открытия в редакторе.. эту штуку врятли реализовать)) даже с помощью перевода в байт-код на этапе сохранения карты - можно написать прогу реализующую обратный процесс, т.к. код двига открытый)) Возможно стоит подумать над этим моментом? Как считаете? Придумать свой механизм защиты карт?
14. Да, кстати, сам я программист по профессии.. если что могу помочь... но только тогда, когда будет расписано все, что хотите сделать.. Кодить рано! Надо все взвесить, продумать.. Потому что можно такого накодить, что придется переписывать все)) да и не нужного тоже))

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

Кроме того если делать по уму, то нужно будет разработать внутренний ассемблероподобный язык для jass-> машины, который, собственно, и будет использоваться для представления в виде байткода.

С полной совместимостью со старым движком - не нужно как уже сказали

3 ...

4. С возможностью создания плагинов для движка - Вообще механизм плагинов представляю себе как возможность замены поведения по-умолчанию

5. С убранными багами и ограничениями старого движка вара - баги? какие? я чето не замечал багов в варике)) Ограничения - не слишком сильно убирать, всетаки не просто так они были придуманы.. в принципе на размер карты можно снять ограничение вообще т.к. инет быстрый.. а вот на кол-во игроков - 12 это много, так не часто даже в карты играют.. ради командной игры делать больше? не уследишь за всеми.. ради какой-нить MMORPG - ну не знаю, для нее вообще еще и сервак надо делать, да и надо профи чтобы смогли сделать не лагучую графику для многих юнитов + работу по сети для многих игроков

С мультиформатной поддержкой моделей - не надо.. формат должен быть стандартным для данной игры, а в него сделать конвертер из всех других форматов (как отдельная прога а не вшито в в движок)

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

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

C поддержкой Lua, который постепенно будет заменять Jass в новых картах - не вижу смысла, если все можно написать на Jass, в который будут вшиты новые нативки.. Может расскажете зачем?

Модульный принцип, описанный в 1м посте... Список стандартных плагинов - и так будет вшито в движок, это уже не плагины.. Список возможных кастомных плагинов - какие-то я описал выше, что касается возможностей "новой рассы" - думаю двиг должен поддерживать такое по-умолчанию, тоесть опять же в архив карты кидаешь файл описания новой расы и все пашет)) даже кнопочка выбора новой расы есть при старте игры)) А вот то, что по "добовлять свои native функции в движок" - какие функции например вы хотите внедрять? Не представляю.. Движок должен быть написан оптимально, с поддержкой структур данных и алгоритмов, которыми могут пользоваться мапмейкеры, обращаясь к Jass-функциям и все.. что еще внедрять? Да даже если дать возможность внедрять любые DLL плагины - дыра в безопасности..

Да, кстати, сам я программист по профессии.. если что могу помочь... но только тогда, когда будет расписано все, что хотите сделать.. Кодить рано! Надо все взвесить, продумать.. Потому что можно такого накодить, что придется переписывать все)) да и не нужного тоже))

Хотя Lua не содержит понятия класса и объекта в явном виде, механизмы объектно-ориентированного программирования с поддержкой прототипов (включая множественное наследование) легко реализуются с использованием метатаблиц, которые также позволяют перегрузку операций и т. п. Реализуемая модель ООП (как и в JavaScript) — прототипная.

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