Разработка игр — творческий и технически сложный процесс, требующий от разработчика умения балансировать между созданием захватывающего геймплея и правильной обработкой масштабных данных. Одна из самых больших проблем — рутинный ввод данных, который часто приводит к выгоранию и потере мотивации. Так было и со мной, когда я разрабатывал свою экспериментальную игру сражающейся карточной системы на Unity3D. Моя идея зародилась много лет назад, и я начал создавать прототипы с помощью бумаги, ручки и Excel, прежде чем переходить к полноценной реализации кода. Со временем моя игра приобрела сложную систему боевых возможностей с разными персонажами, уникальными заклинаниями и характеристиками, но сталкиваться с рутинной работой по вводу данных в редактор Unity стало настоящим испытанием.
Использование scriptable objects и специальных редакторов с помощью Odin позволило упростить работу с простыми списками и словарями, но когда дело дошло до вложенных компонентов, сложных наследуемых классов и nullable-ссылок, это оказалось неудобным и сложно реализуемым. Часто приходилось разбираться с неизвестным происхождением данных в пользовательском интерфейсе, что сильно затормаживало процесс. Чтобы не тратить время на бессмысленную работу, я переключался на разработку других систем, но рано или поздно возникала потребность в большем объёме данных, без которых невозможно развивать геймплей дальше. Однажды меня осенило — зачем я вообще ограничиваю себя редактором Unity, если могу хранить всё в коде? Код легко редактируется, подвергается типизации и гораздо проще анализируется. Я начал экспериментировать с экспортом ассетов Unity в C#-скрипты, но этот путь оказался неудачным из-за сложности двунаправленного преобразования.
Затем я пробовал использовать YAML с кастомной схемой, но это усложнило задачу, дублируя структуру игры в двух форматах. В итоге я пришёл к идее хранить игровых данных именно в виде C#-кода — одностороннее преобразование получалось простой и стабильной задачей. Когда данные стали текстовыми файлами с определенной структурой, я задумался: почему бы не использовать возможности больших языковых моделей (LLM) для автоматизации переноса данных из Excel в код? LLM отлично справляются с распознаванием паттернов и сопоставлением данных, что делает их мощным инструментом для автоматической трансформации текстовой информации. Но работа с LLM — не всегда простая задача, и понимание их ограничений не менее важно, чем оценка их возможностей. Большие языковые модели великолепны в поиске закономерностей, но испытывают трудности с «загрязнением контекста».
В отличие от человека, чей разум способен забывать и переключать внимание, LLM склонны воспринимать лишнюю информацию как главное, что искажает результаты. При совместной работе с ИИ нужно четко структурировать ввод, выделять главные моменты, формулировать ясные задачи. Именно человек остаётся главной управляющей силой, анализирующей проблему, а искусственный интеллект выступает как помощник, быстро находящий варианты решения и генерирующий технологические шаблоны кода. Я решил не просто отдавать LLM Excel-файлы и просить их конвертировать в код, а первым делом потратил время на создание точного и скрупулёзного запроса-подсказки (prompt). В этом запросе я подробно описал формат входных данных, назначение колонок, особенности поиска соответствий в существующих классах таких как Spell.
cs, NullableSpellModifier.cs, а также продемонстрировал примеры сложных вложенных структур. Логика запроса состояла в последовательном разборе свойств, анализе описаний заклинаний, выявлении ключевых действий, модификаторов, условий и их комбинаций, после чего шло сопоставление с существующими игровыми функциями и предложение новых реализаций в случае необходимости. Работа над запросом потребовала ряда итераций: с каждым новым вводом контекста LLM уменьшали количество ошибок и генераций лишнего кода. Стало возможным получать не просто прямой перевод с Excel в программы, а структурированный план действий, включающий отчёты о пропусках и рекомендации по расширению системы.
Теперь я мог автоматизировать рутинный ввод данных, обеспечив корректность и однородность структуры, сэкономив сотни часов потенциальной работы. Этот подход позволил мне вновь сконцентрироваться на том, что действительно интересно — решении сложных задач по игровой механике и программированию. Избавившись от утомительного ручного ввода, я получил возможность экспериментировать и развиваться, что оживило мою страсть к разработке игр. Опыт показал, что комбинирование сильных сторон человека и ИИ создаёт синергию, где человек управляет контекстом и принимает решения, а LLM выступают мощным инструментом ускорения технической части. В моём случае, конечной целью стало создание подробного, структурированного и адаптивного рабочего процесса, который не только превратил Excel из головной боли в надежного помощника, но и существенно повысил эффективность всей разработки.
При грамотном подходе технологии больших языковых моделей способны значительно расширить инструментарий разработчика, особенно в областях, связанных с обработкой и трансформацией текстовых и табличных данных. В сочетании с удобными форматами хранения в виде исходного кода, это открывает новые горизонты для прототипирования, тестирования и масштабирования игровых проектов. Таким образом, метод применения LLM для маппинга Excel-таблиц в C# код не только решает насущную проблему с вводом и ведением игровых данных, но и вдохновляет разработчиков переосмыслить классические подходы к организации рабочих процессов, делает создание игр более продуктивным и творческим. Способность быстро адаптировать и улучшать сценарии с помощью искусственного интеллекта — важный шаг к эффективности и успеху в современной индустрии геймдева.
