Форум » » QSP на SDL » Ответить

QSP на SDL

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

Ответов - 34, стр: 1 2 All

Jumangee: Я начинал делать подобный проект, суть идеи можно посмотреть здесь: 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 это хорошо, но надо сразу понимать, что проекты таких игр несмогут потянуть "начинающие" - это уже скорее будут достаточно большие и сложные игры - хотябы из-за необходимости сделать больше работы. Игры, которым нужна именно такая платформа (имеется в виду - в виде полноценной игры) имеются в наличии. Например, авторы "Высотки" задумываются о продолжении.

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

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


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

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

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

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

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

Jumangee: Ну если по-минимому... то наверное надо сделать возможность применения "скинов" к интерфейсу, а также сделать возможность менять заранее положение окон, плюс, возможность использования полноэкранного режима. Ну вот например, если окна будут в классическом расположении +--------------+---------------+ |[картинка] I инвентарь... | |========+========+ |#варианты I дополнит-ое | |................ I .................. | +--------------+---------------+ то, логично что символы +, -, =, | и I представляют собой отдельные изображения скина плюс, для действий должна быть возможность задать изображение фона и фона при наведении курсора Моё имхо, что для того чтобы во всём этом был смысл, надо чтобы все эти настройки лежали или в отдельном файле, или в каком-то специфичном параграфе, который читал бы sdl-клиент

rrock.ru: Jumangee пишет: возможность использования полноэкранного режима. Знаешь, куда бить;)

rrock.ru: Jumangee пишет: Моё имхо, что для того чтобы во всём этом был смысл, надо чтобы все эти настройки лежали или в отдельном файле, или в каком-то специфичном параграфе, который читал бы sdl-клиент А разве в wx версии не так?

Nex: Jumangee ты имел в виду такую таблицу: [pre2] +------------+--------------+ |[картинка] I инвентарь... | |============+==============+ |#варианты I дополнит-ое | |........... I ............ | +------------+--------------+ [/pre2] ? Насчёт подключения скинов - это замедлит разработку интерфейса, а возможностей скинов обязательно не хватит особо изысканным авторам. Лучше сделать шаблонный проект на C++, который каждый желающий, разумеется разбирающийся в программировании, сможет быстро приспособить под свои нужды, дописав необходимых функциональностей и пр.

Jumangee: Конечно же должен быть некий скин-пример, а уже на основании его каждый смог бы сделать скин "для себя". Если придерживаться: Чего там не будет: 1. Продвинутых функций для работы с графикой из кода игры. То в общем-то для создания скина и не понадобится знаний программирования - это будет просто набор картинок и "настроек" как эти картинки использовать, не более. А разве в wx версии не так? Так, но там настройки общие для КЛИЕНТА а нужно - только для одной конкретной игры.

Jumangee: возможностей скинов обязательно не хватит особо изысканным авторам Не хватит конечно! Но ты вроде предлагал на них и не рассчитывать.

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

rrock.ru: Jumangee пишет: Так, но там настройки общие для КЛИЕНТА а нужно - только для одной конкретной игры. Тоесть ты предлагаешь под каждую игру свой интерфейс??!! по-моему это бред.. интерфейс должен настраиваться конечным пользователем..

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

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

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

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



полная версия страницы