[Adobe Flash] Как я модернизировал свою Flash-игру (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В этом посте я расскажу о том, как перенёс свою Flash-игру Frog Fractions на современную платформу. В результате я создал частично автоматизированный порт на Unity при помощи Haxe. Пост будет интересен всем, кто пытается модернизировать свою кодовую базу на Flash. В посте будут приведены спойлеры о структуре Frog Fractions: Game of the Decade Edition и её DLC Hop's Iconic Cap.
После того, как игре Frog Fractions 2 не удалось сделать меня богатым, я примерно год занимался работой по контракту и скетчами/прототипами. Потом моя жена забеременела, и я решил, что настало время найти настоящую работу, чтобы можно было содержать семью. Перед началом GDC 2018 я опубликовал твит о поиске работы, надеясь найти на конференции нужных людей. Я прошёл собеседования в нескольких местах, но самым важным стало то, что мне удалось найти финансирование для своего следующего проекта.
Проект был таким: спрятать следующую игру Frog Fractions внутри Frog Fractions 1 и продать её в Steam.
Frog Fractions состоит примерно из 13k строк кода на Actionscript 3 и собрана с помощью компилятора Flex. Я прикинул, что после добавления нового контента ремастера объём утроится, примерно до 40k строк кода. (И моя оценка оказалась довольно точной — получилось 28k кода на C# и 3k строк скриптов катсцен/деревьев диалогов в дополнение к оригинальной игре.)
Я рассмотрел несколько возможных вариантов дальнейшей работы:
- Продолжить писать игру на AS3 и собрать её с помощью Adobe AIR. Это был самый простой способ, но он имел несколько важных недостатков:
- Frog Fractions имела программный рендеринг и создавалась под разрешение 640x480. При более высоком разрешении картинка становилась очень некрасивой. Такое ограничение было вполне приемлемым для браузерной игры в 2012 году но, скорее всего, в 2020 году в Steam никого не устроит.
- Flex уже начал выдавать ошибки памяти, когда кодовая база оригинала игры превысила 10k строк кода, если я не делал полной пересборки. Сломается ли всё окончательно при 40k строк? (Специалисты говорят, что нет, и что мне достаточно настроить флаги компилятора.)
- Flash уже находился при смерти. Будет ли вообще существовать AIR в 2020 году? (Оказалось, что он жив и хорошо себя чувствует! Прекратилась поддержка только браузерного плагина.)
- Я подумывал о том, чтобы когда-нибудь перенести игру на консоли. Люди выпускали целые игры, полностью созданные в Scaleform (The Banner Saga, Road Not Taken), но было непонятно, будет ли жив Scaleform или что-то подобное в 2020 году. (Оказалось, что в 2018 году Autodesk прекратила продажи Scaleform, а все обсуждения о его замене касались только самой притягательного его аспекта — дизайна UI.)
- Встроить в мою игру Flash VM и перехватывать её код ввода-вывода. Существуют виртуальные машины Flash с открытым исходным кодом, но ни одна из них не показалась мне доступной или достаточно готовой для моего проекта. Сегодня я слышу хорошие отзывы о Ruffle. Возможно, она неплоха?
- Портировать игру на C#/Unity. Потребуется куча ручного труда и довольно скучная работа по запуску игры.
- Собрать два исполняемых файла: загружать игру на Flash, а когда игрок доберётся до нового контента, переключаться на Unity. Я представлял, что «как-нибудь» заставлю два исполняемых файла выполнять отрисовку в одном окне. Уверен, что это реализуемо, но, вероятно не из Unity, и подобные вещи обычно очень хрупки и обязательно ломаются при следующем обновлении Windows. (Если бы сегодня к моей голове приставили пистолет и заставили это сделать, то я, вероятно, открыл бы TCP-соединение между двумя процессами и передавал бы по нему видео. У Flash имелась хорошая поддержка воспроизведения видео, и я уверен, что существует плагин Unity, выполняющий кодирование видео.)
- Портировать игру на Haxe и OpenFL. Есть инструмент под названием as3hx для преобразования кода на AS3 в очень похожий код на Haxe, а OpenFL пытается стать спасательной капсулой для Flash API. Я с неделю поигрался с OpenFL и пришёл к выводу, что на то время он был недостаточно завершённым.
Хочу здесь подчеркнуть, что все эти подходы основывались на том, что Frog Fractions по своей сути была программой,, которую я писал для компиляции в SWF. Не могу судить, насколько моё решение применимо к вашей игре, если она является таймлайном анимации Flash, интерактивность которой обеспечивают скрипты.
Я поспрашивал советов о том, как мне двигаться дальше, и самый полезный мне дал Ларс Дусет, кроме прочего сообщивший, что у Haxe есть C#-бэкенд и его целевой платформой может быть Unity. Ещё он посоветовал мне сначала придумать рабочий процесс и портировать с его помощью небольшой проект.
(Примечание для себя: добавить Ларса Дусета в титры игры. Я не мог представить, насколько сильное влияние он оказал на прокт, пока не стал перечитывать нашу переписку.)
Спустя неделю экспериментов мне удалось запустить Frog Infarctions (игру, которую я написал 0-hour game jam Соса Сосовски) в редакторе Unity. Результат был неидеальным, но его оказалось достаточно, чтобы понять возможность реализации, поэтому я начал работу над основным проектом.
Вот каким получился мой процесс работы. Эти операции нужно выполнить один раз:
- С помощью as3hx преобразовать код с AS3 на Haxe.
- При необходимости вручную подчистить созданный as3hx код.
После этого итеративно выполнять следующие операции:
- Портировать кодовую базу на Haxe, чтобы использовать Unity API вместо Flash API.
- Использовать C#-таргет языка Haxe для компиляции кода Haxe на C#. Если сообщить Haxe, где находится UnityEngine.dll, он вытащит API оттуда и их можно будет вызывать из кода hx. То же самое можно проделать при помощи Assembly-Csharp.dll с кодом на C#, написанным для проекта.
- Выполнить сборку и протестировать в Unity.
Первая неделя работы была очень утомительной, приходилось подчищать выражения, которые as3hx помечал как противоречивые, устранять добавляемые им ошибки компилятора и разбираться с вызовами ввода-вывода. Устранение ошибок в Haxe неидеально, поэтому при каждой попытке сборки возникало около 30 ошибок, как бы я ни старался, поэтому я понятия не имел, насколько близок к завершению, пока всё не компилировалось без ошибок. Кроме того, мне кажется, as3hx — это транслятор типа «поиск и замена», а не настоящий транспайлер с переводом в AST и обратно, потому что он, похоже, добавляет такие ошибки, как расположение кода с неправильной стороны от скобок, когда в моём управлении потоками используется специфический стиль скобок.
Завершив с этим, я получил кодовую базу на Haxe, успешно компилирующуюся в C#-таргет. После этого я ни разу не касался кода AS3. (За исключением описанного ниже процесса экспорта графических ресурсов.) На этом этапе я решил отказаться от Haxe и просто работать на C#, но хотя выходные результаты as3hx довольно похожи на первоначальный код с сохранением стиля скобок, порядка кода и комментариев,, выводимый Haxe код на C# очевидно не предназначен для человеческого глаза. Поэтому с этого момента, если я не создавал новые сцены, я редактировал код на Haxe и компилировал его в C#.
На этом этапе код компилировался и запускался в движке Unity, но без ввода-вывода. Следующим шагом стало воссоздание всего кода ввода-вывода с помощью Unity API. На это и на преобразование ресурсов ушло около четырёх месяцев, в основном потому, что в Frog Fractions есть множество разных типов ресурсов:
- Векторная графика, нарисованная в редакторе Flash. Я рендерил её в качестве 4k, заставив AIR собрать исходную игру, но не делая ничего, кроме рендеринга кадров анимации и записи их в файлы PNG. Затем с помощью TexturePacker я собрал их в спрайтшиты.
- Векторная графика, использующая Flash Shape API. Во Flash всего в нескольких строках кода можно, например, отрисовать скруглённый прямоугольник и применить фильтры в стиле Photoshop типа скоса или тени. Язык лягушки отрисовывался как толстая линия с закруглёнными концами. В Unity подобные вещи реализовать сложнее. В разных случаях я применял разные приёмы, например, для каждого стиля контейнера текста рендерил 9-slices, а язык отрисовывал заполненным четырёхугольником с отмасштабированным кругом в качестве концов.
- Графика в SVG, взятая с OpenClipArt.org. Так как я записывал имена художников, чтобы указать их в титрах, мне не сложно было найти их на сайте и скачать графику в более высоком разрешении.
- То же самое касалось фотографий, взятых с Flickr. Я использовал для увеличения размера preserve details из Photoshop, чтобы при необходимости вносить изменения, и создал конвейер для разбивки полноэкранного 4k-изображения на текстуры в удобном размере со сторонами, равными степеням двойки.
- Нарисованная от руки растровая графика. В некоторых случаях художники изначально представили мне графику высокого разрешения, которую я уменьшил для оригинальной игры. В других я заплатил художникам, чтобы они перерисовали их собственную графику в 4k. Сложнее всего было убедить их, что мне не нужна более качественная графика, которую они научились рисовать за прошедшие восемь лет — я хотел как можно ближе придерживаться оригинальной игры!
- Пещерный лабиринт сам по себе был огромной проблемой. В оригинальной Flash-игре он был огромными изображениями, которые игра разрезала на куски экранного размера и пропускала через алгоритм наподобие Marching-Cubes для построения меша коллизий. Так как я не хотел увеличивать эти гигантские изображения до разрешения 4k, я применил тот же алгоритм, но с более высоким разрешением для генерации отображаемого меша. Оба меша включены в получившуюся игру, а изображения я убрал.
- Множество полноэкранных эффектов, которые нужно было реализовать заново в виде шейдеров.
- Короткий видеоклип с развевающимся флагом. Когда в 2015 году я создавал Unboxing Story Unity API для воспроизведения видео был ужасным. К 2018 году он перестал быть ужасным. Ура!
- Со звуком всё было проще. У меня сохранились все звуковые эффекты в файлах .wav и я сразу смог их использовать.
- Оригинальная музыка была записана в MP3 с форматом 64kbps mono, что, наверно, сэкономило мне за все эти годы несколько тысяч долларов затрат на хостинг Amazon S3, но у меня уже были высококачественные стереозаписи всей музыки с тех пор, когда я создавал OST.
Всё в ремастере, кроме полноэкранных шейдеров и воспроизведения видео, и большинство того, что есть в новом сюжете, рендерится при помощи вызовов Graphics.DrawMesh, а не как объекты в графе сцен Unity. Поэтому возникает вопрос: действительно ли Unity подходит для этого проекта?
В то время, когда мы с Крейгом Тимпани выбирали движок для Glittermitten Grove, мы остановились на Unity из-за её хорошей поддержки кроссплатформенности, потому что FNA ещё не был готов и потому что создание собственного движка — отличный способ никогда не закончить игру. В конечном итоге, хоть меня и печалила плохая поддержка 2D в Unity, это позволило нам почти без проблем выпустить версии для Mac и Linux, что, по моему мнению, огромная удача. (Предположительно, поддержка 2D в Unity с 2015 года стала лучше, но я её не изучал. Работа Graphics.DrawMesh вполне меня устраивает. Может, даже у FNA теперь появился работающий конвейер обработки ресурсов!)
Для этого проекта я выбрал Unity в основном по инерции — не хотелось заморачиваться изучением нового движка, ведь мне предстояло реализовать описанный выше исследовательский проект; Unity поддерживает все платформы, на которые я хотел портировать игру, в том числе и консоли.
А, ну и потом я создал дополнительную игру! Вероятно, я расскажу об этом творческом процессе в другом посте, здесь упомяну только то, что я собрал в Haxe переходную сцену, а остальную часть новой игры писал на C#. Кроме того, я внёс значительные изменения в основное меню внутри кодовой базы Haxe. Поэтому мне кажется, что вполне возможно после портирования на Haxe продолжать выпускать обновления кода, выполняя разработку на Haxe.
Также я внёс некоторые оптимизации в код оригинала. Код на AS3 намеренно писался без учёта эффективности, потому что я пытался избежать стремления к «безупречному коду». Например, я поверить не мог, что мне сойдёт с рук выделение Vector2 для кучи при каждой арифметической операции! Получившийся результат хорошо работал на компьютерах 2012 года, но части с наихудшей производительностью после двойной транспиляции вызывали значительную нагрузку, поэтому для хорошей работы на современных PC мне пришлось переписать часть кода на нативном C#.
Также стоит заметить, что если бы я не планировал значительно расширить объём оригинальной игры и просто пытался сохранить от смерти вместе с Flash, то OpenFL, AIR или Ruffle были бы, наверно, более умным выбором.
Выпуск игры походил на прощание с ней. Мне нравилось работать на Flash. В то время это был лучший способ показать свои игры людям с наименьшими усилиями и казалось, что они будут жить вечно — SWF из 90-х по-прежнему безупречно работают в последнем Flash player, хотя прошли десятки лет. Наблюдать за тем, как мир пытается перейти на HTML5, когда он явно ещё к этому не готов, было мучительно. (И, честно говоря, всё становится скорее хуже, чем лучше. Я считаю, что браузер никогда больше не станет пригодной для игр платформой, пока владельцы двух самых популярных браузеров имеют собственные магазины приложений для телефонов.) Я создал ремастер частично из-за того, что хотел продать новую игру, но ещё и из искреннего желания сохранить свою часть игровой истории. Спасибо, что вернулись к ней вместе со мной!
===========
Источник:
habr.com
===========
===========
Автор оригинала: Jim Stormdancer
===========Похожие новости:
- [Adobe Flash, Информационная безопасность] Flash Player будет удален с сайта Adobe в декабре
- [Работа с векторной графикой, Adobe Flash, Компьютерная анимация, Графический дизайн, Читальный зал] Flash, «Умрёт ли он ещё раз — неизвестно, а цветы пропадают…»
- [Firefox, Информационная безопасность, Adobe Flash, Расширения для браузеров, Браузеры] Mozilla откажется от Flash с выходом Firefox 84 в декабре
- Релиз языка программирования Haxe 4.1
- [Haxe] Стек технологий Shiro Games (перевод)
- [Haxe] Kha vs HTML5: Компилируем JavaScript в C++ (перевод)
- [Haxe] Forge of Empires из AS3 в Haxe. Постмортем (перевод)
- [Haxe] Зимний отчет о состоянии Haxe (перевод)
- [Haxe] Осенний отчет о состоянии Haxe (перевод)
- Релиз языка программирования Haxe 4.0
Теги для поиска: #_adobe_flash, #_flashigry (flash-игры), #_adobe_air, #_haxe, #_openfl, #_action_script_3.0, #_fleshigry (флэш-игры), #_adobe_flash
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:30
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В этом посте я расскажу о том, как перенёс свою Flash-игру Frog Fractions на современную платформу. В результате я создал частично автоматизированный порт на Unity при помощи Haxe. Пост будет интересен всем, кто пытается модернизировать свою кодовую базу на Flash. В посте будут приведены спойлеры о структуре Frog Fractions: Game of the Decade Edition и её DLC Hop's Iconic Cap. После того, как игре Frog Fractions 2 не удалось сделать меня богатым, я примерно год занимался работой по контракту и скетчами/прототипами. Потом моя жена забеременела, и я решил, что настало время найти настоящую работу, чтобы можно было содержать семью. Перед началом GDC 2018 я опубликовал твит о поиске работы, надеясь найти на конференции нужных людей. Я прошёл собеседования в нескольких местах, но самым важным стало то, что мне удалось найти финансирование для своего следующего проекта. Проект был таким: спрятать следующую игру Frog Fractions внутри Frog Fractions 1 и продать её в Steam. Frog Fractions состоит примерно из 13k строк кода на Actionscript 3 и собрана с помощью компилятора Flex. Я прикинул, что после добавления нового контента ремастера объём утроится, примерно до 40k строк кода. (И моя оценка оказалась довольно точной — получилось 28k кода на C# и 3k строк скриптов катсцен/деревьев диалогов в дополнение к оригинальной игре.) Я рассмотрел несколько возможных вариантов дальнейшей работы:
Хочу здесь подчеркнуть, что все эти подходы основывались на том, что Frog Fractions по своей сути была программой,, которую я писал для компиляции в SWF. Не могу судить, насколько моё решение применимо к вашей игре, если она является таймлайном анимации Flash, интерактивность которой обеспечивают скрипты. Я поспрашивал советов о том, как мне двигаться дальше, и самый полезный мне дал Ларс Дусет, кроме прочего сообщивший, что у Haxe есть C#-бэкенд и его целевой платформой может быть Unity. Ещё он посоветовал мне сначала придумать рабочий процесс и портировать с его помощью небольшой проект. (Примечание для себя: добавить Ларса Дусета в титры игры. Я не мог представить, насколько сильное влияние он оказал на прокт, пока не стал перечитывать нашу переписку.) Спустя неделю экспериментов мне удалось запустить Frog Infarctions (игру, которую я написал 0-hour game jam Соса Сосовски) в редакторе Unity. Результат был неидеальным, но его оказалось достаточно, чтобы понять возможность реализации, поэтому я начал работу над основным проектом. Вот каким получился мой процесс работы. Эти операции нужно выполнить один раз:
После этого итеративно выполнять следующие операции:
Первая неделя работы была очень утомительной, приходилось подчищать выражения, которые as3hx помечал как противоречивые, устранять добавляемые им ошибки компилятора и разбираться с вызовами ввода-вывода. Устранение ошибок в Haxe неидеально, поэтому при каждой попытке сборки возникало около 30 ошибок, как бы я ни старался, поэтому я понятия не имел, насколько близок к завершению, пока всё не компилировалось без ошибок. Кроме того, мне кажется, as3hx — это транслятор типа «поиск и замена», а не настоящий транспайлер с переводом в AST и обратно, потому что он, похоже, добавляет такие ошибки, как расположение кода с неправильной стороны от скобок, когда в моём управлении потоками используется специфический стиль скобок. Завершив с этим, я получил кодовую базу на Haxe, успешно компилирующуюся в C#-таргет. После этого я ни разу не касался кода AS3. (За исключением описанного ниже процесса экспорта графических ресурсов.) На этом этапе я решил отказаться от Haxe и просто работать на C#, но хотя выходные результаты as3hx довольно похожи на первоначальный код с сохранением стиля скобок, порядка кода и комментариев,, выводимый Haxe код на C# очевидно не предназначен для человеческого глаза. Поэтому с этого момента, если я не создавал новые сцены, я редактировал код на Haxe и компилировал его в C#. На этом этапе код компилировался и запускался в движке Unity, но без ввода-вывода. Следующим шагом стало воссоздание всего кода ввода-вывода с помощью Unity API. На это и на преобразование ресурсов ушло около четырёх месяцев, в основном потому, что в Frog Fractions есть множество разных типов ресурсов:
 Всё в ремастере, кроме полноэкранных шейдеров и воспроизведения видео, и большинство того, что есть в новом сюжете, рендерится при помощи вызовов Graphics.DrawMesh, а не как объекты в графе сцен Unity. Поэтому возникает вопрос: действительно ли Unity подходит для этого проекта? В то время, когда мы с Крейгом Тимпани выбирали движок для Glittermitten Grove, мы остановились на Unity из-за её хорошей поддержки кроссплатформенности, потому что FNA ещё не был готов и потому что создание собственного движка — отличный способ никогда не закончить игру. В конечном итоге, хоть меня и печалила плохая поддержка 2D в Unity, это позволило нам почти без проблем выпустить версии для Mac и Linux, что, по моему мнению, огромная удача. (Предположительно, поддержка 2D в Unity с 2015 года стала лучше, но я её не изучал. Работа Graphics.DrawMesh вполне меня устраивает. Может, даже у FNA теперь появился работающий конвейер обработки ресурсов!) Для этого проекта я выбрал Unity в основном по инерции — не хотелось заморачиваться изучением нового движка, ведь мне предстояло реализовать описанный выше исследовательский проект; Unity поддерживает все платформы, на которые я хотел портировать игру, в том числе и консоли. А, ну и потом я создал дополнительную игру! Вероятно, я расскажу об этом творческом процессе в другом посте, здесь упомяну только то, что я собрал в Haxe переходную сцену, а остальную часть новой игры писал на C#. Кроме того, я внёс значительные изменения в основное меню внутри кодовой базы Haxe. Поэтому мне кажется, что вполне возможно после портирования на Haxe продолжать выпускать обновления кода, выполняя разработку на Haxe. Также я внёс некоторые оптимизации в код оригинала. Код на AS3 намеренно писался без учёта эффективности, потому что я пытался избежать стремления к «безупречному коду». Например, я поверить не мог, что мне сойдёт с рук выделение Vector2 для кучи при каждой арифметической операции! Получившийся результат хорошо работал на компьютерах 2012 года, но части с наихудшей производительностью после двойной транспиляции вызывали значительную нагрузку, поэтому для хорошей работы на современных PC мне пришлось переписать часть кода на нативном C#. Также стоит заметить, что если бы я не планировал значительно расширить объём оригинальной игры и просто пытался сохранить от смерти вместе с Flash, то OpenFL, AIR или Ruffle были бы, наверно, более умным выбором. Выпуск игры походил на прощание с ней. Мне нравилось работать на Flash. В то время это был лучший способ показать свои игры людям с наименьшими усилиями и казалось, что они будут жить вечно — SWF из 90-х по-прежнему безупречно работают в последнем Flash player, хотя прошли десятки лет. Наблюдать за тем, как мир пытается перейти на HTML5, когда он явно ещё к этому не готов, было мучительно. (И, честно говоря, всё становится скорее хуже, чем лучше. Я считаю, что браузер никогда больше не станет пригодной для игр платформой, пока владельцы двух самых популярных браузеров имеют собственные магазины приложений для телефонов.) Я создал ремастер частично из-за того, что хотел продать новую игру, но ещё и из искреннего желания сохранить свою часть игровой истории. Спасибо, что вернулись к ней вместе со мной! =========== Источник: habr.com =========== =========== Автор оригинала: Jim Stormdancer ===========Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 15:30
Часовой пояс: UTC + 5