5 баллов... но прикольно же :)
Вид для печати
Гы!
<planes выдаёт запрос к SQL-процедуре базы статистики, которая возвращает хоть чёрта лысого.
Появление на филде игрока запрашивает результат у SQL-процедуры (на Нуле weap_rest), которая до дури всего в статистике анализирует и возвращает результат.
ДЕМОН обязан быть всего лишь обработчиком команд. ВСЁ остальное дело статистики, написанной на простом и всем понятном языке оперирования данных, а именно SQL. Конечно, разным юзерам MyDBF подобный путь заказан, вот и изощряетесь. :)
Демон ничто - статистика всё. А по статистике вы в жизни не договоритесь. :) Так что 5-6 разных демонов не потолок. :)
Гы!
А чем запрос к SQL отличается от запроса к сриптовому движку? Аж ничем. В этом плане написание логики работы на SQL абсолютно аналочино написанию логики на скриптовом языке. А процедуры хранимые есть даже на MySQL, не говоря уж про MsSQL или там Postress ...
Кстати пример был написан не для того, чтобы рассказать как надо делать, а для того чтобы показать сложности межпроцессорного общения.
А по поводу мощности языка БД, то отчего у нас вдруг появилось столько трехуровневых приложений, если все так легко и круто ложиться в БД. А генератор тоже на БД ? Или на скиптах. Ну возьмите шаблон цели и в с помощью SQL скрипта ПОВЕРНИТЕ его на произвольный угол. А потом сравним с тем как это делается в дотнете или яве с их готовой матричной математикой.
Это был простой пример для иллюстрации того, что получается, когда пытаются объединить разные языки и разбить на модули.
А зачем нам о ней договариваться... просто беру и пишу ;).
Ну и MyDBF ни чем не хуже Птиц... та же туфта, что и все остальное... Оракель - вот сила (или Птица уже научилась аналитические функции понимать :umora: ?)
На самом деле мощность зависит от БД. Если рассматривать поделия типа MySQL или Firebird или SQLite, то да... просто хранилки данных, к тому же приложения получаются глупые с постоянным дерганьем бд.
Другое дело что-то более мощьное типа Oracle, я там обхожусь практически без DAO (только что объекты из запросов заворачивать) остальное все на PL/SQL, SLQ и немного embedded java. Жаль токо тут это неприменимо :uh-e:
Когда Борада оставил генератор, размер его был ~140кб. После нормальной чистки и перекидывания некоторой чати на SQL, размер генератора сейчас ~85кб при РАСШИРИВШЕЙСЯ функциональности и несравнимо большей понятности, управляемости и безглючности. Так что вот. :)
Я бы и остальное перенёс, но следую старой привычке: работает - не трогай.
Это я понял, и именно так себе и представляю.
Но проблема как видим не в сложности технической реализации, а в том, что пришлось бы писать больше кода - классы, функции, методы, т.е. в большей трудоемкости. И лишь для того,чтоб сделать возможным обмен данными между какими-то модулями, а нафиг это нужно "когда я возьму и напишу без геморроя все в одной куче". И это понятно.
Но вы упускаете важный момент, который с вашей колокольни вам кажется незначительным и ненужным. У вас получается достаточно узконаправленный и зажатый в свои рамки блок. И менять или переделывать его для кого-то никто из "отцов" не будет. Да просто лениво делать, особенно то, с чем не согласен. Пример - наш разговор. Не раз сказано "каждый пишет на том, на чем лучше всего умеет писать". Готов ли каждый в одиночку написать комплект софта на своем языке и выдать его как законченный продукт? Теоретически - конечно, но практически - вряд ли. Найдется сотня причин, которые помешают это сделать.
Найдется 2-5 человек которые напишут софт на одном языке - чудесно! А кто против? Главное при этом, чтоб еще 30 человек смогли его использовать в своих целях, иначе говоря, чтоб он полностью отвечал их запросам. Шансы? Минимальные.
Пример. Мне необходимо чтоб SC выдал в чат комманду "Равняйсь, Смирна!" Возможно ? Нет. Он закрыт.
Мне надо чтоб JayDaemon это сделал? Нет. Для этого нужно выучить JAVA, разобраться с исходниками и вставить несколько строк кода. Реально, да.. но бррр, а когдаж карты рисовать? А потом вдруг на С# появится софт, который мне понравится больше, будет интереснее. Да фигня! Теперь учим С#, разбираемся с исходниками и вставляем-меняем.
Нда. Делов то.
Но меня интересует другое:
Есть техническая возможность создать софт, для которого я могу написать несколько строк на xml, например, и этот софт его проглотит и выдаст результат? Или я заполню некоторый шаблон, и на основе его сформируется скрипт или еще какая фигня, которая включится в работу не заставляя изучать новый язык программирования?
Я понимаю, что вам это не надо. Это надо НАМ, не программистам, но режисерам, картостроителям, сценаристам...
А зачем это вам? Незачем. Но может найдется один или несколько програмистов, которым будет интересно решить такую задачу. Именно поэтому я и вынес это на обсуждение, надеясь на удачу. На самом деле это гораздо интереснее и круче, чем свой маленький самодостаточный проект - работает, ну и ладно. :)
Тебе уже ответили на жтот вопрос. Конечно есть! Это и называется вставить поодержку СКРИПТОВЫХ языков. Перловку там или питон, а то и жаваскрипт. Это совсем одно.Цитата:
Есть техническая возможность создать софт, для которого я могу написать несколько строк на xml, например, и этот софт его проглотит и выдаст результат? Или я заполню некоторый шаблон, и на основе его сформируется скрипт или еще какая фигня, которая включится в работу не заставляя изучать новый язык программирования?
А вот женить меж собой яву и C# это совсем другое, и заниматься этим ну никто не будет
Чей-то насквозь догфайтный нуль не ломится от количества самолетов. ;)
А надо-то всего ничего - регистнуться и пароль ввестин а входе. Человеку, запускающему все моторы ТБ и пользующемуся огнетушителями вполне под силу. :) А все потому, что наличие цели СИЛЬНО влияет на картину боя. На том0же нуле можно минт 10 просидеть на филде, пока офицеры решат, что куда. Взлетишь - кикнут. :) Много народу готово на это?
Угу. За всех не скажу, кто-то готов на это, Нуль уважаем, живет и здравствует, будь ему хорошо и дальше. Но учитывая, что играть приходят не только молодежь по 18-25 лет, но и "старики" он-лайна... По десять минут ждать, простите. Это все здорово, но есть 3-4 часа на полетушки. И терять даже часть времени нет желания. Когда хочется можно и свой сервант поднять погоняться в кооп-миссиях. Где и техника движется, и прочих прелестей есть, включая планирование... Ибо и в одной кооп-миссии можно навертеть целей, с ковером и без такового, типа проект.
Да и пик с ними. Мне то важен результат, а для начала мне, и не только мне, точно нужно представлять всю ситуацию. Я уж понял (да и знал) что женить их невозможно, но я предложил не женить а сожительствовать :) А это немного разные вещи. В сущности интересуют не конкретные языки (мы просто уперлись в эти два), а технологии и возможности для достижения поставленной задачи.
Конкретно.
Нужен софт с возможностью изменять простыми (с точки зрения простого юзера) способами его функциональность, причем в широких пределах. На чем он будет написан - по барабану. Почему ж хотим модули? Тогда его смогут писать несколько разноязыких программистов, что одновременно и осложняет задачи и упрощает. Меньше шансов долгостроя. Год-два - это слишком много.
Меня бы устроил такой вариант. Взять готовый парсер, заготовку стата (специалистов РНР больше), коммандер с простым подключением скриптов( пусть так назовем). Заготовку генератора ( где уже есть основные алгоритмы). И более менее грамотная комманда ( сквад) может создать сервер хотяб для своих полетушек, а при удачном воплощении и выйти в мир.
Это все замечательно, но по личному опыту, если программистов в команде больше 3х проблемы вылазиют другого рода. Опять же приходим к ведущему-ведомым... ну да фиг с нами, с программисами... смотри другой вариант, почему это реализуемо, но слишком сложно и как следствие будет много глюков (т.к. не будет толковой тест-команды).
Вот в твоем варианте, прикинем, что все хранится в базе.
У нас есть некий показатель эффективности, который зависит от к/д и налета. Это все есть в бд. Это умеет отображать стата. Теперь представь, что нужно добавить еще один параметр: соотношение сил в момент взлета
или сбития. Допустим это не было предусмотрено. В итоге, для добавления этого параметра надо:
1. Изменить базу (SQL программист)
2. Изменить стату (Web программист)
3. Изменить запросы запросы, которые должны учитывать новый параметер. (SQL + Web)
4. Научить командер писать в базу этот параметр (плагин на чем получится).
Т.е. мы имеем довольно сложную систему, которая выглядить примерно как Access какойнибудь, т.е. необходимо сделать ее настолько универсальной, чтобы все параметры, запросы, отображение и прочее описывалось в xml/python/что угодно и система это должна видеть и перестраивать себя...
Често: за бесплатно лично я такой гимморой на себя не возьму... Не каждая коммерческая контора возьмется за столь гибкий проект. Слишком много нужно тестировать и слишком много точек, где могут быть ошибки. Мне проще потратить 2 часа в день на прикручивание фичи по просьбе людей (или допустим взяв nullwar-кий демон поколупать и подправить под себя), чем городить такой огород...
Знаешь... нет ничего хуже, чем из-за непонятного глюка пропадают килы... люди просто уходят на более простой сервер (им пофиг что и как там работает) лишь бы килы не пропадали (на опыте своего сервера).
Ну и языков кучу учить не надо... достаточно выучить Python и можно будет писать плагины (правда только на имеющихся возможностях командера, если он чего-то не знает, то тут надо уже к разработчику идти).
Позволь с тобой не согласиться. Тыж сам сказал "В базе хранится все" Т.е. в базе есть весь распарсенный лог ( что например и делает SC), зачем создавать еще ячейки?
Т.е. работа только у ВЭБ программиста. Изменить html и PHP. Прописать запрос из базы нужной информации и обсчитать ее и показать.
Мы ведь понимаем, что не получится делать проект ничего не зная или не делая. Но вопрос квалификации. Всеж это значительно проще, иначе говоря - РНР знает гораздо больше народу чем С или Java.
И зачем командеру писать в базу этот параметр? Если есть такая задача, тот же РНР при обсчете и пропишет, хотя не вижу смысла.
Без проблем никогда не получится, но надо понимать разницу между проблемами.
А килы пропадают везде. Это от софта уже не зависит, ты и сам это прекрасно знаешь. Тут проблема лога.
И вообще - "волков боятся - щепки летят"
Тут мы приходим к вопросу эффективности... дело в том, что например обсчитать количество пилотов в воздухе в момент вылета пилота в разы проще, чем потом SQL-ем это вытягивать (ибо некислый selfjoin). Например сейчас у меня в базе 120тыщ вылетов. Килов... блин, не помню сколько, но умножь на 0.4 для авиа + умножь на 5 для наземки. Это крайне неэффективно. Нужно все равно предрасчет делать, а некоторые вещи лучше сразу в командере считать и в базу уже в готовом виде писать.
Ну и с il2sc ты не прав... там все разложено по табличкам (в том числе сколько чего сбил (раздельно по типам), стрик, отдельная табличка на килы и т.д.). Я в стате вообще не использую лог. Но приходится добавлять таблицы, чтобы хранить нужную мне информацию.
Ну и если рассчетные параметры так сделать можно... то например как быть с такими параметрами как сквад. Или награды?
Так это потому что: "На том0же нуле можно минт 10 просидеть на филде, пока офицеры решат, что куда."
Проект, не важно кооп или догфайт должен быть ИНТЕРЕСНЫМ для большинства пилотов.
Только тогда в нем будет много народу.
Надо знать что кому интересно.
Мне, как штурмовику/бомберу нужны наземные бои и наполненные целями ж/д станции и т.п.
Кто-то хочет бороться за превосходство в воздухе, кто-то считает, что он мастер прикрытия.
Ну и т.д.
Если в проект будет:
- легко войти, сразу иметь связь со всеми своими пилотами
- быстро получить задачу и вступить в бой
- ПОНИМАТЬ за что воюем, КАК ты можешь повлиять на положение своей стороны
то народ будет в нем летать.
Но "стоить" народ бесполезно. Останутся единицы, остальные разбегутся.
И, еще раз подчеркну - БЕСПЛАТНАЯ работа кучки энтузиастов себя исчерпала. Проект должен быть коммерческим, платным, массовым, рассчитанным на покрытие интересов максимального количества вирпилов.
Как же ты ошибаешься ;)
http://www.mono-project.com/Java
Да упаси боже! Больше 30 пилотов в онлайн на сервере = бардак и полная неуправлямость, отсутствие какой либо мысли и догфайт. Именно потому у Нуля очень строгие рамки в этом плане. Сделать проект, где будет летать 100 раздолбаев крайне легко... А вот собрать и заставить хотя бы 30 человек (из разных сквадов, разных сторон, разных вообще!) действовать в строгой команде - в те же сто раз сложнее.
Так что больше проектов хороших и разных!
Если каждый игрок понимает, что его действия ведут к победе или поражению его стороны, то через какое-то время происходит самоорганизация и тот, кто быстрее организовался - побеждает.
Я ведь не из головы это все придумываю. У нас есть перед глазами World War II Online Battleground Europe, где геймплей ЗАСТАВИЛ изначально неорганизованные толпы играть командно. А там не 30 и не 100 человек играет одновременно, а гораздо больше.
ИМХО - многие принципы организации боев в WWIIOl можно реализовать в проекте по Ил-2.
А как перекидывание части логики на SQL сказалось на возможность интеграции с другим ПО? То есть теперь генератор можно использовать только с такой структурой БД и никакой другой? Так зачем кому-то ещё кроме нуля нужен будет вот такой генератор который нельзя больше никуда интегрировать?