Автоматизированая система - ТЗ
 

Просьба написать то что надо от автоматизированой системы. Ее функции. итп

А че сделать хочешь??? Похвально!!!

Лично я делать не буду. Будет знакомый, наверное. Пока интересует конкретно что нужно в системе..по пунктам.. Предлагаю каждому высказть что он хочет видеть..а там составим единый вариант

Гыгы, ну щас я выскажу :))
Я бы хотел такое видеть:
- Количество заданий в игре, количество подсказок и время выдачи настраиваемое.
- Режимы: линейная, нелинейная игра. Если игра нелинейная, то возможность вручную частично настроить порядок выдачи заданий (например первым заданием поставить половинам команд агента, другой половине команд поставить агента вторым заданием), все что не проставлено вручную, распределяется автоматически.
- Возможность прямо в течении игры организаторам снять уровень и тем командам, которым он еще не выдавался соответсвенно и не будет выдаваться, а тем кому уже выдавали в статистике учитываться не будет.
- Бонусы нескольких разновидностей: бонусы на всю игру независимые друг от друга, бонусы на всю игру по порядку(первый, затем после выполнения или слива второй и т.д.), бонус с привязкой к заданию и действующий в течении задания.
- Статистика, отключаемая(отключаемая либо совсем, либо, например, после выполнения какой-нибудь командой N-ого уровня)

И зачем это писать самим, если это все уже сделано?? Ну акромя бонусов в на всю игру

Гриш, смотри то, что есть, и сделай хоть это =) а потом по исходникам уже доработать.

Ну я ж не знаю какая функциональность у движка с которым мы играли...
Человек спросил, я ответил =)))

Вот, что написал Fomka

ТЗ к движку.

1. ОБЩИЕ ПОЛОЖЕНИЯ.
1.1. Любое максимальное количество играющих команд (Выставляется отдельно для каждой игры)
1.2. Любое количество заданий и бонусов.
1.3. По одному игровому окну на команду.
1.4. Возможность переключения между каждым из открытых заданий/бонусов (как для просмотра текста задания, так и
для ввода кода).
Желательно также, чтобы можно было просмотреть текст уже пройденных заданий.
1.5. Подсчёт времени с точностью до секунд.
1.6. Возможность просмотра текущей статистики в процессе игры (если это разрешено автором игры).
1.7. Возможность аварийного регулирования хода игры организатором.

2. ЗАДАНИЯ.
2.1. Задаётся количество заданий в игре. (и их тексты)
2.2. Для каждого из заданий задаётся количество подсказок. (и их тексты)
2.3. Для каждой из подсказок задаётся время её получения после прихода задания.
2.4. После прихода последней подсказки ко времени команды прибавляется заданное время (штраф за слив).
(Подразумевается, что
последняя подсказка - это код в явном виде. Если задано 0:00, то игра без штрафов).
2.5. Для каждого задания задаётся количество кодов (1 - нормальное задание, 2 и больше - составной код). При этом
количество кодов
явно не показывается движком, коды вводятся по очереди. (При желании, автор сам укажет количество кодов в задании.)
2.6. Для каждого из заданий задаётся очерёдность его выдачи. Должны быть реализованы варианты:
2.6.1. Номер, которым должно по счёту идти это задание.
2.6.2. Диапозон номеров, которым по счёту оно может быть. (Например, для задания с агентом логично задать "1-3",
чтобы не морозить
его на улице всю ночь).
2.6.3. Номер задания, за которым оно должно идти (для логически связанных заданий).
2.6.4. Неважно (случайная последовательность).
2.6.5. Запасное (Должно быть сначала введено в игру организатором. После этого тоже выдаётся в случайной
последовательности.)
Заданная очерёдность должна автоматически проверяться на непротиворечивость.
2.7. Для каждого задания задаётся список номеров тех заданий, которые находятся рядом с ним. (Чтобы не было два
задания подряд в
одном районе. Можно также использовать, чтобы не давать подряд два задания с похожей логикой, либо два задания с
агентом подряд, и
тд.).
2.8. Задания выдаются игрокам согласно следующему списку приоритетов (начиная с наивысшего):
2.8.1. Задан номер задания.
2.8.2. Задание должно идти за предыдущим.
2.8.3. Задан диапозон номеров.
(Эти три верхних слоя уже проверены на непротиворечивость и будут выполняться в любом случае).
2.8.4. Соседние задания не должны даваться подряд.
(В случае невозможности выполнения - этот пункт нарушается).
2.8.5. Команды не должны пересекаться на заданиях.
(В случае невозможности выполнения - команда отправляется на то задание, которое быстрее освободится. Скорость
освобождения
считается по времени до слива.)
Система приоритетов, возможно, будет доработана.

3. БОНУСЫ.
3.1. Задаётся количество бонусов в игре. (и их тексты)
3.2. Для каждого из бонусов задаётся бонусное время.
3.3. Для каждого из бонусов задаётся количество подсказок, для каждой из подсказок задаются:
3.3.1. Их тексты.
3.3.2. Время, на которое получение подсказки уменьшает бонусное время.
3.3.3. Тип получения - вручную (нажав на кнопку "хочу подсказку") или автоматически.
3.4. Для моментов начала действия бонуса, окончания действия бонуса и получения автоматической подсказки задаётся
одно из следующих
условий:
3.4.1. Получено задание Х.
3.4.2. Выполнено задание Х.
3.4.3. Получено n-e по счёту задание.
3.4.4. Выполнено n-e по счёту задание.
3.4.5. Выполнен (или слит) бонус Х.
3.4.6. Прошло t минут с момента получения бонуса Х.
3.4.7. Прошло t минут с момента начала игры.
3.5. Для каждого из бонусов должна быть возможность ввода составного кода на тех же условиях, что и для заданий.

4. ФОРС-МАЖОР.
Организатор игры должен обладать следующими возможностями:
4.1. Аварийный останов игры (с отключением движка и уведомлением всех играющих).
4.2. Снятие одной из команд.
4.3. Общий технический таймаут - пауза в выдаче новых заданий командам.
4.4. Технический таймаут для одной из команд.
4.5. Снятие одного из заданий или бонусов. Снятое задание не будет считаться в статистике для тех, кто уже успел
его пройти.
4.6. Ввод запасного задания в игру.
4.7. Редактирование текстов заданий, подсказок и бонусов в процессе игры. (?) (как вариант - только тех, которые
ещё никто не
получил).
4.8. "Технические штрафы или бонусы" - время, которое можно добавить/вычесть к результату любой из команд в
процессе игры или после
неё.

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

не асилил...така много путктов...

могу помогать исключительно советами. Будь то пхп, mysql иль еще какая-нить хрень. Заниматься проектом совсем времени нет, а помочь мыслями - без проблем =)

сам же знаешь, что с временем напряг...
хватает только на пьянки :(

Движок для работы через интернет я так понимаю?

правильно понимаешь =)

- необходима возможность выдавать каждой команде свою модификацию одного и того же задания. Такое бывает необходимо.

- резервирование поступащей информации по игре, синхронизания результатов поминутно.
Т.е. возможность развертывания резервной серверной части, с восстановлением настроек игры, в течение 15-20 минут. Или возможность перевода игры в ручной режим с последующим учетом текущей статистики.

- необходимо предусмотреть систему сигнализации обрыва связи с сервером. Допустим таймаут - 1 минута. После чего выводится сообщение о дисконнекте.

- желательно чтобы соединение шло по https:// в случае, если будет веб-интерфейс. Ибо секьюрность.

тогда не помошник

А имеет ли смысл при выборе следующего задания для команды руководствоваться тем, чтобы расстояния, пройденные командами (суммируется заданное автором расстояние между пройденными уровнями) было приблизительно равное???

Будет не честно, если "расстояние игры" одной команды будет 100км, а другой команды - 1000км

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

Всегда выполняется :)
Значит прокатит!

Ну воть и проблема с расстояниями и решена...в предедушем посте лучше заменить второе словосочетание "количества команд" на "количества заданий"...утро понимаете:)

Что-то тема дальше флуда не уходит...Кто ответственность на себя берет за выполнение данной задачи?

Походу никто.
Желательно было бы, чтобы в движок можно было входить не только члену кц, а чтобы задания сразу моги смотреть многие, безопасность реализованна так (про дозор) была сделанна в свое время авторизация по логину(чел должен быть добавлен в команду) и логину капитана и пинкоду на игру.....

хм... не совсем сюа, но имхо полезно - когда забивали статистику, попробовали войти в агт с двух ноутов, висящих на 802,11 точке после DHCP сервера. услуга провайдера - динамический ай-пи. так вот, вполне упешно вошли в админку и забивали статы с двух компов. на играх, т.е. под логином-паролем команды пока не проверяли.

В агт почему то дата игры перескочила на год вперед
16.06.2008 - Приключение поручика Ржевского в Петербургской губернии.

Видимо, запускали игру, чтобы посмотреть, как она устроена, а потом не смогли вернуть назад - в АГТ нельзя выбрать прошлый год при редактировании игры, только нынешний и следующий. Надо править в базе вручную (Меееег?)

Тема закрыта или нет?
просто интересно стало

Волкер, про модификацию это как, майн моск не васпринимает инфу такую.

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

А про обрыв связи - это уже по ходу клиентский скрипт или консольное приложение или программа. Если уш на то пошло. то мона убрать web интерфейс и тупо написать прогу на делфях или си++ и не париться, там и обрывы проверять и "браузер" небольшой для заданий сделать. и прошу пользуемся... но смысл опять же, мона и по web интерфейсу получать задания.

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

Я пока могу морально на словах если что помочь, так сказать советом :) ибо сам прогер weba.

Я исправил. Не используя доступ к базе кстати. :)

Шайтан! :D

На прошлой игре произошел не очень приятный инциндент. Бонус вбитый в агт не был посчитан в итоговой статистике.
Как команда может обезопасить себя от технических проблем связанных с агт? Ведь во время игры нет технической возможности проверить принят боунсный код агт или нет. И чем должны руководствоваться организаторы в таких случаях?
В логах агт отмечен факт вбивания боунса до основного, однако то ли он был не правильно вбит (то есть не в то окошко, то ли еще что) но в статистике он никак не отражается. На данной игре организаторами было принято решение не засчитывать данный бонус. Хорошо что он ничего не решал.

Сенич, я могу показать логи агт. Бонус с уровня 03DR с маниакальным упорством вбивался в поле для основного кода. В данном случае орги порешали, что КЦ сами себе злобные буратины, если не попробовали вбить в поле для бонусного. Ибо для основных везде даже указывалось точное кол-во цифр в коде. Бонус этот был взят тремя командами, поэтому подозреваю, что речь идет не о сбоях агт. Так уж получилось, что у нас факт приема кода определяет агт, а не орги. Извините, если что не так. З.ы. и агт вроде подтверждает принятие бонусного кода, если его ввели до основного.

02.11.2008
00:37:00 Начало уровня "От Заката до Рассвета" 0 Одна команда на уровне
02.11.2008
00:58:08 Показ подсказки "От Заката до Рассвета" 1-я Время подсказки
02.11.2008
01:02:01 Попытка ввода ключа "От Заката до Рассвета" 0 Общий ключ #1 неверен ('D50162L')
02.11.2008
01:02:07 Попытка ввода ключа "От Заката до Рассвета" 0 Общий ключ #1 неверен ('D501562L')
02.11.2008
01:02:10 Попытка ввода ключа "От Заката до Рассвета" 0 Общий ключ #1 неверен ('D501562L')
02.11.2008
01:02:22 Попытка ввода ключа "От Заката до Рассвета" 0 Общий ключ #1 неверен ('D501562L')
02.11.2008
01:05:49 Попытка ввода ключа "От Заката до Рассвета" 0 Общий ключ #1 верен
02.11.2008
01:05:49 Завершение уровня "От Заката до Рассвета" 0 Ввод ключа

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

если это действительно так, то кц этого не знали.

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

а вот про это первый раз слышу. почему-то нормально всё потом засчитывает. если бонусный код был введен до основного, то потом как-то пофиг на то, пустое поле или нет.

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

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

Это, кстати, интересный вопрос - засчитывать ли код в таком случае, если по логам видно, что команда его нашла, но в нужный момент он введён не был.
Вопрос на самом деле сложный и неоднозначный. Представим, например, похожую ситуацию: нужен составной код, команда один из них ввела сразу, а другой искала почти до слива. А когда, наконец нашла - оказалось, что успела потерять и забыть первую часть, и в итоге слила задание. Ну или пусть не слила, но потратила лишних минут 5-10 на то, чтобы заново искать первую часть.
С одной стороны, можно засчитать уровень по моменту ввода второго кода, ибо формально условие "все коды найдены" выполнено. Но с другой стороны, в текущей ситуации есть ещё дополнительное условие - "для завершения оба кода должны быть введены одновременно". Разумность этого условия можно оспорить, но оно есть, и все команды предупреждены об этом заранее. Соответственно, почему команда, проипавшая код по собственной невнимательности, должна получать преимущество перед теми, кто не забыл об этом условии и сберёг код?

Раз вопрос обсуждается в теме "ТЗ на АГТ", то, как я понимаю, предлагается при написании новой системы сделать так, чтобы введённые зачтённые бонусы и части составных кодов уже не пропадали? Это будет грамотно, согласен.

Но пока новой системы нет - мы играем по условиям той, которая есть. И, соответственно, ошибка в работе с АГТ - проблема самой ошибившейся команды.
Это имхо) А в игре, как обычно, право решения за организатором)

а не думаете ли вы, что для соблюдения фаер плэй в таком случае придётся просматривать логи агт для каждой команды, выискивая, всё ли правильно товарищи команды ввели?
и в чём тогда смысл автоматизированной агт? время считать?
вот это точно бюрократизм...

Кстати, ещё по АГТ. Не совсем в тему, но, возможно, будет полезно.
Давно хотел написать, но как-то лапы не доходили.

Итак, пока у нас нет нормального движка, будем выжимать максимум из имеющегося. Есть способ, как с помощью бонусной АГТ в большинстве игр можно обойтись без асек вообще. Полноценно выдать все бонусы в нужное время и иметь возможность принимать коды по каждому из них в течение нужного срока.
Для этого в бонусной АГТ создаётся игра из ОДНОГО задания. Только одного. Но продолжительность задания - скажем, 12 часов. И к нему пишется, что должно быть 23 подсказки. (чтобы они приходили каждые полчаса). Соответственно, на самом деле приходить будут не подсказки, а новые бонусные задания - как раз в то время, когда нужно их выдавать. (не обязательно каждые полчаса, часть "подсказок" могут быть пустыми). Код на этом уровне задаётся составной - из такого количества частей, сколько всего у нас бонусных кодов. Все задания и коды нумеруются, чтобы не путаться, какой куда вводить.

И вуаля, мы имеем систему приёма кодов, когда бонусные задания открываются в нужное время, не теряются в недрах хистори, а любой найденный код можно в любой момент проверить на достоверность без участия аськокоординатора. Таким образом можно провести всю игру с бонусами, исключив аськи и человеческий фактор. Можно теоретически вообще не оставлять человека в орг-кц.

Конечно, после игры оргам придётся копаться в логах этого бонусного АГТ, чтобы смотреть, какая команда какие коды ввела. И переделывать статистику, чтобы каждый бонус красиво отображался отдельно. Но на самой игре для играющих команд всё будет выглядеть полностью автоматически. Этот метод был опробован на главной игре Найтфеста и показал свою полную состоятельность.

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

браво!! только проще бонусные прописать))) и будет ещё важным проконтролировать завершение бонусов и основной игры...

Ой, ой круто, я тоже с вашего разрешения ляпну.

Чесно лично я сам еще не видел внутренностей движка, как игрок, но что-то мне подсказывает, что в эти выхи я это сделаю. Ну да лано отступил много от конкретики.
В общем - зачем создавать отдельную гаму? Есть двига, а если нужно бонусы выдавать, так в чем же дело, ифрейм где-нить сбоку и вопрос решен. разделить интерфейс двиги на несколько частей, и для непонятливых написать, что тут вот текущее задание, тут вот вводите коды с него, а вот тут дорогие бонусы, на них столько то времени, и вводить нуна туда-то. Главное продумать как должно работать и выводиться, а про автоматизацию я согласен на 100 процентов. ибо считать после игры результаты, когда есть двига, не рационально по-моему. Так что я готов помочь чем могу обращайтесь. Может советом или описаловом какого нить процесса :)

Чесно говоря, мне было бы интересно поучавствовать в процессе совершенствования двиги и написания к ней ТЗ, ибо в данный момент занимаюсь именно этим, но для нового Московского проекта, пока название в секрете. ( пошется двига для сайта и движок для игры )

PS надеюсь потестить поможете.

Ребята, я понимаю, что тема - баян, но:

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

Если нету, можете отписаться в этой ветке, чего бы вам лично хотелось, если еще не отписывались?
Я попробую хотя бы собрать все вместе.

Спасибо.

Вань - это ты?

В теме по-моему написано многое, это всё можно собрать воедино.
+ то что в этой теме(кусочек правда, но есть)

Более того, как я вычитал, решение по АГТ будет рассмотрено на СК.
Сам АГТ проект устраивает, есть просто "нюансы" которые нужно править/изменить/дописать. С нуля писать двигу бессмысленно, хотя, возможно, у кого-то и есть наработки/разработки похожего двига.

Вопрос, просьба и предложение. Можно ли в агт изменить вид отображения графика прохождения уровней командами ? Просто сейчас эти графики совершенно не информативны, а ведь всегда очень интересно посмотреть динамику прохождения игры разными командами.
http://dead-line.spb.ru/agt_dlone/im...=6&rnd=9746197
Вот тут вообще нихрена не ясно, а часть команд вообще белыми линиями выделена .

Потому что количество линий в графике строго определенное. Линии распределяются в порядке первого обновления АГТ командами.

оно понятно. Я же спрашиваю не почему не отображаются линии, а можно ли изменить вид отображения . Возможно сгладить линии, растянуть картинку(особенно по вертикали) или как то кардинально поменять отображение. Можно ли вообще провести эти изменения ?

Этот вопрос к разработчикам скорее.

А у меня вот сложилось впечатление, что линии распределяются в порядке алфавита и белыми линиями отмечены команды, называющиеся кириллицей и начинающиеся с буквы С в данном случае.
Соответственно, вероятно, есть какая-либо возможность: а) добавить цветов (сейчас их 16); б) повторять цвета (№17=№1,...); в) сделать для команд, начинающихся с 17, общий не белый цвет; г) сделать для графика не белый фон.
Разумеется, все это можно сделать только в том случае, если кто-то вообще в состоянии руками подправить АГТ, а также, если этот кто-то не считает это занятие абсолютно бесполезным)

А кто-нить потрогать АГТ дать может?
И сдвиги какие-нить есть в усовершенствовании системы, или только слова?

Просто "потрогать" АГТ нельзя. Это проприетарная система.
Сдвиги будут, когда кто-нибудь всерьез решит этим заняться. До сих пор таких прецедентов не было, всё ограничивалось, увы, "только словами". Что неудивительно, учитывая объем работы (несколько сотен человеко-часов), и тот факт, что в данной отрасли очень хорошо известна цена рабочего времени.

ок.
А рассматривается только web интерфейс?
Или программа работающая под винду к примеру?

Плохая идея, другое дело, что если найдется энтузиаст, который владеет ASP.Net и напишет с нуля движок, то поставить его на виндовый хостинг большого труда не составит.

Ну если я не ошибаюсь, лицензия включает в себя право неограниченной доработки движка для использования в своих целях.
Хотя, что показательно, Гродно уже отказалось от своего движка и перешло на движок EN)

А смысл?
Я предлагаю клиент под винду, сервер остается любой хоть винда, хоть линуха. Главное БД mysql и php на серваке. А клиенту только обработанная инфа.
Ну видишь, не дают пощупать движок.
Сказать, что "йоптить, да я готов переписать какие-то части кода", без просмотра такового, может он написан настолько коряво, что его и читать сложно, не то что переписать отдельные куски.

Что в этом клиенте такого будет интересно, чтоб городить трехзвенку такую, да еще и платформозависимую? Ужос :eek:

скорее всего так и есть =)

Ну если посмотреть, php возможно и нах не нужно будет.
Клиент-сервер.

Яж просто предлагаю, не говорю, что это писец как круче будет чем в web интерфейсе!

Вот о чём и разговор.

...который постоянно виснет, не справляясь с нагрузками.

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

Что плохого в php?

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

А еще большой минус в таком варианте в том, что, к примеру, толковых программистов на php дохрена, а вот программистов на Cи (если клиент на нем будет разработан) заметно меньше. И если, вдруг, разработчик отойдет от дел, то потом найти человека, который способен будет внести изменения в программу, будет еще более проблематично, чем сейчас.

P.S. А я бы тоже поковырял бы существующий движок. Заодно узнаю как его взломать можно. =)) Шучу. =)

P.P.S. Но, честно говоря, если посмотреть как он работает сейчас (а я представляю какая там каша в коде), дешевле будет написать новый с нуля.

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

Я не предлагаю нам перейти на EN, просто раз даже Гродно проще было перейти на EN, чем дорабатывать свой движок - это показатель кривости кода, имхо)

Кто говорит что php плохо? просто если это виндовое приложение, то php будет выступать в меньшей степени, он будет просто в помощь, обрабатывать минимум инфы, всё остальное будет делать клиент.

А может есть какая нить ваааще первая версия двиги? не та которая сейчас, чтобы хоть её глянуть.

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

Есть где-нить написанное ТЗ на движок ДЛа? как писался существующий, мож реально проще новый написать? дизайн - да тех кто нарисовать его может в проекте много людей.

По большому счету ТЗ для такого двига изначально небольшое:
1. регистрация/аутентификация.
2. Ввод и вывод данных для игр
3. Ввод и вывод данных для команд
4. Счётчик каждого уровня.
5. Статистика-лайт просто подсчёт времени на уровнях + сливы, не всё так сложно.
6. Безопасность вводимых данных, и безопасность от "кривых" рук пользователей и вредных людей, вроже хакеров, которым интересно поломать системки, узнать их косяки.

При грамотном построении ядра модули для начального тестирования пишутся от часа до 5, и их уже мона тестить и дорабатывать.

Вот 6 наверное основных, а всё остальное накручивать можно до хреновой тучи, зная как происходит программирование по проектам, лучше изначально написать Лайт двиг, чтобы потом можно было сразу его дорабатывать и подключать к нему что-то новое, нежели сразу писать что-то тяжелое и ХЗ как оно работать будет, если и будет.

Написать то не сложно, тут как ДРК правильно написал, что человеко-часов много, и это действительно так. Но с учетом того что, что-то уже есть написанное+есть разработки у самих программеров, которые работают или программируют на связке php+mysql от 2х лет, у них и опыт, кто больше работает у них и оптимизация скриптов есть. Можнож разделить всё, одни прогят, вторые оптимизируют, третьи тестят (кнопкодавы :D ).

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

В общем нужно ядро, и от него уже плясать. *взял бубен и сел, ждет комментов*

Я так понял, что нашелся программер на PHP? Тебе нужно ТЗ? Думаю, если никто ничем не рискует, то инигруппу авторов ТЗ на встрече капитанов создать не сложно. Не выгорит - жаль, но не страшно.

Еще раз объясню фундаментальную проблему IT-разработок в нашем и подобных нашему проектах.

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

Способ номер 1. Берём тех, кто есть; студентов-программеров средне-старших курсов, специалистов-кодеров начального уровня, и прочих раздолбаев. В результате имеем систему, которая может даже и написана не криво, но совершенно не отвечает изначальной задаче (хотя бы потому, что эту задачу никто внятно не поставил). Фэйл.

Способ номер два. Берём профессионалов, платим им кучу бабок, и получаем в итоге либо нечто, отдалённо напоминающее то, что нам нужно (если поленились грамотно выбрать исполнителя и сформулировать задачи системы), либо то, что нужно (если не поленились, но за _большую_кучу_бабок_). Поскольку бабок нет вообще, то фэйл.

Поймите, друзья, я не брюзга; я лично кучу нервов и времени на этом убил за последние 5 лет. Если кто-либо готов своими _действиями_ опровергнуть мои утверждения - я буду только рад. И, подозреваю, что не только я.

Ну как нашелся, скажем так готов принять участие в проекте.

Дык вариант того взять написать ТЗ, понять что нужно, но опять же изначально писать не сразу всю систему, а частями т.е. сделать beta версию lite её посомтреть потестить, и потом её крутить до нужной консистенции, изначально повторюсь, нужно ядро системы, это могут быть несколько файлов конфиг+обработчик скажем адресной строки и модулей. Остальной разбор полётов будут осуществлять сами модули.

Можно ж взять и кучу студентов, но нет в этом большого смысла, имеет смысл взять несколько программеров, готовых работать на энтузиазме и при рабочем варианте можно же и бабла получить + если система действительно будет работать, то и продажа с авторскими правами такой системы будет очень круто! :)

Имеет смысл собраться и поболтать. Я бы в коллекцию портфолию взял бы проект движка - это было бы отлично.

Shrek-Ogre, если бы ты взялся писать такой движок, ты бы его делал на связке php+myasql, на чистом php или использовал бы какие-нибудь фреймворки?

Есть куча этих самых фреймворков, но смысл того что они громоздки многа кода и многа букв. Но Jquery вполне бы взял, хотя его можно и своими скриптами сделать, ибо Jquery я начинал узать как ajax для передачи серверу запросов и отдачи от сервера ответа. Менюшки и прочее можно итак написать. А уж красивое и "ползающая" инфа на сайте не всегда круто.

Да, у них есть и плюсы свои, я бы на zend framework мог бы начать писать, он мне ближе. Но хрен знает как он себя поведёт, что из него нам нужно, если только то что он MVC так это и так написать мона, у меня свой двиг для сайтов написан как MVC. по-этому ХЗ сказать что тут нужен какой-то фрейм из тех которые есть пока не могу, да они в связках с jquery работают, с ajax в "голом" виде. Естественно велосипед изобретать желания нет. Сейчас пишется двиг для некой соц.сети если так мона назвать, вот там используется новое ядро двига моего, более усовершенствованное + оптимизированное под нагрузку, и оптимизируется с каждым новым разом, когда нужно.

Так что тут нужно обговаривать всё что нужно и всё что не надо юзать в игровой системе.

Просто, если бы ты собрался писать, к примеру, на связке Zend Framework + jQuery (или Dojo), то я бы тоже с удовольствием вписался бы в проект. А так, не. =))

Развели холивар =)

Как-то слишком рано начался разговор о выборе платформы, пхп/не пхп, фрейм/не фрейм. Какая сейчас разница-то? Разговоры об оптимизации вообще пугают. Какая нагрузка на агт? Сотня человек единовременно хоть набирается? Думаю и то вряд ли.

А проблема совсем в другом. В том, что невозможно в наших условиях сделать качественный продукт. Не рождаются они на энтузиазме. Почти на 100% уверен, что получим еще одну кривокосую софтину, ничем не лучше нынешней. Ее единственным плюсом будет то, что с кодом будет кто-то плотно знаком, ибо писал сам. Но это плюс на первый год. От силы два. Потом вернемся к тому, что есть сейчас. Хорошо, если хуже не будет =)

По поводу того, что хорошие проекты не рождаются на интузиазме. Обрани, пожалуйста, свое внимание на проекты под лицензией GNU. ;)) Многие из них рождались на чистом интузиазме и продолжают быть наиболее успешными.


P.S. Мы тут ничего не разводили. Просто Shrek-Ogre сказал, что готов взяться за проект. А я сказал, что я бы подключился бы только если бы проект разрабатывался с использованием тех технологий, с которыми мне удобно работать. А в другой ситуации я пас.

Вот и все. =))

Кто говорит о том, что проект не получит должного?
ZORGer прав в этом плане, но мы конечно не претендуем на Звание полученное линухом, как изначальное GNU. Мы можем собрать проект внедрить, показать и продать.

Так. Стоп =) Я, если че, совсем не против. Будь я хоть чуть-чуть пхпшником, даже скорее всего поуствовал бы.

Вообще согласен с Дрк. Он очень правильно и внятно проблемы расписал.

А кому ты продавать собираешься? =)

Спасибо.
Меня, вообще говоря, сразу же смущает, когда обсуждение какой-либо системы начинают с выбора платформы разработки.
Если быть более циничным, то это бугага, товарищи. Кому нахрен сдалось, будете ли вы это делать на лампе, или на дотнете, или еще фигзнает на чём. Это же совершенно не важно.
Начинать надо не с этого. А с целеполагания. С ответа на вопрос "зачем?"; "что мы хотим получить?" и т.п.

Так что извините, sandbox он и есть sandbox.

Я бы на твое бугага, ответил бы своим бугага.
Очень немаловажную роль играет средство реализации. А на мой взгляд, так очень даже важную. Ну, если тебе все равно, можете писать на бейсике. =))

P.S. Да, безусловно, первое дело, это постановка задачи и проектирование системы. Да, конечно, я с этим не спорю, более того, все проекты собственно так и делают.

Просто у нас с Shrek-Ogre разговор зашел о средстве реализации, и не более того.

Средство реализации выбирается, исходя из поставленных задач.
В такой постановке вопроса окей, нет проблем.

Дык, продать можно любому проекту, тому же дозору с его глупым двиглом (видел код и бд :) ) таким же проектам как ДЛ, EN.

Ну на чем писать-то понятно, что тут похрену.
Давайте встретимся, выясним что нам нужно, как должно работать, чтобы сдвиги были с мёртвой точки.

Я бы ещё послушал плюсы Zend Framework от ZORGer если он не против, у меня просто времени особо небыло углубиться в него.

Ну я вот точно не возьмусь писать на С или С++ ибо тупо у меня с практикой написания проектов на Си небольшое, на Delphi не вопрос, а раз многие проекты построены на php или perl, то я склоняюсь к ним, да и сам я web-программист, а не системщик.

Готов оказать помощь в написании самой задачи, и принять участие в разработке. (пусть всё вышесказанное мной будет объединено в одно предложение)

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

В контексте текущей темы, это утверждение равно посыланию нахер любого энтузиазма.

Чего смешного?

На словах целеполагать все всегда готовы =) На самом деле это всегда самая большая проблема. И если ее удастся решить, будет смысл дальше разговаривать - энтузиастов искать и со средой определяться. Сейчас это тоже не вредно обсуждать, но оно вторично.

Потому что это смешно.
Ну давайте мы веб-проекты будем писать на бейсике, а системный приложения на Лиспе. Мне лично смешно. Может быть это только у меня юмор такой плоский. =)
Но по-моему, мы тут уже в сторону влуда уходим. ;)

Все бы было так, если б движка EN сейчас не существовало.

Поболтал с Cratonом.
Давайте на ближайшем СК вынести вопрос про Новую систему игры.
Где капитаны выскажут свои предпочтения для того что по их мнению будет иметь смысл + туда же позвать тех самых энтузиастов готовых вписаться в идею разработки.

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

Нет, просто ты не знаешь что такое .net технология.

Темыч, знаешь сколько уже вас таких энтузиастов было в проекте? =))

С тебя убудет?

Эт про меня щас? :rolleyes:

Ну я не один кому будет интересно принять участие. По-этому ;)

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

Да нет, конечно. Много, очень много было людей, которые брались доделать/дописать/переписать/сделать свой движок для нас. И только одна попытка хоть как-от реализовалась - бонусная игра от ОтВинта по Пункту Назначения.

Дык, тут все говорят о том, что АГТ работает не должным образом для нынешних игр проекта. Про продавать, я так к слову сказал-"а вдруг" заинтересует кого-нить.

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

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

Аааа, понял тебя. =)
Нет, я знаю что такое .NET, более того, у меня был очень небольшой опыт работы на C#.NET. Просто, в своей подколке про бейсик, я не имел ввиду вижуал бейсик.
Но, в общем, проедем.

P.S. Согласен, на СК можно будет обсудить этот вопрос с конкретикой.

Может капитаны и не смогут внятно описать то чего хотят, но вот те кто будут разрабатывать может их понять и написать на "русском" языке.

Я бы поприсутствовал на СК при обсуждении этого вопроса.

Нивапрос!

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

Обычно как раз наоборот:))

Давайте тогда сразу поднимем вопрос допустимости открытия домена dead-line.en.cx и проведения игр там? Для комплекта, так сказать.

В общем на таком уровне и надо.

На самом деле это делается совместно. И никак по-другому.

когда СК? :)
Лоу, напиши тогда в теме СК, пусть капитаны заранее подготовят варианты нужных вещей в системе игры.

Я тебе отдельно скажу, когда СК.

А где это показывают код дозорного движка, а?

Не надо никаких сей и дельфи. Наличие связи проверяется из javascript прекрасным образом. Правильное решение - кнопка "обновить", которая работает только при наличии связи, и возможность автообновления по таймеру, работающего по тому же принципу. Или уже full ajax, но на мобильных браузерах с этим могут быть проблемы. Желательно ведь, чтобы даже в опере-мини работало.

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

Чё за проект, что за движок?)

Мотивируй необходимость отдельной программы.
Разговоров много, а ответа на вопрос "зачем" я пока не встречал.

единственный профит от десктопного интерфейса к движку, который я смог придумать, - это возможность настройки гуя, но кому это надо?

правда, win-приложение может общаться с серваком через tcp вместо http, но хз, насколько это будет быстрее.

а вот если объединить навигатор и интерфейс к движку, то можно делать всякие интересности вроде предоставления оргами карты зоны прямо в навигаторе, орговских пометок на игровой карте (в тч привязанных к заданию), стилизации карты под игру и тп :rolleyes: