Наконец-то наступили летние каникулы, а это значит, что я могу сосредоточить свое время на важных делах, таких как создание вещей и оттачивание своих навыков программиста.

Сегодня я буду строить jebot. Я и, наверное, все индонезийцы в этом мире, наверное, помню jebot. В эту игру обычно играют от начальной школы до университета. Когда автобус ходит слишком долго или когда разговор прекращается, люди обращаются к jebot, чтобы развлечься.

Впервые у меня возникла идея сделать джебот в последние дни октября 2018 года. В то время я ехал в деревню в Кунингане. У меня была акция общественных работ под названием жить в, где студенты живут и принимают участие в жизни фермеров. Честно говоря, это действительно интересно.

Однако поездка на автобусе была неинтересной. Это была устрашающая 13-часовая поездка от Джакарты. Добавьте к этому тот факт, что смартфоны были запрещены, никто не приносил игральные карты, книги или какие-либо развлекательные материалы. Единственное, что мы сделали, это поговорили и надеялись, что появятся новые темы для разговора. Через несколько часов всем стало скучно. Именно тогда все начали играть в jebot. Подумайте об этом, полный автобус, играющий вместе. Возможные ответы были бесконечны!

Итак, что такое jebot? По сути, это игра между двумя игроками. Каждый игрок будет начинать с двумя большими пальцами (конечно же), что означает, что в настоящее время на «поле битвы» всего 4 больших пальца. Как только игра начинается - после выбора того, кто ходит первым, - первый игрок (назовем его игроком А) должен выкрикнуть число от 0 до 4 (или количество больших пальцев, оставшихся на «поле битвы»). В то же время оба игрока поднимали большой палец вверх. Если количество поднятых вверх больших пальцев равно количеству, которое выкрикнул игрок А, то игрок А выиграет этот раунд и сможет опустить руку, уменьшив таким образом общее количество поднятых вверх большого пальца до 3.

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

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

Я начал с самого начала игры. Что происходит в начале игры? Кто будет первым? Какой первый ход? Я задавал себе эти вопросы, чтобы иметь хотя бы руководство о том, что писать и о чем думать, вместо того, чтобы просто случайным образом записывать то, что я считаю логикой.

Вскоре после этого я смог придумать правильную блок-схему, дополняющую логику. Блок-схема начинается с команды while, чтобы гарантировать, что игра не остановится, если игрок / компьютер уже не выиграл игру. С этой мыслью я задал себе еще один вопрос. Что значит «выиграть игру»? Какие параметры? Какие конкретные доказательства показывают, что кто-то выиграл игру?

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

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

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

Но не вся надежда была потеряна. К счастью, под всеми этими беспорядочными рукописями на языке, который я не мог понять, я смог уловить суть программы. Имея это в виду, я решил снова сломать игру. На этот раз, имея уже доступные ресурсы, я смог внести значительные улучшения, которые значительно ускорили бы процесс. И в процессе я смог применить некоторые новые концепции программирования к этому проекту! Прежде чем я продолжу, вот как выглядит часть кода (исходный код можно найти в GitHub):

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

Начиная со строки 1, код импорта. Мне нравится думать, что это важная часть для меня, потому что, в отличие от JavaScript, не все функции уже включены в Python. Пока я все еще делал игры на JS, мне не нужно было импортировать random jumbos. Фактически, все, что мне нужно было сделать, это написать Math.random() (или Math.floor(Math.random())), чтобы убедиться, что это целое число). В Python не все доступно из первых рук. Раньше я был ленив при импорте библиотек, даже библиотеки Math, потому что я привык писать код сразу на JS. Но в этом проекте я смог изучить дисциплину, необходимую для импорта библиотеки, прежде чем использовать их полезные функции.

Следующий сегмент - это код класса. Честно говоря, я никогда так хорошо не понимал ООП. Впервые я узнал об ООП из книги по Java. Я знал концепцию и то, что она может быть лучше процедурного программирования. И еще одна вещь, на которую следует обратить внимание, заключалась в том, что я действительно не понимал, почему я должен был использовать класс. Во время мозгового штурма у меня возникла внезапная мысль, что переменные относительно одинаковы. Итак, вместо того, чтобы создавать множество различных переменных, таких как user_currentThumbsUp или computer_guess, почему бы не создать класс, который мог бы определять все эти переменные, а затем создать объект на основе этого класса!

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

Эта рекурсия наиболее очевидно заменяет цикл while, о котором я изначально думал. Почему я перешел на рекурсию? Потому что это весело. Приятно пробовать что-то новое и видеть результат. Если не сработало, значит, я чему-то учусь. Если да, то я тоже кое-чему научился. Я считаю это беспроигрышным решением и считаю, что именно это действительно делает обучение прекрасным.

В любом случае, я хотел использовать цикл while для запуска игры. Но я почему-то подумал, что циклы while неэффективны, что делает код несколько запутанным и трудным для построения. Существует определенная логика между использованием цикла while, который просто кружит мне голову. Кроме того, если я пытался вернуть определенное значение, перебирая функцию в цикле, почему бы не использовать рекурсию?

Если бы я использовал цикл while, он выглядел бы примерно так (на самом деле, исходя из моего мозгового штурма):

while(user.currentThumbs != 0 or computer.currentThumbs != 0):
    if randomInt >= 5:
        #code user turn
    else:
        #code computer turn

Проблема с указанным кодом в том, что он недостаточно гибкий. Каким будет второй ход после выбора randomInt? Это не должно быть решено другим randomInt, вместо этого оно должно быть передано оппоненту. Теперь я мог бы попытаться написать новую переменную, которая имела бы строку или целое число, которое могло бы показать, кто это делает, а затем, когда поворот будет сделан, я могу изменить это целое число на другое значение (на самом деле имеет смысл, какой). Но что-то в нем кажется сложным и ненужным. Я имею в виду, разве в программировании не замечательно то, что существуют более эффективные способы делать что-то? Даже в CodeWars люди могли решать проблемы, используя всего 1–3 строки кода.

Еще одна проблема с этим кодом: что, если я захочу добавить еще одного игрока? Должен ли я сделать еще один elif оператор и изменить randomInt, одновременно изменив роль переменной, которая определяет, кто получит следующий ход?

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

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

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

Итак, в общем, вот что я узнал из этого проекта:

  • Задавайте вопросы, отвечайте на них по ходу дела.
  • Мозговой штурм и дать время подумать - лучший способ подумать
  • Рекурсии могут быть полезными и интересными
  • Understanding Class поможет сэкономить время
  • «Думающая» часть программирования - это то, что заставляет людей увлекаться
  • Начать проекты. Вы можете многому у него научиться.

Спасибо, что прочитали эту статью! Я надеюсь, вам понравится. Пожалуйста, напишите мне, если у вас есть какие-либо вопросы. Я рад учиться на своих ошибках.