вавилонский лабиринт
Проект игры для программистов: по карте-лабиринту двигается робот, нужно написать программу, помогающую ему попасть в отмеченную точку карты. Традиционно имеется выбор датчиков и эффекторов, ограничения на объём программы, данных и времени.
Но язык программирования на каждом уровне другой. ( Интересно только программистам )
Но язык программирования на каждом уровне другой. ( Интересно только программистам )
рассмотрим тривиальный лабиринт и разные условия:
* неограниченный запас топлива, запас памяти на весь лабиринт, зрение на 1 клетку вперёд (тривиальный обход с построением карты).
* сильно ограниченный запас топлива, видение карты в радиусе 0.1 диаметра лабиринта (на тупой обход не хватит, надо строить карту по фрагментам).
* маленький топливный бак, заправки разбросаны по лабиринту.
* ограниченная память, в которую весь лабиринт не влезет даже как битмэп.
* скользкий пол: в таких клетках нельзя затормозить или повернуть, начав движение.
* инерция: разгон требует топлива, контролируемое торможение рекуперирует часть топлива, столкновение нет. поворот на большой скорости невозможен.
* гравитация: лабиринт расположен вертикально, как в платформере, можно прыгать и падать, с ограничением высоты или без.
* окна: непроницаемые стены, через которые виден лабиринт за ними.
* зеркала: непроницаемы, но датчики зрения видят "сквозь них" мнимое изображение лабиринта "за спиной".
* рентген: по "цвету" стен можно определить, сколько других стен за ними.
* двери: клетки с односторонним движением, заранее различимые или нет.
* знаки: искомое место не помечено прямо, надо расшифровывать знаки на стенах/полу.
* дорогостоящее (по времени или топливу) зрение вдаль, бесплатное зрение в соседнюю клетку.
* темнота: дельнее зрение работает только вблизи "источников света", в иных местах работает "осязание" на одну клетку вперёд.
* бесконечный, процедурно генерируемый лабиринт; известно, что цель не далее указанного расстояния от стартовой точки.
* реал-тайм: за время перемещения вдоль клетки может исполниться ограниченное число инструкций (осмысленно для инерции и командных режимов).
Это навскидку вариации почти только лабиринтов (их можно комбинировать), и ни слова о характере предлагаемых языков.
Reply
ограниченная память - это фигня, если на пиксел тратить один бит то картинка влезет куда угодно. ну и так далее.
Reply
ограниченная память, в которую *не* влезает картинка целиком, даже по биту на пиксел - хорошее развлечение на эффективное внутреннее сжатие, например, или на векторизацию.
кстати, можно же и лабиринты делать не только из клеток, а из произвольных полигонов.
Reply
есть и другой недостаток у идеи - реализация упомянутых мелочей и борьба с меняющимся языком займет большую часть времени. в реальной жизни обычно одни люди пишут низкоуровневый глубоко оптимизированный код, а другие придумывают всякие умные алгоритмы, потому что так эффективнее.
Reply
ну, не знаю, как люди, хорошо играющие в Starcraft, имеют большой объём внимания и стратегическое мышление, или там умелые главы кланов в EVE умеют и в реальной жизни проектами рулить, так и тут я надеюсь на некоторую корреляцию. но не более.
Reply
Reply
Reply
Хотя я ни о чем подобном не слышал.
В конце концов, в логических играх соревнования алгоритмов процветают.
Естественно было бы, если бы издатели нанимали победителей, хотя бы когда "AI" компютерных противников труден для написания, но существенно влияет на интересность игры для людей.
-----
А в описанном случае хардкор, с элементами психологии программистов и всякими интересностями, вроде существования "равновесия Нэша", более экзотических равновесий, кооперации и т.д.
И заранее ничего не будет понятно.
Reply
Leave a comment