RU

Необходим ли API над языком QSP?

Воден #360 09.06.2011 06:53 15 comments 10892 views

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

В связи с этим у меня вопрос к вам, написавшем уже не одну и не две игры: было бы легче писать игры, если бы работа с предметами, действиями, событиями и т.д. велась через работу с объектами и их свойства?
Т.е. вместо создания предмета в рюкзаке “лампа”, переменной “лампа_горит”, написания множества условий ‘если есть предмет “лампа”, то есть действия “А”, “В”, “С”’ и прочей горы неочевидного кода - создать один раз объект: “лампа”, обозначить его тип: “предмет”, прописать там же все возможные действия с ним со всеми условиями, там же добавить его описание, и т.д.

Что скажете?

Т.е. превратить QSP в объект-ориентированный язык? Я вообще говоря пока не понимаю чем это проще и как оно вообще будет работать.

Возможно, я излишне сделал акцент на “объектности”. Ведь суть не в том, объекты или какие-то иные сущности - а в наличие стандартизированного инструмента для упрощения разработки игр

Воден:

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

В связи с этим у меня вопрос к вам, написавшем уже не одну и не две игры: было бы легче писать игры, если бы работа с предметами, действиями, событиями и т.д. велась через работу с объектами и их свойства?
Т.е. вместо создания предмета в рюкзаке “лампа”, переменной “лампа_горит”, написания множества условий ‘если есть предмет “лампа”, то есть действия “А”, “В”, “С”’ и прочей горы неочевидного кода - создать один раз объект: “лампа”, обозначить его тип: “предмет”, прописать там же все возможные действия с ним со всеми условиями, там же добавить его описание, и т.д.

Что скажете?

Не было бы проще. Было бы кондовее. Сейчас можно легко сделать простые вещи и без объектов. И легко можно сделать сложные вещи с минимумом извратов. Приведя всё к объектам мы усложним создание сложных вещей и упростим создание простых. По-моему это никому не нужно.

Более того, если бы мне это было нужно, давно ушла бы в инстид, ибо там именно так всё и есть.

Любое упрощение лишает нас гибкости. QSP достаточно прост, нет смысла делать его еще проще за счет чего-то другого.

Dark[Ol(U23)leneri] #34 09.06.2011 11:01 (14 years ago)

а я наоборот за усложнение
даешь переименовывание инвентаря оператором
даешь картинки вместо имени объектов
даешь полноценные картинки в меню объектов
даешь возможность разбить одну строку действия на два столба… или хотя бы возможность полноценного использования html.

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

Воден,
все твои беды - от программистского наследия, оставшегося у тебя от других языков. Путь “писания API”, “движков”, “объектов” - типичная дорожка граблей, по которой уже устремился вприпрыжку Олегус, и ты на нее тоже стремишься.

Платформа Instead, как правильно заметила Аджента, как раз предоставляет инструментарий для тех, кто уже увяз в программировании настолько, что не может адаптироваться под язык QSP. Попробуй, может тебе лучше подойдет Instead, он полностью объектный и пр. и пр.

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

Никто не мешает тебе заняться технической чепухой и угробить свое время на построение очередного “игрового движка” на QSP. Флаг в руки. Только не пытайся ради этого перекроить QSP под себя.

Dark[Ol(U23)leneri],
расширенные возможности оформления - AeroQSP.

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

P.S. что такое API в QSP не очень хорошо понимаю.

Dark[Ol(U23)leneri] #34 09.06.2011 16:16 (14 years ago)

Nex:

расширенные возможности оформления - AeroQSP.

А если я не хочу использовать Аеру?)

Dark[Ol(U23)leneri],
тогда ты можешь написать свой плеер, или дождаться, когда кто-нибудь напишет.

Dark[Ol(U23)leneri] #34 09.06.2011 21:10 (14 years ago)

Nex:

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

Благодарю.

Что такое текстовая игра для программиста? Программа из переменных, циклов, функций, подпрограмм, и т.д.
Что такое текстовая игра для писателя? Сюжет с возможностью ветвления, интерактивными элементами, игровым процессом и т.д.
То есть хорошую игру может написать тандем писатель+программист (возможно, в одном лице) а таких единицы.
Причем чистый программист напишет игру скучную, богатую техническими выкрутасами, но скудную текстом. А писатель создаст замечательную текстовую составляющую, но запутается в программировании.

Поэтому я брежу идеей дать возможность писателю программировать без программирования.

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

Мое мнение: Воден, лучше помоги авторам с программированием. Мне кажется, модули на куспе успеха не имеют, какой смысл тратить силы и время.

И еще. Воден, сделай нам лучше курсор на мышку, чтоб менять можно было. =)

Да, она нам в аеру очень очень сильно нужна. :(

Log in or Register to post comments.