Синтекси: Универсальный плеер интерактивных книг-игр / Сообщество / КвестБук

^{Пт Май 16, 2008 10:20

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Для того, чтобы не путать понятия в разговоре, стоит посмотреть для начала эти книги-игры:

Зыков И.А., Stone of Shady Sands («Камень Шейди Сэндс»)
Высотка

Что их объединяет? Они написаны как полноценные игры – свой интерфейс, графическое оформление и т.д.
Плюсов и минусов у книг в таком виде не мало, но мы сейчас смотрим только на плюсы.

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

Просьба не путать с qsp, urq и подобными – это совершенно другое.

Цель – получить программу, которую будет (относительно) несложно переделывать под конкретную книгу-игру.

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

Требований, как видите, не мало. Поясню, что все компоненты, по возможности, должны быть максимально... независимы. Не надо на каждом шагу изобретать велосипед. Так, например, для структуры хранения параграфов желательно использовать xml (как вариант – база данных access, но это уже тяжеловесно), такие варианты как хранение строк с разделителями – нежелательны (надо ли пояснять почему?).
По поводу скриптов, здесь тоже не надо самодеятельности – qsp, urq и подобные движки используют самописные парсеры, что вызывает массу неудобств и нюансов. Необходимо использовать что-то общедоступное, такое, что сам язык будет развивать отдельное сообщество. Я в нескольких проектах использовал язык Lua (www.lua.org) – он легок, и к нему есть документации даже на русском, предлагаю его.

Но вот есть несколько сложностей которая нас разобщают. Один из них – среда программирования. Я для проектов подобного уровня, предпочитаю c++ в среде c++builder2006. Но, я так понимаю, далеко не все программируют в этой среде. Delphi для таких проектов, лично я, не хочу – в большом проекте синтаксис паскаля меня начинает сильно напрягать своей неудобностью. Ещё два представителя животного мира – visualc++ и c# (этот я вообще обхожу стороной) подразумевают очень грандиозные размеры проекта – так как намного больше придется взять "на себя", они больше подходят большим командам.
В общем, этот вопрос надо обсуждать.

Теперь, обсудим организацию всего этого. Сейчас лично у меня много незакрытых проектов, я не могу начинать ещё один. Да и размер проекта не мал – один могу не справиться. Надо организовывать совместные разработки. Поэтому предлагаю обсудить все вопросы касающиеся организационных моментов. Можно обсудить объектную модель и нюансы реализации платформы. Предостерегаю – не надо сразу писать что-то законченное, работать будем постепенно – обсуждая каждый шаг – торопиться нам точно некуда.
Скорее всего, совместную разработку организуем на основе патчей – код будет общедоступен, а любой желающий сможет прислать свои изменения.

И на последок, чтобы обсуждение было понятным всем, давайте условимся:
дизайнер – человек, который переводит книгу-игру в интерактивный вид (может быть и автором и программером...)
автор – автор книги-игры
программист – человек участвующий в разработке движка
(это, конечно, обсуждаемо)

Этот пост я буду корректировать по мере того, как в ходе обсуждения мы будем приходить к каким-то решениям

^{Пт Май 16, 2008 14:19

Доступные действия:}

Piligrim
³ ^{Меценат}

идея хорошая, в результате получится полный комплекс программ для книгр. еще один из вариантов хранения данных SQLite. К сожалению я принадлежу к тем кто не приветствует С++, т.е. к дельфистам, кстати в своих проектах использовал Innerfuse Pascal Script Sad

_________________
Все движется... Иногда даже вперед!

Написать комментарий

^{Пт Май 16, 2008 14:21

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Ну, я тут где-то вычитал, что по-идее, в проектах среды borland developer studio 2006 можно объединять дельфи и си, правда я такого ещё не делал.
Вообще, какие предложения будут?

Написать комментарий

^{Пт Май 16, 2008 14:38

Доступные действия:}

Piligrim
³ ^{Меценат}

про объединениеэто интересно, тоже почитаю, придется BDS 2006 поставить, а то я на D7 остановился пока.
я так понимаю пишется оболочка, как можно более универсальная, для собственно процесса игры, сама книгра состоит из двух частей, отображаемой и скриптовой или это будет полностью скрипт вида (не считай его самописанным, это только для примера Smile )?

back "img15.jpg"
echo "Вы поворачиваете за угол и видите тяжелую железную дверь."
select 300, "Используете мастерство взломщика"
if(items("key")){
select 425, "Открываете дверь ключом"
}

ЗЫ: как мы это реализуем в myis?

_________________
Все движется... Иногда даже вперед!

Написать комментарий

^{Пт Май 16, 2008 14:53

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

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

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

if (v.money > 10) then  -- предмет куплен  inv.add('item123', 1); // в инвентарь положить 1 предмет item123  v.money = v.money - 10;  else  -- не хватает денег  -- вариант сообщения 1 (текст отдельно от программы)  para.txt = text_by_key("not_enough_money") // в списке сообщений будет найден текст с ключом и показан вместо изначального текста  -- вариант сообщения 2 (текст в программе)  para.txt = "У Вас недостаточно денег";  para.cancel_show(); // говорит что на этот параграф игроку переходить нельзя, ему будет высвечено сообщение и переход "назад"  end    // скрипт завершается, осуществляется вывод параграфа на экран

здесь:
v – сборник разных параметров и переменных (можно будет разделить или сделать по-другому, сейчас неважно)
inv – инвентарь
para – предзаполненные данные параграфа согласно номеру параграфа (включая переходы) – из некой библиотеки параграфов

Не уверен что этот пример работоспособен на луа, мог и ошибиться, но тут есть пример – как можно сделать то о чем ты говоришь. Вариативность довольно большая, например txt_by_key можно сделать методом какого-то класса, того же para или ещё как. Не суть – так мы можем делать универсально, и в тоже время, делать так чтобы было легко неопытным – ведь целевая аудитория программы не всегда будет достаточно квалифицирована в программировании.

Кстати, надо ещё будет обдумать эдакого визуального рисования скриптов – для несложных скриптов это думаю возможно

Добавил через 1 минута:

Да, ещё по поводу скриптов – наверное надо будет сделать многое на основе "событий", но об этом сейчас ещё рано

Написать комментарий

^{Пт Май 16, 2008 15:04

Доступные действия:}

Piligrim
³ ^{Меценат}

все понятно. что-то похожее я делаю и в мобильной версии, только там у меня скрипт на основе XML.
из опыта хочу сказать, что с получением полной интерактивности книгра теряет часть "личности" Smile ведь в книгре довольно часто пишется: "Если у Вас есть колба зеленого цвета, Вы можете отдать ее дракону", а в интерактивной версии скрипт отработает отсутствие колбы и даже не покажет такой вариант событий, хотя с другой стороны это повышает играбельность при повторных попытках прохождения Surprised
похоже надо вылезать в асю и работать над ТЗ. Если честно, мне это все-таки ближе чем BS и гексы Embarassed

Написать комментарий

^{Пт Май 16, 2008 15:11

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Piligrim
даже не покажет такой вариант событий, хотя с другой стороны это повышает играбельность при повторных попытках прохождения

В космических рейнджерах это решено очень красиво – пункт есть, а выбрать его нельзя Smile

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

Написать комментарий

^{Пт Май 16, 2008 19:50

Доступные действия:}

Monax

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

Насчёт объединения Си и Дэлфы – маразм конечно, если уж так надо, то есть конверторы которые исходники Дэлфы конвертируют в исходники Визуал Си и наоборот, сам конечно же этим дейсвом не увлекался, ибо нет причин. Всё, что мне нужно(и не только мне) я могу создать по средствам Дэлфы. 7-я вполне актуальна и достаточна, в 8-й просто усиление на Вэб.

Насчёт таких моментов как "Отдать дракону, если есть", то это в моей проге обычное условие к пораграфу(есть такой скрипт у параграфов), так что с этим проблем я не встретил, единственное над чем надо было подумать – это "Если у вас есть этот меч, то этот враг получает на 2 дамага больше", но я справился с этим, приписав в базу данных врагов артефакты и урон от них.

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

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

Написать комментарий

^{Пт Май 16, 2008 20:22

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Monax
игры будут получатся как с конвеера – разные с лица, но одинаковы скелетом

Внутренностями. И только. Между прочим, скелет у людей очень похож, но сами люди почему-то выглядят по-разному Smile
Прошу не путать с движками текстовых квестов. Суть идеи, дать возможность дизайнеру сделать такую игру какую хочет – даже в визуальном смысле. Да, что-то может быть похоже в силу различных причин, но то, что кнопки можно будет двигать – я уверен Smile
Кстати, так как исходники всё-равно будут открыты, скомпилировать с изменениями "для себя" всё равно будет возможно.

Конвертировать исходники не будем, это точно. Я подумываю сделать объединение, как вариант, на уровне отдельных dll-ок. Это должно быть довольно удобно.

Monax
Насчёт таких моментов...

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

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

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

Monax
Насчёт фуллскрина и Директа, если юзать в директе 2Д графу

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

Написать комментарий

^{Пт Май 16, 2008 21:54

Доступные действия:}

Piligrim
³ ^{Меценат}

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

_________________
Все движется... Иногда даже вперед!

Написать комментарий

^{Пт Май 16, 2008 22:54

Доступные действия:}

Monax

Я о том, что в фуллскрине интерфейс win32 пользовать не получится, а значит, надо писать все необходимые компоненты и связанные с ними нюансы

Ессесьно! Для этого и надо дизайнеров хороших) Всё с нуля, я и в 2Д так же делаю – мало компонентов использую, поэтому и имел ввиду что разница небольшая будет)

Написать комментарий

^{Пт Май 16, 2008 23:00

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

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

Сами подсистемы, наверное надо сделать по принципу конструктора – "на выбор", например
video: win32/directx/sdl/...
sound(+библиотека музыки): fmod/...(?)
script: lua/basic/...
data: xml/sqlite/mdb/...
это как пример

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

Monax
Для этого и надо дизайнеров хороших)

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

Написать комментарий

^{Пт Май 16, 2008 23:21

Доступные действия:}

Piligrim
³ ^{Меценат}

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

_________________
Все движется... Иногда даже вперед!

Написать комментарий

^{Сб Май 17, 2008 8:53

Доступные действия:}

К. Киламов
² ^{Свободный искатель}

А мне нравится ваш настрой! Smile
Так деражать!

Написать комментарий

^{Сб Май 17, 2008 13:12

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Piligrim
сменить отображение из оконного в полноэкранное

Тут ещё одна подковырка есть... ресурсы для этих режимов – одно дело вывести графику в окно, скажем 640×480 – графику подготовили под нее, всё ок. А тут, в игре менается на фуллскрин 1024×768 – графику под этот режим что, растягивать? Получается, ресурсы должны лежать пачками согласно используемому разрешению.

Таким образом, теоретически, exe-ник программы будет представлять из себя нечто навроде лаунчера – он запускается, ищет файл описателя игры, устанавливает начальные параметры, и ищет описания подсистем. Если из подсистем есть выбор (win32/фуллскрин) то в игре можно будет выбрать между ними.

Для каждой подсистемы, ещё надо хранить параметры. Например для подсистемы книги-игры (параграфов) – имя файла например. Плюс, будут спепцифические параметры для реализаций подсистем, например для режима win32 ничего толком не надо, а для dx – кучу всего.

Ну а теперь интереснее. Насколько сильно мы будем внедрять скриптовый язык? Объяснюсь. Можно скриптовым языком управлять только книгой-игрой – параметрами и т.п. А можно – что скрипт сам по-себе будет управлять ВСЕМ движком, т.е. даже руководить созданием окон, интерфейсом и т.п. Можно сделать что разные потоки (т.е. не связанные никак) скриптов раздельно управляют интерфейсом и игрой. От этого вопроса, зависит достаточно многое. В первом случае, мы просто сделаем несколько предопределенных окон (меню, сохранить/загрузить, игра, параметры...) которые можно будет только настроить. В остальных, надо будет из скрипта их создавать, рулить ими по полной и т.д.

Написать комментарий

^{Сб Май 17, 2008 20:41

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

У меня получилось использовать модуль и форму дельфи в проекте для билдера. Форму просто включил проект, потом юнит скомпилировал (отдельно) – сгенерировался заголовочный файл .hpp для формы и проект скомпилировался, фсё заработало

Написать комментарий

^{Сб Май 17, 2008 21:06

Доступные действия:}

Piligrim
³ ^{Меценат}

Второе, конечно, очень заманчиво, но тогда где граница между программой и скриптом? И нужна ли, вообще программа? Если я правильно понял, тот же луа есть и отдельный.
Надо у ребят спросить BDS 2006 Smile

_________________
Все движется... Иногда даже вперед!

Написать комментарий

^{Сб Май 17, 2008 21:10

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Да, луа можно использовать отдельно, но как ты отобразишь графику?

А бдс мог по частям выложить на скачивание

Написать комментарий

^{Сб Май 17, 2008 21:20

Доступные действия:}

Piligrim
³ ^{Меценат}

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

пока не надо выкладывать, в понедельник брошу клич, просто самому на рынок лень ехать

по формату книгры: это xml, в котором, внутри текст скрипта?

_________________
Все движется... Иногда даже вперед!

Написать комментарий

^{Сб Май 17, 2008 21:31

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

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

можно делать xml all-in-one – для хранения, но на этапах подготовки и этапе игры они должны быть разделены – для удобства дизайнеру

Добавил через 2 часов 55 минут 41 секунд:

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

igb.gif (13.25 КБ) : 464 раз(а) Скачать
violet.rar ^{1.53 МБ}

Загрузок: 575 раз(а)

Написать комментарий

^{Пн Май 19, 2008 10:07

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

Только, наверное я забыл ещё добавить подсистему ресурсов игры (графика, звук, скрипты...), например IResource_subsystem, и реализацию – VirtualDir_ResourceSubSys – на этапе разработки просто каталог с подкаталогами, который потом становится одним сжатым файлом ресурсов.

Написать комментарий

^{Пн Май 19, 2008 12:27

Доступные действия:}

APROMIX
¹ ^{Свободный искатель}

Интересный проект! Насчет переноса кода Си в Дельфи, то переноситься все на 100%, мне приходилось так делать не раз, так что можно отдельные классы делать и там, и там, а потом объединять в одно целое, скажем, на Си. Можно также исп. перекодировщик и подобное. В выборе языка, как я вижу, нет проблемы Smile А ЛУА – это вобще сказка!!! Прост и удобен. На Дельфи у меня есть наработки 2Д движка ДиректИкс, все четко работает, хотя есть некоторые проблемки со звуком Smile Проектик, как мне кажется, долгостройный, без обдумывания и четкого планирования соваться не стоит Smile И устраивать всех на 100% не сможет :cry:

_________________
Плееры интерактивной литературы QuestBox и IFPhoenix

Написать комментарий

^{Пн Май 19, 2008 14:41

Доступные действия:}

Nex
^Путник

Скажу по первому посту, т.к. всё дело в нём.

Если вкратце – вы опять изобретаете велосипед.

Например, QSP удовлетворяет всем требованиям, которые заявлены для "нового супер-движка".

Jumangee, ты плохо знаком с QSP.

По поводу скриптов, здесь тоже не надо самодеятельности – qsp, urq и подобные движки используют самописные парсеры, что вызывает массу неудобств и нюансов. Необходимо использовать что-то общедоступное, такое, что сам язык будет развивать отдельное сообщество. Я в нескольких проектах использовал язык Lua (www.lua.org) – он легок, и к нему есть документации даже на русском, предлагаю его.

Есть новая уркообразная платформа Милена, которая использует немного доработанный язык Lua.
В QSP язык самодостаточен, ему не нужны Lua-расширения, т.к. в нём уже есть всё, что необходимо для написания текстовых игр.

Синтаксис скриптового языка – это очень важно для текстовых игр. Он обязан быть максимально простым и понятным для непрограммиста. QSP я считаю таковым. Lua, PHP, C# и пр. я таковыми не считаю. Урка ещё проще и понятнее, но у неё слишком много других недостатков.

вызывает массу неудобств и нюансов

Какие же неудобства и нюансы создаёт язык QSP? Расскажи, обсудим.

На мой взгляд, для ваших целей всего лишь надо сделать удобный редактор для QSP.

Написать комментарий

^{Пн Май 19, 2008 14:58

Доступные действия:}

Jumangee
^{Во всех бочках затычка}

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

Дело не только в синтаксисе, не только в парсере...

Nex
Какие же неудобства и нюансы создаёт язык QSP? Расскажи, обсудим.

Приведи мне пожалста примеры создания игр-квестов на qsp (милена, не суть) которые бы выглядели как упоминавшиеся "высотка", "soss" и "путь героя" ???
Скажем так, того что есть в qsp достаточно для квестов, но недостаточно для полноценной игры. Даже изменить интерфейс окна из квеста не получится.

Я хорошенько прошёлся по qsp и с уверенностью могу сказать – qsp с лихвой делает то что от него можно потребовать. Но может потребоваться и намного большее.

Да, синтаксис qsp не сложен, для тебя и меня. Но для непрограммиста – это всё равно язык который надо изучать. Т.е. делать квесты (программировать) всё равно будет человек это умеющий. А умеющему – что qsp что Lua (да хоть свой парсер прикрутить – было б желание) одинаково. Но блин, не в этом дело...

Я же написал сразу – это не убийца qsp/urq! Этот совсем другое! Да, возможно писать игры для него (правда термин не подходит) будет сложнее, но и задачи он будет решать совсем другие!

Кстати, скажи Nex а исходники qsp открыты?

Добавил через 46 минут:

Прошёлся по if-wiki на предмет того чего ещё не видел – схожих движков-проектов нету.

Написать комментарий

^{Пн Май 19, 2008 16:31

Доступные действия:}

Nex
^Путник

Jumangee

выглядели как упоминавшиеся "высотка", "soss" и "путь героя"

Ты имеешь в виду возможности оформления?
То есть, нужно чтобы возможности оформления и "перестройки" интерфейса были больше чем в QSP?

скажи Nex а исходники qsp открыты?

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

для непрограммиста – это всё равно язык который надо изучать. Т.е. делать квесты (программировать) всё равно будет человек это умеющий. А умеющему – что qsp что Lua (да хоть свой парсер прикрутить – было б желание) одинаково. Но блин, не в этом дело...

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

Т.е. делать квесты (программировать) всё равно будет человек это умеющий.

Многолетняя практика показывает, что это не так. Автору игры непрограммисту в большинстве случаев легче освоить простенький язык, чем сразу обратиться за помощью к "знающему". И он обязательно попробует, когда возникнет необходимость. А если попробует и увидит что скриптовый язык сложен (ну или несложен, но требует соблюдения строгих правил и привычки), если не сможет разобраться в азах и построить работающий код за 10 минут, то плюнет и разочаруется.
Велосипедисты всегда плевали на этот аспект, и получили по заслугам. У них просто нет авторов. Не стоит повторять их ошибок.

Если уж так хочется сделать "круче всех", и обязательно "своё", то учитывайте желания будущих авторов. Я не говорю "пишите на QSP", я лишь предостерегаю от клепания кривых велосипедов. Если ваш велосипед получится красивым, блестящим и будет к тому же быстро ездить – я буду только "за". С онлайновым редактором у вас вышло неплохо, хоть он ещё и не готов.

Написать комментарий