Вот тут и появляются 2 проэктаСообщение от boRada
. Один на C#, другой на Java... что собственно сейчас и есть... и еще есть NullWar на Python.
А по поводу проблем... ОС - не главная проблема... гораздо сложнее договорится об архитектуре... тут как раз проще одному начать, а потом уже другие подключаются и пишут в рамках одной архитектуры...
По поводу платформы... не будем засорять топик
...И от полученных знаний скончался на месте
Не будемВот тут и появляются 2 проэкта
По поводу платформы... не будем засорять топик
А по поводу проектов - догфайт - а их всего два.
1. Нульвар на Питоне
2. АДВ на С++
Остальное - это только заготовки и сырцы. И будут ли они вообще доведены до уровня этих двух проектов - вопрос тот еще. По крайней мере, кто-нибудь летал на названных тобой двух проектах не в режиме "тест"? А скоро БОБ и смысл их доделывать уже не тот будет.
Я знаю насколько программисты народ упрямый и независимый и не жду легкого разговора.
Спасибо что поддерживаете тему.
Не будем
АДВ вроде как Server Commander на C#... или я путаю чего?А по поводу проектов - догфайт - а их всего два.
1. Нульвар на Питоне
2. АДВ на С++
Остальное - это только заготовки и сырцы. И будут ли они вообще доведены до уровня этих двух проектов - вопрос тот еще. По крайней мере, кто-нибудь летал на названных тобой двух проектах не в режиме "тест"? А скоро БОБ и смысл их доделывать уже не тот будет.
Я знаю насколько программисты народ упрямый и независимый и не жду легкого разговора.
Спасибо что поддерживаете тему..
Лучше все писать на одном... при чем основной движек писать на Java (или C#, кому что больше нравится), а логику войны например на встроенном питоне...А на каком тогда можно писать "управление" сервером?
...И от полученных знаний скончался на месте
ГТ сказали С++АДВ вроде как Server Commander на C#... или я путаю чего?
Тем не менее.. проектов два. Тестов других я не видел, при всем моем желании
Ну уже что-то.Лучше все писать на одном... при чем основной движек писать на Java (или C#, кому что больше нравится), а логику войны например на встроенном питоне...
Разве нереально - парсит С#. Генератор на Питоне ( да хоть на чем)
управление на Java. В чем тут могут быть проблемы? Ведь откопилированные программы мало чем отличаются друг от друга? Тем более их работа практически не пересекается!
PS Возможено я что-то не так спрашиваю - вы уж простите, я программист любитель с маленьким багажом.
Тут как раз ключевое - должен быть один основной язык (либо C# либо Java либо С++) и идин или несколько скриптовых (например вот тут можно выбрать на любой вкус http://www.robert-tolksdorf.de/vmlanguages.html) предусмотренных разработчиками движка.
Обьясню. Дело в том, что скриптовый язык (СЯ) может выполняться в виртульной машине основного языка (для С++ будет запущена виртуальная машина скриптового, например Lua или Python) и этот СЯ будет оперировать классами и объектами основного языка. Но когда мы захотим смешать 2 основных языка (например Java и C#) то получим гимморой, т.к. каждый их этих языков имеет свою виртуальную машину, свой фреймворк и средств встаивания друг в друга не имеют (в отличии от СЯ). По этому основной должен быть один - Java/C#, а уже плагины могут быть написаны как на основном так и на любом СЯ, для которого _разработчики_ предусмотрели поддержку. (т.е. просто взять любой и написать не получится, нужны так называемые "биндинги", т.е. специальные конструкции, обеспечивающие трансляцию из скриптового языка в основной и обратно).
...И от полученных знаний скончался на месте
Извини, но я не пойму, по какой логике они должны быть смешаны. Мы так же смешиваем и язык игры ил2 (с любым языком, на котором ты предлагаешь писать) и ничего криминального при этом не происходит? При том что параллельно работать могут еще с десяток разых программ. Зачем нам встраивать их друг в друга?
Смотри. Смешение языка ИЛ-2 требует написание парсера/командера. Понимаешь ? Ява с дотнетом не МОГУТ обмениваться обьектами/вызовами. Они могут обмениваться только упаковаными в тот или иной вид пакетами чистых данных через некие туннели (TCP, Файлы, пайпы, ...) В результате, чтоб поженить яву с дотнетом надо на одной стороне писать паковщик данных, на другой распаковщик, и еще и реализовывать канал передачи данных. Все эти задачи не менее сложные и трудоемкие, чем собственно парсиг ила в чистом виде. Поэтому вязать яву и дотнет нецелесообразно - чем городить танспорт и систему вызовов проще написать свой командер.
А чтоб возможен был обмен ОБЬЕКТАМИ и вызовами, надо чтоб в ЕХЕ исполняемый, написанный на одном языке, был ВСТРОЕН модуль написанный на другом языке. Вот тут и вылазит скрипт, так как встраиваемые скриты позволяют а) не думать о сложностях ООП основоного языка и б) получить доступ к НУТРУ командера, манипулировать обьектами и вызовами.
Поэтому вот пожеить яву и C# не выйдет НИКАК, а вот их с каким нибудь скриптом - запросто.
И вот тут вылазит еще один нюанс. Если у нас есть группа, в которой ядро пишет архитектор, а обвязку народ на подхвате, то тут возможен вариант со скриптами. Так как в этом случае уровень "народа" может быть ниже сильно. Не надо знать всяких премудростей. НО! если у нас на все один-двое, то им проще все фигачить на одном "тяжелом" языке, так как это и быстрее и багов меньше и писать проще и отлаживать и ... вобщем одни плюсы.
Если ты веришь, что все можно испортить, поверь и в то, что все можно исправить. Раби Нахман из Браслава.
tahorg уже написал все правильно, но я хочу проиллюстрировать простым примером.
Рассмотрим ситуацию: Игрок дал команду <planes.
Раздельная реализация: парсер на Java (П), контроллер миссий на C# (К) и логика на Питоне (Л).
1. П видит команду <planes, и должен спросить К о наличии самолетов
2. Каким-то образом опрелелят где находится К
3. Устанавливает канал обмена информацией с К
4. Упаковывает данные: имя команды,имя игрока, координаты... возможно еще что-то
5. Передает К
6. К распаковывает
7. Производит вычисления и определяет наличие самолетов на данном поле.
8. Запаковывает запрос к Л на определение возможности взлета данному игроку на каждом из самолетов.
9. Передает Л
10. Л анализирует
11. Упаковывает обратно отфильтрованный список
12. K принимает ответ
13. Упаковывает для ответа П
14. П распаковывает ответ
15. П форматирует, переводит в локаль пользователя и выплевывает в чат.
В случае с встроенным СЯ и имея контроллер K допустим на Ruby получим:
1. П видит команду <planes, и должен спросить К о наличии самолетов
2. Находит у себя объект К
3. Вызывает метод для команды <planes
4. Производит вычисления и определяет наличие самолетов на данном поле.
5. Находит объект Л
6. Вызывает метод объекта Л и получает отфильтрованный список
7. К возвращает список
8. П форматирует, переводит в локаль пользователя и выплевывает в чат.
При этом создание протокола для передачи это отдельная задача, гораздо более сложная и ошибкоемкая чем парсинг лога...
...И от полученных знаний скончался на месте
Это я понял, и именно так себе и представляю.
Но проблема как видим не в сложности технической реализации, а в том, что пришлось бы писать больше кода - классы, функции, методы, т.е. в большей трудоемкости. И лишь для того,чтоб сделать возможным обмен данными между какими-то модулями, а нафиг это нужно "когда я возьму и напишу без геморроя все в одной куче". И это понятно.
Но вы упускаете важный момент, который с вашей колокольни вам кажется незначительным и ненужным. У вас получается достаточно узконаправленный и зажатый в свои рамки блок. И менять или переделывать его для кого-то никто из "отцов" не будет. Да просто лениво делать, особенно то, с чем не согласен. Пример - наш разговор. Не раз сказано "каждый пишет на том, на чем лучше всего умеет писать". Готов ли каждый в одиночку написать комплект софта на своем языке и выдать его как законченный продукт? Теоретически - конечно, но практически - вряд ли. Найдется сотня причин, которые помешают это сделать.
Найдется 2-5 человек которые напишут софт на одном языке - чудесно! А кто против? Главное при этом, чтоб еще 30 человек смогли его использовать в своих целях, иначе говоря, чтоб он полностью отвечал их запросам. Шансы? Минимальные.
Пример. Мне необходимо чтоб SC выдал в чат комманду "Равняйсь, Смирна!" Возможно ? Нет. Он закрыт.
Мне надо чтоб JayDaemon это сделал? Нет. Для этого нужно выучить JAVA, разобраться с исходниками и вставить несколько строк кода. Реально, да.. но бррр, а когдаж карты рисовать? А потом вдруг на С# появится софт, который мне понравится больше, будет интереснее. Да фигня! Теперь учим С#, разбираемся с исходниками и вставляем-меняем.
Нда. Делов то.
Но меня интересует другое:
Есть техническая возможность создать софт, для которого я могу написать несколько строк на xml, например, и этот софт его проглотит и выдаст результат? Или я заполню некоторый шаблон, и на основе его сформируется скрипт или еще какая фигня, которая включится в работу не заставляя изучать новый язык программирования?
Я понимаю, что вам это не надо. Это надо НАМ, не программистам, но режисерам, картостроителям, сценаристам...
А зачем это вам? Незачем. Но может найдется один или несколько програмистов, которым будет интересно решить такую задачу. Именно поэтому я и вынес это на обсуждение, надеясь на удачу. На самом деле это гораздо интереснее и круче, чем свой маленький самодостаточный проект - работает, ну и ладно.
Крайний раз редактировалось boRada; 31.10.2006 в 07:14.
Ваши права
Ответить с цитированием