Сумашедший проект

[aeropunk]

ИМХО - если процесс доступа в проект был бы быстрее и проще количество пилотов в проектах стало бы ГОРАЗДО больше. В чем такой уж "хардкор" проектов? Те же воздушные бои, только у них цель есть, в отличие от догфайта.
Из догфайта в коопы идут мало потому что:
- очень желательно состоять в скваде
- сложно и долго входить, стоять в слоте
Вот и все. Упростить и ускорить вход - и пилоты из догфайта потянутся в проекты

Согласен. Сужу по себе.

Прихожу с работы. Сколько у меня свободного времени до сна? Ну 2-3 часа. Если не конченый Ил2ман (таких очень немного), то не каждый день потратишь это время для полетов. Итого получается по 1-2 часа полетов через день или еще реже. Честное слово, жалко тратить это время на стояние в слотах и ожидание решения стратегов. Хочется сбить 3-4 самолета перед сном и оказаться сбитым несколько меньшее количество раз.

Интересность проекта зависит не от софта, а от людей. Софт может только упростить некоторые рутинные операции. Интересность нельзя запрограммировать. Нужен человек, game-master. Надолго ли хватит у него энтузиазма? Не думаю, что надолго.

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

[tahorg]

ВОПРОС:Каков вариант, что можно собрать в один проект 3-4 программиста, которые найдут общий язык не только в программировании, но и в концепции ОДНОГО сервера? При условии что это будет бесплатно и в свободное от работы время?

Ответ на сайте http://www.vef3.net/

Андрей, подобные вещи делаются 1-2мя прогрмистами, если туда не вкладываются деньги. У меня ситуация вот простая - я сделаю ВСЕ для создания войны, и все жто выложу. Надо будет писать свой генератор лишь и свой механизм обработки результатов. Со всеми крючками по управлению в процесе. Свой генератор я конечно выкладывать не буду, ну такова вот селяви.

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

Ну а вообще я уже больше в БОБ смотрю. Поскольку он по C# и плагины анм там уже обещаны, то может там можно будет к серверу цепляться ...

[McFris]

Знаете... Не пинайте труп давно почившего Ила. Дайте ему покоиться с миром и с лучшими воспоминаниями.
Эта игра написана догфайтерами и для догфайтеров, и хватит тащить на себе, на добровольных началах то, что должны тащить сами разработчики за деньги. Причём тащить ещё и ВОПРЕКИ этим самым разработчикам... Вам это надо? Кто нить когда нить из разработчиков с вами общался? Предлагал что-то исправить, добавить, обсудить? За время существования Нуля (3.5 года) со мной лично никто не общался. Однажды, через третьих лиц, по знакомству (sic!!!), по просьбе тех же третьих лиц включили лог. Спасибо большое!!! С тех пор всё никак выключить не могут...
Вам этого показателя недостаточно, а? Это однозначно говорит - нафиг вы никому не сдались, и разработчикам только в тягость! Им КОКПИТЫ рисовать некогда!!!
А во всевозможные нынешние вариации правил и войны и невойны и чего угодно мы наигрались уже по самое немогу, к чему лично я приложил большую лапу. Ну может уже хватит? Вы думаете что все остальные идиоты, а уж вы то сделаете таааакой сервер, прям такой... Не получится! Уже примеров предостаточно.
Я ещё понимаю, если бы надо было подготовиться к БоБу, собраться всем вместе сторонним разработчикам, обсудить что нам надо от игры, какой АПИ (да хрен с ним, лог), какие разработчики предоставят нам инструменты (как они недавно сказали "специально оставленные ДЫРЫ"!!!)... Но ничего этого нет, не планируется и не будет. И потому - бросьте пинать ЭТО. Оно мертво. А мы все некрофилы.

[boRada]

Для того, чтобы это все работало, потребовалось куча времени и труда, чтобы создать штуку, которая называется ОС. Но даже это не помогло... если на Java программу можно запускать как на Windows так и на Linux, то например на VB или C# - это фактически напрямую сделать нельзя...

Таким образом создание подобного монстра сопоставимо с написанием собственной миниос... что очень затратно, и главное не понятно зачем...

Вот эта часть и есть самая нереальная... я не зря про CORBA/СOM написал... это как раз и есть попытка людей реализовать вещь которая поможет общаться разным программам на разных языках... но вся беда в том, что в данном проекте это не поможет по несольким причинам:
1. Архитектура. Т.е. для того, чтобы все это работало, нужна единая стройная архитектура со своей иерархией объектов (т.е. например пилот состоит в скваде, самолет имееет вооружение, миссия состоит из целей и т.д.)... но если есть архитектура, тогда не зачем зоопарк языков разводить, проще все на одном писать, ибо на разных в разы сложнее.
2. Как ни странно, ОС. Ибо командер может работать и на винде, а вот стату например можно на юниксах пускать... но при использовании C# это проблематично, а на VB дык вообще почти невозможно... (ну исключая всякие костыли типа разных эмуляторов)
3. Протокол обмена будет нереально сложным... Ибо на данный момент реальным протоколом обмена данных, который уже есть - это лог. Т.е. проще в каждый модуль воткнуть свой анализатор и пусть сам разбирается...

Т.е. ИМХО это как раз утопия...

ЗЫ: по хорошему конечно ОС -сильно сказано, но довольно мощьный и навороченный фреймворк потребуется... к тому же все равно надо выбирать, на чем будет он написано, ибо остальное все - это суть плагины.

Честно говоря я не увидел существенных препятствий. По моему - эти рассуждения излишне глобальны для конкретной реализации, и в этом наши трения. Разве Ил2 или Боб планируется на другие платформы кроме Винды? Зачем нам думать о Линуксе и иже с ним??? Давайте упростим задачу изначально, нам не нужны кроссплатформенные программы и прочие хитроумные штучки-дрючки. Собра - наглядный пример лищь того, как разные программисты не сумели договорится что и как делать, в итоге она никому не нравится и никто не хочет писать-использовать. имхо.
Евент лог служит наглядным примером, что проблемы с обменом приувеличены. Ведь с ним работают программы на разных языках? Так в чем проблемы? Можно по разному назвать элементы софта - плагины, модули, компоненты, трали-вали - а суть?
Ставя задачу на Линукс или юникс - мы сознательно загоняем себя в такие рамки, что делать просто нечего кроме как застрелится или застрелить.
Я могу понять, что винда - это не круто. При этом все выделенные сервера в иле работают на ней или на хитрой связке (простите не помню какой). А когда я лечу, на Нуле например, мне по барабану что стоит на сервере.
А MS тем временем все агрессивнее лезет во все области. Ну это уже не к теме.

[MoHaX]

ВОПРОС:Каков вариант, что можно собрать в один проект 3-4 программиста, которые найдут общий язык не только в программировании, но и в концепции ОДНОГО сервера? При условии что это будет бесплатно и в свободное от работы время?

Очень много OpenSource проектов именно так и начинались и были доведены вполне до функционального состояния именно такими командами. Так что это вполне реально и уже ни раз был проделано.

[tahorg]

Знаете... Не пинайте труп давно почившего Ила.

+1

Вчера подцепил кота к компу, подумал, покрутил ... и отцепил ... Так что тока для отработки идей перед грядущим БОБ. Ну а дырки, на полноценный внешний API я не упроваю, но всеж надеюсь будет сделано БОЛЬШЕ чем в иле.

[boRada]

Ответ на сайте http://www.vef3.net/

Я не понял, это положительный пример или отрицательный?

Андрей, подобные вещи делаются 1-2мя прогрмистами, если туда не вкладываются деньги. У меня ситуация вот простая - я сделаю ВСЕ для создания войны, и все жто выложу. Надо будет писать свой генератор лишь и свой механизм обработки результатов. Со всеми крючками по управлению в процесе. Свой генератор я конечно выкладывать не буду, ну такова вот селяви.

В принципе после отладки написать войну используя это все - вопрос только генератора и програмирования правил. Может быть это кому-то пригодиться.
Ну а вообще я уже больше в БОБ смотрю. Поскольку он по C# и плагины анм там уже обещаны, то может там можно будет к серверу цепляться ...

Сергей!
Ну и опять пришли к чему? "Я сам с усам и я сделаю сам себе что захочу и как захочу"
Не верю. Я не верю что одному и даже двум удасться сделать законченное изделие.
Что получается? Так и будем сидеть каждый за своей печкой на своем обшарпанном сундучке и хитро улыбаться "Програаамку захотелось? Я над ней сутками сидел и вдруг отдай? Гурлум-гурлум.." :confused: Шучю. Но в шутке есть доля правды.
Почему большинство программистов категорически отвергает любое сотрудничество с коллегами (видят в них конкурентов?).
Но ведь большинство доводов "против" не выглядят железными?

[boRada]

Очень много OpenSource проектов именно так и начинались и были доведены вполне до функционального состояния именно такими командами. Так что это вполне реально и уже ни раз был проделано.

Я ведь спросил о варианте, имея в виду шансы в данном случае. Я знаю о таких проектах, но это скорее исключения, и не имеют варианта устойчивой тенденции. А уж тем более в специфичном жанре симулятора. Ну вот давайте кинем клич "Программисты С++ обединяйтесь!" Много получим откликов? При том что программистов пишущих для ила можно насчитать с десяток, ну два десятка.

[Baks]

Честно говоря я не увидел существенных препятствий. По моему - эти рассуждения излишне глобальны для конкретной реализации, и в этом наши трения. Разве Ил2 или Боб планируется на другие платформы кроме Винды? Зачем нам думать о Линуксе и иже с ним???

Вот тут и появляются 2 проэкта . Один на C#, другой на Java... что собственно сейчас и есть... и еще есть NullWar на Python.

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

По поводу платформы... не будем засорять топик

[boRada]

Попробую так еще спросить:
На каком языке можно написать парсер эвентлога? Чтоб работало под виндой.

[Baks]

Попробую так еще спросить:
На каком языке можно написать парсер эвентлога? Чтоб работало под виндой.

На любом. Python, Ruby, C# и Java вполне подходят, как по количеству программеров, так и по возможностям языка.

Хотя Ruby конечно несколько экзотичен... тут вроде немного любителей... но остальные - вполне.

[boRada]

Вот тут и появляются 2 проэкта . Один на C#, другой на Java... что собственно сейчас и есть... и еще есть NullWar на Python.

По поводу платформы... не будем засорять топик

Не будем Я читал не раз жаркие баталии. Но к делу они не относятся.

А по поводу проектов - догфайт - а их всего два.
1. Нульвар на Питоне
2. АДВ на С++

Остальное - это только заготовки и сырцы. И будут ли они вообще доведены до уровня этих двух проектов - вопрос тот еще. По крайней мере, кто-нибудь летал на названных тобой двух проектах не в режиме "тест"? А скоро БОБ и смысл их доделывать уже не тот будет.

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

[boRada]

На любом. Python, Ruby, C# и Java вполне подходят, как по количеству программеров, так и по возможностям языка.

Хотя Ruby конечно несколько экзотичен... тут вроде немного любителей... но остальные - вполне.

А на каком тогда можно писать "управление" сервером?

[Baks]

Не будем Я читал не раз жаркие баталии. Но к делу они не относятся.

А по поводу проектов - догфайт - а их всего два.
1. Нульвар на Питоне
2. АДВ на С++

Остальное - это только заготовки и сырцы. И будут ли они вообще доведены до уровня этих двух проектов - вопрос тот еще. По крайней мере, кто-нибудь летал на названных тобой двух проектах не в режиме "тест"? А скоро БОБ и смысл их доделывать уже не тот будет.

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

АДВ вроде как Server Commander на C#... или я путаю чего? . Но не суть. Дело в том, что для того, чтобы еще один проект поднялся, нужно чтобы его начали ставить (как в свое время Server Commander, тоже те еще глюки были). Т.е. нужно желание админов ставить альтернативу... Ибо открытый проект без тестеров - это труп .

А на каком тогда можно писать "управление" сервером?

Лучше все писать на одном... при чем основной движек писать на Java (или C#, кому что больше нравится), а логику войны например на встроенном питоне...

[Charger]

Ответ, WBFH.

[boRada]

АДВ вроде как Server Commander на C#... или я путаю чего? . Но не суть. Дело в том, что для того, чтобы еще один проект поднялся, нужно чтобы его начали ставить (как в свое время Server Commander, тоже те еще глюки были). Т.е. нужно желание админов ставить альтернативу... Ибо открытый проект без тестеров - это труп .

ГТ сказали С++
Тем не менее.. проектов два. Тестов других я не видел, при всем моем желании

Лучше все писать на одном... при чем основной движек писать на Java (или C#, кому что больше нравится), а логику войны например на встроенном питоне...

Ну уже что-то.
Разве нереально - парсит С#. Генератор на Питоне ( да хоть на чем)
управление на Java. В чем тут могут быть проблемы? Ведь откопилированные программы мало чем отличаются друг от друга? Тем более их работа практически не пересекается!

PS Возможено я что-то не так спрашиваю - вы уж простите, я программист любитель с маленьким багажом.

[Baks]

Ну уже что-то.
Разве нереально - парсит С#. Генератор на Питоне ( да хоть на чем)
управление на Java. В чем тут могут быть проблемы? Ведь откопилированные программы мало чем отличаются друг от друга? Тем более их работа практически не пересекается!

Тут как раз ключевое - должен быть один основной язык (либо C# либо Java либо С++) и идин или несколько скриптовых (например вот тут можно выбрать на любой вкус http://www.robert-tolksdorf.de/vmlanguages.html) предусмотренных разработчиками движка.

Обьясню. Дело в том, что скриптовый язык (СЯ) может выполняться в виртульной машине основного языка (для С++ будет запущена виртуальная машина скриптового, например Lua или Python) и этот СЯ будет оперировать классами и объектами основного языка. Но когда мы захотим смешать 2 основных языка (например Java и C#) то получим гимморой, т.к. каждый их этих языков имеет свою виртуальную машину, свой фреймворк и средств встаивания друг в друга не имеют (в отличии от СЯ). По этому основной должен быть один - Java/C#, а уже плагины могут быть написаны как на основном так и на любом СЯ, для которого _разработчики_ предусмотрели поддержку. (т.е. просто взять любой и написать не получится, нужны так называемые "биндинги", т.е. специальные конструкции, обеспечивающие трансляцию из скриптового языка в основной и обратно).

[boRada]

http://www.sukhoi.ru/forum/showpost....&postcount=113
Затрагиваются вопросы из той же оперы. А ответ то достаточно стандартный - делайте что хотите, но сами и не больше того что позволено программой. Так обясните мне смысл, может просто удовлетворение "я это сделал" или "я это сделал вот так"? И это нормально, но малопригодно для большинства остальных творцов.

[Baks]

http://www.sukhoi.ru/forum/showpost....&postcount=113
Затрагиваются вопросы из той же оперы. А ответ то достаточно стандартный - делайте что хотите, но сами и не больше того что позволено программой. Так обясните мне смысл, может просто удовлетворение "я это сделал" или "я это сделал вот так"? И это нормально, но малопригодно для большинства остальных творцов.

Это особенность опенсорц проектов, особенно в стадии, когда еще не было даже релиза... Это связано с тем, что обычно на проектирование системы нет ни времени ни желания (конечно проектирование есть, но оно не в том объеме, которе необходимо, чтобы учесть все мыслимые потребности).
Тот же SC много имеет возможностей к расширению?

[boRada]

Но когда мы захотим смешать 2 основных языка (например Java и C#) то получим гимморой, т.к. каждый их этих языков имеет свою виртуальную машину, свой фреймворк и средств встаивания друг в друга не имеют (в отличии от СЯ).

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

[tahorg]

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

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

[boRada]

Тот же SC много имеет возможностей к расширению?

И я про это! Но почему? Да потому что это разработчикам не надо! И если меня вполне устраивает как он парсит и пишет в базу, то меня( и не только меня) не устраивает как он реагирует на события, или сказать не реагирует на нужные мне события! И все! Развитие закончено. Чтоб добавить новую команду в SC мне надо железно убедить в этом ГТ, и если они найдут время - они добавят 1 комманду. А если мне надо 5 комманд? А если соседу надо еще 3 к этому количеству? И все. На этом все модификации и закончаться, не успев начаться. Монах правильно расставил акценты - и это волнует не только его.
Ну я тож имею некоторые планы. Что мне предстоит? А практически сесть, выучить подходящий язык и написать свой парсер-демон -коммандер-генератор-статистику-карты-сайт-послатьвсекчерту. Результат? А никакого результата,только выброшенные на ветер силы и время. Кроме опыта программирования - никаких положительных результатов. Что я пока и делаю - изучаю язык.

[tahorg]

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

Смотри. Смешение языка ИЛ-2 требует написание парсера/командера. Понимаешь ? Ява с дотнетом не МОГУТ обмениваться обьектами/вызовами. Они могут обмениваться только упаковаными в тот или иной вид пакетами чистых данных через некие туннели (TCP, Файлы, пайпы, ...) В результате, чтоб поженить яву с дотнетом надо на одной стороне писать паковщик данных, на другой распаковщик, и еще и реализовывать канал передачи данных. Все эти задачи не менее сложные и трудоемкие, чем собственно парсиг ила в чистом виде. Поэтому вязать яву и дотнет нецелесообразно - чем городить танспорт и систему вызовов проще написать свой командер.

А чтоб возможен был обмен ОБЬЕКТАМИ и вызовами, надо чтоб в ЕХЕ исполняемый, написанный на одном языке, был ВСТРОЕН модуль написанный на другом языке. Вот тут и вылазит скрипт, так как встраиваемые скриты позволяют а) не думать о сложностях ООП основоного языка и б) получить доступ к НУТРУ командера, манипулировать обьектами и вызовами.

Поэтому вот пожеить яву и C# не выйдет НИКАК, а вот их с каким нибудь скриптом - запросто.

И вот тут вылазит еще один нюанс. Если у нас есть группа, в которой ядро пишет архитектор, а обвязку народ на подхвате, то тут возможен вариант со скриптами. Так как в этом случае уровень "народа" может быть ниже сильно. Не надо знать всяких премудростей. НО! если у нас на все один-двое, то им проще все фигачить на одном "тяжелом" языке, так как это и быстрее и багов меньше и писать проще и отлаживать и ... вобщем одни плюсы.

[boRada]

Это понятно. Что проще написать все на одном языке. Но я ведь не о том как сделать проще!
Ессно сложнее предусмотреть в коде разные варианты, разные выводы-вводы через внешние пути(туннели), но это неизбежная плата за гибкость в построении софта сервера. Но я хочу, чтоб гипотетически программер на VB смог написать внешнюю программу, которая будет через "ядро" управлять сервером. Чтоб для этого не нужно было знать язык ядра, а только структуру "туннеля". Пускай и парсер и коммандер будут написаны на одном языке или в одном блоке "опенкоммандера", но ведь сейчас управлять сервером снаружи, например Питоном, невозможно? Пусть это называется скрипт. Но у себя я хочу один скрипт, а сосед хочет другой.
Неужели вы не видите эту проблему? Вы лучше меня сможете с этим разобраться, но надо захотеть этого, а это дополнительная и ненужная вам работа. Вот в чем проблема.
Допустим вот что
У меня есть генератор на каком-то языке. Где мне взять парсер-коммандер? Брать то что дают и переделывать, и учить при этом новый язык?
А брать то получается и нечего! При всем наличие предложений.

[Baks]

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

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. П форматирует, переводит в локаль пользователя и выплевывает в чат.

При этом создание протокола для передачи это отдельная задача, гораздо более сложная и ошибкоемкая чем парсинг лога...