Как использовать свое решение
GHub Platform · Гайд · 0 ответов · 5 просмотров

«Гольф» — термин из сообщества развлекательных программистов. «Кодовый гольф» — это игра, в которой вы пытаетесь решить задачу на заданном языке программирования, используя как можно меньше символов. Есть и другие виды гольфа. Программы можно сравнивать по скорости, сложности или эстетике. В контексте Opus Magnum игра в гольф означает минимизацию количества циклов, площади или стоимости решения. Обычно невозможно оптимизировать все три сразу, хотя площадь и стоимость часто идут рука об руку. В большинстве случаев площадь и стоимость можно свести к минимуму, используя одну руку с длинной и сложной серией инструкций. Оптимизация для циклов гораздо сложнее. Поэтому остальная часть этого руководства посвящена исключительно циклам. Временная шкала представляет собой набор плиток в нижней части экрана. Он контролирует порядок, в котором происходят события, а также решает, когда компонент будет ждать, а не делать что-то полезное. Поначалу правила могут показаться немного неинтуитивными, поскольку они созданы для того, чтобы делать «правильные вещи» для любого дизайна. Каждый компонент имеет ряд инструкций. Если вы оставите пустое пространство между двумя инструкциями (но не в начале временной шкалы), игра автоматически заполнит пустые инструкции. Пустые инструкции всегда считаются «настоящими» инструкциями. Каждая инструкция выполняется ровно за один цикл. Пустое пространство в начале временной шкалы не учитывается, потому что игра выполняет эту задержку только в первый раз. У всей машины есть период. Период машины — это просто количество циклов, необходимое для повторения всей машины. Какой бы компонент ни имел больше всего инструкций, он будет определять период. Игра не позволит компоненту выйти из синхронизации с остальной частью машины. Таким образом, если компонент не имеет инструкций за полный период, игра просто дополнит его пустыми инструкциями. Это отображается в виде светлого фона после окончания размещенных вами инструкций. В качестве примера предположим, что у вас есть такая простая машина: рука №1 содержит две инструкции без пробела в начале. Рукав №2 содержит три инструкции плюс дополнительное пространство в начале. Рука №3 содержит пять инструкций, включая пробел посередине. Рука №4 имеет шесть инструкций. В редакторе это выглядит так: При нажатии кнопки шага оно меняется на следующее: Период этой машины равен шести, потому что рука №4 имеет больше всего инструкций. Итак: Рукав №1 дополняется четырьмя пустыми инструкциями, потому что 6–2 = 4. Рукав №2 дополняется тремя пустыми инструкциями, потому что 6–3 = 3. Пустое пространство не имеет значения. Рукав №3 дополняется одной пустой инструкцией, и пробел также превращается в пустую инструкцию, всего шесть. Рукав №4 не дополняется, поскольку 6–6 = 0. Опять же, все пустое пространство в начале игнорируется. Понимание того, как работает временная шкала, имеет решающее значение для правильного принятия решений. В общем: каждая рука выполняет свои инструкции только один раз, прежде чем машина повторит их. Если вам нужно, чтобы рука проделала одно и то же действие более одного раза в течение всего периода работы машины, используйте команду повторения. Вы можете использовать команду clock, чтобы увеличить период работы машины. Это влияет на всю головоломку, поэтому вам понадобятся только одни часы. Большую часть времени вам вообще не нужны часы. Пустое место в начале временной шкалы в большинстве случаев не имеет значения. Пустое пространство в середине временной шкалы учитывается, как и пустое пространство в конце. Пустое время, которое имеет значение, обычно возникает из-за ожидания другого компонента. Если вы сможете заставить этот компонент работать быстрее, у вас будет меньше пустого времени на вашей временной шкале. Как мы обсуждали ранее, пробелы в середине или конце временной шкалы замедляют работу машины, поскольку компонентам приходится ждать друг друга. Когда вы видите много пробелов, следует искать «узкое место». Это та часть машины, которая больше всего замедляет остальную часть машины. Вот простой пример: очевидно, это не лучший дизайн. Но что конкретно в этом не так? Проблема в правой руке. Он делает слишком много вещей. Это видно по тому, что он постоянно движется, в отличие от руки слева. Постоянно движущаяся рука указывает на то, что игра не добавила никаких отступов на временную шкалу, поэтому в ней должно быть больше всего инструкций. Компонент с наибольшим количеством инструкций всегда определяет период работы машины, поэтому правая рука замедляет всю машину. Следовательно, если мы сможем заставить правую руку работать быстрее, мы ускорим всю машину. С другой стороны, ускорение левой руки не поможет (пока), потому что в конечном итоге придется ждать дольше. В этом случае решение простое: добавьте третью руку, которая выполняет часть работы, выполняемой в настоящее время правой рукой. Как только мы это сделаем, мы получим такую конструкцию: Это немного лучше и экономит несколько циклов, но для настоящего улучшения потребуется больше рук. Сейчас оба плеча фиксированной длины отвечают за два атома, но было бы более эффективно, если бы каждому приходилось присоединять только один атом. Вы можете ясно видеть, что каждая фиксированная рука тратит много времени на движение, а не на ожидание. В финальной версии мы также переместили символы кальцификации, чтобы атомы огня и воды кальцинировались после соединения. Нам не нужно было этого делать; с таким же успехом мы могли бы кальцинировать их, пока новые поршневые рычаги перемещали атомы. Но часто проще сначала связать, а затем кальцинировать, потому что вы можете перемещать всю молекулу по глифам как единое целое. Конечно, возможны дальнейшие улучшения, но, вероятно, на данный момент этого достаточно. Одна из самых простых оптимизаций — использовать руку с более чем одним захватом. Руки с несколькими захватами могут восстанавливаться быстрее, чем руки с одним захватом. Например, на обложке этого руководства (см. справа) изображен тройной рычаг, который не нужно сбрасывать после поворота. Эмпирическое правило: рычаги, которые вращаются три раза, а затем сбрасываются в исходное положение, должны быть двойными. Руки, которые вращаются дважды, а затем возвращаются в исходное положение, должны быть тройными. Руки, которые вращаются один раз, а затем возвращаются в исходное положение, должны быть шестигранными. После выполнения этих замен вы можете заменить любые инструкции по сбросу одной инструкцией по выпуску, что сэкономит много времени. При выполнении этой оптимизации тщательно проверьте изменения, прежде чем продолжить. В этом примере это работает, потому что молекула исчезает, как только мы помещаем ее в слот продукта. Но если вы хотите, чтобы молекула задержалась на какое-то время, ваша рука снова поднимет ее, если только вы не отодвинете ее другой рукой. Вы также можете видеть, что мы не удосужились оптимизировать два одиночных плеча до шестигранных. Это потому, что тройной рычаг в этом решении постоянно перемещается, поэтому это узкое место. Мы не сможем сделать машину быстрее, не улучшив тройную руку. Тем не менее, шестисторонним рукавам придется ждать друг друга, чтобы избежать одновременного захвата одного и того же атома, поэтому подход с одним плечом в любом случае уже оптимален. «Перевод» означает перемещение молекулы по прямой линии с помощью поршня или направляющей. «Вращение» означает вращение молекулы с помощью рычага. Существуют важные различия в том, как работают эти два вида движения. Трансляция всегда стоит один цикл на шестигранник. Он сохраняет ориентацию молекулы и особенно хорошо подходит для изготовления длинных полимеров или бесконечных изделий. Молекулу также довольно легко модифицировать по мере ее прохождения, например, путем связывания или кальцификации. Вращение стоит один цикл на каждые шестьдесят градусов, на которые вы поворачиваетесь. Расстояние не имеет значения; длинная рука вращается так же быстро, как и короткая. В результате вращения хорошо подходят для более крупных неполимерных молекул и ситуац
ИсточникGHub Platform · автор31.07.2026, 22:00:16
«Гольф» — термин из сообщества развлекательных программистов. «Кодовый гольф» — это игра, в которой вы пытаетесь решить задачу на заданном языке программирования, используя как можно меньше символов. Есть и другие виды гольфа. Программы можно сравнивать по скорости, сложности или…
Войдите, чтобы писать в группе