Привет Пикабу! Недавно я выпустил свою книгу по программированию и вы поддержали меня 20 000 лайками O_o
Сказать что я шоке - это словно промолчать. Очень приятно, спасибо! Хочу поблагодарить вас и всем моих читателей и разыграть 5 ноутбуков чтобы добавить вам мотивации в изучение IT. В конце поста будут подробности.
А пока хочу рассказать о своём первом ноутбуке и как я стал программистом, нашёл свою первую работу и меня первый раз уволили.
Эта история началась в 2011 году в Казахстане
На мое 14-летие родителе подарили мой первый пк - HP 620. К этой адской машине я каким-то образом приколхозил телефон в качестве модема и шиковал на 50 мегабайт в день за какие-то астрономические деньги (все школьные пайки туда улетали).
HP 620 (Фото не мое, но модель та же)
О С++ тогда в интернете было написано только то, что мне нужно установить Visual Studio. Который я так и не смог скачать и очень долго грустил. Где-то начитался, что в такой ситуации нужно установить Linux и взять компилятор GCC, который уже в нём на борту :)
Злой школьник
Нельзя давать юноше Linux. После того, как я добыл диск с Ubuntu, меня выключило из жизни лет на 5. Я херачил на плюсах, собирал Debian и с утра до вечера вдуплял в сканер портов.
Но это совсем другая история.
Параллельно с этим у меня появилось жгучее желание стать хакером. А еще я хотел писать сайты, реверсинжирить программы, заниматься системным администрированием и, конечно же, делать игры. Я, как голодная собака на фуршете: Пытался запихнуть в себя всё и сразу.
Где-то через годик я уже сделал свой первый сайт и написал первый работающий вирус. Он заражал компьютеры и заменял локально сайт VK на специальный фейк, который присылал мне введённые данные. За год у меня накопилось около 500 аккаунтов.
В моменте я чувствовал себя королём горы. Умею всё! Знаю столько языков! И жнец, и певец, и на дуде игрец… Но как лопатой по голове, мне сбило корону, когда я попытался на этом заработать. Оказалось, что я всё знаю поверхностно и только копирую примитивные примеры с книг и разных статей.
Эго сбило. И я чувствовал себя раздавленным. Оказывается, я не хакер, а злой школьник, который не может взяться за что-то одно и нормально в этом разобраться. Каждый раз, когда я брался за что-то одно, меня мучали вопросы:
1) А вдруг на чём-то другом будет больше денег?
2) А пока я буду учить, не станет ли это не актуальным?
3) А точно ли это моё?
Робко начинаю что-то понимать
Все изменилось вместе с этим скриншотом и моим первым проектом на Unity. Тогда я впервые сфокусировался на чём-то одном, отбросил все вопросы и начался настоящий прогресс.
Мой первый проект в Unity
Проект мы так и не закончили, хоть и работали над ним 2 года. Но это не важно. С этого момента я стал разработчиком игр. И это самое важное, что случилось в моей жизни.
Тогда мы с моим школьным другом оба хотели стать разработчиками. Вместе искали первые книжки и тыкались в Unity. Но, к сожалению, он бросил после первых неудач, а я выдержал и продолжил идти этим творческим путём.
Оно того стоило. Самым сложным периодом стало время до первой оплачиваемой работы. А дальше с денюжкой уже повеселей пошло.
Новогоднее чудо и первая 1000 долларов
В 15 (!) лет я начал работать программистом за деньги. Я был очень-очень счастлив, когда меня наняли. Это был просто какой-то взрыв чувств на толчке от которого я лечу уже 12 лет.
Мне повезло, но есть поговорка: "Удача сама не приходит: ее работа за руку приводит."
В 2012-ом году я просто учился программировать и работать в Unity. А ещё я сидел в группе VK по тематике, в которой было около 100 человек. На тот момент это было единственное сообщество)
И так как я был книжным червём, то каждый раз, когда там кто-то что-то спрашивал, я просто отвечал и помогал разобраться. Бесплатно. Потому что любил это.
Родители, правда, были против. Я забил на школу и меня оставили тогда на второй год. Каждую неделю папа приходил с серьёзным разговором: "Переставай ерундой заниматься. Чем себя кормить будешь?". Так я просидел весь 2012-ый год.
Чудо произошло под Новый год. Родители пришли с ультиматумом, что либо я найду работу и буду обеспечивать себя сам и жить как хочу, либо болты затянут полностью. Я почти отчаялся, но буквально через два дня мне в личку постучался незнакомый человек.
Он такой: "Слушай, мы ищем разработчика в компанию. Видели, что ты всем отвечаешь. Не хочешь попробовать?"
Я помню, как под ёлкой загадал желание: "Хоть бы меня взяли".
И меня взяли))
Проект был онлайн-файтингом под VK. Скриншот прикрепил.
Конечно, были проблемы из-за того, что мне было всего 15. Но компания пошла на встречу и деньги я получал на папу. Платили каждую неделю. И мы стабильно раз в неделю ездили в банк и снимали наличку. Папа просил не тратить деньги, вдруг "назад попросят", но меня больше не трогал. Платили мне тогда 1000$ в месяц. В Липецке на эти деньги в 15 лет я был прям королём и мог купить всё.
Ну и перестала ходить в школу, перешёл на домашнее обучение и кое, как через несколько лет получил аттестат за 9 классов с тройками по всем предметам.
Выстрел в колено
Меня сгубило полное отсутствие Софт Скиллов. Если по-человечески, то был обычным задротом.
На моей первой работе я быстро разобрался с новой системой анимации в Unity и с сетевым программированием. Сетевой файтинг - это, конечно, то ещё задротство. Это считается одним из сложнейших жанров. У меня от этого ЧСВ до небес взлетело. Кстати, именно это мы часто наблюдаем у наших учеников, когда после учебы они получают сочное портфолио и многих начинает заносить.
Косяки у меня были простые:
1) Мог выполнить задачу и сдать её, не протестировав.
2) Закрыл задачу - поехал тусоваться и тратить деньги. А когда звонят и спрашивают, почему не за компом, то искренне удивлялся: "Ну я же всё сделал, вам какая разница".
3) Мог искренне считать, что геймдизайнер не прав и начать саботировать задачи. Мол, они дураки и всё равно хрень получится.
Тогда мне казалось, что я самый крутой, ведь я был единственным разработчиком на проекте. За это меня через пол года справедливо выгнали. А я потом ещё несколько месяцев гордый ходил, мол: "такого специалиста потеряли". Но правда была в том, что программистом я был начинающим, а вы*бывался за десятерых.
Не будьте тупыми мудаками
После того как отсутствие денег меня приземлило, я пошёл хреначить на фрилансе.
После увольнения было легко, пока были деньги. А потом они закончились, и встал вопрос: "На что жить дальше?". Я хотел заниматься своими проектами, поэтому пошёл фрилансить. Профессия разработчика игр этим очень удобна. Можно делать проект мечты и для поддержания штанов параллельно выполнять заказы.
На биржах фриланса мне долго не удавалось найти. Там либо какие-то неадекваты типа: "Сделайте мне убийцу ГТА за 2000 рублей", либо без очень жирного портфолио даже рассматривать не хотели.
Заказы было сильно проще искать в профильных группах и чатах по разработке игр. Там всегда тусуются заказчики, с которыми можно адекватно и по-человечески договорится. На бирже я протусовался неделю и тишина. А по дедовскому методу уже к вечеру нашёл первый заказ.
У меня заказали сделать Драг Рейсинг игру. Буквально базовую механику, натянуть UI и добавить три готовых машины. За это мне заплатили 320$. Я его сделал не спеша, где-то дней за 5. Мне всё оплатили и я довольный делал проект мечты, но это уже другая история.
А что с ноутбуком?
Потом было много чего еще, работа в США, переезд в Питер, основание своей игровой студии, открытие собственной школы. Но старичок HP уже не справлялся и остался в моей детской комнате в Липецке. Он до сих пор со мной и до сих пор лежит там с уже высаженным аккумулятором и с Ubuntu 14.10 на борту.
Это я все к чему? Подарок родителей стал для меня знаковым, и вместо того, чтобы пить пиво за гаражами я стал программировать, а потом пить пиво за гаражами.
И сейчас когда у меня у самого есть возможность делать такие подарки, я хочу ей воспользоваться и дарю 5 моим подписчикам ноутбуки. Розыгрыш делаю через функцию в телеграмме, платформа сама выберет 5 победителей. Принять участие можно здесь - https://t.me/sakutin_csharp/2282
Если вам интересно позже сделаю вторую часть где расскажу как попал на работу в США, потом собрал свою команду и открыл свою студию разработки игр.
Сейчас отличное время, чтобы делать видеоигры. Нет, серьезно. Представить миру собственную игру — по умолчанию круто. А в наши дни это еще и доступно, ведь есть удобные инструменты, курсы и опыт разработчиков, которым они делятся в сети.
Тем не менее довести проект до релиза — большое дело, и проделать этот путь в команде намного проще. Рассказываем об оптимальном составе маленькой инди-студии.
Почему нужна команда
Игру можно сделать и в одиночку. Таких примеров в индустрии масса: от легенд вроде Minecraft и Papers, Please до лавины пиксельных квестов и бумер-шутеров, которые заполонили Steam.
По тегу «инди» в Steam нашлось свыше 90 тысяч игр — это более чем половина всего каталога!
Работа в команде позволяет удобно распределить задачи и объединить разнообразные навыки и подходы в едином творческом порыве. Ну и, конечно, не так просто сорваться и забросить проект, когда есть еще несколько заряженных людей — они создают мотивирующий фон, чтобы двигаться дальше.
С командой больше шансов довести проект до релиза, особенно если у вас нет опыта в игровой индустрии. А релиз — это важный момент, который обеспечит ценным опытом и кейсом в портфолио.
Можно сделать десяток игр в стол. Но какими бы концептуально крутыми они ни были, один-единственный выпущенный на рынок проект будет бесконечно ценнее.
Главные роли в команде
Раз команда небольшая, то каждый участник будет брать на себя разные обязанности. Но есть несколько направлений, которые лучше разделить между отдельными специалистами.
1. Гейм-дизайнер
Без него ни о каком цельном видении проекта не может быть и речи. Предлагать идеи и решения могут все члены команды, но в итоге именно гейм-дизайнер складывает из всех элементов концепцию, механики игры и не дает случайно «сломать» их в потоке безудержного креатива.
Инди-RPG Undertale — пример того, как оригинальная концепция Тоби Фокса даже в простейшем пиксельном исполнении перевернула представления о жанре
Есть много операционных задач, которыми не займутся другие специалисты. Например, продумать все игровые циклы, рассчитать баланс, написать документацию — все это в компетенции гейм-дизайнера.
2. Арт-директор
Это человек, который отвечает за визуальное оформление — определяет, как игра будет выглядеть на релизе и взаимодействовать с геймером. Арт-директор может стать художник, иллюстратор, дизайнеры разных направлений.
Например, чтобы создавать и редактировать визуальные ассеты (модели, текстуры, эффекты, элементы интерфейса) нужны навыки, связанные с графическим дизайном.
1/3
Головоломка FEZ потеряла бы огромную часть своего очарования без яркого визуального стиля и милых персонажей — и да, эту игру сделала команда всего из двух человек
3. Разработчик
Без него идеи гейм-дизайнера и визуальные ассеты арт-директора так и останутся на бумаге. Разработчик должен обратить их в код и собрать на основе всего этого рабочую игру. Эта роль часто самая технически сложная и требует тесного взаимодействия с гейм-дизайнером.
Трио «гейм-дизайнер, графический дизайнер и программист» — база, которая нужна любой игре. Повторимся: это не минимальный, а оптимальный состав инди-команды, чтобы довести проект до релиза.
Конечно, в геймдеве еще полно должностей: например, кто-то может заняться сценарием, звукорежиссурой, маркетингом, тестированием. Если нет возможности нанять таких специалистов, придется делить обязанности по-братски: за одни задачи возьмется тот, у кого больше времени и энтузиазма, за другие — у кого есть подходящие навыки.
Звучит неорганизованно? Да, в команде из трех человек всегда есть место авралу и хаосу — они соседствуют с фаном, удовольствием от достигнутого результата и исполнением своей давней мечты. Идите к ней вместе с Яндекс Практикумом: проходите бесплатные курсы, определяйтесь с IT-профессией и осваивайте навыки, которые помогут разрабатывать игры.
Какие навыки нужны
У каждой роли есть обязательный набор навыков и специальный, который зависит от проекта: в каком жанре игра, как она будет выглядеть, на каком движке собрана и так далее.
Для роли гейм-дизайнера
Нужно научиться работать с системой контроля версий. Это важно, потому что гейм-дизайнер участвует в прототипировании игровых механик, тестирует актуальные билды — работает в связке с разработчиком, который точно использует систему контроля версий. Самая популярная называется Git. Кстати, в Яндекс Практикуме есть бесплатный курс «Основы работы с Git» — добавляйте в закладки.
Основы программирования (тоже доступно бесплатно в Яндекс Практикуме) — еще один навык, который объединяет разработчика и крутого гейм-дизайнера.
В зависимости от проекта может пригодиться высшая математика с теорией вероятностей. Например, для экономических и 4X-стратегий или для больших многослойных RPG. Обновить знания поможет бесплатный тренажер «Основы математики для цифровых профессий». Теория там тоже есть.
Для роли арт-директора
Обязательный навык — UX/UI-дизайн. Пользовательский опыт от взаимодействия с игрой и ее интерфейсом сильно влияет на общее впечатление от проекта.
В курсе «Дизайнер интерфейсов» как раз обучают продумывать пользовательские сценарии и делать интерфейс интуитивно понятным, что важно для любой игры.
Кроме этого, арт-директор обязан разбираться в цвете, композиции и типографике, а также работать с векторной графикой в актуальных редакторах. Всему перечисленному (и даже больше) учат на курсе «Графический дизайнер».
Программист, каким бы языком он ни владел, пользуется системой контроля версий, знает основы программирования и хотя бы немного — алгоритмы.
Дальше главная развилка: движок. Скорее всего, ваша команда восходящих инди-звезд выберет для своей первой игры один из этих движков (потому что они удобные, доступные и по ним больше всего гайдов на YouTube):
Unity;
Godot;
Unreal Engine.
Если вы остановились на Unity или Godot, то ваш разработчик наверняка знаком с языком C#. А если вы замахнулись на Unreal Engine, значит, в вашей команде есть обладатель сакральных знаний С++.
Начинающие команды редко настолько фундаментально подходят к созданию игры, чтобы можно было осознанно выбрать движок на стадии предпроизводства. Обычно проект собирают на том, с чем умеет работать программист.
Ну что, готовы войти в геймдев? Выберите свою роль в команде будущей игры и начните учиться бесплатно. Вас ждет теория, практические задания, хакатоны и тренажеры — все, чтобы получить ценные знания и успешно завершить свой проект в команде или самостоятельно.
Кто знает, возможно, именно ваша игра когда-нибудь получит престижную премию, принесет вам успех, славу и признание в индустрии.
Взять с собой побольше вкусняшек, запасное колесо и знак аварийной остановки. А что сделать еще — посмотрите в нашем чек-листе. Бонусом — маршруты для отдыха, которые можно проехать даже в плохую погоду.
Меня мало кто помнит но старички надеюсь пустят ностальгическую слезу. 8 лет назад здесь я кинул абсолютно безумный клич: "Буду обучать бесплатно любого желающего программированию". Я думал соберу человек 10 и в качестве хобби помогу людям. :))
Шут там, собралось почти 2000 человек и я провёл месяц без сна так, как проверял всем домашки и постоянно вёл лекции. И самое весёлое что это правда было просто хобби и я не взял ни рубля с людей а также не продавал никаких курсов. Странно это слышать в эру прогревов и теневых продаж, не правда ли?
Через 2 года после этих занятий я сел писать книгу по программированию на языке C# и благодаря участникам тех занятий мы собрали 85 000 рублей на написание на краудфандинге. Спустя 6 лет с того момента я закончил.
Книга научит вас языку программирования C# с самых основ через практику. Мы начнём с вами с переменных и закончим инкапсуляций техник динамического программирования в объектно-ориентированном дизайне (чтобы это не значило).
Всё же решился я на некий DevLog, буду пробовать здесь, а дальше скорее всего перетеку на более предназначенную для этого площадку. Скорее всего boosty или публикация из notion, где мне гораздо удобнее.
Кто я?
Я относительно молодой человек 26 лет, окончивший обучение по направлению Информационные системы и технологии на степень магистра. На данный момент работаю инженером-программистом в одной из государственных организаций. Являюсь инициатором данного проекта и по сути являюсь его продюсером, а также его представителем.
Не стану описывать свой путь, который меня привёл к данной инициативе, т.к. это тема не для девлога. Но обозначу, что я посвятил большую часть своей жизни игровому опыту в различных видеоиграх, увлекаюсь геймдизайном на любительском уровне уже около 4 лет, и решил посвятить свою жизнь созданию видеоигр. Данный девлог является результатом 8 лет работы над собой, чтобы иметь минимальный набор знаний и навыков, которые необходимы для моей уверенности в своих силах, а также понимания как правильно идти к своей цели.
У меня есть некая серия постов обо мне, где я "изливал душу" о каких-либо перенесённых личностных трудностях, поэтому если кто то хочет познакомиться с моей негативной стороной то пожалуйста.
Что является вдохновением для создания проекта?
Потенциал огромных игровых возможностей
Я бы мог тут уйти в философский вопрос - "а что такое игра?", но не стану. Ибо каждый человек в них видит свою причину эскапизма. Кому то надо просто расслабиться, а кому то реализовать свои "тёмные" стремления, в месте, где его действия не понесут последствий в реальном мире. Каждая из них достойна того, чтобы была игра, которая бы удовлетворяла их потребности.
У меня есть мои "потребности", которые не смогла удовлетворить ещё ни одна игра - это "потребности" в огромном наборе игровых возможностей. Я являюсь любителем игр, относящихся к условному жанру Соулслайк, которые показали как можно сделать достаточно нарративную сложную в освоении игру, которая понравиться огромному количеству людей.
Но мне данного поджанра не хватило, и тогда я наткнулся на серию игр Nioh, в которой идей боевой системы возвели на небывалые вершины. Всё это может не заметить обычный игрок, потому что сама игра хоть и даёт тебе очень мощный инструмент, но не старается тебя ему научить должным образом, постепенно скатываясь в гринд уровней и экипировки. Но ведь это выбор игрока, улучшать свои навыки согласно предоставленному инструменту или пойти "наращивать циферки", а это тоже надо уважать.
Идеальной системы не бывает, но к ней надо стремиться.
Всё это стало причиной тому, что в моей голове засела "идея" реализации игры, в которой сам бы игрок имел очень большой выбор своего стиля игры, и чтобы каждый из них имел действительно смысл.
Потенциал ИИ в играх
Ещё на старте развития ИИ, ещё в начале пандемии я уже был заинтересован в нейросетях. Даже мой диплом бакалавра к ним имел косвенное отношение - Программный модуль на нечёткой логике. Ещё тогда я задумал использовать это для непредсказуемого ИИ для НИПов в играх. Что по сути и послужило началу разработки данного концепта.
Представьте, что если бы моб в очередной игре, вместо того чтобы в очередной раз получить от вас один и тот же удар, резко бы увернулся после второго или третьего раза? Что если бы очередной отряд противника, вместо того чтобы стоять как истуканы, начали формировать динамически изменяемый боевой строй с правильным позиционированием? Все эти вопросы не дают мне покоя. Сама идея "живого" противника, у которого появляется возможность "думать" в процессе боя, обучаться на игроке, уже достойна того, чтобы сделать игру основываясь только на ней.
Состояние игровой индустрии
В моём понимании, игровая индустрия в определённый момент, свернула куда то "не туда". Чётко выделить этот момент у меня не получиться, но могу лишь сказать, что стоимость реализации идеи раздулась как мыльный пузырь, а игры теперь оценивают по каким то косвенным характеристикам, типа качество графики или задействованный актёрский состав. Здесь то я подниму тот самый вопрос, а что такое Игра? Что её отличает от других сфер искусства? Какой аспект в играх является ключевым? Я его нашёл для себя - геймплей. Мои слова подтверждает текущее состояние инди-рынка, там огромное количество дешёвых в производстве проектов заслуживают признание, просто потому что у них хорошая геймплейная основа. Поэтому в процессе разработки я буду следовать принципам минимальных затрат, избавляясь от излишнего, но не забывая о нарративе, чтобы не выбивать из окружения.
В процессе всей разработки я буду формулировать основные решения, которые необходимы для максимальной экономии ресурсов, чтобы предоставить систему из данных решений всем.
Идея
Сразу обозначу, это лишь сама идея, а не фактическая запланированная реализация проекта. То что будет далее, это то что послужило основой вдохновения на саму разработку.
Action/RPG в сеттинге Sovietpunk с широкими возможностями кастомизации стиля игры, против обучающихся противников.
Данная формулировка мне стоила почти полгода, чтобы я наконец смог это выразить в одно простое предложение.
Также были сформулированы основные игровые особенности, так называемые киллерфичи:
Система механик манипуляций с ходом игрового времени как в процессе боя, так и в ходе решений игроком различных ситуаций.
Обучающийся ИИ для поведения НИПов.
Сюжетный и роуглайт режимы.
Продвинутая боевая система, основанная на системе из Nioh 2.
Опять же напомню, что мы этапе завершения препродакшена и данные особенности могут измениться.
Наш подход
Мы решили разделить работу над игрой на два основных направления:
Исследовательское, который заключается в изучении существующих технологий или создании своих решений. В данное направление я отнесу также свою работу над геймдизайном и игровой теорией в целом.
Производственное, которое предназначено конкретно для разработки данного проекта, т.е. непосредственная реализация.
Про исследовательское направление я напишу в другой раз, потому что оно больше относится к игровой индустрии в целом, чем к конкретному проекту, хотя систему экспериментов я буду ставить именно вначале на данном проекте.
Производственное же направление будет заключаться в планировании и непосредственной разработке.
В качестве основной методологии разработки была выбрана спиральная модель. Сильно в подробности уходить не будем, но объясню главный смысл: составляется техническое задание на первый минимальный прототип игры, реализуется (попутно фиксируется опыт), затем проходит тестирование, в котором происходит анализ, из этого анализа формируется техническое задание для следующей итерации и повторить. И так до тех пор пока не надоест не придёт к чему то полноценному, что можно считать хотя бы бэта-версией игры. Это к тому, что от обычного линейного планирования мы не отказываемся.
Картинка из интернета
По достижению состояния бэта-версии мы будем действовать по ситуации. На неё будут влиять как наше личное время, как и возможное финансирование. Поэтому дальнейшая детализация не имеет смысла.
Команда состоит на данный момент из шести человек: я, программист, два 3D-моделлера, 2 художника. Мы почти все являемся новичками в индустрии, поэтому напомню, многим вещам будем учиться буквально на ходу. Для этого у нас и есть исследовательское направление.
В данный момент художники занимаются созданием основного дизайн-проекта для игры, а именно формированием основного визуального дизайна игры, что является следствием отсутствия артов в посте. Потом они будут.
Мы с программистом составляем "адекватное" ТЗ на первые итерации, когда моделлеры уже во всю корпят:
Меч из к-ф Грань будущего
Набросок платформы боевого дрона
Прототип боевого дрона
Набросок экзоскелета
Боевой шагающий дрон
Эти скриншоты служат демонстрацией процесса работы.
Эпилог
Данный пост является первым в серии, а также первой попыткой в девлог. Как говориться, все тапки ловлю. Публикация в сообществе Лига Разработчиков Видеоигр считаю спорной из-за одно правила:
Правило Лиги Разработчиков Видеоигр
Но пожалуй рискну. Просто не могу сказать что данный пост является полноценным девлогом, но вроде и прямой рекламы с интеграцией здесь нет.
Всем привет! Года 2 назад я хотел стать художником и рисовать арты для игр. Начал делать свою настолку для портфолио и так мне понравилось придумывать правила, что я совсем забил на рисунки и пошел узнавать про геймдизайн, как там и что творится. Оказалось, без опыта в разработе игр в геймдизанеры не попасть, что приводит к выводу - надо делать игры. Я уже знал про sКАЛбокс, но ничего не слышал о качестве курсов. Скачал и не понял совершенно ничего. Пошел смотреть Дударя (он объясняет понятнее чем ребята из коробки!) и Симплкода, начал разбираться мало мальски, но все-равно не до конца понимал по правильному пути иду или нет, а спросить не у кого! Наткнувшись на видео Романа Сакутина, который критикует код, по которому я тогда учился (!), я подумал - "Жесть, конечно, идейный чел." Скинул своему другу программисту его видос на оценку и получив положительную рецензию купил курс в ЯЮниоре.
И вот, почти закончив курс, я могу сказать, что не зря все это было! На курсе туча задачек по C# и Unity на разные темы, которые проверяют менторы и помогают разобраться с любым затыком который только может быть. Хоть тебя ручку ведут, ты в любом случае набиваешь шишек и становишься опытнее и увереннее. И вот Сейчас у меня уже финальные шаги, две полноценные игры сделаю под присмотром менторов, выложу на Яндекс игры и вперед в геймдев!
Но самое крутое то, что там туча людей с которыми можно обсудить и учебу, и идеи игр, и ошибки и тд и тп! Роман создает комьюнити заинтересованных людей и это очень подстегивает развиваться дальше!
Спасибо ЯЮниору, Роману и моим менторам! И удачи мне)
Если сейчас приехать в пункт приема металлолома, то можно обнаружить просто огромные кучи различных телефонов и прочих электронных «отходов», которые стоят под открытым небом и ждут, когда придёт их черёд окончательного разложения. Однако при ближайшем рассмотрении выясняется, что многие девайсы оказываются полностью рабочими даже после недельного лежания под палящим солнцем и проливными дождями, а сдали их в чермет по причинам «не нужен, надоел, купил новый» и т. п. Я не считаю это правильным, ведь даже в простые кнопочные звонилки имеется возможность вдохнуть новую жизнь, если знать один интересный, но малоизвестный факт: для них можно писать нативные приложения на C и использовать железо телефона в своих целях. А это, на минуточку, как минимум: дисплей с подсветкой, вибромотор, динамик, клавиатура и GSM-радиомодуль с возможностью выхода в сеть. Сегодня мы с вами: узнаем, на каких аппаратных платформах работают китайские телефоны, какие существуют программные платформы и где взять для них SDK, а в практической части мы напишем 2D-игру с нуля, которая будет работать на многих китайских кнопочниках. Интересно? Тогда жду вас под катом!
Содержание:
Не J2ME едины
Аппаратные ресурсы
Кроссплатформенный рантайм
Кроссплатформенный рантайм: Win32
Кроссплатформенный рантайм: MRE
Кроссплатформенный рантайм: VXP
Наконец-то пишем игру
Тестируем на реальных девайсах
Заключение
❯ Не J2ME едины
Думаю, многие мои читатели помнят о такой платформе, как J2ME. Java-приложения стали фактически основной возможностью расширения функционала телефонов в 2000-х годах. API для них был достаточно хорошо стандартизировано, программы не зависели от архитектуры процессора и ОС устройства, а порог вхождения для написания собственных приложений был довольно низкий и даже новички могли за пару дней написать свою игрушку или какое-нибудь GUI-приложение!
Однако не одним J2ME мы были едины: существовало множество платформ, которые так или иначе пытались занять нишу Java на рынке. Некоторые из них я упоминал в своей прошлой статье о написании 3D-игры под Sony Ericsson с нуля: например, была такая платформа на телефонах Sony Ericsson серии T, как Mophun, а CDMA-телефонами с чипсетами Qualcomm использовалась нативная платформа BREW. Пожалуй, я не буду упоминать о .sis и .cab — поскольку это форматы нативных приложений для смартфонов, а не простых «фичефонов».
В какой-то момент, ближе к 2006-2007 году, прилавки российских официальных ритейлеров (по большей части это были телефоны Fly) и неофициальных продавцов на рынках заполонили различные китайские телефоны, которые предлагали какой-то немыслимый функционал для тех лет за копейки, да ещё и визуально напоминали флагманские модели известных брендов. Пожалуй, одним из самых популярных таких телефонов была Nokla TV E71/E72 (да, именно «нокла»), вышедшая примерно в 2008 году и производившаяся аж до 2011 года! За 2-3 тысячи рублей (это менее 100 баксов), пользователь получал здоровый 2.4" дисплей с разрешением 240x320 весьма неплохого качества (когда в те годы многие продолжали ходить с 176x220), да ещё и с тачскрином, гироскоп, огромный громкий динамик (пусть и не очень качественный), поддержку SD-карточек до 32Гб, нередко фронтальную камеру, а также премиальный дизайн с вставками из алюминия. Частенько китайцы заботливо клали в коробку ещё чехольчик и дополнительный аккумулятор :)
Были даже полные копии существующих устройств от Nokia. Особенно китайцы любили подделывать массовые модели на S40: они были очень популярными и китайцы хотели откусить свой кусок рынка у Nokia. Пусть и рынка серого импорта — очевидно, в салонах связи подделки никто не продавал:
Но была и ложка дёгтя в этой бочке меда: китайские телефоны очень часто не имели поддержки Java, из-за чего многие пользователи разочаровывались в них из-за отсутствия возможности установить необходимые им приложения. Никакой тебе оперы, аськи, игр… Скорее всего, это связано с необходимостью отчислений Sun, а также разработчикам реализации J2ME-машины (JBed/JBlend) и установки чипа флэш-памяти чуть большего объёма.
Но многие пользователи не знали, что такие девайсы не просто поддерживали сторонние приложения, но и умели выполнять настоящие нативные программы, написанные на полноценном C! Всему помешала китайская костыльность и тотальная закрытость. Платформа предполагалась для работы на внутреннем рынке. Для вызова менеджера нативных приложений необходимо было вводить специальный инженерный код в номеронабирателе, предварительно скопировав приложение в нужную папку, а SDK долгое время было платным и доступно только для компаний из Китая. Кроме того, далеко не все приложения могли запустить на конкретном девайсе — были серьезные проблемы с совместимостью.
Всё как вы любите: HiTech-девайсы на фоне ковра, который старше автора лет на 30 :)
В ранних китайских телефонах использовалась платформа Mythroad (MRP, MiniJ) от китайской компании SkyWorks, которая лицензировала свою технологию производителям чипсетов. Поддержку MRP можно было встретить на телефонах с чипсетами MediaTek, Spreadtrum, а также MStar (и возможно Coolsand). Mythroad предоставлял некоторое API для работы с железом телефона и разработки как UI-приложений, так и игр, кроме того, Mythroad позволял хранить ресурсы в одном бинарнике с основной программой и даже имел какой-то интерпретируемый язык помимо возможности запуска нативного кода. Для работы таких приложений необходимо было скопировать менеджер приложений dsm_gm.mrp и игру в папку mythroad во внутренней памяти устройства или на флэшке, а затем набрать в номеронабирателе код *#220807#, иногда при отключенной первой SIM-карте. Костыльно? Костыльно! Откуда об этом знать среднестатистическому пользователю? Не откуда! Но работало!
Эта платформа поддерживалась на большинстве подделок под брендовые устройства Nokia, Sony Ericsson и Samsung, а также iPhone и на многих китайских кнопочных телефонах 2008-2010 годов.
Ближе к 2010 году MediaTek разработала свою собственную платформу, которая должна была заменить MRP — WRE (VXP). Эта платформа была гораздо шире с точки зрения функционала (например, был доступ к UART) и её API был вполне удобно читаем для программиста, а SDK свободно доступен для всех. Один нюанс всё портил — приложения без подписи привязывались к IMSI (даже не IMEI) симки в девайсе и на некоторых девайсах требовали переподписания под каждую конкретную SIM или патчинг дампа оригинальной прошивки телефона на отключение проверки подписи. Эта платформа поддерживалась на многих кнопочниках и смарт-часиках 2010-2020 годов: к ним относятся новодельные телефоны Nokia, телефоны DNS и DEXP, Explay и т. п. Для запуска приложений достаточно было выбрать файл с разрешением VXP в проводнике и просто запустить его. Но с совместимостью всё равно имелись проблемы: если запустить VXP для версии 2.0 и выше, мы получим лишь белый экран. Ну хоть не софтресет, и на том спасибо!
Далеко не все такие часы поддерживают MRE, смотреть нужно от устройства к устройству
❯ Аппаратные ресурсы
Большинство китайских кнопочных телефонов работает на базе одних и тех же чипсетов. В конце нулевых чаще всего использовались чипсеты MT6225, SC6520 и некоторые чипы от Coolsand. Средние хар-ки девайса были следующими:
Процессор: ARMv5 ядро на частоте ~104МГц, ARM926EJ-S. Нет FPU, есть Thumb. Большую часть процессорного времени программа могла забрать себе.
ОЗУ: ~4Мб SDRAM. Программам было доступно 512Кб-1Мб Heap'а. Это, в целом, довольно немало для большинства применений.
Флэш-память: ~32Мб, пользователю доступно пару сотен килобайт. Да, вы не ослышались, килобайт! Однако можно без проблем использовать MicroSD-флэшки до 32Гб.
Дисплей: от 128x128 до 320x480, почти всегда есть 18-битный цвет (262.000 цветов), в случае TV E71/E72 используется очень неплохая TN-матрица с хорошими углами обзора и яркой подсветкой. Иногда есть тачскрин.
Звук: громкий динамик, наушники.
Аккумулятор: ~800мАч, на некоторых девайсах может быть и 2.000мАч, а то и больше!
Ввод: клавиатура, иногда была поддержка QWERTY.
Внешние шины: почти всегда был доступен UART, причём его можно было свободно взять прямо с платы — он был явно подмечен! Взять GPIO с проца не выйдет (кроме, возможно, вибромотора), SPI и I2C также напрямую недоступны. Внешние шины можно реализовать с помощью UART через GPIO-мост из микроконтроллера.
В итоге мы получаем очень неплохие характеристики для устройства, которое сочетает в себе сразу всё. На базе такого девайса можно сделать и сигнализацию, и HMI-дисплей с интерфейсом для управления каким-нибудь устройством, и игровую консоль с эмуляторами… да на что фантазии хватает! И это за какие-то 200-300 рублей, если мы говорим о б/у устройстве или 600 рублей, если говорим о новом. Это дешевле, чем собирать девайс с подобным функционалом самому из готового МК (например, RP2040) и отдельных модулей. Кстати, дешевые 2.4" дисплеи на алике — это ни что иное, как невостребованные остатки дисплеев для подобных китайских телефонов на складах! А вы думали, откуда там значки на тачскрине снизу?
Однако в рамках данной статьи мы не будем ограничиваться лишь теорией и на практике напишем примитивную 2D-игрушку, которая будет работать сразу на трех платформах без каких-либо изменений в коде самой игры: Windows, MRP (Mythroad) и VXP. Но для того, чтобы достигнуть такого уровня абстракции от платформы, нам необходимо написать рантайм, который оборачивает все необходимые платформозависимые функции для нашей игры.
Игрушка будет простой: 2D скролл-шутер с видом сверху, а-ля Asteroids. Летаем по космосу, и стреляем по враждебным корабликам, стараясь не попасть под вражеские лазеры. Всё просто и понятно :)
❯ Практическая часть: Кроссплатформенный рантайм
Итак, что нам необходимо от абстракции для такой простой игры? Давайте посмотрим:
Графика: очистка экрана, отрисовка спрайтов с прозрачностью (без альфа-блендинга, только колоркей), отрисовка текста. При возможности, желательно использовать нативное API системы для рисования графики, а не городить собственный блиттер. Формат пикселя фиксирован: RGB565 (65к цветов).
Ресурсы: хранятся в одном образе с основной игрой. Фактически, все ресурсы упакованы в виде обычных массивов байт в заголовочных файлах. Я пользуюсь вот этой тулзой для конвертации спрайтов в массивы байтов.
Звук: воспроизведение хотя-бы одного WAV-потока. Почему одного? Потому что далеко не на всех платформах есть доступ к аппаратному микшеру… да и вообще не везде есть прямой доступ к PCM (привет MRP), иногда разработчики ограничиваются лишь одним каналом для WAV-звука без возможности воспроизведения нескольких аудиофайлов одновременно.
Ввод: абстракция от клавиатуры классического моноблока: стрелки, OK, левый и правые софткеи.
Стандартная библиотека: не на всех платформах можно вызывать функции напрямую из stdlib. Как минимум в MRP и, например, «эльфах» для Motorola, нет возможности вызывать аллокатор, rand и некоторые другие функции из обычных заголовочников стандартной библиотеки. На таких платформах, системные инклуды дефайнами подменяют стандартные функции на своих реализации:
#define malloc system_alloc
#define free system_free
Но если у нас игра кроссплатформенная, то и платформозависимые инклуды мы использовать не будем.
Выглядит всё достаточно просто, верно? Примерно такого набора функций хватит для нашей игры:
❯ Win32
Давайте же перейдем к реализации рантайма на каждой платформе по отдельности. Начнём с Win32, поскольку адекватно отлаживать игру можно только на ПК.
На десктопе у нас будет фиксированное окно 240x320, в качестве GAPI будет использоваться аппаратно-ускоренный OpenGL, а для обработки ввода будет использоваться классически GetAsyncKeyState. Реализация точки входа, создания окна и инициализации контекста GL и главного цикла приложения у нас такая:
Реализация отрисовки спрайтов очень примитивная — OGL 1.0, полностью FFP, вся отрисовка — это 2 треугольника, формирующие квад. Спрайт заливается при первом использовании в текстуру, последующие кадры реюзается уже готовая текстура. Фактическая реализация всего рендерера — т. е. функций для рисования «просто картинок», без поддержки атласов, блендинга цветов (З.Ы - длинные листинги будут на пастбине, на Пикабу нет нормального тега для кода):
С вводом тоже всё просто. Есть биндинг кнопок клавиатуры к кнопкам на кейпаде телефона. inGetKeyState предполагается вызывать один раз за кадр, поэтому функция опрашивает ОС о состоянии нажатых кнопок на клавиатуре и назначает состояние виртуальных кнопок относительно состояния физических кнопок на клавиатуре.
Результат:
❯ MiniJ
Переходим к реализации рантайма для первой китайской платформы — MRP. Обратите внимание — я использую нативное API платформы для рисования спрайтов. Связано это с тем, что софтварный блиттер работает невероятно медленно даже с прямым доступом к скринбуферу устройства, а в чипсете предусмотрена отдельная графическая подсистема с командбуфером для быстрой отрисовки примитивов и графики:
SDK для MRE можно найти здесь (SKYSDK.zip): оно уже пропатчено от необходимости покупки лицензии. MRP не развивается более 10 лет, поэтому, думаю, его можно считать Abandonware. Компилятор находится в compiler/mrpbuilder.NET1.exe. За китайские SDK в публичном доступе нужно поблагодарить пользователя 4pda AjlekcaHgp MejlbHukoB, который раздобыл их на всяких csdn и выложил в свободный доступ :)
У MRP собственная система сборки, основанная на конфигурациях. Поскольку MRP может работать на устройствах с разными платформами и размерами дисплеев, под каждую можно настроить свой конфиг, который пережмет ресурсы в нужный формат. Дабы ничего не ломать, я заюзал абсолютные пути:
Компиляция приложения:
mrpbuilder.net1.exe game.mpr
Начинаем с функций обработки событий и инициализации, которые вызывает рантайм при старте приложения: mrc_init вызывается при старте приложения, а mrc_event при возникновении события. Вся инициализация очень простая: создаём таймер для обновления и перерисовки состояния игры и вызываем инициализацию игры:
С вводом тоже никаких проблем нет, нажатия кнопок прилетают как события в mrc_event. Переводим кейкоды MRE в наши кейкоды и сохраняем их состояние:
Опять же, отлаживать MRP-приложение под реальным устройством проблематично, поэтому платформозависимый код должен быть минимальным. Кроме того, обратите внимание, что некоторые функции в MRP зависят от библиотек-плагинов. Линкер слинкует вашу программу, но на реальном устройстве их вызов вывалится в SIGSEGV и софтресет устройства. Также нельзя использовать ничего из стандартной библиотеки именно в стандартных заголовочниках (т. е. stdlib.h, string.h и т. д.), часть стандартной библиотеки реализовывается MRP и дефайнится в mrc_base.h
Что интересно, защиты памяти толком нет. Если приложение падает в SIGSEGV или портит память — систему, судя по всему, ребутит Watchdog. Защиты памяти никакой, можно напрямую читать и писать в память ядра, а также писать в регистры периферии чипсета. jpegqs, покумекаем над этим? :)
Переходим к рендереру. Тут буквально две функции, gClearScreen очищает экран, а gDrawBitmap рисует произвольный спрайт с форматом пикселя RGB565. В качестве ROP используется BM_TRANSPARENT — таким образом, mrc_bitmapShowEx будет использовать левый верхний пиксель в качестве референсного цвета для реализации прозрачности без альфа-блендинга.
voidgDrawBitmap(CBitmap* bmp, int x, int y) {
mrc_bitmapShowEx((uint16*)bmp->pixels, x, y, bmp->width, bmp->width, bmp->height, BM_TRANSPARENT, 0, 0);
}
Да, всё вот так просто. Рантайм теперь запускается на реальных китайских девайсах и работает стабильно.
❯ VXP
Теперь переходим к VXP — платформе не менее неоднозначной, чем MRP. Пожалуй, начать стоит с того, что VXP существует аж в трёх версиях: MRE 1.0, MRE 2.0 и MRE 3.0. В MRE 2.0 и выше появилась поддержка плюсов (в MRE 1.0 только Plain C) и довольно интересного GUI-фреймворка, MRE 1.0 же предлагает реализовывать гуй самому. Платформа распространена на большинстве кнопочных телефонов и смарт-часиков на чипсетах MediaTek, примерно начиная с 6235 и заканчивания 6261D. SDK можно скачать вот здесь (см MRE_SDK_3.0).
VXP сам по себе более функционален чем MRE, поскольку ориентирован исключительно на телефоны с чипсетами MediaTek. Но что самое приятное — есть доступ к уарту без каких либо костылей! То есть, если сделать GPIO-мост на условной ESP32, то мы можем получить готовый мощный МК с клавиатурой, кнопками, дисплеем, звуком и т. д. Звучит не хило, да? Кроме того, у нас есть доступ и к BT, и к GPRS, и к SMS без каких либо ограничений.
Однако в бочке мёда нашлась и ложка дёгтя: для компиляции MRE-приложений необходимо накатывать и крякать довольно старый компилятор ADS, который сам по себе поддерживает только C89 (например, нет возможности объявить переменную в объявлении цикла или середине функции, только в начале, как в Pascal). ADS уже вроде как Abandonware, так что это вроде не наказуемо… но всё равно неприятно.
Кроме того, на некоторых девайсах (в основном, фирменных Nokia а-ля 225), прошивка требует подписи у всех бинарников, либо если бинарник отладочный, то должна быть привязка к конкретному IMSI.
К тому же, каждая программа должна фиксированно указывать в заголовке, сколько Heap-памяти ей необходимо выделить. Оптимальный вариант — ~500Кб, тогда приложение запустится вообще на всех MRE-телефонах.
Зато у VXP есть адекватный симулятор под Windows. Но зачем он нам, если у нас порт игры под Win32 есть? :)
Начинаем с инициализации приложения. В процессе вызова точки входа, приложение должно назначить обработчики системных событий, коих бывает несколько. Для обработки ввода и базовых событий хватает всего три: sysevt (события окна), keyboard (физическая клавиатура. Есть полная поддержка QWERTY-клавиатур), pen (тачскрин).
Переходим к обработчику системных событий. Обратите внимание, что MRE-приложения могут работать в фоне, из-за чего необходимо ответственно подходить к созданию и освобождению объектов. Что важно усвоить с самого начала — в MRE нет понятия процессов и защиты памяти, как на ПК и полноценных смартфонах. Любая программа может попортить память или стек ОС, более того, программа использует аллокатор остальной системы, поэтому если ваша программа не «убирает» после себя, данные останутся в памяти со временем приведут к зависанию. Впрочем, WatchDog делает свою работу быстро и приводит телефон в чувство (софтресетом) за 1-2 секунды. Но как и в случае с MRE, есть приятный бонус: прямой доступ к регистрам чипсета :)
Переходим к обработке событий с кнопок. Тут всё абсолютно также, как и на MRE, лишь имена дейфанов поменялись :)
И наконец-то, к графике! Пожалуй, стоит сразу отметить, что более 20-30 FPS на большинстве устройств вы не получите даже с прямым доступом к фреймбуферу. Похоже, это связано с тем, что в MRE довольно замороченная графическая подсистема с поддержкой альфа-канала (только фиксированного во время вызова функции отрисовки картинки/примитивов, сам пиксельформат всегда RGB565) и нескольких слоев. Кроме того, похоже есть ограничения со стороны контроллера дисплея.
Изначально, MRE предполагает то, что все картинки в программе хранятся в формате… GIF. Да, весьма необычный выбор. Однако для работы с пользовательской графикой, есть возможность блиттить произвольные картинки напрямую из RAM. Вот только один нюанс — посмотрите внимательно не объявление следующей функции:
dst_disp_buf — это целевой RGB565-буфер. Логично предположить, что и src_disp_buf — тоже обычный RGB565-буфер! Но как бы не так. Документация крайне скудная, пришлось посидеть и покумекать, откуда в обычном 565 буфере возьмется индекс кадра. С подсказкой пришёл пользователь 4pda Ximik_Boda — он скинул структуру-заголовок, которая идёт перед началом каждого кадра. В документации об этом не сказано ровным счетом ничего!
Сначала я реализовал софтовый блиттинг, но он безбожно лагал. Мне стало интересно, почему нативный blt быстрее и… вопросы отпали после того, как я поглядел в ДШ чипсета: тут есть аппаратный блиттинг. И даже с ним девайс не может выдать более 20FPS!
Для реализации более-менее шустрого вывода графики, необходимо сначала создать канвас (фактически, Bitmap в MRE), создать и привязать к нему layer, получить указатель на буфер слоя и только потом скопировать туда нашу картинку. Да, вот так вот замороченно:
И только после этого всё заработало достаточно шустро :) В остальном же платформа довольно неплохая. Да, без болячек не обошлось, но всё же перспективы вполне себе есть.
На данный момент, этого достаточно для нашей игры.
❯ Пишем геймплей
Рантайм у нас есть, а значит, можно начинать писать игрушку. Хоть пишем мы на Plain-C, я всё равно из проекта в проект использую +- одну и ту же архитектуру относительно системы сущностей, стейтов и т. п. Поэтому центральным объектом у нас станет CWorld, который хранит в себе на пулы с указателями на другие объектами в сцене, а также игрока и его состояние:
Система стейтов простая и понятная — фактически, между состояниями передавать ничего не нужно. При нажатии в главном меню на «старт», нам просто необходимо проинициализировать мир заново и начать геймплей, при смерти игрока — закинуть его обратно в состояние меню. Стейты представляют из себя три указателя на функции: переход (инициализация), обновление и отрисовка.
typedefvoid(CGameStateCallback)();
Поскольку мы хотим некоторой гибкости при создании новых классов противников, то вводим структуру CEnemyClass, которая описывает визуальную составляющую врагов и их флаги — могут ли они стрелять по игроку или просто летят вниз (астероиды), как они передвигаются (зигзагами например) и т. п.
Всё! Для текущего уровня реализации игры этого достаточно :) Переходим к реализации игровой логики. Вообще, динамический аллокатор в играх для китайских платформ лучше использовать как можно меньше. Heap'а довольно мало (~600Кб), да и не совсем понятно, как этот аллокатор реализован, есть вероятность, что используется аллокатор и куча основной ОС.
Начинаем с реализации полёта кораблика. Для этого он должен реагировать на стрелки и не улетать за границы экрана, а ещё для красоты он должен «вылетать» из нижней границы экрана при старте игры:
Переходим к динамическим пулам с объектами. Как вы уже заметили, их всего два — враги и летящие снаряды. Реализация спавна врагов/снарядов простая и понятная: мы обходим каждый элемент пула, если указатель на объект не-нулевой, значит объект всё ещё жив и используется на сцене. Если нулевой — значит ячейка свободна и можно заспавнить новый объект:
При обходе пула во время обновления кадра, мы обновляем состояние каждого объекта и если его функция Think вернула true, значит объект больше не нужен и его нужно удалить:
if (enemyThink(world.enemyPool[i]))
{
sysFree(world.enemyPool[i]);
world.enemyPool[i] = 0;
}
А вот и реализация Think:
boolenemyThink(CEnemy* enemy) {
enemy->y += enemy->_class->speed;
if (enemy->y > gGetScreenHeight() || enemy->health <= 0) return true;
return false;
}
Но кораблики должны же откуда-то появляться! Для этого у нас есть переменная nextSpawn, которая позволяет реализовать самый простой тип спавнера — относительно времени (или в нашем случае тиков):
world.nextSpawn--;
if (world.nextSpawn < 0) {
CEnemy* enemy = spawnEnemy(&enemyClasses[0]);
world.nextSpawn = randRange(40, 70);
}
Результат: мы уже можем полетать, пострелять и поуворачиваться от вражеских корабликов!
Уже что-то напоминающее игру! Осталось лишь добавить подсчет очков, менюшку, разные виды противников, возможно какие-то бонусы и у нас будет готовая простенькая аркада. В целом, выше приведена достаточно неплохая архитектура для простых 2D-игр на Plain C. Фактически, она может быть хорошей базой и для ваших игр: в теме о китах на 4pda я встречал немало людей, которые банально не знали, с чего начать.
❯ Что у нас получилось?
Но без тестов на реальных устройствах материал не был бы таким интересным! Поэтому давайте протестируем игру на двух реальных телефонах, как вы уже догадались, один — Nokla TV E71, а второй — клон Nokia 6700, который подарил мне мой читатель Никита.
На TV E71 игра идёт не сказать что очень бодро. Кадров 15 точно есть, что, учитывая разрешение 240x320, весьма неплохо для такого девайса.
а 6700,, даже учитывая более низкое разрешение — 176x220, дела примерно также — ~15FPS! Но поиграть всё равно можно. Уже хотите написать «автор наговнокодил, а теперь ноет из-за низкого FPS»? Ан-нет, я попробовал игры сторонних разработчиков — они идут примерно также :( К сожалению, таковы аппаратные ограничения устройства.
Исходный код игры с Makefile'ами и файлами проектов для Visual Studio и MRELauncher доступны на моём GitHub. Свободно изучайте и используйте его в любых целях :)
❯ Заключение
Но в остальном же, демка получилась довольно прикольной, как и сам опыт программирования для китайских телефонов. В общем и целом, китайцы пытались максимально упростить API и привлечь разработчиков к своей платформе. Если ради примера взглянуть на API для Elf'ов на Motorola, можно ужаснуться от state-based архитектуры платформы P2K. А тут тебе init, event, draw — и всё!
Но популярности помешала непонятная закрытость платформы, костыльный запуск программ, отсутствие нормального симулятора. А ведь сколько фишек было: даже возможность писать и читать память ядра! А вы как считаете? Можно ли вдохнуть в китайские кнопочники новую жизнь, узнав о наличии возможности запуска нативного кода на них?
P. S.: Друзья! Время от времени я пишу пост о поиске различных китайских девайсов (подделок, реплик, закосов на айфоны, самсунги, сони, HTC и т. п.) для будущих статей. Однако очень часто читатели пишут «где ж ты был месяц назад, мешок таких выбросил!», поэтому я решил в заключение каждой статьи вставлять объявление о поиске девайсов для контента. Есть желание что-то выкинуть или отправить в чермет? Даже нерабочую «невключайку» или полурабочую? А может, у этих девайсов есть шанс на более интересное существование! Смотрите в соответствующем посте, что я делаю с китайскими подделками на айфоны, самсунги, макбуки и айпады! Да и чего уж там говорить: эта статья уже сама по себе весьма наглядный пример! Найти меня можно в комментариях тут, на Пикабу, и в тг @monobogdan
Понравился материал? У меня есть канал в Телеге, куда я публикую бэкстейдж со статей, всякие мысли и советы касательно ремонта и программирования под различные девайсы, а также вовремя публикую ссылки на свои новые статьи. 1-2 поста в день, никакого мусора!
Полезный материал?
Были ли у вас такие китайчики?
Материал подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!