Как стать автором
Обновить

Комментарии 50

да, это супер штука в свое время была) Я обычно не люблю «ремейки», но тут реально хорошая игрушка получилась.

Интересно, но хотелось бы больше технических деталей, конечно.

Макнейл: это идеальная мобильная игра, потому что в неё играли все, и особенно люди, в жизни не игравшие больше ни в одну игру.

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

Но ведь в то время все эти внутриигровые покупки и пр, было практически невозможно реализовать. Не было никаких гарантий что у игрока есть интернет и карта для оплаты.
Во времена появления змейки в nokia, игры были в прошивке. J2ME появилась в телефонах позже.

Моя история про Змейку.
В 91м году один из компьютерных журналов напечатал листинг Nibbles на QBasic. На то время у меня был ЕС1840 с GW-Basic на дискете с MS DOS, катастрофическая нехватка игр и неуемный оптимизм 8-летнего ребенка. Несколько дней я кропотливо перебивал код из журнала и исправлял опечатки, чтобы в итоге узнать, что инструкции QBasic и GW-Basic не полностью совместимы и код в принципе не запустится — обязательно нужны номера строк, отличаются некоторые операторы, а команда PLAY почему-то не издает звук и ее пришлось комментировать. Так я сделал первый в своей жизни порт. И понеслось :)
Так всё-таки запустил?
Конечно! :) Играть же надо было во что-то
То есть человек просто реализовал давно известную игру на новой платформе, по сути украл идею, а его превозносят как создателя? Забавно.
Присоединяюсь.
В змейку я еще на СМ-4 играл. В 1985 году.
на СМ-4 играл

АААА… это зеленое свечение дисплеев в ВЦ ЛГУ имени Петера Стучки… Змейку не помню, но помню «Танчики»! По «сети»! В тот же примерно год!
Ну сам он, вроде как, не считает им совершённое подвигом. А люди любят раздувать из мухи слона…

Написано действительно чудно.


Но он не был бы таким быстрым, если бы вызывал сбои в телефоне, происходящие из-за утечек памяти. Поэтому я реализовал его так, чтобы утечек памяти не было.

Интересно, он был первый в подобных подвигах, что аж без ликов реализовать столь сложный проект?

Думаю нет. Я думаю что это сложности перевода с финского на английский. Имелось в виду, что «я хотел сделать её настолько быстрой, насколько возможно… можно было бы сделать её ещё быстрее, если бы я допустил утечки памяти… но я этого не хотел и сделал её без утечек».

Невыясненным остался один вопрос: как, чёрт побери, он собирался сделать «Змейку» быстрее, допустив утечки памяти?

Вот это меня как бы больше волнует — я себе этого даже представить не могу…

"как создавалась «Змейка» для телефонов Nokia":
-Хотели сначала тетрис, но оказалось, что у тетриса был владелец, поэтому решили делать змейку.
-Это феномен.
-Моя самая любимая игра.
-А ещё я добавил задержки и не стал добавлять утечки памяти.
-Сначала я нарисовал круг, и вот уже получилась сова, т.е. змейка!

«Эрикссону», кстати, наличие владельца у тетриса как-то не помешало.
Арманто сдержан и скромен, когда рассказывает о своей карьере. «Очень многие приходят в восторг, когда узнают, что это я написал Snake», — говорит он

… поэтому я скромно умалчиваю, что я её не писал, а просто перенёс на новую платформу, — думает про себя Арманто при этом, но вслух не говорит.
Про перенос можно было бы говорить, если бы он где-то взял код и монтировала его.

Но змейка, как бы, настолько простая вещь, что её проще написать, чем портировать… Особенно если писать нужно на ассемблере под нестандартную платформу…
Прошивка 6110 однозначно писалась на С, в ней видно следование соглашениям о вызове, стековые переменные итд. Там уже относительно приличное железо было — 32-битный процессор (ARM7TDMI) для UI и верхнего уровня GSM протокола, DSP (что-то из ранних TMS320) для нижних, flash память как бы не 512К.
Когда о мобильных телефонах мы и не мечтали.
image
Питон на 8-битном процессоре!
Но не Micropython
Поэтому я реализовал его так, чтобы утечек памяти не было.

То ли баг перевода, то ли человек и правда гордится тем, что реализовал код так, как и надо писать программы — без утечек памяти!

А в змейке всегда поражало, что у нее этакая красивая графическая заставка, и совершенно неграфический, аскетичный геймплей. Прямо стоило подогнать стили заставки и игры — впрочем, кого это из программистов волновало?
А в змейке всегда поражало, что у нее этакая красивая графическая заставка, и совершенно неграфический, аскетичный геймплей. Прямо стоило подогнать стили заставки и игры

Как вы себе эту подгонку представляете?
Разрешение экрана у 6110 всего 84x48, для украшательств банально нет пикселей.

Не рисовать красоты (заставку) там, где их в игре не будет.

Создатели демосцен так не думают.

По сути, вы предлагаете отказаться от рекламных материалов.


Следуя вашей логике, нужно убрать с обёртки шоколадных конфет «Мишка косолапый» репродукцию, ведь внутри нет никаких мишек в сосновом бору.


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


Да и дизайн коробок с настольными играми тоже переделать, а то непорядок: на обложке яркая картинка с героями, а в коробке невзрачные пластмассовые фишки.


Вряд ли это можно счесть здравым предложением.

Никогда не любил эту игру!

Бунтарь!

Тоже всегда был равнодушен к ней, пока случайно не попробовал режим на двоих, и вот это уже совсем другое дело. Попробуйте, от напряжения можно вспотеть.
Этой игре более 50 лет, и популярна она именно на Motorolla. Ни о чем статья.

Играл в эту змейку на тетрисе на батарейках еще когда телефоны были с проводами!

Помню когда-то в журнале «Радио» публиковался код для этой игры для компьютера Радио 86РК. Так вот, Радио 86РК у меня не было, а был ZX Spectrum. Осложнилось дело тем, что у Радио 86РК экран текстовый, а спектрума — графический (да ещё и по нынешним меркам очень нестандартный). Вышел из положения тем, что вместо вывода символа — менял атрибуты знакоместа, так что вместо цепочки букв «О» у меня ползала просто белая полоса. Тогда я был ещё школьником, поэтому восторг от того, что игру удалось самому ввести с клавиатуры был огромным. Что там ваши нокии…
Было дело, игрался змейкой на Радио-86рк. Работала быстро, тк была на ассемблере. Я туда еще немного своего функционала добавил и звуковое сопровождение на таймере (по моему таймер был ви53, на 3 канала, в стандартном комплекте его не было, зато был хрипящий динамик подключенный к выходу разрешения прерываний).
Ну а Nokia черно белая у меня до сих пор как второй телефон идет, причем по сравнению с iPhone ловит мобильную связь лучше в зоне с плохим покрытием, и батарейка 10 дней держит.
Было дело, игрался змейкой на Радио-86рк
Почти уверен, что их там было много. Слишком простая и примитивная (хотя и затягивающая) игра, а авторскими правами тогда никто не заморачивался.

Да, возможно были другие, но это была «та самая» которая была опубликована в журнале Радио с подробным объяснением как этот код работает. Собственно это и была моя точка входа в программирование.

Кому интересно, вот залипательная змейка littlebigsnake.com
Тем временем где-то на планете грустит один создатель Змейки :(
Или давно умер уже.

Недавно была статья История алгоритмов рандомизации «Тетриса», вот бы и про рандомизацию в Змейке почитать.

Кто-нибудь релизовывал Змейку сам? Там используется массив из координат каждого пикселя змейки или у вас другое решение? И чему соответствует размер массива? Размеру количества пикселей экрана?
Просто подумал, что можно хранить не координаты, а длину отрезка и поворот — одной цифрой со знаком. Допустим, -7 — это поворот против часовой и до этого поворота позади остаётся отрезок в семь пикселей. По памяти выигрыш должен быть в два раза, зато значительно возрастут вычисления?
Есть множество способов сделать змейку. Массив — это в примерах для начинающих программистов на Бейсике из 70-х. А по нормальному — не надо никаких массивов, длин и вычислений. Достаточно хранить только координаты и вектор головы и хвоста. Т.е. мы знаем, в какую сторону движется голова — куда в экране ставить новый элемент, и откуда движется хвост — где стирать лишний элемент. Для удлинения на элемент достаточно один раз пропустить стирание элемента, тогда голова передвинется, а хвост нет, и змейка станет длиннее.
А откуда хвосту знать где поворачивать?
И вместо внутреннего массива используется массив пикселей экрана, значит? Ещё, чтобы реализовать неоднородный фон, понадобится рисовать змейку на отдельном слое.
Почти все реализации змейки работают на регулярной сетке. Это могут быть непосредственно знакоместа текстового экрана, или буфер в памяти, но в общем да — в любом случае всегда уже есть некий массив флагов, показывающих, занята ли клетка игрового поля элементом змейки (также камнем, морковкой, стеной). И этого достаточно, чтобы описать все возможные положения и перемещения змейки. В классических реализациях ещё добавляют растущий массив элементов в памяти, и вот как раз он реально не нужен. Скорее всего причина его появления в том, что эти (старые) программы были призваны как раз продемонстрировать использование массивов, а цели эффективно реализовать игру в них не стояло.

Про вектор хвоста я подзабыл, да, важный момент в том, что он хранится прямо в сетке. Это похоже на волновой алгоритм — пишем вектор головы в сетку, и, зная начальную позицию, читая значения из сетки, можем восстановить весь путь, пройденный головой, т.е. всю длину змейки. Если тело змейки не анимировано, достаточно перерисовывать только голову и хвост.
В классических реализациях ещё добавляют растущий массив элементов в памяти, и вот как раз он реально не нужен.
А где эта «классическая реализация» существует??? Змейка — была одной из первых программ, которые я реализовал в школе (Turbo Pascal, вот это вот всё, SegB000/SegB800, вот это вот всё), и никогда не задумывался над тем, что это может быть реализовано иначе чем для каждого знакоместа хранить направление…

Интересно всё же увидеть — что я пропустил…
Я имею в виду реализации из книжек по программированию на Бейсике, которые появились у нас в конце 80-х. В них были подобные варианты с массивом.
Круто. Конечно BASIC способствует кривому коду, но всё-таки предел какой-то должен быть…
Для Трона очень подходит, ведь по сути Трон — Змейка без хвоста.
А насчёт своей идеи выигрыша по памяти в два раза я поторопился — он ещё больше, т.к. поворотов бывает меньше даже чем самый длинный отрезок Змейки.
А насчёт своей идеи выигрыша по памяти в два раза я поторопился — он ещё больше, т.к. поворотов бывает меньше даже чем самый длинный отрезок Змейки.
Вы считаете максимальный возможный выигрыш? А зачем? Чтобы игра упала, если кто-то будет играть «неправильно»? Понятно же, что если кто-то устроит из Питона кривую Гильберта, то вам потребуется больше памяти, чем с тривиальным решением…
Допустим, у нас экран 2 на 2, массив на 4 элемента. Если заполнить его Змейкой, то это три отрезка и три элемента — разве не так?
Так. На таком только поле ваша оптимизация может иметь смысл. Так как длина отрезка всегда один и её можно не хранить.

Но «Змейка» на поле 2x2 — это какая-то ну исключительно грустная «Змейка»…

А если поле будет хоть чуть-чуть больше, скажем 3x3, то вам уже потребуется на каждый отрезок три бита: один на длину, два на направление.

Отрезков на поле 3x3 может быть до шести — это уже 18 бит.

А «наивная реализация» — это чётко два бита на каждый элемент, только направление и всё. То есть те 18 бит, только манипулировать проще.

Начиная же с размера 4x4 там уже получается 12 отрезков по 4 бита (2 на направление, 2 на длину), итого 48.

А с наивной реализацией — 32 бита.

Ну и так далее — чем больше будет поле, тем больше вы будете проигрывать в наихудшем случае…
Хранить в битах — об этом речи в теме не шло же, тут уже совсем всё по другому :)
Выходит тогда, что мой способ больше подходит цветным Змейкам с неоднородным фоном.
У разных людей — разные умолчания. Нам нужно хранить «дофига» направлений — по одному на каждую точку поля. Чтобы хвост стирать.Как ещё их хранить, если не как по паре бит на точку? Мне всегда казалось это самым разумным, как-то никогда даже не задумывался о том, чтобы по другому хранить. Я змейку в школе писал, тогда я ни про какие «Big O» не знал… структура данных была смешная (Turbo Pascal, поле 80x25):
var
  GoTop : array[1..25] of set of 1..80;
  GoLeft : array[1..25] of set of 1..80;


Сейчас, когда вы заговорили об экономии при использовании явно не слишком эффективного метода (ну то есть он сходу кажется неэффективным: данные неоднородны, манипуляции сложные) — пошёл, посмотрел на кривую Гильберта, посчитал… Всё равно тот вариант, что у меня — проще и быстрее… хотя сегодня я, наверное, сделал бы по другому (уж как минимум использовал числа от 0 до 79, а не от 1 до 80)… но идея та же, всё равно.

P.S. Для чего подходит ваш способ я, если честно, затрудняюсь сказать. Навскидку не вижу никаких вариантов, когда он был бы эффективнее… В худшем случае, когда ресурсов не хватает, конечно…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.