177 описаний дополнительных существ (спутники героев);
85 художественных текстов о разных аспектах жизни во вселенной игры;
25 текстов с описанием логики мира, частично художественных, частично технических;
Pixelart sprite sheets для карты и некоторые иконки.
Лицензия CC BY 4.0 значит, что вы можете почти всё: копировать и распространять, изменять и перерабатывать — даже в коммерческих целях. При условии, что указываете лицензию, оригинальных авторов и внесённые изменения.
Мы с друзьями надеемся, что наши наработки окажутся полезными начинающим разработчикам и авторам.
P.S. За всё время в игру активно играло 39 000 человек, игроки написали больше 1 000 фанфиков, создали огромное количество фанарта, несколько текстовых квестов по миру игры, и оставили больше 270 000 сообщений на форуме. Поэтому, пусть лор и не уровня ААА игр, есть основания предполагать, что он достаточно увлекательный.
На днях выходила статья по собеседованиям на Unity. Вышла уже аж вторая редакция. Первая содержала «контент не для слабонервных». Жаль, что его по итогу вырезали — это был очень полезный опыт из реальной корпоративной практики. Тем не менее, всё полезное для широкого круга читателей осталось. В т. ч. отличные советы, под которыми я ставлю свои «+».
Процессы проведения собеседований — очень индивидуальная штука, и везде всё устроено по-разному. Есть вводные у кандидата, у команды, у проектов, у бюджета и т. д. Между ними приходится как-то балансировать и искать наиболее равновесную точку. Общего рецепта, как это сделать, нет. Только разве что «нормально делай — нормально будет». Поделюсь коротенько тем, как это делаю я.
1️⃣ Я стараюсь проводить собеседования наименее ресурсозатратно и для себя, и для кандидата. Мои целевые показатели — 30 мин на интервью, 30 мин на подготовку (но реальные медианные будут побольше 👺). Подготовка — это осмотр резюме, изучение информации о кандидате и прошлых местах работы в сети, знакомство с проектами и кодом.
2️⃣ Для меня код (если нужен программист) — ключевой и самый говорящий фактор. ТЗ я давать не люблю: стараюсь обходиться петами кандидатов. Но если посмотреть нечего или нет проектов с релевантными технологиями, то выдаю ТЗ на какие-то отдельные конкретные моменты, которые бы мне хотелось прояснить. Или посмотреть, насколько хорошо удастся разобраться с новой технологией.
Правда, если кандидатов много, то всё приходится усреднять и ставить на поток. Иначе основной рабочий процесс будет саботирован. Главное, чтобы на ТЗ уходило минимальное количество времени. В конце концов, и мне же это потом смотреть. Поэтому с каждой новой волной найма я стараюсь оптимизировать коллекцию заданий.
3️⃣ Интервью — самый дорогой этап с точки зрения времени и организации, поэтому он обычно остаётся на самый конец (чтобы оставалась возможность до него не дойти). Но если попадается интересное резюме, то могу сразу и перейти к нему, пропустив или отложив этап «кода».
Я перестал открыто гонять кандидатов по техническим вопросам. Более эффективным нахожу обычное общение про опыт, компетенции, практические кейсы и т. д. И в процессе, если натыкаюсь на что-то значимое и шаткое, начинаю копать глубже.
❗Причём я считаю очень важным давать свои комментарии на темы, в которых кандидат не смог достаточно раскрыться. Пусть он уйдёт, если без оффера, то хотя бы с новыми знаниями.
Из-за специфики разработки мне часто важно, чтобы новые члены команды были заинтересованы в продолжительном сотрудничестве. Поэтому на интервью я стараюсь определить ценности, мотивацию и цели кандидата. Что он понимает, куда и почему собеседуется, а не пытается просто запрыгнуть хоть куда-нибудь на какое-то время. И, со своей стороны, искренне даю все вводные. Для взаимовыгодного и плодотворного сотрудничества нужна обоюдная совместимость 🤝
Разгребая бэклог, добрался до поста канала S0ER с «темами по архитектуре, которые должны входить в архитектурный минимум каждого инженера». Структуризация, возможно, спорная, но это авторское видение, и если «душность» оставить за скобками, то ещё и очень хорошая система тегов для профессионального развития.
✍ По схеме у меня есть ряд пробелов, которые я планирую заполнить. Но с большей частью за свою карьеру я в том или ином виде успел повзаимодействовать.
☝ Пользуясь случаем, напомню, что игры — это тоже ПО. А разработка ПО — инженерная дисциплина. У игр, несомненно, есть своя специфика, но она никак не отменяет всего остального инженерного бэкграунда. Особенно, когда работаешь не только на клиентской части.
🤓 Скорее всего, вся эта «техническая канитель» не нужна людям, которые идут в геймдев ради творчества и самореализации через инди-проекты в инди-командах. Но если ты осознаёшь себя программистом, осознаёшь геймдев своей специализацией, хочешь уметь разрабатывать более сложные продукты, развиваться как профессионал, расширять зону ответственности, приносить больше ценности для своей команды и, как следствие, в какой-то форме для себя, то (-записывайся на курс-) держи бесплатную верхнеуровневую роудмапу для расширения своих компетенций. Корреляция с игровыми проектами произойдёт сама собой по мере получения большего опыта в сфере.
🎥 Можно ещё побродить по YouTube-каналу S0ER'а. Видео не выходили давно, но контента там уже накопилось много. Например, я недавно пересматривал видео по KISS, чтобы освежить в памяти некоторые красноречивые пункты.
Сейчас будет немного спорный контент: так и не смог ёмко и лаконично выразить мысль, а раздувать статью из этого не хочется. Но всё же. Просматривал небольшую обзорную статью про Cell-Based Architecture из своего бэклога. И глаз зацепился об одну занятную мелочь.
Эта мелочь — EventBus. Про него можно посмотреть, например, тут и тут. Что я хотел отметить: обрати внимание на положение EventBus'а на схеме. Сейчас маленько «сову на глобус», но замени клетки на отдельные логические модули из своего игрового проекта — у них, как и у клеток, тоже должен быть высокий Cohesion (и низкий Coupling по GRASP'у). Это могут быть, например, CoreGame и MetaGame или Presentation-слой и Business-слой. И посмотри на положение EventBus'а ещё раз.
EventBus — это один из способов коммуникации между модулями. Он «связывает» большие самодостаточные модули между собой, обеспечивая им низкий Coupling, что позволяет им быть отдельными переиспользуемыми образованиями, а не одним большим неразрывным «куском кода».
Он не находится внутри модуля. У модуля есть только тычка Events для общения с EventBus. А внутри модуля коммуникация производится более явно. В т.ч. через «классические» события, которые не требуют дополнительных слоёв абстракций, как в EventBus.
Почему-то так сложилось, и почему-то преимущественно в геймдеве (в других сферах, по крайней мере, я не встречал), что на его основе пытаются стряпать проекты прям «от и до». Пример: тык. Даже на дорогостоящих курсах про это рассказывают.
Но EventBus — не для того, чтобы в проекте всё подряд сделать несвязанным. Если всё не связано — значит, связано всё, только неявно, что ещё хуже.
Чтобы убедиться, достаточно самостоятельно «сунуть пальцы в розетку». Вот инструкция:
сделать проект на >5000 строк собственного кода на основе EventBus,
запланировать масштабную геймплейную фичу,
забыть о проекте на две недельки,
вернуться в проект и сделать эту фичу,
оценить пережитый опыт от 0 до 10 по шкале «спасибо, до свидания».
EventBus — это не плохо, если использовать по назначению. Это инструмент для связи того, что быть связанным напрямую не должно. И чем такого будет меньше, тем лучше. Поэтому подход неплохо приживается на более верхних слоях, где элементов взаимодействия меньше. Но на более низких — часто превращает проект в очень запутанную и сложно контролируемую историю.
Есть исключения. Не всё так просто. Бывают кейсы, где и игровую логику удобно сделать на EventBus. Только название у этого будет более контекстное, а область использования — ограничена этой игровой логикой. Т.е. это будет не совсем EventBus, а иная структура, по реализации похожая на EventBus.
У Артёма Шумейко ещё не очень давно вышло два видео, посвящённых CI/CD. Одно теоретическое, другое — практическое. И вот второе мне очень даже понравилось — хочется им поделиться. К тому же ранее я уже рекомендовал его видео по деплою приложений, а CI/CD можно рассматривать как автоматизацию этого процесса.
🤔 При чём тут геймдев:
Указанный уровень материала очень условный. Вопросы CI/CD "официально" не входят в область GameDev-специальности, а уж тем более middle-уровня. Но навык это незатейливый и очень полезный на любом уровне специализации. Полезный и для корпоративной жизни, и для личной — навести автоматизацию на своих петах тоже удобно. А достопочтенному senior'у как-будто бы даже зазорно не уметь в такое хотя бы на уровне теории.
В больших компашках на 100+ человек обычно есть выделенные devops-человечки. И обычно они постоянно заняты, т.к. обязанностей у них предостаточно. Оперативно решить вопросики с CI\CD малого масштаба можно самостоятельно — тут и поможет накопленная экспертиза.
Или можно угодить в коллектив поменьше или того страшнее — собрать его самому. Тогда автоматизируешь рутину и повысишь эффективность команды или ты, или никто.
Запустить автотесты, собрать билд, собрать бандлы, задеплоить бандлы, опубликовать приложение во внутреннее тестирование — как часто это приходится делать и как много это времени занимает, если делать всё вручную. А если ещё есть какие-то зависимые сервера и прочая инфраструктура, то всё становится в разы увлекательнее. В какой-то момент становится выгоднее посидеть денёк другой и всё разочек автоматизировать, чем продолжать тратить время на эту рутину.
☝️ Что хорошего в видео:
Этот ролик — пока самое лучшее из того, что я видел вводного по теме. Он короткий, он по делу, он ёмкий и понятный, он легко и интересно смотрится, он наглядный и качественно сделанный.
Показан весь путь автоматизации: от самого процесса выбора, аренды и настройки сервера до непосредственного автоматизированного деплоя приложения. Хоть тут же повторяй, даже если понятия не имеешь, где и как брать сервера.
И сам пример хорошо демонстрирует для чего нужен CI/CD, для чего нужны тесты, почему важно это всё автоматизировать и почаще гонять.
Gitlab, возможно, не самое популярное решение в геймдеве: я обычно встречаю Jenkins и TeamCity (и изредка Unity Build Automation). И т.к. сборка игрового проекта занятие продолжительное и тяжеловесное, то и сборки делаются не так часто, как об этом пишут применительно к другим сферам. Особенно если проектов много, а машинок для сборки — чуть-чуть или вообще одна. Но на уровне идеи это всё не имеет значения: процессы примерно одинаковые во всех системах и для разной природы проектов. А как выглядит дашборд и какие цифры ставить в настройках — дело наживное.
Пока в столице гремел РЭД, я на выходных посещал другую локальную конференцию — KD Conf. Помимо приятного чувства, что на конференцию не надо никуда лететь/ехать, подхватил два интересных инсайта про внедрение LLM-моделей в процессы:
📃 Можно валидировать ГДД:
Проверить документ на противоречивость информации.
Проверить документ на достаточность информации.
Отформатировать документ под конкретный отдел. Т.е. переоформить так, чтобы с доком было удобно работать программистам, художникам и т.д.
🏷️ Можно валидировать описания для задач:
Проверить, что описание соответствует шаблону.
Проверить, что информация релевантная, а не ради удовлетворения шаблона.
Проверить, что предоставленной информации достаточно для выполнения задачи.
Делать это можно вручную, по необходимости, или автоматизированно через API.
Нужно только подобрать подходящий для команды набор промтов и следить, чтобы нейронка не нагаллюционировала лишнего 🤩
В этой схеме есть две явные проблемы — это конфиденциальность🛡️ и стоимость запросов 💵 Решается это развёртыванием внутренней корпоративной LLM. На конференции я чаще всего слышал про Llama от Meta. И мы в команде тоже как раз смотрим в сторону этого решения.
Мероприятие было «не геймдевное» — весь этот опыт исходил от энтерпрайза, банкинга и прочего бигтеха. Поэтому интересно, пробовали ли кто уже в геймдеве вводить в процессы подобные инструменты❓
💡 Это хорошая возможность запустить свою карьеру в индустрии и поработать над реальным, крупным, глобальным и сложным проектом. У ребят частые, мощные и интересные стажировки. И сами они скилловые, дружелюбные и открытые — в этом просто убедиться, лично пообщавшись с ними на игровых конференциях.
Интересная коротенькая статья про то, как устроено deltaTime в игровых движках. Никакого откровения нет, если внимательно прочитать само определение параметра в документации к движку (например, Unity). Но всё равно найдутся те, для кого это может оказаться неожиданностью.
А не зная, как работает инструмент, можно получить неожиданное поведение при использовании.
Рекомендую также заглянуть в Appendix — там есть ссылки на более углубленные статьи: про нюансы отрисовки, общение между CPU и GPU, способы определения deltaTime, влияние параметра maxQueuedFrames и особенности работы при vSync.
Это контент посложнее, но, если заинтересует, уже будет понятно, в какую сторону рулить поисковые запросы и промпты для чат-ботов.
🎄 Последняя в этом году подборка GameDev и IT мероприятий, которые встретил в чатах, группах и просто в сети. Митапы, конференции, фестивали, джемы, конкурсы и другое. >> предыдущая подборка <<
🔹🔹 Декабрь: 🔹🔹
🧑💻🎤🎫 2 и 3 декабря. Мск [Offline] [Online] HighLoad++ 2024. "Сколково". Билеты от 41 000 ₽.
На YouTube-канале CodeMonkey недавно вышло два больших видео, два бесплатных курса. Это 12-часовой курс по C# и 7-часовой курс по DOTS. Я их ещё не просмотрел и не могу объективно оценить. Но если вдруг какой-то подобный контент был как раз нужен — возможно это оно. Ранее там же выходил ещё курс по C# Intermediate.
# Про C#:
Видео по C# для меня интереса не представляет. Полистал, вроде всё адекватно, примеры нормальные. Видел пример реализации [Flags] для enum через побитовый сдвиг — очень полезная штука, почему-то её при обучении любят игнорировать.
✨ Про DOTS:
А вот видео по DOTS я, пожалуй, затестирую лично, но уже в новом году — пока катастрофически загружен. Напомню, что DOTS — это не только ECS-фреймворк, но и целый стек технологий, часть которых доступно и вне ECS (например, Burst Compiler и Job System).
Из ECS-решений ранее я пробовал DOTS, Entitas, LeoECS и Morpeh — и последний мне нравится больше всех, пусть он и не самый производительный. А DOTS нравился меньше всех. Интересно будет посмотреть, что в нём изменилось и что он из себя представляет сейчас.
📖 Про подобные курсы в целом:
Помнится, год назад Сакутин тоже выпускал подобные YouTube-курсы по C# и по Unity. Я их не смотрел, ничего сказать не могу. Видел только в чатах отзывы проходивших, что классическое «обо всём и ни о чём». Что, на самом деле, ожидаемо. 7–12 часов — это капля в море, особенно для Unity. Можно только успеть «тегов» набросать и по верхам пробежаться.
Так что это всё не более чем помощь в самообучении и практике. Только самостоятельное копошение в теме сможет чему-то научить. Не нужно ждать, что такие короткоформатные курсы смогут резко прокачать. Только подскажут и направят, не более.
🔖 Рекомендация от себя:
Пользуясь случаем, порекламлю мой любимый ресурс по C# (и не только) — Metanit. Удобный, качественный, бесплатный, масштабный. Он не заменит всё на свете, но это очень хороший дополнительный ресурс, который удобно использовать параллельно с другими ресурсами и к которому удобно возвращаться потом.
Сам по нему учился, параллельно с кучей других профильных книг. В «своё время» выел там весь контент по C#. Пригодилось ли мне это?
С практической точки зрения: что повседневно не использую, то уже, конечно, не помню совершенно.
С точки зрения эрудиции: в моменте, когда учишься, когда много белых пятен, такой широкий контекст помогает выстроить майндсет и осознать, что где, как и почему используется. А в последствии помогает решать проблемы более высокого порядка, чем простое написание кода.
Кто из лагеря Visual Studio уже успел попробовать теперь уже бесплатную версию Rider? Внутри много интересного: тесная интеграция с движками, шустрый и настраиваемый анализатор кода, полезные подсказки и автодополнения, генератор кода, мощный отладчик и всякое другое.
Даже простое знакомство с настройками может затянуться не на один час (при этом они удобно скомпонованы, и поиск по ним работает отлично). Но что важно — у Rider очень гибкая система шорткатов и хоткеев.
❓ Зачем это нужно? Для удобства. Конечно, для эффективности тоже. Но главное — для удобства. Нажатие на клавиши значительно быстрее, чем аналогичное действие совершённое мышкой. И требует меньше внимания. Мышку нужно перехватить, передвинуть, навести на меню, потом на вложенное меню, кликнуть и вернуть руку обратно (если нет навыка однорукой печати).
Rider позволяет полностью отказаться от мыши и сосредоточиться на работе. Захотел что-то сделать – стукнул пальцами и моментально увидел результат. При доведении до автоматизма, это превращается в настоящую магию, как-будто IDE управляется силой мысли. И это доставляет определённый кайф от работы.
Особенно ярко это раскрывается при рефакторинге кода. Во многих IDE есть куча автоматизаций для этого процесса, которые невероятно облегчают жизнь разработчику. И шорткаты превращают это всё в увлекательный процесс грациозного и эффективного дирижирования кодом.
🎥 Приложу видео, которые могут помочь познакомиться с основными возможностями. Они не очень свежие, но всё ещё актуальные, только с тех времён всё стало ещё лучше, и возможностей прибавилось.
⚙ Рекомендую также заглянуть в настройках во вкладку Keymap, где можно через поиск найти практически любое действие в IDE, которому можно назначить свой шорткат. Что-то часто приходится делать мышкой? Или на видео показывают полезный шорткат, который у тебя не срабатывает? Зайди в Keymap, найди нужное действие и назначь желаемую комбинацию.
Если запоминать комбинации не хочется, достаточно запомнить название операции и использовать поиск по Action'ам. Также в запоминании шорткатов может помочь плагин Key Promoter X (или может раздражать, если шорткаты игнорировать).
🤹 Шорткаты есть во всех программах. И везде они помогают сделать работу более комфортной (и эффективной). Не только в Rider и не только в IDE стоит уделять этому внимание. В т.ч. горячие клавиши есть и в Unity. И я рекомендую посмотреть их официальный тутор. Уверен, что ты сможешь узнать что-то новое, потому что в Unity далеко не все полезные возможности «лежат на поверхности». Также у них есть Shortcuts Manager, куда стоит периодически заглядывать.
Уровень материала: 🐣 #junior <тестирую раздел Посты. этот материал уже можно было встретить в моём Telegram>
В рекомендации отправляю видео, которое показывает два любопытных подхода:
1. Хранение конфигурации уровня в ScriptableObject, а не в отдельной сцене. 2. Анимированное появление тайлов уровня.
И внутри есть ряд ещё более мелких интересных деталей.
📋 1. Хранение конфигурации уровня:
С этим я столкнулся в самом начале своей карьеры, т.к. начал с матч-3 направления, которое славится большим количеством уровней. По неопытности я хранил каждый настроенный уровень в отдельной сцене. Это привело к тому, что 10 таких уровней раздули билд без существенного контента до 100Мб.
Поизучав предметную область подробнее, я пришёл к тому, чтобы для уровня иметь одну сцену, а её наполнение формировать по данным из некоторого файла. Я использовал XML, т.к. тогда это было популярно (позднее для настройки уровня был подключен Tiled, который как раз умел экспортировать в XML). Билд тут же сдулся до 20Мб. А подход подарил невероятное количество всяческих бенефитов.
ScriptableObject — это тоже некоторый файл с данными (а точнее YAML или Binary, в зависимости от настроек Unity), который Unity умеет красиво отрисовывать в инспекторе.
А вот пример ассета (с ёмким описанием), который конвертирует уровень в JSON.
🎲 2. Анимированное появление тайлмапа:
Если уровень строится из тайлов, то это отличная возможность за "дёшево" сделать его эффектное появление. Например, как в видео, от точки позиции игрока плавно появить все тайлики в порядке удаления. Также можно и в целом оживить тайловое окружение, реагируя на разнообразные действия игрока.
✨ 3. Полезные мелочи:
В видео можно подглядеть:
Как удалять элементы из списка, чтобы в for не делать лишних декрементов и в foreach не получить исключение InvalidOperationException “Collection was modified”. Подробнее про это можно также почитать в этом материале.
Использование sqrMagnitude при сравнении дистанций для оптимизации вычислений. Про сравнение с обычным magnitude — тут (я тоже проводил подобные замеры: данные всё ещё актуальны).
Как оформлять Coroutine для анимаций: нейминг, аргументы, содержание.
Использование AnimationCurve для контроля плавности анимации.
Проблемные игроки, покупатели лутбоксов (LB) и пользователи, открывающие бесплатные лутбоксы, разделяют несколько когнитивных искажений, причем уровень этих искажений выше в данных группах, чем у группы игроков без признаков проблемного поведения, даже при учете пересечения между группами.
Результаты исследования не выявили различий между проблемными игроками, покупателями лутбоксов и пользователями, открывающими бесплатные лутбоксы, в отношении иллюзии контроля или предсказательного контроля.
До сих пор сложно поверить, что с релиза Bioshock Infinite прошло аж 11 лет. Это был не просто культурный феномен, захлестнувший миллионы людей по всему миру. Нам подарили очень личное и эмоциональное приключение для каждого игрока, который вместе с Букером и Элизабет ворвался в Колумбию. Но после того, как вы узнаете об истории разработки Bioshock Infinite, вам будет казаться, что случилось чудо.
В этом посте я хочу рассказать о библиотеке, которая дает мне надежду, надежду на светлое будущее! Где я могу создать свой игровой фреймворк или движок. Зачем это нужно и причем здесь SDL3? Представим что вы одинокий странник в мире разработки игр.
Концентрированные проблемы:
Универсальные игровые движки не всегда удобны и иногда приводят к выгоранию, отказу от идей. Современные графические api сложны и требуют много времени, знаний, тестирования на реальных устройствах. Время, его мало, нормальные решения делаются годами. Все сильно индивидуально и раздроблено, не всегда можно использовать наработки других. Сакральные знания и смыслы.
Встречайте SDL3 с GPU! Это вам не рендерер, это полноценная абстракция над такими api как Vulkan, DirectX 12, Metal и в будущем WebGPU.Один из авторов SDL, заметил проблему и поднял ее достаточно давно. OpenGL легаси, а современные api крайне сложны. Там были взлеты и падения, но главное это появилось.
Концентрированные плюсы:
Огромное сообщество, а значит и покрытие устройств. Включает поддержку консолей. API от окна до камер и геймпадов. Есть шанс что сообщество будет поверх этого делать свои библиотеки. Imgui из коробки работает с SDL. C API, используйте на любимом языке программирования и с любимыми шейдерами. Идеальный баланс между простым и сложным.
Доступна версия 3.1.6 (Pre-release), релизной ожидается 3.2.0
Минпросвещения собирается расширить перечень специальностей среднего профессионального образования.
Разработчики компьютерных игр и специалисты по работе с искусственным интеллектом (ИИ) появятся в российском перечне профессий и специальностей среднего профессионального образования. Это следует из проекта приказа Министерства просвещения, опубликованного на официальном сайте для размещения информации о подготовке нормативных правовых актов.
Начиная с 2025/2026 учебного года получить профессию разработчика игр смогут молодые люди как после девятого, так и после 11-го класса. Выпускники колледжей смогут работать в соответствии с профстандартом «Связь, информационные и коммуникационные технологии».
Федеральный образовательный стандарт среднего профессионального образования по специальности «Разработка компьютерных игр, дополненной и виртуальной реальности» включает, кроме самих игр, изучение разработки программных модулей, иммерсивных и мультимедийных приложений, тестирования информационных систем, 3D-моделирование и визуализацию компонентов системы.
Дата окончания общественного обсуждения документа — 6 ноября текущего года.
Колледжам будет непросто найти педагогов по таким дисциплинам, но это возможно, считает директор спортивно-методического центра «Кафедра киберспорта» [...]
Интересный механизм генерации экрана для ATARI XL/XE. Из-за особенности работы видеочипа мы можем для каждой строки сканирования указать видеорежим и то, с какого участка памяти брать данные для строки.
На картинке можно увидеть зоны хода луча, когда он выключен, это Horizontal Retrace и Vertical Retrace, соответственно интервал между строками и между следующими кадрами. В эти интервалы можно выполнять код, который будет делать что-то интересное для нас. Тут будем переключать таблицы символов. Зачем это нужно? Есть текстовый режим графики 40х24 с пятью цветами, который можно использовать для игр, но мы сильно ограничены в рисовании контента динамически, так как это по сути спрайты ориентированные по знакоместам. Символы в XL/XE представлены таблицей в 128 штук (1024 байт) и мы можем рисовать изображение внутри кодовой таблицы, а потом выводить символы в виде текста. Кажется, что 128 символов не хватит чтобы заполнить экран в 40х24=960 байт, вот тут мы и получаем профит.
Новый экран будет (условно) выглядеть так:
ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!@#$
И так 24 раза. После каждых 8 строк сканирования (1 знакоместо) мы сдвигаем кодовую таблицу на 40*8 байт, где уже готово изображение для второй порции строк и т.д. То есть рисуем в памяти где участок для кодовой таблицы, а видеочип рисует их как символы. Мы получаем динамическую генерацию экрана и 5 цветов.
Когда я такое придумал, то думал, что это изобретение века, но потом нашёл информацию о таком способе: Источник 1, источник 2.
Здесь базовый класс, который я использую, чтобы добавить поля в любой встроенный инспектор: GitHub | CustomOverrideEditor
Может быть непросто показать всё, что изначально рисовал встроенный инспектор (например, в примере с ModelImporter, у меня исчезли кнопки «Apply/Revert»), но имея доступ к декомпилированному коду, через рефлексию я успешно все отрисовал
В ваших пользовательских полях вам также придется обрабатывать mixed values вручную, потому что у вас нет общего SerializedObject. Вы можете создать ScriptableObject для каждого AssetImporter.userData, но это может крайне медленно, при выделении множества объектов одновременно
Код полной реализации с картинки-примера, ModelImporter с полем Enum, сохраняемым для каждой модели: GitHub Gist | Source code
[Микро-Пост-Мортем] После двух лет разработки зарелизил свою ретро экшн игру. Получился Action Roguelike Deckbuilder с сотней мини-игр.
С год назад сильно поменял концепцию. Первоначально игра задумывалась, как линейное прохождение около ста уровней. Однако первые бета-тесты показали, что по сегодняшним меркам игре не хватает глубины. Сами мини-игры воспринимались отлично. Однако их линейное чередование - это слишком просто.
Пришлось принимать сложное решение - добавлять "мета-игру". Отдельную игровую механику, связывающую разрозненные аркады (2.5D Top-Down). За прохождение мини-игр стали выдаваться картриджи, наделяющие способностями и дающие разнообразное оружие. Игра превратилась в Action Roguelike Deckbuilder с сотней мини-игр.
Игра стала сложнее. Пришлось основательно заниматься балансом, ведь за прохождение каждой аркады выдаются картриджи, из которых собирается колода. Максимальное количество картриджей в колоде, кстати, зависит от прокачки самого героя.
