Интересные проекты из скучных

Последний пост(ссылка на него в посте сверху) был о постепенном переходе к большим и сложным проектам. Сегодня, о диаметрально противоположном - маленьких, начальных проектиках, таких - из первых глав книг по вводу разные ЯПы. Обычно, они очень банальны, их главная задача показать какие то основы синтаксиса, но даже из них, можно сделать что то интересное.

В предыдущем посте, упоминалось простое, но, как мне кажется, крайне эффективное упражнение - посматривать и исправлять свой код недельной/месячной давности, особенно на начальных этапах. Этот пост, примерно о том же, только тут, доводим старый код до более менее интересного проекта.

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

Добавить реализаций
В чем суть программы? В игре, в реализации алгоритма игры, самый простой вариант - рандомно ставится крестик/нолик в незанятую ячейку, и так до выполнения условия для победы. Очевидно, рандом - так себе реализация. Можно зайти в википедию и узнать про метод минимакса, комбинаторику, разные стратегии, дерево игровых ситуаций и т.д. Можно в гугле найти "как выигрывать в 'крестики-нолики'", и попробовать реализовать разные варианты самому. Да даже, просто первый ход в центр поля, дает преимущество, и улучшают метод полного рандома(кстати, в игре разные варианты реализаций, можно представить как уровни сложности).

Тут важно сказать одну вещь, она как раз относится к таким простеньким играм, если в игре реализовано взаимодействие человек vs компьютер, то ОБЯЗАТЕЛЬНО, должно быть вариант компьютер vs компьютер, кажется мелочь, но на деле архиважная штука, особенно, если взаимодействие происходит в окошке терминала. 

Сравнить их между собой(проанализировать)
Именно на этом шаге, проект становится интересным. Что в данном случае сравнивать? Очевидная метрика игры - победа/проигрыш/ничья, еще на ум приходит количество ходов. Пару счетчиков, и у нас уже есть цифры которые можно сравнивать. Самый простой пример: в позапрошлом абзаце, я написал, что 'первый ход в центр поля, дает преимущество', вроде бы логично, но нет примерной цифры, насколько это большое преимущество, нужно это проверить. Запускаем, предположим 1000 итераций игры, игрок A всегда начинает с занятия центра поля, дальше идет рандом, смотрим какой процент игр, в итоге, выиграл игрок A.

Эта программа не сильно отличается от самой простой реализации "крестиков-ноликов". Вместо хода пользователя, мы заново запускаем функцию заполняющую свободную рандомную клетку, прикручиваем счетчик, добавляющий единицу при каждом вызове этой функции, ну и при исполнении условия для победы, прибавляем к другому счетчику 1, после чего смотрим какой процент составляет это число от 1000 и считаем среднее колл-во ходов за игру. 

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

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

Эти же правила применимы к некоторым cs проектам(хотя они и так самодостаточны). К примеру, возьмем все тот же архиватор, разные варианты сжатия, разные алгоритмы.