Основная задача игры в танчики Battle City - не только перебить врагов, но и сохранить целым.
Прими участие в бешеных танковых боях - круши вражеские танки, помогай своей команде. «Танчики Pro» — продолжение Танчиков. Тем, кто еще не играл, доставит. Java игра Tanks Pro для телефона. Вы можете скачать игру на ваш мобильный.
Многие из нас выросли на «Танчиках», «Марио» и прочих нетленных шедеврах времён рассвета игровой индустрии. Приятно порой вспомнить, как днями напролёт резались с друзьями у экранов телевизоров, меняя джойстики как перчатки.
Но время не стоит на месте, и одни интересы сменяются другими. Однако, порой любовь к старым-добрым игрушкам не угасает. Я отношу себя к людям именно таким, и мой интерес к старым играм пошёл в сторону реверс-инжиниринга, что и привело меня в IT-сферу, где я и осел с концами.
Скачать Игру Танчики Java
Я хочу рассказать вам о том, что же под капотом у железных монстров из знаменитой игры Battle City (в простонародье «Танчики») с не менее знаменитой приставки Nintendo Entertainment System (сокращённо NES, в России более известен её китайский клон «Dendy»). Мне в своё время эта информация показалась довольно любопытной — надеюсь, такой же она покажется и вам. Предыстория Несколько лет назад, изучая разнообразные графические библиотеки, я поставил перед собой цель написать точный клон «Танчиков». Так уж сложилось, что как раз в тот момент один мой знакомый занимался созданием довольно интересного путём модификации кода оригинальной игры, так что я решил проконсультироваться у него (кстати, огромное ему спасибо за консультацию и помощь в подготовке статьи). Тогда меня поразило то, какими методами реализовывался некоторый функционал.
Вот и решил я, спустя годы, поделиться этими знаниями с общественностью: всё-таки это часть истории геймдева, которая может показаться интересной как ценителям классики, так и разработчикам современных игр. Хочется сказать отдельное спасибо человеку под ником за труды по декомпиляциии игры. Прежде всего благодаря полученным им исходникам стало возможно настолько подробно вникнуть в суть. Карты уровней Карты в Battle City состоят из тайлов — блоков размером 8x8 пикселей. Весь фон, видимый на экране, является картой — гипотетически даже со счётчиком жизней можно взаимодействовать, но по факту это, конечно же, не удастся. Однако, в сериализованном виде уровни хранятся более компактно: для этого тайлы компонуются в блоки размером 2x2 тайла. Всего имеется 16 разновидностей блоков, которые приведены в таблице ниже.
Хранится только основная часть карты (13x14 блоков), по которой и ездят танки — нет смысла сохранять статичные стены и вспомогательную информацию. Для записи одного блока используется 4 бита, таким образом, вся карта занимает 91 байт. Блок Код Блок Код Блок Код Блок Код 0 1 2 3 4 5 6 7 8 9 A B C D E F В отличии от блоков, разновидностей самих тайлов гораздо больше, а именно — 256, т.е. Ровно столько, сколько вмещает одна страница знакогенератора — участок видеопамяти, где каждому тайлу соответствует индекс от 0 до 255. Тайлы используются как для создания окружения уровня, так и для отображения информации о количестве вражеских танков, жизней и т.п.
Но непосредственно в элементах уровня их используется всего 22 — из них 6 для формирования перечисленных блоков, остальные 15 — дополнительные тайлы кирпичных блоков, о них стоит рассказать подробнее. Если карта состоит из тайлов размером 8x8 пикселов, то как же получается уничтожать кирпичные мини-блоки размером 4x4 пиксела? Дело в том, что на самом деле не существует «кирпичей» такого размера, вместо этого существует 16 видов обычных тайлов — по одному на каждое состояние. При попадании по блоку размером 4x4, в реальности заменяется целый тайл, а сам кирпич переходит в другое состояния, в зависимости от того, куда попал снаряд. Тот же эффект можно заметить, когда в танк попадает снаряд.
Визуально соприкосновение возникает на разной дистанции от границы спрайта танка (как внутрь, так и наружу) — от 0 до 7 пикселей. Но если танки рисуют под собой стену, то пули — нет.
Более того, на расчёт коллизий между снарядами уходит большая часть времени кадра! И в особых случаях его может даже не хватить, тогда все эти операции перенесутся на следующий кадр, а текущий не будет изменён.
Да, и в «Танчиках» бывают лаги. При попадании снаряда одного игрока по другому, второй теряет управление движением на 192 кадра, т.е. На три игровых секунды. Но в режиме демонстрации этого не происходит.
Примечательно то, что снаряд имеет две точки, по которым проверяются коллизии. Они находятся по бокам от носа пули, и фактически может быть обработано две коллизии одновременно (иначе, после обнаружения хотя бы одной из них, снаряд исчезает). Это и происходит, если, например, целиться в центр кирпичного блока: уничтожается целая полоска.
Ещё одна интересная вещь: медленные пули (подробнее о скорости чуть ниже) обрабатываются не каждый кадр, а через кадр. Теоретически может возникнуть ситуация, когда игра будет тормозить в каждом нечётном кадре, и процессор не будет успевать дойти до обработки коллизий такой пули, откладывая её.
А ведь в следующем кадре он и вовсе не должен будет её обрабатывать! Из-за подобного стечения обстоятельств медленные пули в некоторых чрезвычайных случаях могут пролетать стенки насквозь, когда игра сильно притормаживает. Движение Скорость в игре обуславливается количеством пропускаемых кадров при изменении координат. Так, например, у игрока координата меняется каждые три кадра из четырёх, у самого быстрого врага в игре — каждый кадр. То же самое касается и снарядов — их существует два типа: быстрые, летящие со скоростью 4 пикселя в кадр, и медленные, имеющие скорость 2 пикселя в кадр.
Танк Скорость, px/frame Тип снаряда Танк Скорость, px/frame Тип снаряда 3/4 Медленный 2/4 Медленный 3/4 Быстрый 4/4 Медленный 3/4 Быстрый 2/4 Быстрый 3/4 Быстрый 2/4 Медленный Поскольку при движении необходимо обрабатывать и коллизии, то уместно было бы оптимизировать рассчёты, как можно более равномерно распределив их по кадрам. При самом простом подходе достаточно было бы в чётных кадрах обрабатывать перемещение всех врагов, а в нечётных только передвижение шустрого БТР. Но тогда нечётные кадры могли бы быть перегружены, и игра бы просто лагала. На самом деле нагрузка распределена довольно хитро. Производится «XOR» между номером кадра и номером танка, и только потом проверяется чётность/нечётность результата. В итоге получается, что в чётных кадрах обрабатывается одна половина медленных танков, а в нечётных — другая. И немного информации о скольжении на льду.
Тут всё просто: после того, как игрок отпустит кнопку направления на льду, танк будет ехать сам ещё 28 кадров (т.е. Проедет 21 пиксель) или пока не выедет со льда.
В этот период состояние его гусениченого трака не меняется и звук езды не проигрывается, а если нажать кнопку направления уже на льду — будет проигран характерный звук, если таймер скольжения в этот момент равен нулю. Пасхальные яйца Пасхальные яйца во многих играх того времени, не обошли стороной они и Battle City. Если на титульном экране выбрать режим CONSTRUCTION, войти и выйти из него 7 раз (нажимая START, START), затем зажать на первом джойстике кнопку «вниз», нажав на втором кнопку A 8 раз, потом зажать на первом джойстике «вправо», нажав на втором кнопку B 12 раз, и, наконец, нажать на первом джойстике кнопку START, то мы увидим трагическую историю любви.
Кроме того, в игре можно встретить неиспользуемые данные — имена разработчиков (RYOUITI OOKUBO, TAKEFUMI HYOUDOU, JUNKO OZAWA) и иероглифы, означающие имя главного героя лавстори и название улицы (возможно, на которой жил он сам или его возлюбленная). Пожалуй, здесь я не буду вдаваться в подробности, ибо это подробно изложено по ссылке чуть выше. Эпилог В заключение хочу сказать, что раньше создание игр было в некотором смысле всё же большим искусством, чем сейчас.
Это же колоссальное мастерство — уложиться в ограничения аппаратной части, и в то же время создать хорошую игру. Это сродни демосцене, которая, по сути, преследует те же самые цели — создавать шедевры там, где это сложно вообразить. В наши дни всё это уходит в прошлое, позволяя не особо задумываться о способах реализации. На мой взгляд, это сильно понижает порог вхождения в процесс разработки игр, что постепенно, но верно превращает его скорей в обыкновенный бизнес, чем в искусство.
Хотя, возможно, я просто слишком эстетичен в этом отношении. Метки:. Добавить метки Пометьте публикацию своими метками Метки необходимо разделять запятой. Например: php, javascript, андронный коллайдер, задача трех тел. Помните стеб во времена дисков типа «1000 лучших игр» когда выходила какая-нибудь тяжелая игра говорили с сарказмом, что «теперь компактная игра — это игра, с трудом влезающая на компакт!» Тогда казалось, что игры под 600 -700 метров это дикость какая-то.
А сейчас выгоднее заниматься не оптимизациями, а кроссплатформенностью, чтоб и на PC и на приставках играть можно было, над пиаром, чтобы игра в первые дни разошлась как можно большим тиражом, т.к. Очень быстро появляются пиратки. Время разработки становится гораздо важнее оптимизаций, т.к.
Пока конкурент усиленно вылизывает свою игру, можно уже 2-3 своих выпустить. Иногда выпускают такое, что не верится, что у разработчиков вообще был отдел тестирования. То, что значительное количество плюсов позволяет смириться с минусами, не означает, что минусы — это хорошо. Например, очень часто в TBS не заморачиваются с оптимизацией поиска пути, что приводит к тому, что ход занимает три секунды вместо трехсот миллисекунд.
А эти секунды складываются в полчаса ожидания за партию из полутысячи ходов. Пример реальный, в той игре после того, как оптимизацию таки сделали, ходы компьютера стали практически моментальными, а до того на больших картах занимали секунд по 15. Особенно «весело» когда подгрузки практически не завясят от железа — это явный признак косяка в архитектуре. Забить на оптимизацию ради души — и есть крайность:) Я готов простить примитивную графику, но когда игра по десятку секунд грузит маленький спрайтовый уровень на мощном процессоре и сверхбыстром SSD — это, извините, никуда не годится.
Когда на этом же железе в реальном времени и идеально гладко рендерится сложнейшая 3Д графика с уймой объектов, полигонов и источников света, а убогая плоская картинка дергается в конвульсиях — это рукожопие программиста. Возможно, впрочем, это у меня профдеформация — уже который год в геймдеве, а когда приходится писать свои имплементации механизмов типа ArrayList (да, Java) ради выигрыша в скорости то как-то раздражают те, кто просто кладут на это.
Забить на оптимизацию ради души — и есть крайность Опять вы в крайности. Где «забить на оптимизацию»? Почему если оно не работает на 1.76 МГц, то это уже «забили на оптимизацию»? Почему нельзя «оптимизировать в меру»? Выше я приводил в пример Арканум.
Да, графа так себе. Да, на слабых машинах тормозит. Но играли с упоением.
А если бы писали свои имлементации типа ArrayList ради выиграша в скорости, то мы бы могли вообще игры не увидеть. Когда игра по десятку секунд грузит маленький спрайтовый уровень на мощном процессоре и сверхбыстром SSD и снова крайности. Покажите пример игры, которая «по десятку секунд грузит маленький спрайтовый уровень на мощном процессоре и сверхбыстром SSD»? Хотя бы одной? Только не случай, когда человек вообще не разбирается в основах игростроения, а нормальный продукт, рассчитанный на людей. И снова крайности.
Покажите пример игры, которая «по десятку секунд грузит маленький спрайтовый уровень на мощном процессоре и сверхбыстром SSD»? Хотя бы одной? Только не случай, когда человек вообще не разбирается в основах игростроения, а нормальный продукт, рассчитанный на людей. Вот вам на выбор разные масштабы. Eador — через 3 года после выхода автор таки немного занялся скоростью, после чего ход компьютера ускорился на 2 порядка, и почти исправлены дикие тормоза анимаци на более-менее мощных компьютерах. Раньше приходилось извращаться с замедлением процессора.
Mass Effect 2 — если заменить ролики во время загрузки уровней на заглушки то грузится всё практически моментально вместо десятков секунд. Magic the Gathering 2012 — в момент перевода хода часто игра заметно подвисает на пустом месте, с явной зависимостью от мощности компьютера. Откровенный и бросающийся в глаза косяк. Recettear — что там вообще можно грузить совершенно неясно, графика примитивная спрайтовая, уровни маленькие, но из-за ошибки где-то в архитектуре прогрузки дико долгие. Зато если поковыряться в конфиге и выставить жесткий лимит FPS то грузит моментально. Опять вы в крайности.
Где «забить на оптимизацию»? Почему если оно не работает на 1.76 МГц, то это уже «забили на оптимизацию»? Почему нельзя «оптимизировать в меру»?Оптимизация в меру — это когда на актуальном железе всё работает с вменяемой производительностью. А если имеются очевидные косяки с явным несоответствием производительности и результата — это рукожопие.
И оно ну никак не связано с качеством сюжетной линии и проработанностью игровой механики. Я бы ещё добавил в качестве введения об устройстве видеопамяти устройств от Nintendo. Конкретно вот это описание я делал про Gameboy, в NES оно тоже близкое к этому: Довольно интересная организация экрана. Как таковой сплошной экранной памяти (как в БК или хотя бы как в ZX Spectrum) вообще нету. Отдельно лежат тайлы 8x8 в количестве до 192 штук. На экран выводится проекция аж трёх планов, снизу вверх: фона, окна и объектов (т.е.
И фон и окно — это матрицы 32x32 индексов тайлов. И для фона и для окна можно задать координаты от угла, с точностью до пиксела — тем самым, полноэкранный скроллинг не стоит буквально ничего, значение в регистр занести! Объекты (они же спрайты) — это те же тайлы, но для каждого спрайта задано положение с точностью до пиксела, и цвет 00 считается прозрачным. При этом можно создать до 40-ка спрайтов размером 8x8 либо 8x16 (размер одинаков для всех спрайтов).
Каждому спрайту можно задать отражение по вертикали и/или горизонтали — тоже даром, один битик взвести. Но в одной строке может быть не более 10-ти спрайтов. В общем, получается вещь довольно удобная для разного рода платформеров и скроллеров — загружаем кучу тайлов, набираем из них игровую сцену, сверху плюхаем подвижные спрайты. С другой стороны, работать с экраном как со сплошным полем — довольно тяжело. Прям чувствую как Вам хочется похоливарить, поэтому это мой последний комментарий — дальше пишите что хотите. 8bit CPU, 64Kb Ram — это одинаково и в NES и в ZX-Spectrum Z80@4MHz успевал (не нравится Black Raven — посмотрите первую UFO — она тоже realtime была) заниматься расчетами и (очень важный фактор) отрисовывать всю графику (а экран на спектруме был не особо удобно с точки зрения «что нибудь на нём нарисовать» устроен).
В NES есть спрайтовый процессор, т.е. CPU отрисовкой графики не занимается, только расчёты.
Конкретно в Battle city расчетов этих — около нуля, т.к. Вычислительная мощность этой игрушки никакая. «Задача недорогая для процессора» — означает что он её овер9к раз успеет посчитать без задержек в игре. Объективные доводы? Ну я не знаю. Вытащите кусок кода который занимается «обработкой коллизий», сделайте бесконечный цикл и посмотрите, сколько раз он их за время одного кадра успеет посчитать, прежде чем считать это «дорогой» задачей. Спасибо за оказанное внимание:).
Java Игра Танчики
Мне хотелось лишь услышать что-нибудь более объективное, чем ваше личное мнение. Всё-таки перед написанием статьи я проводил кое-какие исследования, и если я где-то допустил ошибку — то будьте добры, укажите на неё.
Иначе холивар затеваю не я:) А вам советую просто взять ручку, бумагу и прикинуть «на глаз»: при частоте 1.76 МГц мы получаем простор примерно в 30 000 тактов в кадр. Допустим, на обработку коллизии одной пули надо 50 инструкций, максимум на экране может находиться 10 пуль (6 вражеских и 4 пули танков игроков). В среднем на инструкцию приходится 4 такта, т.е. Получаем 200 тактов на обработку одной пули. Пусть мы проверяем пули только на столкновение друг с другом. Чтобы попарно сравнить 10 пар, понадобится 45 сравнений. 45.
200 = 9 000 тактов, и это не учитывая других проверок и излишней оптимистичности исходных данных. Могу где-нибудь ошибаться, но это не важно — даже при грубых подсчётах очевидна дороговизна данной операции.
Игры Танки Танки – безусловно, одно из самых эффективных средств для наземных боевых сражений. Танки применялись в военных действиях во времена последних ста лет. И даже на сегодняшний день эти боевые машины применяются для урегулирования конфликтов между определенными странами населения. Если вы желаете ощутить всю мощь настоящих, железных танков и жаркую атмосферу сражений, сыграйте в игры «Танки». Здесь вас ждет множество заданий, захваты территорий, танковые баталии и даже начало настоящей войны с применением танковых единиц.
Каждая игра имеет свой уникальный смысл. В какой-то из них вам нужно взрывать вражеские танки, в другой - нужно защищать свою базу от нападения танков. Все танки делятся на разные типы: противотанковые установки, артиллерийские, тяжелые танки, средние и легкие. В этих играх о танках вам предстоит выполнять различные задания по уничтожению вражеской техники и захвату определенных территорий. Также в этом разделе есть игры «Танки» о Второй Мировой Войне, а также игрушечные танки, которые станут весьма интересным развлечением для мальчиков.
Игры Танчики На Двоих
Выбирайте игру на свой вкус - и вперед на поле боя!