Отправлено: 24.02.09 22:03. Заголовок: QSP на SDL

Может, у кого-то есть желание реализовать сабж?
Некоторым будет удобно - например, для визуальных новелл :)

 Отправлено: 24.02.09 22:34. Заголовок: Я начинал делать под..

Я начинал делать подобный проект, суть идеи можно посмотреть здесь: http://wiki.jumangee.net/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5_%D0%BA%D0%BD%D0%B8%D0%B3%D0%B8-%D0%B8%D0%B3%D1%80%D1%8B:SINTEXI#SINTEXI. Я хотел реализовать возможность использования различных технологий (подсистем) - например не только sdl но и другие.
Вообще, подобный проект не должен быть только "новым интерфейсом", это должен быть немного другой подход к текстовым квестам. Например то, что из кода квеста должна быть возможность управления визуализацией и интерфейсом. Плюс, не только код игры, но и все данные игры (графика, музыка...) должны быть помещаемы в один игровой файл, при этом желательно так, чтобы файл был "невскрываем при желании автора. Конечно простой синтаксис qsp это хорошо, но надо сразу понимать, что проекты таких игр несмогут потянуть "начинающие" - это уже скорее будут достаточно большие и сложные игры - хотябы из-за необходимости сделать больше работы.
Игры, которым нужна именно такая платформа (имеется в виду - в виде полноценной игры) имеются в наличии. Например, авторы "Высотки" задумываются о продолжении.

 Отправлено: 25.02.09 07:12. Заголовок: Byte если ты имеешь ..

Byte если ты имеешь в виду не участие в "синтекси", а написание альтернативного SDL-GUI для "родной" qsp.dll, то почему бы и нет?
В таком случае мы получим:
1. Возможность собрать QSP-игру как stand-alone. Некоторым авторам это действительно пригодится.
2. Полностью кастомизируемый GUI. Для визуальной новеллы это необходимо, для некоторых текстовых тоже пригодится, при достаточном опыте разработчика.

Чего там не будет:
1. Продвинутых функций для работы с графикой из кода игры.

Получится движок для "среднего класса" разработчиков, бесплатный и простой движок.

Для первой версии "Высотки" хватило бы и этого.

 Отправлено: 25.02.09 16:20. Заголовок: Nex, я и не думал об..

Nex, я и не думал об участии в "синтекси" :)
Да, речь идёт об альтернативном интерфейсе для qsp.dll

 Отправлено: 25.02.09 16:59. Заголовок: Ну, теперь понятно. ..

Ну, теперь понятно.
Что ж, подождём ещё одну свободную пару рук.

 Отправлено: 26.02.09 03:41. Заголовок: Собственно мой QSP W..

Собственно мой QSP Way начался с сабжа. ^__^
И я очень давно хочу сделать таую штуку. Только не SDL, бррр...
Если руки найдутся - помогу, т.к. сам вряд ли в ближайшие несколько лет собирусь, только если проект какой сходный подвернётся.

 Отправлено: 26.02.09 11:25. Заголовок: Попытаться сделать х..

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

 Отправлено: 26.02.09 11:28. Заголовок: Можно начать с обдум..

Можно начать с обдумывания интерфейса :) То есть, на основе существующего QSPGUI можно представить то, что может делать гуй..

 Отправлено: 26.02.09 11:57. Заголовок: Думаю, пока не настр..

Думаю, пока не настрою в никсах компилер под WM, попробую что-нить соорудить ..

 Отправлено: 26.02.09 12:23. Заголовок: Ну если по-минимому...

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

+--------------+---------------+
|[картинка] I инвентарь... |
|========+========+
|#варианты I дополнит-ое |
|................ I .................. |
+--------------+---------------+

то, логично что символы +, -, =, | и I представляют собой отдельные изображения скина
плюс, для действий должна быть возможность задать изображение фона и фона при наведении курсора

Моё имхо, что для того чтобы во всём этом был смысл, надо чтобы все эти настройки лежали или в отдельном файле, или в каком-то специфичном параграфе, который читал бы sdl-клиент

 Отправлено: 26.02.09 12:52. Заголовок: Jumangee пишет: воз..

Jumangee пишет:

цитата:

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

Знаешь, куда бить;)

 Отправлено: 26.02.09 12:54. Заголовок: Jumangee пишет: Моё..

Jumangee пишет:

цитата:

Моё имхо, что для того чтобы во всём этом был смысл, надо чтобы все эти настройки лежали или в отдельном файле, или в каком-то специфичном параграфе, который читал бы sdl-клиент

А разве в wx версии не так?

 Отправлено: 26.02.09 13:05. Заголовок: Jumangee ты имел в ..

Jumangee
ты имел в виду такую таблицу:

 
 +------------+--------------+ 
 |[картинка]  I инвентарь... | 
 |============+==============+ 
 |#варианты   I дополнит-ое  | 
 |........... I ............ | 
 +------------+--------------+ 
 

?

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

 Отправлено: 26.02.09 15:08. Заголовок: Конечно же должен бы..

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

цитата:

Чего там не будет: 1. Продвинутых функций для работы с графикой из кода игры.

То в общем-то для создания скина и не понадобится знаний программирования - это будет просто набор картинок и "настроек" как эти картинки использовать, не более.

цитата:

А разве в wx версии не так?

Так, но там настройки общие для КЛИЕНТА а нужно - только для одной конкретной игры.

 Отправлено: 26.02.09 15:12. Заголовок: возможностей скинов ..

цитата:

возможностей скинов обязательно не хватит особо изысканным авторам

Не хватит конечно! Но ты вроде предлагал на них и не рассчитывать.

 Отправлено: 26.02.09 15:15. Заголовок: Думаю, что скины обя..

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

 Отправлено: 26.02.09 15:17. Заголовок: Jumangee пишет: Так..

Jumangee пишет:

цитата:

Так, но там настройки общие для КЛИЕНТА а нужно - только для одной конкретной игры.

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

 Отправлено: 26.02.09 15:54. Заголовок: rrock.ru здесь идёт ..

rrock.ru здесь идёт речь не об универсальном интерпретаторе игр, а о специальных "сборках" под конкретную игру.

Byte механизм скинов будет перерабатываться до бесконечности, разработка займёт на порядок больше времени. Это не нужно. Для начинающих разработчиков серьёзных игр, не составит большого труда приспособить шаблонный проект на C++ под свои нужды. Если там будет поддержка скинов, то им обязательно не хватит их возможностей, и они полезут в код, а из-за скинов код отображения будет сложный, путанный, непонятный, да ещё и разных версий.

Jumangee я предлагаю рассчитывать на тех разработчиков, которым нужен "быстрый старт". Изучение механизма скинов и создание собственного займёт не меньше времени, чем переделка "C++ шаблона".
Полные возможности по кастомизации элементов интерфейса и переделка языка QSP для поддержки продвинутых графических функций - это совсем разные вещи.

Поймите, этот должно быть ориентировано не на новичков а-ля "сделай игру в три клика а потом забацай скин в один присест", а на тех, у кого есть действительно хорошая игра и кое-какой опыт, желание сделать красиво оформленный продукт и нет времени писать свой движок с нуля. Если таким разработчикам попадётся Skinned-QSP, они обрадуются, сделают свой скин, а потом увидят, что нужно вписать какой-то не предусмотренный скином элемент, и опаньки! Либо вообще исходников не найдут, либо зароются в код скиностроителей. А когда им понадобится изменить что-то ещё, они просто плюнут и станут писать своё с нуля. При достаточной сложности проекта легче написать свой, чем разбираться в существующем. Не усложняйте то, без чего можно обойтись. В данном случае, т.к. заведомо проект собирается под конкретную игру, без скинов обойтись можно.

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

 Отправлено: 26.02.09 16:26. Заголовок: Nex, если делать кли..

Nex, если делать клиент расчитанный на визуальную кастомизацию, то делать это нормально. Иначе в таком клиенте вообще необходимости не будет, это факт. Автору(ам) игры сделать настройки своего интерфейса (а зачастую просто перерисовать чужие картинки даже без какой-либо настройки) гораздо проще чем править c++ программу! К тому же c++ программиста ещё надо найти, да ещё чтобы сумел разобраться в чужом коде! Тем более что технологии скинов open-source существуют и прекрасно могут быть использованы. Да и не надо чего-то уж совсем продвинутого.

цитата:

интерфейс должен настраиваться конечным пользователем..

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

 Отправлено: 26.02.09 16:47. Заголовок: Jumangee факт то, чт..

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

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

Цените своё и чужое время, не тратьте его зря.

 Отправлено: 26.02.09 16:55. Заголовок: Nex Это тебе кажетс..

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

 Отправлено: 26.02.09 17:14. Заголовок: Jumangee даже в этом..

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

 Отправлено: 28.02.09 12:57. Заголовок: Ну и что мы решили??..

Ну и что мы решили??? Ничего?

 Отправлено: 28.02.09 13:59. Заголовок: Ждём свободные руки...

Ждём свободные руки. Все, что есть - заняты и так.

 Отправлено: 13.03.09 14:02. Заголовок: Такс.. Может кто-нит..

Такс.. Может кто-нить сделать в фотожабе примерный набросок внешнего вида?

 Отправлено: 13.03.09 19:26. Заголовок: rrock.ru собрался вз..

rrock.ru собрался взяться за SDL?

 Отправлено: 14.03.09 10:52. Заголовок: попробую.. просто у ..

попробую.. просто у мну хреново с дизайном))

 Отправлено: 21.03.09 02:22. Заголовок: Ну народ! надо вам э..

Ну народ! надо вам это или нет???!!! неужели трудно нарисовать простенький макет??!!

 Отправлено: 21.03.09 10:07. Заголовок: rrock.ru сейчас важн..

rrock.ru сейчас важнее чтоб ты доделал QSPCE.

Кстати, было предложение делать кастомный GUI сразу на флэше.

 Отправлено: 24.03.09 20:37. Заголовок: Nex Не пали контору...

Nex
Не пали контору. (:

 Отправлено: 20.05.09 21:06. Заголовок: Up. Никто не хочет ..

Up.

Никто не хочет взяться за сабж?

 Отправлено: 21.05.09 17:01. Заголовок: Для визуальных новел..

Для визуальных новелл есть родные движки. ren'py к примеру, простой как три копейки.
Поддержка графики в QSP вполне на уровне для текстовых квестов. Единственная фича, которая была бы интересна в SDL варианте это рендеринг текста, возможность использовать свои, а не системные шрифты. Так как сколько бы графики не было в текстовой игре, текст, его отображение и удобочитаемость - это все-таки главное.

 Отправлено: 21.05.09 19:24. Заголовок: luciofulci Согласен,..

luciofulci Согласен, но всё же родные движки - это родные движки, а кусп - это кусп. Например, можно сделать так чтобы одна картинка на другую накладывалась. Или чтобы кусп реагировал на нажатие клавиш. Но это всё реализуемо без SDL (да, Байт, а внатуре зачем он нужен?). Хотя уже сейчас, отключив все окна, можно делать граф. новеллы. Я бы сделал парочку :)

 Отправлено: 25.05.09 21:16. Заголовок: Byte Кстати как там ..

Byte Кстати как там с движком для новелл?

 Отправлено: 25.05.09 21:51. Заголовок: Пока что только QSPG..

Пока что только QSPGUI.