Необходим ли API над языком QSP?
Возможно, оттого, что я больше программист, чем литератор, процесс написания игры на QSP в значительной степени состоит из попыток написать код игры с минимальным числом повторов и как результат, я увязаю в сложности грамотной (с точки зрения программирования) обработке происходящего в игре.
В связи с этим у меня вопрос к вам, написавшем уже не одну и не две игры: было бы легче писать игры, если бы работа с предметами, действиями, событиями и т.д. велась через работу с объектами и их свойства?
Т.е. вместо создания предмета в рюкзаке “лампа”, переменной “лампа_горит”, написания множества условий ‘если есть предмет “лампа”, то есть действия “А”, “В”, “С”’ и прочей горы неочевидного кода - создать один раз объект: “лампа”, обозначить его тип: “предмет”, прописать там же все возможные действия с ним со всеми условиями, там же добавить его описание, и т.д.
Что скажете?
Т.е. превратить QSP в объект-ориентированный язык? Я вообще говоря пока не понимаю чем это проще и как оно вообще будет работать.
Возможно, я излишне сделал акцент на “объектности”. Ведь суть не в том, объекты или какие-то иные сущности - а в наличие стандартизированного инструмента для упрощения разработки игр
Воден:
Возможно, оттого, что я больше программист, чем литератор, процесс написания игры на QSP в значительной степени состоит из попыток написать код игры с минимальным числом повторов и как результат, я увязаю в сложности грамотной (с точки зрения программирования) обработке происходящего в игре.
В связи с этим у меня вопрос к вам, написавшем уже не одну и не две игры: было бы легче писать игры, если бы работа с предметами, действиями, событиями и т.д. велась через работу с объектами и их свойства?
Т.е. вместо создания предмета в рюкзаке “лампа”, переменной “лампа_горит”, написания множества условий ‘если есть предмет “лампа”, то есть действия “А”, “В”, “С”’ и прочей горы неочевидного кода - создать один раз объект: “лампа”, обозначить его тип: “предмет”, прописать там же все возможные действия с ним со всеми условиями, там же добавить его описание, и т.д.Что скажете?
Не было бы проще. Было бы кондовее. Сейчас можно легко сделать простые вещи и без объектов. И легко можно сделать сложные вещи с минимумом извратов. Приведя всё к объектам мы усложним создание сложных вещей и упростим создание простых. По-моему это никому не нужно.
Более того, если бы мне это было нужно, давно ушла бы в инстид, ибо там именно так всё и есть.
Любое упрощение лишает нас гибкости. QSP достаточно прост, нет смысла делать его еще проще за счет чего-то другого.
а я наоборот за усложнение
даешь переименовывание инвентаря оператором
даешь картинки вместо имени объектов
даешь полноценные картинки в меню объектов
даешь возможность разбить одну строку действия на два столба… или хотя бы возможность полноценного использования html.
Даешь больше пространства для решения задач, устраивания нычек и прочих понтов^^
Воден,
все твои беды - от программистского наследия, оставшегося у тебя от других языков. Путь “писания API”, “движков”, “объектов” - типичная дорожка граблей, по которой уже устремился вприпрыжку Олегус, и ты на нее тоже стремишься.
Платформа Instead, как правильно заметила Аджента, как раз предоставляет инструментарий для тех, кто уже увяз в программировании настолько, что не может адаптироваться под язык QSP. Попробуй, может тебе лучше подойдет Instead, он полностью объектный и пр. и пр.
Преимущество QSP не в том, что он “дает возможность извратиться” - в конце концов, это есть у каждой платформы - а в том, что на нем может писать автор, не знакомый с программированием. Использование “объектного” подхода в качестве “стандарта” его усложнит, и лишит этого преимущества.
Никто не мешает тебе заняться технической чепухой и угробить свое время на построение очередного “игрового движка” на QSP. Флаг в руки. Только не пытайся ради этого перекроить QSP под себя.
Dark[Ol(U23)leneri],
расширенные возможности оформления - AeroQSP.
Мне кажется, что это уже есть. Точнее так уже можно сделать.
Например написать функции работы с инвентарём например, выложить их в отдельный qsp-файл.
Для использования их в игре догружать спец-командой.
Есть пример Библиотечка дополняющая инвентарь 0.76
P.S. что такое API в QSP не очень хорошо понимаю.
Nex:
расширенные возможности оформления - AeroQSP.
А если я не хочу использовать Аеру?)
Dark[Ol(U23)leneri],
тогда ты можешь написать свой плеер, или дождаться, когда кто-нибудь напишет.
Nex:
тогда ты можешь написать свой плеер, или дождаться, когда кто-нибудь напишет.
Благодарю.
Что такое текстовая игра для программиста? Программа из переменных, циклов, функций, подпрограмм, и т.д.
Что такое текстовая игра для писателя? Сюжет с возможностью ветвления, интерактивными элементами, игровым процессом и т.д.
То есть хорошую игру может написать тандем писатель+программист (возможно, в одном лице) а таких единицы.
Причем чистый программист напишет игру скучную, богатую техническими выкрутасами, но скудную текстом. А писатель создаст замечательную текстовую составляющую, но запутается в программировании.
Поэтому я брежу идеей дать возможность писателю программировать без программирования.
Воден,
во-первых, конструкторы давным-давно придуманы.
Во-вторых, для написания хорошей текстовой игры не нужно разбираться в программировании.
Мое мнение: Воден, лучше помоги авторам с программированием. Мне кажется, модули на куспе успеха не имеют, какой смысл тратить силы и время.
И еще. Воден, сделай нам лучше курсор на мышку, чтоб менять можно было. =)
Да, она нам в аеру очень очень сильно нужна. :(