В общем изучаю в последнее время Phaser3
В общем изучаю в последнее время Phaser3 по рабочим задачам. Это пиздец. Да, очередной пост в рубрике «Как Хейзера всё заебало».
За всю свою жизнь я работал со следующим инструментом для разработки игр:
GameMaker 5.3A/6/7/8/8.1/Studo1.4/Studio2
Unity 4
Construct 1/2
Stencyl
Flashdevelop+Flixel
Phaser2/Phaser3
Вот вкратце рцензии о них:
GameMaker — мой фаворит и надёжный друг, пока что меня не подводил. Игры делают просто и быстро. Что в нём хорошо, так то что он только улучшается. То есть попробовав новую версию не хочется возвращаться на старые. Со временем баги активно исправляются и остаётся только новый крутой функционал. В полседние версии даже драгндроп завезли, не так как в юнити, конечно, но всё же.
Unity — в целом нормально, было. В современном юнити я не работал, но вижу как лагают игры на нём сделанные, а потому страшно. В нём очень круто сделаны компоненты — разработка превращается в конструктор, только моделки успевай клепать. Я делал на JS, а C# показался мне перегруженным, когда нужно было все имена классов прописывать. В итоге чтобы просто подвинуть объект порой пишешь строку кода длинной в сотню-другую символов. Ещё знаю что в
нём хорошо расшрияемый разработческий функционал.
Construct — я не видел ни одной нормальной игры на этом движке. Помнится, Konjak начинал делать Iconoclasts (в то время Ivory Springs назывался проект), но, видимо, не выдержав убогости движка перешёл на GameMakerStudio. Когда я сам его пробовал он постоянно вылетал, падал и выглядел очень сложным.
Stencyl — милая вещица когда я пробовал. В некотором смысле экономила время на переиспользуемых блоках кода. Но собирать эти кусочки кода и конструктора довольно утомительно. И после компиляции игра нещадно тормозила.
Здесь следует остановиться и сказать что для себя я уже давно решил что движки делятся на два типа: ООП и хуёвоеООП. Всё что выше этого абзаца — ООП. Инструменты, которые создавались для объектной парадигмы с целью наболее близко приблизить человека к решаемым задачам в терминах объектов их взаимосвязей и их поведениям. И там всё круто сделано — ты создаёшь объект и описываешь его поведение в околочеловеческих понятиях. Ты создаёшь объект и думаешь как объект.
А есть хуёвоеООП, которое соблюдает (и то не до конца) формальные признаки парадигмы, но на практике ни на йоту не сдивгает разработчика к околочеловеческим понятиям, делая процесс разработки как можно более запутанным.
Flashdevelop + Flixel — это такой салат в котором плавает всё — объекты, ассеты, библиотеки и т.д. Мой опыт работы с ним был полон страданий чтобы закрепить эту ебучую иерархию игра->сцена->объекты->хуелионвложенностей. То есть вместо нормального ООП мы получаем какой-то кусок кала в котором нужно точно знать ссылку на родительский объект путешествуя по иерархии вникая во внутреннюю кухню движка, чего по идее быть не должно. Отдельного упоминания заслуживает дырявая документация самого Flixel. Недавно пытался собрать standalone версию игры на ПК. Оказывается адоб окончательно охуела. Флэш же умер как всем известно, но даже в конвусливных остатках нельхя собрать прожектор. Ну тупо опция вылючена. Пришлось собирать в AIR и это, скажу я вам, просто ёбаный пиздец. Начиная с того что ебаный Flashdvelop не может нормально поставить SDK для него и собрать exe-шник, и заканчивая тем что приходится собирать проект из виндовой консоли, что ссаный AIR не прописывает пути в path, и требует создания каких-то непонятных сертификатов для компиляции. Комьюнити хуёвое — вместо того чтобы написать пошаговую инструкцию или манул дать — пишут в своих ускоспециализированных терминах. Документация AIR наполовину из бытх ссылок и не работающих примеров. Успокою читателя — с матами я победил это убожество и собрал EXE_шник в итоге.
Phaser2/Phaser3 — со второй версией я познакомился года полтора назад. В целом примерно то же самое что и Flashdevelop + Flixel только в HTML5. Снова сборная солянка из ресурсов и объектов только теперь на JS, а не AS3. Сейчас как я понял идёт активная разработка Phaser3. Ситуация хуже не придумаешь, когда старая версия скоро станет неактуальной с заброшенной документацией, а для новой версии этой документации толком нет. Это особенно хуёвый пример ООП. Когда я сегодня делал таскание камеры мышкой обнаружил что у input-а есть свойства upTime и downTime, которые фиксируют время нажатия и отпускания. При этом времени которое игрок держит клавишу нажатой нету! А это ведь основая swipe, между прочим! Но мне нужно было что скрывать попап если игрок двигает мышкой более 300ms. Разработчики, видимо, считают что мы должны сами это всё вычислять. Но мне то нужно было не просто upTime-downTime, а в реалтайме. И у этого грёбаного input-а нет никакого функционала чтобы это посчитать! Для этог оприходится лезть в топ иерархии и обращаться к игровому циклу! Это просто пиздец какая инкапсуляция, главное — удобная! Public Morozov называется!
В общем вот такой у меня сегодня coming out, может поможет кому определиться с выбором инструментария.
P.S. Мой совет — видите штуку в которой на каждый объект херачится файл — это хуёвое ООП которое стоит послать подальше чтобы не ебать себе мозг копанием в дивжке а заниматься самой игрой.
- 23 ноября 2018, 19:01
- 09
непонятно как, ведь человек, которому сказали написать браузерную игру, на гамаке её никак не запилит.
Почему? Последний гамак вроде как в HTML5 может.
Тогда чего Хейзер не придёт и не скажет "Буду пилить в Гамаке"?
Не знаю. Может ему хочется превозмогание?
Мобильное рабство: контора\босс\заказчик требуют?
тут не вижу связи
тут обычно можно убедить
разве что
Нубский вопрос. HTML5 на гамаке не работает, или есть подводные камни?
Давно пробовал на GMS 1, шейдеры не работали, а в остальном в html5 без проблем экспортировалось.
Слишком уж кратко, если подводить итог, то у каждого движка есть целый список достоинств и целый список недостатков.
Есть натив через hxcpp же (в том числе, на мобилки). Да, иногда требует немного портирования, если начинали проект на флеш, но зато будет ещё и GPU-ускорение. (если, конечно, речь про flixel на Haxe, а не оригинальный, который умер ещё раньше, чем флеш)
ООП вредно для производительности. Нужно больше data-oriented design :D
Про C# полностью согласен, почему-то в яваскрипте можно отдельно работать с каждой осью вектора, а на шарпе нужно полностью прописывать все оси, если хочешь сдвинуть по одной оси, это раздражает. Я не люблю много символов в коде, для меня идеально как было на бейсике, чем меньше символов, тем лучше.
На яваскрипте сдвинуть объект по одной оси:
transform.position.x += .5;
На сишарпе сдвинуть объект по одной оси:
transform.position = transform.position + new Vector3(0.5f,0,0);
а как я не люблю на юнити sendmessage отправлять на обоих языках, там столько много символов приходится писать(( и почему в коде не заботятся об уменьшении количества символов
SendMessage("NewAwake",null,SendMessageOptions.DontRequireReceiver);
и почему SendMessageOptions.DontRequireReceiver не стоит по дефолту в юнити, чтобы не писать эту муть каждый раз!? мне ещё ни разу не пригодился другой вариант опции
В C# есть extension methods. Это дописывания произвольных методов любому классу.
То есть, можно писать так: transform.ChangePositionX(0.5f); и так SendMessage("NewAwake");
Для этого достаточно написать экстеншн методы ChangePositionX(float x) и SendMessage(string msg). Это просто. Но с одной стороны это лишнее движение, а с другой больше возможностей. В js вы же не допишете свои методы для чисел, а в c# можете.
C# сложнее, но в больших и сложных проектах с ним должно быть проще, я так думаю.
В смысле? JS слаботипизирован, а значит по-умлочанию более гибкий. Можно хоть методы для чего угодно писать, хоть функции анонимные передавать без костылей =)
Да и не нужно в JS ничего дописывать. Там и так всё работает без изваращений.
Я лишь хотел показать, что с должным знанием инструмента (C#) описанная выше проблема с длинными строками не проблема. Защищаю (C#), но против (JS) ничего против, естественно, не имею.
О числах я написал, чтобы показать красоту екстеншн методов.
В (C#) можно написать 14.ValueByPercent(50);
В (JS) так написать нельзя, можно просто юзнуть функцию ValueByPercent(14, 50); что по сути почти то же самое, но немного не то.
И это не костыли и не извращения. Просто типизация сильнее. Что делает код багоустойчивее и проще для понимания.
Или написать всё то же самое в Haxe и компильнуть в JS :D
Ну это какой-то пиздёж. Тот же (14.2323).toFixed(2) отлично работает в JS, например. А кастомные функции к базовым типам на прототипах делаются замечательно.
Ну и допустим и в C#, можно да. Но зачем? Чтобы покрыть какие-то синтаксические косяки C#? То что сильная типизация делает код багоустойчевее и быстрее отлаживаемым - есть такой факт. А про простоту понимания - нет. Тебе выше привели пример, что вместо простой и понятной операции на JS
Ты будешь вынужден писать
Ну или так:
Дописав ещё три функции тем самым умножив сущности. А ведь погрузиться в API, который в большинстве своём использует общепринятые операторы и операнды гораздо проще и быстрее чем в какие-то самопальные. Меня кстати потому и бесило всегда читать документацию к самопальным фреймворкам - флэшу, фликселю и вот к фазеру.
А в это время на JS всё это работает из коробки. Так что всё-таки костыли и извращения... По крайней мере в тех случаях когда язык пытаются применять не по назначению.
ИМХО чем круче язык тем меньше нужно в нём пилить своего. А в .NET дофига библиотек, да и сама платформа задумывалась как кроссплатформенная межязыковая пополняемая библиотека. Но хуй то там как мы видим. Постоянно приходится кучу всяких надстроек надстраивать и костылей костылять да ещё и за версией ебучего фреймворвка следить ведь то что у тебя есть 4.0 вовсе не значит то 3.5 в него входит. Как бы это пиздец, и поэтому я считаю C# заведомо фейловым языком хоть и вынужден с этим мириться хотя бы из-за существования Game Maker Studio, который на нём написан. Так что можно предположить для чего C# подходит неплохо, как в своё время ассемблер =)
C# совсем не как ассемблер. На шарпе пишут много конечных продуктов. И он не может быть заведомо фейловым, потому что он прямо сейчас успешен. Я участвовал в двоих успешных проектах. C# хорош. А JavaScript я плохо знаю, не могу ничего сказать. Скажу только, что выбор языка зависит от конкретной задачи.
Реально удели один вечер на Defold Engine. Там нет ООП, луа прост, ентити замкнуты на себя как компоненты в юнити (они правда добавляются не драг-и-дроп а через add game object file через жопку). очень крутая документация, все гуглится. Очень крутой форум с ответами на вопросы, все гуглится. Очень хороший редактор сцены. Хорошо экспортит под разные платформы, в HTML5 экспорт недавно добавили еще и wasm target. Ты кайфанешь если попробуешь.
Поглядел главную страницу сайта и мне уже не понравилось сходу.
Вот для кого эта хуйня? Что это за фича такая? В том же GMS если речь идёт о быстрых изменениях, то в room editor для объекта я просто цвет напипал и всё. В коде же я просто пишу image_blend = make_color_rgb(255,255,255). Без вот этой вот хуелионуровневой фигни go.set(path,attr,vmath.vector4(...)). Нихуяж в сходу непонятно. В том числе и роль этого vector4. Нужно лезть в документацию и всё это читать. В GMS всё проще гораздо. Код пишется и читается легче.
В общем этот defold вот в этой вот штуке точно такой же как фазер. Вечно пишешь обращения к каким-то левым объектам вместо того чтобы строить логику из внутренностей того что есть.
причем тут flashdevelop?
какая еще документация?
типа тебе лень вычесть x из y? Сначала жалуешься что слишком ооп, потом жалуешься что чего-то не хватает. при том, что именно модульная архитектура движка позволяет держать там в строгой иерархии довольно много разных состояний. Для твоей задачи все данные есть, надо только код написать. Если лень возьми мой
Лол, не поверишь
Весь мир уже кодит на одних DI контейнерах а у тебя все еще бомбит от классов.
Ответный совет - если не хватает ума понять как пользоваться движком надо не писать пост на гамин, а поискать готовые проекты и почитать их код.
Я тебе Godot Engine советую...
Тоже решил попробовать. Давно слышал об этом движке, но я слишком много сил вложил на изучение юнити)
А сегодня просто решил посмотреть на уроки на ютюбе, и на первый взгляд кажется легче юнити, но хз как там дальше пойдёт, пока что попробую посмотреть, что там можно сотворить.
PS +мне всегда казалось что юнити стабильнее Godot, хотя бы потому-что там работает больше команда, не знаю насколько там есть проблема с багами и какие там подводные камни имеются
В годоте баги приходят и уходят, в юнити остаются навеки. :'D
Вроде сейчас юнити развивается в неплохом направлении, но ждать, пока разовьётся, как-то некогда.
Делай, как я - пиши собственный движок. %)
В любой непонятной ситуации
Собственный велосипед. Или нет?