> А значит нету дублирования имен(как для комнат, так и для объектов).
В инстеде это не дублирование, а разное назначение. Одно дело, как выглядит объект для игрока, и другое — для программиста. Писать все время «Замечательный меч кладенец».sila = 100, вместо sword.sila может быть кому-то и удобно, но не мне точно. :)
Если уж и сравнивать, то эквиваленты:
vset("меч.сила", 100) и sword.sila=100
Вот здесь уже стоит почесать репу, т.к. программист не будет писать названия диферамбами(лень заставит писать короче) + из кода убирается транслит и только-автору-ведомые сокращения на английском.
Я серьезно!
_smzap=false; -- Смотрел ли записку
_rzsv2=false; -- Разговаривал ли с Вовой 2
_rzvsl=false; -- Разговаривал ли с Леной
_smblo=false; -- Смотрел блокнот
_rzsv3=false; -- Разговаривал ли с Вовой 3
-- Инстедоз-1. Дежавю.
Если вы взглянете на любую игру то увидите что авторам названия приходится выдумывать(причем английским или транслитом):
criocabin2 = obj {
nam = 'Криокамера';
Причем далеко не все объекты и комнаты содержат параметры, чтоб это дублирование приносило пользу.
Лагранжа, Лапласа и Лейбница — почему существует три(а на деле еще больше) нотации для записи дифференциалов?
Потому что, «there is no silver bullet».
Эта древняя проблема перекочевала в программирование из математики. Некоторые даже используют больше одной нотации при решении диффуров — меняя одну на другую прямо в процессе.
Подумайте.
А в справочниках можно встретить двойную таблицу — для нотации Лагранжа в одной колонке и нотации Лейбница в другой. В учебниках по теории даже пояснения дают иногда в обоих нотациях.
Нет самого лучшего способа представления подходящего сразу для всех IF'ов.
А выбор формата представления под соответствующую механику/модель мира на больших задачах может быть существенным.
Возможно, но нежелательно. К такой таблице нужен ворох автоматических проверок — как минимум что room2 и room1 действительно существуют, а переменные visited_mall существуют и где-то используются
Проверки(комнат и переменных) нужны в любом случае и при любом движке(это элементарная вещь). Пренебрежение отловом ошибок — на совести разработчика API.
(у вас в табличке, кстати, нет разделения между проверкой переменной и изменением)
Вообще-то она есть — во второй колонке проверяются переменные, а в четвертой выполняется код(в т.ч. и установка переменных "(set x)").
object("стол")
act("click",'Гм... Просто стол...')
obj("яблоко")
end()
Почему яблоко — это obj, а не object? Почему у него нет свойств, описания? А между прочим, в исходном примере на INSTEAD это — такой же объект, как и стол. По-моему, упрощение некорректно.
obj() — это процедура включения объекта в данную комнату/объект. Стол содержит яблоко как объект. Однако в примере яблоко не объявлено(не объявлено оно и в instead-примере) — было решено этим пренебречь — главное суть перехода к другой форме записи(а они всегда эквивалентны, т.к. это всего-навсего другая форма записи). Так что я ничего не упрощал — только иначе записал(причем у такой формы записи менее нагруженный(запятыми и скобками, лишними именами) синтаксис).
Строго говоря, любая однопользовательская игра — это конечный автомат, потому что все исходы детерминированы. Но вы пытаетесь описать одной моделью и простые механики интерактивной литературы, которые соединяют куски текста (например, параграфы книг-игр), и игры с моделью мира, откуда возникает путаница.
Я о том и говорю, что внутри одной комнаты может быть несколько состояний и поэтому взаимосвязь состояний(как граф) может не соответствовать однозначно модели мира(как граф)(количество состояний необязательно соответствует числу комнат). Никакой путаницы здесь нет — придется только объявлять состояния(прогресс в истории) как комнаты(что в Instead, что в QSP) и делать «комнатные» переходы. Момент интересный, тем не менее.
1) Нужно найти способ увеличения числа участников не за счет денег.
2) Общее количество игр в год остается примерно одинаковым, не смотря на техническое развитие ИФ — это тоже негативная тенденция.
Если взять соотношение работ вообще и конкурсных игр, то получится та же картина:
2011: 52/98 = 53%
2012: 64/95 = 67%
2013: 84/132 = 63%
2014: 35/109 = 32%
Нельзя не заметить резкое падение на 30% в 2014-ом.
Пиар — это не только сообщения на форумах, это еще и размер призового фонда.
Игры, опубликованные в сети Интернет до 16 ноября 2015 года, будут не допущены к участию в КРИЛ-2015.
Ждем, чуть-чуть осталось.
На деле есть где-то 4 игры, пара из них уже относительно больше среднего размера(есть во что поиграть). Вероятность, конечно же, закончить только одну, но будем целить на большее; думаю над тем, чтобы две из них представить как реализацию идей.
Иногда можно встретить, в ответ на теорию, слова «пишите лучше игры».
Но отнесемся серьезно.
Это равносильно тому чтобы многократно говорить человеку «строй», не объясняя как это строительств происходит. Естественно, получается тяп-ляп. И, естественно, игры имеют низкое качество, которое не дотягивает до рамок конкурса.
Теория иногда бывает поверхностна(в принципе очевидна) и бесполезна(количества и качества написанных рассказов не увеличивает, а ведь она должна!).
Теория действительно должна увеличивать количество и качество выпускаемых изделий.
Поэтому, считаю, что развивать на данном этапе надо именно теорию и привлечение людей вообще к ИФ(т.к. пока что, к сожалению, ничто кроме бюджета не влияет на количество игр; причем, даже его наличие, не гарантирует авторов или количества работ на конкурс).
Вот здесь уже стоит почесать репу, т.к. программист не будет писать названия диферамбами(лень заставит писать короче) + из кода убирается транслит и только-автору-ведомые сокращения на английском.
Я серьезно!
Если вы взглянете на любую игру то увидите что авторам названия приходится выдумывать(причем английским или транслитом):
Причем далеко не все объекты и комнаты содержат параметры, чтоб это дублирование приносило пользу.
Потому что, «there is no silver bullet».
Эта древняя проблема перекочевала в программирование из математики. Некоторые даже используют больше одной нотации при решении диффуров — меняя одну на другую прямо в процессе.
Подумайте.
А в справочниках можно встретить двойную таблицу — для нотации Лагранжа в одной колонке и нотации Лейбница в другой. В учебниках по теории даже пояснения дают иногда в обоих нотациях.
Нет самого лучшего способа представления подходящего сразу для всех IF'ов.
А выбор формата представления под соответствующую механику/модель мира на больших задачах может быть существенным.
Вообще-то она есть — во второй колонке проверяются переменные, а в четвертой выполняется код(в т.ч. и установка переменных "(set x)").
obj() — это процедура включения объекта в данную комнату/объект. Стол содержит яблоко как объект. Однако в примере яблоко не объявлено(не объявлено оно и в instead-примере) — было решено этим пренебречь — главное суть перехода к другой форме записи(а они всегда эквивалентны, т.к. это всего-навсего другая форма записи). Так что я ничего не упрощал — только иначе записал(причем у такой формы записи менее нагруженный(запятыми и скобками, лишними именами) синтаксис).
Я о том и говорю, что внутри одной комнаты может быть несколько состояний и поэтому взаимосвязь состояний(как граф) может не соответствовать однозначно модели мира(как граф)(количество состояний необязательно соответствует числу комнат). Никакой путаницы здесь нет — придется только объявлять состояния(прогресс в истории) как комнаты(что в Instead, что в QSP) и делать «комнатные» переходы. Момент интересный, тем не менее.
Имеет смысл скорее как учебный проект для Ардуино.
Дело даже не в этом, LCD(4') и Ардуино потребляют около 250мА. При емкости кроны(~250мА), такой набор не протянет и часа.
Arduino, сама по себе, питается от кроны(9В).
2) Общее количество игр в год остается примерно одинаковым, не смотря на техническое развитие ИФ — это тоже негативная тенденция.
Offtop: как тут редактировать сообщения?
2011: 52/98 = 53%
2012: 64/95 = 67%
2013: 84/132 = 63%
2014: 35/109 = 32%
Нельзя не заметить резкое падение на 30% в 2014-ом.
Пиар — это не только сообщения на форумах, это еще и размер призового фонда.
Заметна тенденция.
Конкурс «Проект 31»
forum.ifiction.ru/viewtopic.php?pid=31993#p31993
Нужно ли проводить ЛОК 2015?
urq.borda.ru/?1-0-0-00000492-000-0-0-1438027018
Если вглядеться, то спад виден. Можно и отрицать — примеры для этого тоже есть.
На деле есть где-то 4 игры, пара из них уже относительно больше среднего размера(есть во что поиграть). Вероятность, конечно же, закончить только одну, но будем целить на большее; думаю над тем, чтобы две из них представить как реализацию идей.
Иногда можно встретить, в ответ на теорию, слова «пишите лучше игры».
Но отнесемся серьезно.
Это равносильно тому чтобы многократно говорить человеку «строй», не объясняя как это строительств происходит. Естественно, получается тяп-ляп. И, естественно, игры имеют низкое качество, которое не дотягивает до рамок конкурса.
Теория иногда бывает поверхностна(в принципе очевидна) и бесполезна(количества и качества написанных рассказов не увеличивает, а ведь она должна!).
Теория действительно должна увеличивать количество и качество выпускаемых изделий.
Поэтому, считаю, что развивать на данном этапе надо именно теорию и привлечение людей вообще к ИФ(т.к. пока что, к сожалению, ничто кроме бюджета не влияет на количество игр; причем, даже его наличие, не гарантирует авторов или количества работ на конкурс).