Forum.iFiction.Ru

Ветераны IF продолжают вбивать в голову новичкам мысль о первейшей необходимости движка

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

забудьте о движке и СРАЗУ НАЧИНАЙТЕ ПИСАТЬ ИГРУ самым простым способом - IF-ELSE-ELSEIF. Множьте свои IF-ы (в смысле условия внутри программы) и не обращайте внимания на то, что это самый "чайниковый" способ

Зачем?! Есть RTADS, RInform, URQ, QSP - чего там не хватает? Пять минут изучения и уже можно написать простейшую локацию. Программеру и того быстрее.

в) Этот момент я называю "IF-аномалией автора-новичка". Абсолютно ВСЕ существующие движки отвергаются в конечном счете. Причины называются разные - итог один.

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

В общем, нафик. Надо писать мануалы, гетстартеды на существующие платформы. В этом смысле я очень рад за QSP - там совершенно замечательный набор уроков. Только бы автор их не забросил...

2 OwlWilson

ППКС

Твои слова - подтверждение происходящего со мной. Именно, solid code была моей мечтой о программировании: "Блин, а нельзя разве, чтобы это как-нибудь вместе лежало?" - вопрос, которым закончились мои попытки осилить ТАДС.
Именно возможность начать с "чайниковского" программирования, постепенно (на ходу!) изучая более ёмкие и изящные способы организации методов и процедур, помогла (и помогает постоянно) побороть свою лень и продолжать проект.
(еще раз отмечу печальный факт, что С++ для подобного "восхождения" никак не годится, ибо чайниковское программирование там попросту невозможно). Так что IF..THEN..ELSE - действительно гораздо быстрее даст чайнику понять, чего на самом деле он хочет от своей игры (и быстрее получить первые результаты), чем сразу "мокать с головой" в ООП, рискуя не выплыть и бросить эту затею.

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

(Однако, справедливым остаётся тезис, который высказал где-то тут zerr, о том, что написание первых 80% кода занимает 20% времени, и оставшиеся 80% уйдут на написание оставшихся 20% кода. У меня такая же история вышла с "Шорохами", но, к счастью, уже работа подходит к завершению.)

Owl Wilson написал:

fireton написал:

Зачем?! Есть RTADS, RInform, URQ, QSP - чего там не хватает? Пять минут изучения и уже можно написать простейшую локацию. Программеру и того быстрее.

...
в) Этот момент я называю "IF-аномалией автора-новичка". Абсолютно ВСЕ существующие движки отвергаются в конечном счете. Причины называются разные - итог один.
...

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

Что же до парсерных... Никакой аномалии здесь нет. Про "пять минут изучения" РТАДС - это красивая сказочка про пушистых белочек, сочинённая программерами якобы для чайников, но на деле итог тоже один: дальше "простейших локаций" дело обычно не заходит. В англоязычном ИФ-мире поэтому новичка сразу честно предупреждают: ТАДС - это очень сложная и громоздкая система, для новичков не рекомендуется.
А без новичков никакого движняка и "притока новых игр" не будет. Вот и получается коровья запятая.

Желание писать текстовую игру у начинающего программиста возникает совместсно со своим (пусть туманным и ошибочным) видением того, как там всё должно работать. Но если не набить свои шишки на простом программировании, то до сложного дойти шансов почти нет, ибо не будет понятно ЗАЧЕМ нужно оптимизировать\увеличивать те или иные куски кода (и потом уже КАК это сделать). В ТАДСЕ всё сложное вроде бы уже сделали добрые дядьки, и остаётся просто вписывать в нужные места нужные слова. Но это лишь кажущееся упрощение. На деле это медвежья услуга.
Такое обучение - это всё равно, что учить ребенка ходить показывая ему чертежи ходящего робота. И как ни крути, изобретать велосипед приходится всем, даже знающим ТАДС. Но тут уже для кого что лучше: изобрести свой велосипед, или разобрать (и потом долго собирать) чужой.

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

Отредактировано oleksus (16.02.2008 01:38)

oleksus написал:

Owl Wilson написал:

fireton написал:

Зачем?! Есть RTADS, RInform, URQ, QSP - чего там не хватает? Пять минут изучения и уже можно написать простейшую локацию. Программеру и того быстрее.

...
в) Этот момент я называю "IF-аномалией автора-новичка". Абсолютно ВСЕ существующие движки отвергаются в конечном счете. Причины называются разные - итог один.
...

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

Oleksus, а Вы много менюшных игр написали? Мягко говоря, неосторожное заявление... (Я имею в виду часть про "делать в чем угодно"; касательно  того, что "поиски новых движков выглядят странно" - полностью согласен;).

oleksus написал:

Что же до парсерных... Никакой аномалии здесь нет. Про "пять минут изучения" РТАДС - это красивая сказочка про пушистых белочек, сочинённая программерами якобы для чайников, но на деле итог тоже один: дальше "простейших локаций" дело обычно не заходит. В англоязычном ИФ-мире поэтому новичка сразу честно предупреждают: ТАДС - это очень сложная и громоздкая система, для новичков не рекомендуется.
А без новичков никакого движняка и "притока новых игр" не будет. Вот и получается коровья запятая.

Желание писать текстовую игру у начинающего программиста возникает совместсно со своим (пусть туманным и ошибочным) видением того, как там всё должно работать. Но если не набить свои шишки на простом программировании, то до сложного дойти шансов почти нет, ибо не будет понятно ЗАЧЕМ нужно оптимизировать\увеличивать те или иные куски кода (и потом уже КАК это сделать). В ТАДСЕ всё сложное вроде бы уже сделали добрые дядьки, и остаётся просто вписывать в нужные места нужные слова. Но это лишь кажущееся упрощение. На деле это медвежья услуга.
Такое обучение - это всё равно, что учить ребенка ходить показывая ему чертежи ходящего робота. И как ни крути, изобретать велосипед приходится всем, даже знающим ТАДС. Но тут уже для кого что лучше: изобрести свой велосипед, или разобрать (и потом долго собирать) чужой.

Это не кажущееся упрощение. Просто все люди - разные, одним проще освоить имеющийся функционал (сесть на готовый чужой велосипед и поехать), другим - создавать свой. Только что-то среди парсерных игр более-менее приличного качества TADSовских "на круг" получается больше, чем всех других. Плюс, не устану повторять: какой бы ни была простой в работе платформа - для реализации нетривиальных вещей автору все равно придется отчетливо понимать, чего именно он хочет, и научиться формулизовать свои требования.

oleksus написал:

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

В какой-то степени согласен, только пока нормальные ноги что-то не очень конструируются.

Eten написал:

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

С этим-то никто не спорит. Вопрос в другом: зачем?

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

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

Ну вот взять хотя бы этот нюанс с оформлением частей объектов ("ручка чашки", "ствол ружья"), обсуждаемое сейчас в ветке ТАДСа. Приходится авторам вставать на ходули, чтобы реализовать такую простую вещь. Взгляните на билдер 6 дней и увидите, как русская падежность реализуется быстро и изящно. Есть там и "зеленая ручка чайника" и "ножка красного стола", причем проще зевка.

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

Падежные окончания в ТАДСе не автоматизированы, да. Ну и фиг с ними, пока есть "Генератор". На самом деле, я уверен, что можно нормально реализовать функцию склонения (в RInform же она есть). Просто у Гранда руки пока не дошли.

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

fireton, в принципе тебе и так уже указали, на одну из проблем.
goraph, а где ты видел много игр на РТАДС и особого рвения в таком сложном языке у квестостроителей. В данном плане, лидером остается УРКА, т.к. она очень проста.

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

Проблема в том, что игры писать очень сложно, особенно на РТАДСе. А для языков программирования существуют всякие IDE, которые делают написание кода (особенно для тех, у кого программирование - хобби) сравнительно простым.
Пока самый крутой вариант IDE - это новый TADS-режим для Emacs'а. Подсветка синтаксиса, автоматическая вставка отступов, автодополнение и т.д. Emacs вообще прикольная штука (сорри за оффтоп).
Идеальная среда разработки для интерактивной литературы - это когда работа распределяется так: 10-15% на кодинг, все остальное - на сюжет. То есть захотел, например, добавить локацию - нажал на кнопку, появилось окно, заполнил поля и все. Жаль, что этим никто не занимается.
Нужны качественные генераторы коды, вроде "Генератора падежей". Признаться, если бы этой программы не было, я бы вообще никогда не заставил себя садиться за написание игры - это был бы ад А так пишу потихоньку на РТАДСЕ и хочу лишний раз выразить респект всем участникам этого проекта.
А парсер я таки написал Простой, как три рубля, но тем не менее. Разумеется, он абсолютно бесполезен с точки зрения написания игр, зато он немного научил меня программировать на Python'е, ценить имеющиеся движки, и отучил изобретать велосипеды с квадратными колесами Но единственное, что: писать на Python'е мне, не имевшему до этого практически никакого опыта кодинга, было гораздо проще, чем на ТАДСе Так что, на мой скромный взгляд, исходя из собственного опыта - нужны генераторы кода (я уже приводил пример генераторов падежей), помощники и так далее.
Так что если кто-то захочет вписать свое имя историю и поупражняться в кодинге - не стоить тратить время на собственный движок, лучше разработать IDE для RTADS на уровне скажем SPE для Python'а...

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

Я могу сказать, что ныне сущевствующие западные платформы не полностью отвечают нашим требованиям, русские пишутся по принципу нам и этого хватает (но не всем же! ). Далее, на мой взгляд можно написать платформу, которая может не только работать с одним парсером (по типу один парсер один язык, т.е. у каждого свой). Это реально потому, что мы люди и говорим об одних и тех же вещах, а значит используем одни теже смыслоформы (к примеру слово молоко обозначает то, что под этим словом значится, но на разных языках этот смысел имеет другие формы, иначе говоря другое слово, предлоги почти во всех языках обозначают одни и теже отношения, но также словами они отличаются). Главное, научиться создавать правила задания слов для любого парсера так, чтобы парсер уже сам задавал, как с этим работать.

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

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

К примеру на нашем языке: 1) положить стрелы на стол и 2) положить стрелы в стол - это разные действия. В 1) случае мы кладем стрелы на что-то (поверхность), во втором кладем стрелы во что-то (контейнеры). Допустим стол является контейнером и поверхностью (к примеру есть ящик в столе), то выполняя два действия мы кладем стрелы на стол и в стол (т.е. в тот-самый ящик, вместо выполнения целого ряда команд). Это считается нормальным. Также к примеру стол может быть поверхностью, тогда отказ выполнения действия 2) будет логичным, чем наоборот, иначе с таким же успехом можно положить объекты в камень.

Отредактировано Eten (18.02.2008 17:06)

Много раз перечитал предпоследний пост Eten'a, но понять не смог.
В двух словах-то можно повторить?

Я тоже не понял. Какой-то поток сознания, извини Андрей.

А чего тут не понятно, в моем городе газета называется "Суть", т.е. зри в корень проблемы. Такая проблема не у нас одних, все языки не основанные на ероглифах, отличаются только способом говорить (вспомните, как мы говорим, привет на разных языках), а суть остается таже. Так, блин в чем проблема?! В том, что мы не можем создать эти понятия на программном уровне парсеров, которые будут принимать общее привило, выражющее суть, а построение слов - это дело лично парсера, а не наше.
З.Ы.
Если вам и это не понятно, то извините, видать не туда написал, о чем тогда говорить вообще??!!

fireton, интересная идея, но свой то движок еще не закончил. Вот когда закончу с первой веткой, тогда велком.
З.Ы.
Когда переведете ТАДС3, проверьте есть ли там действительно возможность не так сильно париться над словами.

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

Отредактировано Eten (18.02.2008 18:32)