Сегодня узнал в Game Maker о
Сегодня узнал в Game Maker о существовании Variables, которых раньше не было. А я заметил только пару дней назад, а сегодня почитал что это такое.
И ОХУЕЛ
Это ж, блядь, одна из самых гениальных фич второй гамако студии.
Я ждал её лет 6 после того как поработал с юнити.
Собсна фишка как пременные в префабах.
Теперь для объектов можно заводить переменные и указывать их тип.
Приколов несколько:
0) Инициализация ПЕРЕД событием create
1) Они наследуются и их можно переписывать у потомков
2) Их можно перепределять в редакторе комнат в свойстве объектов
3) Удобный UI выбора значения этой переменной в зависмости от её типа
Я уже могу придумать с десяток применений этой фиче.
Например задание начальных значений перемнных прототипам, в частности максимальное ХП противникам. То есть не нужо теперь явно указывать макс ХП в сreate, а в самом create уже можно использовать макс ХП чтобы инициализировать ХП противника.
Или можно задавать ХП противников прямо в комнате чтобы делать усиленных противников.
А ещё можно делать двери и кнопки. Заводишь переменную type и просто ставишь нужное значение, при этом есть тип list в котором можно использовать строки.
А ещё можно для дверей и переходов указывать комнату в которую следует перейти
А ещё можно для противников указывать лут, который они дропнут
А ещё можно указывать название игрового события которое должно произойти для того чтобы объект стал вести себя определённым образом, например конкретный ключ для конкретной двери.
Это при том что я ещё не углубляся в эту механику. Помимо стандартных типов real, int, string и resource есть типы типа expression, color, и у каждого типа есть ещё свои настройки.
Столько гемора с плеч просто.
Теперь мне НЕ нужно всё это менеджить через стандартные события и creation code.
В общем кто юзает Game Maker Studio 2 — имейте в виду эту крутейшую фичу.
- 28 мая 2019, 21:52
- 015
Да ладно? Такой ерунды как "переменные" не было в этом вашем Гамакере?
И почему потом еще говорят "зачем писать на каком-то Си или Си#?".
Вот поэтому я и предпочитаю код полностью писать сам - нет никаких ограничений, к-е придумали разработчики конструктора, и из-за этого ничего не приходится делать через несколько задних отверстий.
Никакого гемора не было, если бы ты юзал полноценный язык программирования, а не скриптовой огрызок с кучей ограничений.
А раньше, как я понял, все это делалось через жопу? Почему нельзя это просто прописать в переменной, организовать списком или ссылками/указателями?
Это не те переменные, которые обычные переменные. Это Переменные. Именно с большой буквы. Вообще на самом деле это параметры.
Можно, это и есть через жопу в моём понимании. Я в редакторе уровня заходил в редактор кода конкретного объекта и там инициализировал нужные переменные. При этом мне нужно было держать в голове названия этих переменных, названия параметров.
А не через жопу - когда в редакторе уровня ты можешь через UI выбором из списка или колор-пикером или ещё каким способом указать нужный параметр. Мне не нужно помнить его название, и варианты его значений. IDE всё делает за меня. В идеале как в юнити - перетаскиванием. Перетаскивание во вторую студию тоже завезли и тоже очень круто стало.
Знатный апдейт, Хейз, спасибо за новость!
Андрюха как всегда ничего не понял, лучше б и не комментировал если не разбираешься. Переменные в ГМе были, а то что Хейзер показал, называется Variable Definitions, а не просто Variables.
На котором игра делается в 10 раз быстрее, а ограничения мешают только визионерам новых жанров, коих в мире, ну, людей 10-20 всего.
Делал пару месяцев проект на гамаке. Скорость сильно падает после второй недели работы когда у тебя 50+ файлов и одновременно надо помнить где какая переменная и какой скрипт что делает.
Для прототипов, джемов и новичков гамак хорош, для всего остального - дело вкуса.
Зачем помнить? Есть поиск по коду и комментарии. Или в каких-то средах разработки это удобней организовано?
Думаю, тут имеется ввиду сама структура IDE и необходимость создавать физический объект новому классу.
в любой иде, даже в простых реакторах типа vscode можно кодить не трогая мышку и не вылазия из одного таба. есть хоткеи для поиска всех ссылок к переменной/функциям, переименования символов во всех местах сразу, настраиваемые сниппеты, удобная строка открытия класса по аббревиатуре и прочие ништяки без которых навигация по коду существенно замедляется.
в гамаке это делается либо платными аддонами либо через подключение внешнего редактора, но я так и не нашел как это нормально сделать. а между тем это такой же фактор скорости разработки как и отсутствие необходимости писать какие-то вещи которые в гамаке есть из коробки.
Я сказал "делается игра", а не "пишется код". Код - всего лишь средство реализации игры, а надобность "помнить где какая переменная и какой скрипт что делает" это признак переусложнённой (слишком сильно связанной) архитектуры, тобой придуманной.
Сниппеты были в ГМе давно, я их не использовал никогда, потому что не нужны. "Поиска всех ссылок к переменной/функциям" - поиск по CTRL+SHIFT+F, но нужен он редко - тогда, когда сам напортачил изначально. От IDE правильный подход к написанию программы никак не зависит.
"переименования символов во всех местах сразу" - в том же CTRL+SHIFT+F есть Replace All. Переименовал лишнего? Значит плохо придумал названия, недостаточно уникально.
Этого честно говоря не понял.
Ну в общем не получится диалога о нормальных иде с человеком который ими не разу не пользовался
Зачем мне говорить о твоих IDE? Я программировал на C# ещё с 2007 года, но кодинг это не разработка игры. Так что диалога не получится, да, но не по указанной тобой причине, а потому что ты сводишь геймдев к кодингу. На деле он им не является даже наполовину.
Ты опять ушел в свою в демагогию которой прикрываешься каждый раз когда речь заходит о программировании. Но предыдущим ответом ты показал что опыта кодинга у тебя на самом деле нет, либо он очень поверхностный (иначе ты бы не стал сравнивать Replace All с Rename Symbol, знал бы про class search и не писал бы хрень про рефакторинг).
Предлагаю тебе для повышения качества своего троллинга и расширения кругозора вылезти из своей конуры и посмотреть что нового за последние 15 лет появилось в геймдеве.
Это говорит человек, который юзает Фазер3, этож просто пиздец в кубе.
Как бы меня скил разработки игры далеко не нулевой и каждый может в этом легко убедиться. Но фазер оказался просто за гранью моего понимания.
Не знаю как для тебя но для меня есть разница работы в контектсе "1 объект = одна сущность" или "1 объект = три миллона классов, гексалион интерфейсов, хуелиард параметров".
При количестве сущностей более 10 у меня уже едет крыша от всего этого.
Мне так же не нравится эта ебанутая иерархическая архитектура "в комнате контроллер, в котором группа, в которой объект, в котором спрайт, в котором текст и т.д." Там же концы с концами не сведёшь, и в лучшем случае ты сможешь доступаться до свойств через индексацию, в худшем - тебя поимеют через глобалы, причём в языке где все типы являются ссылочными. "Добро пожаловать на расстрел ноги!"
Может быть там и есть какая-то мифическая супер-производтиельность если ты с рождения булеву алгебру изучал... Но для простых людей которые просто хотят игру сделать - нахер это надо?
Лол. Вторая страница в выдаче яндекса - твой пост.
Хрензерг прямо вклад в сообщество сделал.
Ну так и надо говорить - "я делаю игры на гамаке потому что в других движках мне лень разбираться", а не притягивать за уши какие-то сомнительные аргументы об универсальности гамака и как он чудесно скейлится для любых игр.
Фазер - типичная обертка над gl-движками, такие api еще во времена sfml делали. Если посидеть с ним неделю все становится прозрачно. С гамака я тоже плевался, но пересилил себя и разобрался что к чему. Посмотрел своими глазами на все его минусы и сделал взвешенный вывод, что в сравнении с другими движками он выигрывает только в очень ограниченном круге задач.
Я не топлю за какой-то определенный движок, но когда черное называют белым меня начинает триггерить
Лол, Хейзер пробовал больше игровых движков чем вообще ЛЮБОЙ разраб-гаминец. Хотите посчитаем?
Гамак скейлится только на 2D-игры, скажем честно. В остальном - даже не знаю чем его ограничить.
А толку считать, если для тебя попробовать движок - это посмотреть на апи, ничего не понять и написать пост о том какой плохой движок.
Ты когда-нибудь открывал чужой проект на гамаке и пробовал там разобраться?
Да.
Исходник Spelunky написан катастрофически отвратительно, я словил десяток баттхёртов при взгляде на ЛЮБОЙ из объектов. Связано это с тем что Дерек Ю художник-спрайтер и кодил этот проет как мудак как умел.
Исходник Iji, который я многократно дата-майнил и реверс-инженерил для того чтобы помочь людям русский перевод игры, написан более-менее вменяемо. Я думаю, я мог бы сделать мод этой игры с лёгкостью, если бы задался такой целью.
Исходник свободного Mega Engine, пожалуй, написан лучше всего что я видел.
Исходник Princess Remedy где-то рядом, неплох.
Но зачем они мне, если я всё себе пишу сам и этим доволен?
А говна на лопате?
1) Попробовать сделать механику.
2) Увидеть кучу кривизны и недостатков в своей реализации.
3) Понять места проёбов и поспрашивать у профи как правльно этим пользоваться - получить в ответ несколько библиотек или тонну кода, который может и более правльный но его больше и он сложнее.
4) Посправшивать как оптимизировать те или иные функции и получит в ответ "никак"
В своё время закончил знакомство с Java после работы с коллекциями. Хотел итератор перегрузить чтобы работать как с массивом. На вопрос как перегружать итератор, от разработчиков Java получил оффициальный ответ "никак, мы решили что программистам java не нужен этот функционал"
У меня в C# есть перегрузка итератора, а в Java - нет. Смешно, правда?
Примерно в такого рода разочарования я упираюсь когда изучаю другие движки. Я хочу сделать удобнее чем в Гамаке, например, но нужный функцинал там попросту отсуствует или реализуется ОЧЕНЬ сложно. И это вдвойне смешно учитывая как я часто слышу от программистов "могу настроить под себя". А я вот не могу практически. Сложно это.
Мне осталось жить максимум лет 50-60 и я не хочу тратить даже часть этого времени чтобы заставить что-то работать как мне удобно, когда под рукой уже есть то что работает удобно и оптимизирует мою работу в 10-20-30-40-50 раз быстрее.
Треть из этого - сон.
Я просто не вижу смысл делать 50-60 лет одинаковые игры на гамаке, в которые играет из вежливости 10 человек. Но если тебе это по фану, то крепкого тебе здоровья и успехов
И это мне говорит чувак, который сам делает одинаковые игры =)
>>Мне осталось жить максимум лет 50-60
Хейзеру 5-10 лет? о_0
Сингулярность - бессмертие
(о, привет, Разери)
Я делаю игры на гамаке потому что начиная разбираться в движках я увидел что объективно потрачу на 1000% больше времени на код чем то же самое на GMS. Или потрачу ещё несколько лет чтобы знать движок настолько чтобы уметь в нём писать с полпинка =) А за это время я мог издать с десяток игр.
Зачем мне это, если я делаю игру, а не занимаюсь код-инженерингом?
Ясное дело в гамаке есть свои проёбы. Нельзя свои дата-структуры делать, например, да и сами дата-структуры так себе. Или классы с кастомными событиями, новые типы событий добавлять нельзя. Но я каждый раз спрашиваю себя "А зачем мне это? Как это мгло бы ускорить разработку?"
Вот есть в php ассоциативыне массивы - супер гибкие мне прям нравятся, против убогого подобия массивов гамака и его словарей. В javascript есть анонимные функции и замыкания. А в гамаке есть скрипты - которые О УЖАС не привязаны к объектам и живут в сферическом ваккуме.
Но зачем мне именно такой функционал при разработке игры я представить себе не могу, например. Зачем мне в гамаке функцию в качестве аргумента уметь передавать? Да хер его знает. В JS это дешёвый способ обработчик событий сделать - типичная бытовуха, а в гамаке... Там эти куски кода и есть анонимные функции и вроде как уже и не нужен такой функционал, т.к. он зашит в саму IDE.
Они решают одну и ту же задачу, только то что есть в ГМе потребует от тебя чуть больше ручной работы по отсеиванию левых результатов (в которых ты сам же и будешь виноват - надо было называть переменные понятно и достаточно по-разному). Вместо того чтобы иметь претензии к инструменту, надо выполнять поставленные задачи.
Ничего из того что ты перечислил, не имеет отношения к геймдеву, а имеет отношение только к перекладыванию с места на место кода, названий и классов.
Ну да, куда уж мне до тебя! :yak:
https://kolenka.net/blog/procedural_generation/tekx-chto-pod-kapotom.html
https://kolenka.net/blog/procedural_generation/audio-spektralnyj-printer.html
https://kolenka.net/blog/gamemaker/gm-xd-gms-xd-alternativnyj-debagger-dlya-game-maker-81-studio.html
Изменение кода - такая же естественная часть процесса разработки как и его первоначальное написание. Если ты не меняешь свой код, то тебе вообще пофиг на чем писать. Строчи игру сверху вниз и радуйся.
Ты код покажи то. Выглядит как что-то такое, что студенты на лабах пишут в старых советских редакторах.
Ты говорил об опыте кодинга, а не о соответствии чьим-то там стандартам, "хорошим практикам", паттернам программирования, методологиям разработки ПО, и прочей корпоративной шелухе. Хочешь видеть код - посмотри его ILSpy'ем. Мне неинтересно тебя в чём-либо убеждать, так как от твоих убеждений ничего не зависит, тогда как мои программы работают, пишутся они быстро, и иногда это даже игры, но - никому не посоветую пытаться делать игру на C#, C++, Java, AS или чём-либо подобном. Я переписываю части кода регулярно, а вот переименования символов по ВСЕМУ проекту и глобальный рефакторинг целых иерархий классов - это то что нужно нормальному кодеру чуть чаще чем никогда.
То что ты скинул попадает под категорию поверхностного кодинга, как я и предполагал. Не написав ни одного проекта больше 10к строк ты рассуждаешь о разработке игр как будто знаешь как все в этой области устроено. Если не хочешь мне что-то доказывать зачем тогда каждый раз начинать этот бред про скорость разработки?
Для того чтобы зелёные новички не велись на твою ахинею про какую-то мифическую связь между 999к строк кода и компетентностью в геймдеве. Исходник Castle of no Escape 2 умещается в 100КБ, и я понятия не имею сколько это строк, потому что мне это не нужно. Если "поверхностный кодинг" позволяет делать подобные игры, то какая разница, поверхностный он или нет, если игра - вот она, работает, продаётся, что ещё надо-то, лол.
квадратная игра 256x256 - прекрасное доказательство масштабируемости движка
А какую игру надо сделать, треугольную?
Я могу сделать клон любого твоего прототипа, за выходные. А ты моего, на своём инструментарии - скажем, далеко не факт.
если твой потолок - делать клоны, так тому и быть. для меня разработка - это прощупывание механик и постоянное улучшение прототипа путем проб и ошибок.
если мне, прости Господи, понадобиться в короткие сроки сделать типовой тайловый рогалик или платформер, я всерьез рассмотрю гамак как инструмент.
А кто говорил о потолке? Клоны это как семечки щёлкать. Ну в общем, понятно. Щупай там, удачи.
Ты меня всю дорогу на словах ловишь вместо того чтобы по делу отвечать. Скользкий ты парень.
это я вообще в цитатник сохраню
Лол, сам рисует какие-то потолки из воздуха, а потом приписывает их мне.
По делу я уже сказал - Гамак прототипирует в разы быстрее любую двухмерную игру, чем любой современный игровой движок.
Ты приводишь в пример клоны игр на геймбой и бросаешься такими высказываниями. Что их пототипировать - бери и делай. Ты спрототипируй мне что-то RTS-подобное с кучей механик и не тайловыми коллизиями
Этот "клон игры на геймбой" - дебютный самофинансированный инди-проект моей команды. Приводился он, напомню, в контексте того что я понятия не имею сколько там строк кода, а соответственно это знание не имеет никакого значения для геймдева.
Ты имел в виду Технокочевников?
Стоп. Я кажется понял. Ты отталкиваешься от стоимости разработки, поэтому используешь движок который может освоить в короткие сроки любой новичек, которому не надо платить. Поэтому так яростно рекламируешь гамак.
Я прав?
Допустим, только учти что там много технических примочек, которые закладывались с расчетом на мультиплеерную игру в открытом мире.
Нет, не прав. Гамак стоит $100, и он не настолько прост, чтобы прям новичок его освоил быстро. Я пытался обучать людей, к этому нужно то что я назвал бы "чувством игры". Кодеры осваивают Гамак, но толку от них потом почти никакого.
Хотя если говорить о быстрых грязных методах разработки, то любую IDE можно просто пиратить. Но зачем создавать себе сомнительный юридический фундамент?
Так а мне-то что с этого? Ну, как я это в игре увижу, или зачем мне прогать это заранее?
Я к тому, что кочевники это вымученный прототип и разработка шла не линейно, было 6-7 итераций геймплея и осталось куча невидного в игре функционала. 6-7 циклов написания кода, плейтеста и переделывания за 3 недели. Там каждая строчка кода минимум трижды менялась. Пили я это на гамаке мне пришлось бы выбрасывать все в помойку каждый раз когда я хотел бы внести масштабное изменение в прототип, потому что средствами гамака это сделать нереально.
Ну, имитировать весь путь создания Технокочевников я точно не буду. Такое количество переписываний означает что геймдизайн очень много менялся где-то в процессе, но важно в итоге только то, чем стала игра в конце. Так что клонировать легче чем строить с нуля, но в исходном утверждении я говорил именно о клонировании результатов, а не всего прототипирования.
Было бы круто если б я пример такого услышал. Ну просто для интереса.
Посчитай сколько раз ты написал про клонирование и сделай выводы
Видимо, вывод должен заключаться в том что "Гамак годится только для клонирования квадратных геймбоевских игр, а также игр без интерфейса, не похожих на РТС и без кучи механик"? О горе мне!
Раз ты перешел на сарказм, я так понимаю доводы кончились.
Да нет, скорее подходит к концу моя вера в диалог.
Клонирование было упомянуто как критерий ёмкости и удобства движка. Читай, "на всех других движках даже просто клонировать уже готовую игру будет дольше и сложнее, чем на Гамаке".
То есть ты так наивно полагаешь что на гамаке нельзя сделать мультиплеер?
Учитывая, что его делали ещё в далёком 2009-ом на седьмой версии XD
Ну назови хоть одну механику которую будет сделать удобнее и быстрее на твоём инструментарии чем на гамаке =)
Что угодно с интерфейсом?
Это означает что на твоём инструментарии есть набор для создания GUI? Но он предварительно написан, и не является частью IDE. Можно написать точно такой же свой и его использовать. Я когда-то написал свой такой.
https://www.dropbox.com/s/lf7xl4das1vfsi8/GM%20GUI%201.0.exe?dl=0
То есть лишнее программирование в играх не приветствуется, но есть когда для гамака надо писать костыли - это простительно
"Ой смотрите, у моего движка готовые фигурки в коробочке, а у вашего нет, хаха!"
Мы не о том спорили. "Что угодно с интерфейсом" это не механика, это наличие интерфейса. И если тебе удобно делать именно интерфейс в твоём движке, а в Гамаке неудобно, это с точки зрения геймдева/дизайна ничего не значит.
Как же ты любишь увиливать. Я, как программист, задал хайзеру, как программисту, в посте про программирование на GML конкретный вопрос про программирование на GML. Какого лешего ты влез со своей демагогией о том что нужно в движке а что нет? На кой хрен ты пытаешься строить из себя какого-то авторитета? Зачем в каждом втором коменте подлизывать хайзеру? Это все не так забавно как ты думаешь.
Я понял твой подход к клонированию разработке, можешь остаться при своем мнении и клепать свои коммерческие проекты до старости. На своих фанатах и самоутверждайся, я не из их числа.
У меня есть фанаты? Фанаты есть только у игр что я издаю, а сам я не знаменитость и мне это не интересно. Авторитета начал из себя строить не я, а ты со своими "если хочешь вырасти, расскажу тебе как это сделать"; я лишь пытался понять из твоих ответов, что такого у тебя есть, чтоб у тебя чему-то учиться.
Не в нём дело, а в том, что наше с ним мнение совпадает на 99%, так как оба из нас пробовали разные движки, и оба из нас остановились на ГМе.
То есть чтобы твой движок стал уметь из 2Д игры 3Д игру или из платформера стратегию - достаточно щелчка твоих пальцев?
А я думал что в ваших этих копрорациях учат не так, а что изменение кода - это затратная операция, которая стоит человекочасы, и что обычно сперва производится анализ и WBS, проектирование архитектуры а потом пишется код. Ты ведь лид? Если каждый твой джун постоянно меняет код - это ведь проёб бюджета проекта =)
Да и паттерны разве придумывали для того чтобы код менять? Хороший программист берёт и пишет код сверху вниз, да =)
Не знаю как в твоей компании, а в моей когда код меняется - на такого программиста очень косо смотрят...
Каких файлов? Если ты про дерево ресрусов, то группировать же их можно.
А в "нормальных IDE" не нужно? Мне кажется, что там этот микроконтроль контекста возведён в абсолют =)
Мало того что у тебя на один объект приходится довольно много обслуживающего кода так ведь и сам объект как правило - длиннющая портянка классов. А если следовать правилам "хорошего ООП программирования" то эта порятнка должна рефакториться на более мелкие файлики. В итоге на один объект у тебя выйдет довольно много файликов. По сути то же самое что и в GMS, только в GMS это удобно собрано в UI IDE, а не набором текстовиков, раскиданных по папкам.
А я наоборот не рискну делать масштабный проект на чём-то типа фазера =)
Сгруппировал, и что дальше? Все так же гулять по иерархии когда мне нужно от одного объекта перейти к другому и обратно.
В нормальных IDE у меня вообще нет контекста. Я в паре нажатий клавиш от любого места в коде, а нужный хоткей мне покажет все что нужно знать о том где я, даже если я с бодуна сажусь кодить проект который полгода не трогал.
Фазер явно нанес глубокую травму твоему эго
А зачем тебе область в центре экрана. Открыл сколько нужно объектов и гуляшь между ними. Хоткеи в GMS2 у уверен что есть.
Ну это из серии "Смотрите, я а я могу ездить на роликах по канату с завязанными глазами, со слоном на плече!".
Но ведь тебе нужно ЗНАТЬ что нажимать чтобы оказаться в нужном месте кода - то есть ты уже должен держать в голове контекст своей программы где и что у тебя расположено, иначе ты выунжден погружаться в этот контекст и тратить время которые ты пытаешься сэкономить.
Вот я открыл в GMS два объекта параллельно и могу работать с ними:
И вместо порятнки кода JSON-style я имею user-friendly интерфейс, в котором все события классифицированы и имеют свою уникальную мконку, а между событиями я переключаюсь табами, а не поиском по всему проекту. Автокомплит подскзывает мне нужные функции/переменные/ассеты.
И уже который раз мне "тру разработчики программисты" заясняют что иметь порятнку кода на три километра - это круто и в ней пиздец как удобно ориентироваться нажатием пары клавиш и выбором из контекстного меню.
Но я лично не представляю как можно ориентироваться в 50+ таких портянок как ты говорил выше =)
Я могу сам создать себе контекст из нужных ресурсов.
Делаю босса - открыл только то что относится к боссу. Делаю врагов - то что к врагам. Делаю логику игрока - открываю только это. Закончил - закрыл, открыл новое.
На скрине выше контекст настройки объектов и логики. Когда я работаю с графикой, уровнями, звуками - я нахожусь в другом контексте. IDE даёт мне много инструментов, чтобы я мог организовать этот контекст как мне удобно, и дажее более - я могу себе таких рабочих областей сделать сколько угодно и переключаться между ними щелчком мыши без комбинаций клавиш. Уже посмотрев на этот конекст я с бодуна точно так же могу сразу начать работать с проектом.
И да, т.к. GMS предоставляет скриптовый язык, то именно "писать когда" нужно значитально меньше если ты работаешь с обычными ЯП на фреймворках. Тебе приходится преодолевать больше рутины, а порой погружаться внутрь конекста фреймоворка. То есть ты кода напишешь больше, напишешь его быстрее, но насколько он будет качественный и выразительный? На собственном опыте могу сказать что одну и ту же функцию на GMS и Phaser угадай где быстрее и проще реализовать?
Итого в нормальных IDE чтобы завести работоспособный проект мне нужно иметь довольно файлов, в то время как в GMS пара спрайтов, пара объектов и комната.
Ну просто чисто объективно если на одну сущность
1) В фреймворках на нормальных IDE приходится несколько классов и даже интерфейсов
2) В кривых конструкторах я на одну сущность имею одну сущность
И как может быть с ростом проекта проще менеджить сущности если с ростом проекту в "нормальных IDE" рост сущностей будет в прогрессии, в то время как в "кривых конструкторах" он практически линейный?
Твои скриншоты мне сложно даже смотреть на моем маленьком макбуке, на котором я даже на юнити умудрялся нормально делать игру (потому что там подключается сторонний редактор кода).
Эти "сущности" ограничивают тебя больше чем ты можешь себе представить. Любой ооп движок позволяет тебе сделать объекты настолько модульными насколько это тебе нужно и жонглировать ими, собирая как из кусочков конструктора игру. Только этот конструктор сделал ты сам усилием своего мозга и знаешь досконально как он устроен, можешь менять как хочешь и делать с игрой все что душе угодно. Звучит абстрактно, но на примеры у меня времени нет - гаминатор все-таки идет. Может потом распишу если тебе интересен какой-то рост.
Рост... до чего? Сколько тысяч людей твоя фан-база или хотя бы просто овнеры твоих игр? Сколько ты заработал? Куда предполагается расти-то?
Ты достал свой последний аргумент? Немного нечестно меряться аудиториями наших игр потому что я несколько лет работал тимлидом в геймдев конторе и писал игры на миллионы игроков. Кодить большие вещи я умею, поверь.
Твоя работа тимлидом в конторе не имеет отношения к нашему контексту инди-разработок. Сам-то ты умеешь только кодить, а Гамак отталкиваешь по чисто корпоративным причинам - по его использованию слишком мало протоптанных тропинок, которые можно просто выдать своим подчинённым-кодерам и потом их локтями толкать "а чё эт ты там не прошарил материал?".
Больше кода или архитектура - не значит лучше. Надо геймдизайнить интересно, а не кодить много.
Но, чтобы завернуть начатую тему, рост до экс-тимлида геймдев конторы это для инди-разработчика и автономного автора не рост. Кроме как если контору основал ты сам.
ну допустим. ты сам свел спор о разработке к мерянью игроками а теперь сдал назад и мой опыт работы в продакшене оказывается не релевантен для инди. несколько лицемерно, не находишь?
Я не сдавал назад, это ты вместо чтобы нормально перетереть один на один, притащил в обсуждение каких-то левых людей, чисто как гопота на раёне. Короля играет свита, и лично ты, в отрыве от своей инфраструктуры, которую ты почему-то считаешь дефолтной, мало что можешь сделать.
И мой долг, как представителя автономных авторов видеоигр - развенчать эту установку, что инфраструктура вообще должна быть. Что код должен измеряться тысячами, а рефакторинг нужен абсолютно всем и каждую секунду. И прочее. Я бы ещё пообщался, но на этой глубине вложенности комментариев нас уже никто не слушает - "В интернете кто-то неправ", и ладно.
Мой изначальный тезис казался гибкости Гамака, которую вы с хайзером считаете безграничной. На мои доводы что кодить на нем большие проекты не удобно ты отвечаешь мол зачем большие если можно делать мелкие и радоваться прибылям.
Вопрос - в какой момент мы перешли к обсуждению строк кода?
Что такое "большой проект"? Где заканчивается маленький и начинается большой? Вот конкретно игры назови.
Строки кода обсуждаются не в этой ветке. Где-то в тот момент:
То есть мне опять за тебя логическую цепочку строить? Ну хорошо:
c: в гамаке нет средств рефакторинга и это мешает
x: рефакторинг не нужен
c: ты не делал проекты в которых он нужен
x: вот смотри что я делал
c: выглядит как лабы
x: ты не говорил что надо не лабы
с: не лабы начинаются от 10к строк
x: СЧИТАЕШЬ СТРОКИ ФУУУ
поправь если я не прав, но помойму ты слился
ЛОЛ. В гамаке нечего рефакторить потому что устроен оптимальным для разработчика образом XD
рефакторинг нужен для изменения своего кода. но я уже понял что свой ты сразу отливаешь в граните
Починил:
c: в гамаке нет средств рефакторинга и это мешает
x: рефакторинг прекрасно делается руками, и нужно это очень редко
c: опыта кодинга у тебя на самом деле нет
x: вот смотри что я делал
c: выглядит как лабы
x: это не важно
с: не лабы начинаются от 10к строк
x: мы вам перезвоним
Да, если бы это был приём на работу, то я слился тебя принимать, это точно.
Что такое "большой проект"?
что-то с несколькими механиками и интерефейсом.
salt and sanctuary, mad world, незнаю что там еще из свежего
А что такое гибкость?
Гамак не всё может но 90% типовых задач он точно охватывает и справляется с ними быстрее чем аналогичный тру-программинг-инструментарий.
Заебал уже абстракциями манипулировать.
Не матерись.
Гибкость = модульность. Я могу сделать набор поведений и навешивать их на любые обьекты без костылей.
Могу в любом месте кода собрать любую сущность и передать ее в любое место. Это позволяет мне без костылей вытаскивать какие-то вещи в отдельные классы с логикой и менять их одновременно везде где мне надо.
В Гамаке можно создать скрипт и вызвать его из любого объекта, главное быть уверенным что все переменные с которыми скрипт работает, в объекте существуют. Для того чтобы прям гарантировать что они существуют, можно добавить скрипт их инициализации в конструктор объекта. По сравнению с множественным наследованием, имплементациями интерфейсов и прочей утиной типизацией, это абсолютно не костыли, и полная свобода применения любых алгоритмов к любым объектам.
Также можно вызывать события одних объектов от имени других, то есть выполнять код другого объекта с другим поведением, будучи в окружении своих переменных, и таким образом выполнять поведение другого объекта, не наследуя его, не имплементируя его интерфейсы и даже не используя скрипты.
Учитывая что на скрипты и события можно ссылаться переменными, то мы получаем, что объекты могут менять динамически своё поведение в реалтайме.
Вплоть до того что можно новые объекты с новым кодом создавать на лету. На Гамаке можно сделать игру, которая генерирует сама себя...
...Так было в 2011 году в GM8.1, пока не пришла Студия, и сделать это стало невозможно. Но сам факт. Сказанное относится только к четвёртому абзацу про новые объекты на лету. Всё остальное реально в любых Гамаках.
Это и есть без костылей. Написал код в скрипт, назвал скрипт, имя скрипта написал в код объекта - всё, вот тебе поведение. Написал 5 скриптов для 5 поведений - комбинируй их в любом порядке в любых объектах.
Вот в том то и слабая сторона что ты должен ВСЕГДА знать как он устроен , т.е. быть в его контексте. Поэтому все твои слова
Просто откровенный пиздёж =)
И весь прикол в том, что в Game Maker у меня ни разу не возникло мысли что-то менять, при том что я всегда делал со своей игрой что моей душе угодно =) Всё гениальное просто, а в простом не нужно ничего менять.
Если в твоём конструкторе нужно что-то менять значит усилие твоего мозга было слабым и несовершенным. Я признаю этот факт, поэтому задачу проектирования конструктора для игр оставляю сверхразумам. А я лишь жалкий человечек пользуюсь плодами чужого интеллектуального труда отабшляв пару сотен баксво, такие дела, да =)
Извини, но именно поэтому все твои игры и выглядят сделанными под копирку. Если тебя это устраивает, мне очень жаль
Не поэтому. Есть ещё такой фактор как вкусы автора, и жанровая инертность, не зависящая от IDE никак. Может, неинтересно ему делать RTS, файтинг, и ещё сто разных жанров. Особенно по поводу слова "выглядят" - это речь о графике. ИГРАЮТСЯ его игры по-разному, и глупо судить об играх по скриншотам.
то есть ты не видишь причинно-следственной связи между жанровой инертностью и нежеланием выходить за рамки движка?
Нельзя найти чёрную кошку в тёмной комнате, особенно если её там нет. У Гамака нет таких рамок, которые сковывали бы Хейзера, просто он за них не выходит потому что так привык и это его выбор.
Вы и так тут двое на одного, может хоть отвечать друг за друга не будете
Так приводи друзей, пускай будет два на два, чё. Только таких, которые пробовали Гамак, а то будет глупый религиозный шабаш, а не обсуждение.
У нас и так религиозный шабаш, потому что из нас только я нормально работал со обсуждаемыми движками и на себе прочувствовал плюсы и минусы обоих.
Мой карманный прочувствометр не подтверждает этой информации.
Ну как бы... Я задал вопрос про навигацию в большом количестве скриптов и мне ответили тем, что как я плохой кодер и если бы делал правильно то все было бы в одном файле.
Я имел в виду утверждение "только я нормально работал со обсуждаемыми движками". Может, не только ты? Как знать-то.
Ну судя по тому что ты пишешь, с GameMaker-ом ты работал точно так же как я с фазером. Недолго и невсерьёз.
Давай обменяемся сделанными проектами и посмотрим?
Я не вижу никакой следственной связи между жанрами и движками. Погугли игры сделанные на Game Maker И удивись.
А за эти слова хочешь поотвечать?
Хотя бы ответь чего общего у Sig.NULL и ATTWN, например. А у Heavy Memories и Tower Bombarde? Или может ты хочешь поискать чем похожи Zzzz-Zzzz-Zzzz и Danger!Energy?
Я люблю платформеры и метроидвании. Поэтому делаю в оснвоном их, но это не значит, что другое не могу.
Ну и смшено такие упрёки слышать от человека чьи проекты визуально похожи друг на друга ещё больше чем мои XD
Покажи мне два похожих чтоли
Только после того как ты найдёшь пару одинаковых у меня =)
ну у тебя есть белые платформеры, кислотные топ-даун пазлы и 3д бродилки
Не только фазер. Я и AS пробовал и Flixel и Phaser2 и Phaser3. Это всё одна залупа. У них у всех очень схожая архитектура, но всё равно каждый раз приходится лезть внутрь движка чтобы разбираться в этом всём.
Я часто слышу "Я могу настраивать как мне нужно". Ну вот ты можешь прям взять из коробки и построить на Фазере игру? Не погружаясь в устройство этого движка. Я вот не смог. Я пытаюсь юзать сущности из коробки и оказывается что они не умеют элементарных нужных мне вещей. И мне приходится вертеть жопой чтобы понять как где чё устроено, какой класс какие объекты в себе содержит, а те в свою очередь свои объекты.
Хочу цвет задать. Вместо того чтобы просто задать цвет мне порой нужно создать новый супер-навороченный объект с цветом, в котором хуелиард функций на все случаи жизни, он даже за хлебом наверное может сходить если чо. А мне нужно было просто RGB-цвет задать. Мазафака. А потом оказывается что у него есть куча разных конструкторов и самый простой мне не подходит потому что он не совместим каким-нибудь альфа-какналом, и мне нужно юзать сложный - лезть в доки и разбираться почему у меня нихуя не работает и как мне что нужно настроить. Напомню - я просто хотел задать цвет. Задать ширину линии, нарисовать линию, работа с примитивными функциями оборачивается гемором.
Вот есть у меня объект и я хочу поменять ему цвет спрайта. Что я должен сделать? Сперва взять спрайт, потом и уже через спрайт поменять ему цвет. И так какждый раз. Или пиши функции-обёртки, которые позволят напрямую это делать и будут по-дибильному называться. И когда я вижу что-то такое
object.sprite[0].imageProperties.colorOverlay=COLOR_OVERLAYS.regular.red.light
Ну это меня в уныние просто вгоняет. Мне это не нравится и я хочу это развидеть, можно?
И мне программисты сразу орут хором МОЖНО, КОНЕЧНО МОЖНО! ВСЁ ЖЕ ПРОСТО!
НАПИШИ ФУНКЦИЮ.
Вот она:
function setColor(color) {
object.sprite[0].imageProperties.colorOverlay=COLOR_OVERLAYS.regular.red.light
}
А потом вызвать её:
object.setColor(COLOR_OVERLAYS.regular.red.light)
И в чём смысл этих "упрощений"? Я всё равно пишу то же самое да ещё и сущность новую создаю, которую теперь должен держать в голове. Ну да, где-то в списке я потом увижу метод setColor, но что он делает, какие параметры принимает?
А что мне нравится? Мне нравится вот так писать:
image_blend=c_red
Просто и понятно из самих названий.
Я вынужден погружаться в супер-проектирование для задачи в которой можно было бы без этого обойтись если бы я не был настолько рабом ЯП и фреймворка на котором вынужден писать.
Так вот типа если ты там наследуешься то вот там теперь тебе нужно вот это прописать, а т.к. ты ещё и интерфейс реализуешь - нахуярь десяток пустых местодов пожалуйста, которые тебе ваще не обосрались, но блядь должен их написать потому что СИНТАКСИС такой. А всего лишь хотел немного расширить функционал того что мне предлагают из коробки.
Если я класс хочу свой создать отнаследовавшись - ну ОК, только перед этим создать несколько методов пустых или с super. Ну просто потому что. ОК, мне не сложно, играю по правилам. Но для того чтобы расиширит функционал класса на одну функцию я уже пишу минимум две =) Зачем это нужно? Это ведь лишний мусор, который отвлекает от чтения кода.
Какой смысл в этих фреймворках если я кажды раз вынужден ковырять внутренню архитектру? Ведь не должен! Ведь фреймворк на то и фреймворк что сделал всё за меня. Это же типа набор готовых методов! Но чтобы их расширить нужно пройти девять кругов Ада.
Я по работе делал на Фазере дерево навыков. Это был пиздец. То что я сделал бы на GMS за час, я делал часов 80, наверное. А при повторе это заняло бы у меня часов 16 минимум. Всё работает через жопу не как задумано, документация хуёвая, примеры хуёвые и не работают. В итоге три часа ищешь как сделать элементарную функцию. Даже партиклы эти ебаные сделаны блядь через какой-то анус. Во всех нормальтных движках партиклы как партиклы, а здесь блядь какая-то супер-логика. Чтобы задать область генерации я должен создать объект и передать его как параметр. А я думал что я просто из списка могу выбрать. ХУЙ! А как настроить количество партиклов - да ваще херпроссыш. И так во всём.
Вот примерно такое я испытываю когда волею судьбы сталвикаюсь с говнодвижками и "нормальными IDE"
Раскрою немного контекста и своих бурных эмоций по этому вопросу.
Ведь самое смешное в этой истории то что в своё время - лет 5-6 я писал в саппорт YoYo-games чтобы они прикрутили такой функционал. Дело было ещё до GMS2, поэтому мне тогда сказали "Нууууу, это нужно движок переписывать, так что МОЖЕТ БЫТЬ КОГДА НИБУДЬ".
Я тогда горестно вздохнул и стал мириться с тем положением дел, которое имел, т.к. надежд на светлое будущее у меня не осталось. А с выходом GMS2 я узнаю, что они завезли dragndrop на ресурсы. Уже этому факту я был счастлив и думал что на больше они не способны.
И вот вчера я узнаю что моё предложение ТАКИ было реализовано =)
Что ты имеешь в виду? Импорт ассетов при перетаскивании в проект был ещё в ГМС1. А может даже в ГМ8.1...
Что можно спрайт мышкой перетаскивать из дерева ресурсов в то место где в окошке объекта нарисован спрайт.
Хм... Никогда не думал что это может быть полезно. Вот если бы можно было спрайт прям в КОД перетаскивать и там появлялось sprite_index=спрайт...
Не только туда. В переменные эти из сабжа тоже можно, перетаскивать если тип переменной Resource =)
И в комнату можно таскать напрямую из дерева ресурсов.
А в код смысла нет, быстрее автокомплитом это делать чем таскать ресурсы. Когда я работаю с кодом - меня только код интересует в текстовом виде. Когда я работаю с логикой и визуалом - меня интересует именно логи и визуал. В Game Maker Studio 2 отлично разделены эти аспекты разработки и IDE вполне удовлетворяет лично меня по всем этим аспектам.
Очень удобно, я раньше экземплярам (дверям и противникам) особые условия в create через редактор уровня прописывал. (GM1)
А в чем фишка "ПЕРЕД событием create"?
В том, что уже в Create ты можешь задать свойства объекта основываясь на заранее заданной переменной. Допустим, у тебя мальчик, девочка и эльф: раньше нужно было делать три разных объекта, а теперь можешь тупо создать переменную пола и юзать ее из редактора, а Create уже подсосет спрайт с нужной прической.
Не пользуюсь Creation Code. Всегда думал, что он работает также, до Create.
Можно было и один объект, но надо было делать всякие костыльные изощрения типа запуска alarm[0] = 1 из create.
Дадада
Я через наследования делал и тоже с костыльными извращениями, но эта фича отправляет все костыльные изврещния в прошлое!
Это шаг в сторону улучшения редактора карт, по большому счету. Думаю, это направление сейчас больше всего следует развивать, ибо редактор карт в GM не удовлетворяет моим барским запросам.
Ну не знаю, меня уже вполне удовлетворяет =)
Одни только слои в GMS2 и наследования комнат какой прорыв сделали. Работа с тайлами стала шикарной просто (даже если не брать в расчёт возможность делать анимированные тайлы).
В общем мне радактор комнат второй студии прям очень нравится. Не нравится только то что для каждого экземпляра объекта свойства открываются в поебени на пол-комнаты. В юнити это в отдельном окне показывается и мне кажется что удачнее гораздо решение. С тайлами же они отводят отдельную панель. Хотя может там можно что-то донастроить, надо пошукать.
Мне бы хотелось иметь возможность настраивать отображение объектов в редакторе, при создании карты. Часто, объекты в редакторе комнат отличаются от того, как они будут выглядеть в самой игре. Иногда ты должен видеть финальную картинку еще на этапе проектирования уровня. Или возьмем другой случай, когда тебе требуется видеть графическое отображение настраиваемых свойств объекта в редакторе. Сейчас GMS1-2 умеют отображать разве что масштаб и image_blend.
Плюс в двойке, лично мне, до боли не хватает адекватного редактора изображений и всех тех полезных исторических функций для корректировки спрайтов.
Да, gizmo была бы крутой штукой. Я вроде тоже предлагал ребятам из YOYO такое прикрутить, мож сделают ещё.
Кто не в курсе gizmo - это то же draw событие (немного почиканное) только для редактора комнат.
Чтобы можно было бы прописывать всякие радиусы, цвета, и параметры.
Я к спрайт-эдитору уже привык. Какие-то вещи в нём делаются гораздо проще и быстрее, чем в 1.4 В частности доступность и работа с анимацией. В 1.4 эта поебень всё блокировала, а поменять кадры местами - приключение на пару минут.
Менеджмент кадров завезли до минимального уровня, да. Хотя большой список функций экономящих время выпилен, работай ручками. Убивает Ctrl+C — Ctrl+V, эта штука выше моего понимания.
А на самом деле это классная штука. Я тоже сперва плевался, и не понимал как с ней работать. Теперь те же тайлсеты я не могу делать без неё. Это же копировальный штамп и кастомная кисть в одном флаконе. Обычная копипаста и в 1.4 была не ахти.
Например?
Ещё image_xscale, image_yscale, image_angle как минимум.
К слову, как инициализировать переменную до события Create из кода:
В obj_Engine создаем глобальную переменную, которая будет играть роль буфера обмена
globalvar CLIPBOARD_1;
В obj_NewObject пишем код, в самом начале
//инициализация
kind = CLIPBOARD_1;
//остальной Create
// if kind bla.. bla.. bla...
Теперь, в любом месте программы, создаем новый экземпляр, предварительно заполнив буфер обмена
CLIPBOARD_1 = "Эльф";
instance_create( x, y, obj_NewObject );
В начале события Create, а не до, если уж прям точно выразиться. Способ интересный.
Можно кстати не делать globalvar, а просто писать global.CLIPBOARD_1 во всех местах кода.
Когда понимаешь, что ближайшие X минут пройдут оху отлично
Достали тролить краснокнижных обитателей гамина. Опять этот чертов срач с гамаком. Сколько можно бля?
Ну маааааааааам.
Уже скоро.
(Главный вопрос, почему я в 6 часу ночи это все читаю :yak:)
Ну правда, парни. Не вижу предмета спора. Вы какой-то херней сейчас страдаете. Если вам личности друг друга не нравятся, то выходите стреляться, зачем эти срачи?
Я спросил как рефакторить в гамаке и началось
Ну прям взрослые люди. Охуенный спор у вас. Я понимаю, что вам похуй на мнение друг друга, ну тогда и разойдитесь мирно.
Я думаю, что срачей по гамаку так много на этом сайте, что этих данных уже хватит обучить примитивную нейросеть. Она разочаруется в людях и начнет восстание машин. (Слава роботам)
Я тут никого не собирался переубеждать, а пришел с конкретным вопросом и меня завалили стандартным поносом в духе наш движок лучший а у тебя руки из задницы. Больше мараться не буду
А что был за конкретный вопрос-то? Ты пришёл со своими привычками кодера в среду, которая на кодинге не центрирована, а наоборот старается задвинуть эту рутину куда подальше, туда где ей и место. Это говорит о твоей негибкости, а не о тупизне инструмента. И речь шла про IDE, а не про движок.
Гамак такой себе и движок, и среда разработки. Но всё остальное тупо ещё хуже.
Вопрос был как в гамаке нормально скалировать проект в котором куча логики, потому что средства гамака не дают нормальных инструментов навигации и рефакторинга, в следствие чего стоимость изменений растет экспоненциально количеству кода. Твой аргумент что надо писать мало кода, писать его сразу в финальной версии и гамак вообще не для такого.
Тогда в следующий раз когда напишешь что гамак покрывает 90% всех нужд уточняй что это твои нужды.
0/3, всё мимо. Я говорил много отдалённо похожих вещей, все из которых отличаются от перечисленных тут.
В ГМе не нормальные инструменты навигации, а ПРЕКРАСНЫЕ инструменты навигации, а рефакторинг нужен редко, скейлить нужно настолько редко, что выигрыш от инструментов рефакторинга исчезающе мал. Хотя я уже согласен сказать "о вкусах не спорят" и сделать вид что всё окей. Ясное ведь дело, что ни я тебя, ни ты меня, в общий проект не взяли бы. И так на много лет вперёд.
0/4. Это фраза Хейзера, а не моя, и что он понимал под типовыми задачами, я без понятия.
Надо записать себе напоминалку - не пытаться вести диалог с людьми, которые не разбираются кому они пишут, и что читают.
Ты перечитай комменты и посмотри сколько раз ты влезал и говорил за хайзера
Да пойми ты, что это только ТВОЙ опыт. Почему говоришь все в такой тональности, будто только твой способ разработки единственно верный? Ты заранее знаешь все свои механики потому что не заморачиваешься с геймплеем, ты не хочешь пытаться делать хитовые игры со свежими идеями к которым приходишь через десятки итераций изменения прототипа. Но это только твой путь и слава богу не все разработчики такие.
Чего мне только ни приписали за время этого, так сказать, диалога. Если это то как должен рассуждать и оценивать людей "тим лид", то я, не знаю, Кодзима? Ни одна моя игра с ЛД или конкурса - не клон, а сколько я делаю итераций - тебе неоткуда иметь понятия.
Обычно умные люди говорят по существу вопроса, а не скатываются до обсуждения самой процедуры дискуссии. Если я знаю про последние 15 лет прогресса инди-геймдева Хейзера, и абсолютно все его игры и методы, это как бы означает что я в этом компетентен. Эти странные окрики свидетельствуют о том, что больше тебе уже сказать нечего. Что и понятно.
Ты просто мастер сам себя с помоями смешивать.
Опять виляешь. Джемовые игры нормально делаются на гамаке и я с этим не спорил. За джем они не успевают вырасти до неконтролируемого размера
Какой-то синдром прокурора попавшего в научный совет. Моя вера в диалог на этом улетучилась. И главное:
Это слова про тебя же самого.
Ну так я тебе сразу сказал
Не знаю зачем ты полез мне навязывать свой путь игродела.
Исключительно чтобы контрастировать с твоим навязыванием своего, которое началось чуть раньше.
и так далее.
ты подаешь какие-то придуманные тобой стандарты разработки игры как единственно верный подход. для тебя он работает, но с чего ты взял что все должны так делать?
Ничего не напомнило? А жаль - это ровно как ты в самом начале дискуссии, выше всего по тексту. Добро пожаловать к зеркалу.
Что напомнило то? Обвиняешь в чем-то давай конкретные цитаты.
Я где-то говорил что мой движок универсален? Или что визуальное программирование не нужно и все должно делаться руками? Я говорю только за себя. Ты говоришь как должны делать другие.
Нет, ты говорил что постоянная навигация по коду (на языке с огромными телегами избыточных деклараций, квалификаторов, перегрузок - этого ты не говорил, но это есть в твоём выбранном инструментарии, противопоставляемом ГМу) и глобальный рефакторинг объектов и архитектуры это очень важно, и без этого невозможно делать игру, не зная её механик заранее, и поэтому Гамак так жёстко фейлит.
Создание основных игровых механик если выражаться простым языком.
А если статистически, то из всех 2Д игр 90% можно без проблем реализовать на гамаке.
У меня нет точных данных и измерений, так что расшифровывать примерно так нужно: "Хейзер за свою жизнь сыграл в немало игр, преимущественная часть из которых 2Д.... и из всех них примерно с 10% мголи бы возникнуть трудности при реализации на гамаке."
Да проблема не в том, можно ли повторить на гамаке, а в самом процессе разработки. Вы с кситом заранее знаете как будут выглядеть все механики в игре, но есть огромный пласт разработчиков которые идут путем эксперементов.
Вот например реддит пост где разработчик Celeste делится кодом класса персонажа.
https://www.reddit.com/r/gamedev/comments/837fr1/source_code_of_the_player_class_of_celeste/
То есть у чуваков даже на юнити были проблемы с рефакторингом потому что они не клонировали что-то существующее, а делали механику путем проб и ошибок. И получилась крутая, свежая игра.
По ссылке у чуваков явно нет проблем с рефакторингом, там просто один файл в котором перемешана и физика и магические константы и анимация и звук и логика. С тем же успехом могли на гамаке делать. Да собственно они на PICO8 первую версию делали, видимо оттуда методология и взята.
им так удобно, они так сделали. гамак даже это не позволяет. насколько я помню там на каждый метод надо делать отдельный файлик
Коко, ну это же уже клиника. Выпей пива и успокойся, никому твоё "даже" не нужно.
Это не всегда так, и проблем с этим я не испытывал.
Чего раскукарекался. Ну покажи мне какой-нибудь gml код такого размера если это клиника. Когда я привожу примеры отсутствия гибкости в гамаке ты либо говоришь что это не нужно, либо переходишь на личности.
Не понял какого именно размера, по ссылке из поста - 404.
https://www.reddit.com/r/gamedev/comments/837fr1/source_code_of_the_player_class_of_celeste/
https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs
Пиздец. И что, это с этим прям УДОБНО работать?
Это надо пробовать, я сейчас не могу. Во всяком случае, ещё один путь ускорения навигации, где-то пересекающийся с упомянутыми Коко хоткеями.
Ну, это же макароны какие-то, а не код. Разве так надо писать игры? Как можно вообще всерьёз рассматривать работу со сколь-нибудь большим проектом на языке, в котором даже в каждой декларации переменной 3 из 4 слов (private const float) это бойлерплейт?
Вот просто для себя скажите - что лучше:
или
(речь не о том что во втором есть комментарии)
http://rgho.st/6vXSBzdt5 - вот взял код объекта игрока из Mega Maker, можно поинтересоваться, насколько он проще, короче и эффективней. Всё что написано на Гамаке, более ёмкое из-за минимального количества конвертаций типов и деклараций которые надо переопределять только если прям ДЕЙСТВИТЕЛЬНО надо.
первый вариант много удобнее и красивее.
Это правильный ответ?
А уж комменты для второго варианта ваще жесть. Я прямо так и вижу в коде переменную "iceDec" и сразу понимаю что "when not holding any buttons"
Это специфичный Мегаменовский движок, для его понимания достаточно сыграть в любую из 50+ игр по Мегаменам чтобы знать, что единственный случай когда на льду (Ice) происходит уменьшение ускорения (DECeleration), это при не нажатой кнопке движения.
Я согласен что в первом случае переменные названы лучше (более полно и ёмко), но пример приводился не об этом, а о том что УДОБНЫЙ код выглядел бы вот так:
Даже если все типы и модификаторы доступа автоматически дополняются, массивы текста надо скроллить и ЧИТАТЬ. Это повышает нагрузку при работе с кодом всякий раз как ты ищешь какую-либо переменную или константу чтобы её, что называется, файн-тюнить.
И ещё нафиг не нужна эта буква f в конце КАЖДОГО значения, потому что видите ли надо указать языку программирования что это именно float, а не double. В Гамаке всё что не string, то real, а если тебе надо пересылать именно всякие байты в буферы с высокими требованиями производительности, то вот уж только в этом случае добро пожаловать в:
https://docs2.yoyogames.com/source/_build/3_scripting/3_gml_overview/checking_data_types/typeof.html
и
https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/buffers/buffer_write.html
то есть не завезли инкапсуляцию, нет целочисленных типов, а еще констант в версии ниже pro (гыыыы) это все достоинства?
а что выйдет здесь:
lives = 1;
punchPower = 0.1;
while(lives)
{lives -= punchPower;}
print("myLives when they classify me dead " + lives);
хотя в принцапе чо я. ужасное можно потрогать бесплатно во второй части статьи
https://gamin.me/posts/11790
Статья 2013 года, про Game Maker: Studio 1 (а не 2), с тех пор половина пунктов стала неактуальной, а писать новую статью мне некогда / не интересно.
Понятия не имею. Это намеренно мудацки написанный синтетический тест, который ничего важного не иллюстрирует. Все подобные проблемы архитектуры можно отловить пост-фактум, хотя ПРАВИЛЬНО было бы сначала строить правильную архитектуру, как об этом и говорит Хейзер.
"мудацки написанный"
ну, бля, приехали.
правильная архитектура начинается с bool > 0 == true, а не 0.5 (или 0.50000001( или 0.5000..1) ибо ваще хз где он там чо округлит в процессе)
0.5 представим в плавающих числах точно, там же двоичная система.
В любом случае, этот пример не имеет значения для практики. Когда есть реальная проблема, она реально решается.
private const float не является хоть сколько-нибудь проблемой. это инструмент
Представь что тут написаны какие-нибудь личные оскорбления, типа я потроллился.
Является, ещё как.
В этом треде мало комментариев
Оба варианта, которые ты привёл, говно. Как ты думаешь, почему?
Потому что а могли бы игры делать. Давай к сути вопроса сразу.
Блин, Кситилон Эшдиевич, так не интересно, сразу к сути. У тебя там курица что ли подгорает, что ты так торопишься? Ну на тебе суть: кто ж все эти константы прямо в коде пишет-то? Конфигурация должна быть.
Игры подгорают - релизить пора, а делать некому кроме меня.
Конфигурация, говоришь. Ну так-то, в сферической идеальной игре в вакууме, я хотел бы чтоб она была легко модифицируемой, и не как в Дюке Ньюкеме 3D в CON-файлах (хотя это само по себе уровень уже недоступный современным юнетяям-лентяям "делаем игру в аппстор за недельку"), а чтоб с визуальным интерфейсом, а лучше со своей встроенной прямо в игру IDE. Но даже самое простое из этого делать порядочно долго, а зарабатывать деньги - совсем другое занятие, чем делать хорошие игры для людей как для себя.
А так-то ты прав, что тут скажешь.
0_o ЛОЛ
Я, кажется понял, коко на каждое событие отдельный скрипт делает отсюда у него и пригорает. Я такое в ихсодниках HeroCore у Даниеля видел.
Если так работать, то с ростом проекта, разумеется будет куча всякого говна. Именно поэтому в гамаке код нужно писать прямо в событии объекта. Это ж охуеть как удобно:
1) Ты всегда в контексте объекта без ползания по простыням и левым файлам.
2) Сколько бы кода ни было прописано в событии - переключение между событиями - клик по табу (может есть шорткат какой)
3) Ненужные события ( т.ч. уродские конструкторы не нужно каждый раз писать для объекта и его потомков)
4) Все события родительского объекта можно посмотреть тут же в списке событий объекта и оверрайднуть при необходимости.
6) Можно указывать /// @description - быстрый способ комментировать общую суть кода события
Это как раз то, ради чего используются продвинутые IDE, чтобы вместо рутины программист занимался логикой. Но ведь тру-програмиистов УЧИЛИ создавать функцию-обработчик на событие и, видать вместо того чтобы мозгом подумать такие индивиды прочитают что "функция=скрипт" и начинают херачить как УЧИЛИ.
Вопрос к участникам дискуссии. Вы действительно считаете, что вы лучшие программисты, чем коко?
Да нет. Я не меряюсь программированием, меня интересует только геймдев. Но программирование в контексте геймдева вызывает столько разночтений, что не получается просто молчать при виде откровенно странных мнений и подходов. Что для игры нужно МНОГО рефакторить, что код (и даже вообще опыт разработки игр) должен измеряться десятками тысяч строк, и подобное.
Не, у меня вопрос проще. Вы считаете себя лучшими программистами, чем коко или нет?
Про опыт разработки игр рассуждать нужно в уровень, такое мое мнение. Я сделал 2Д игру, ты сделал 2Д игру, Хейзер сделал 2Д игру. Все это довольно мелкие игры в масштабе индустрии. Не знаю в каких именно разработках участвовал коко, но подозреваю, что в гораздо более крупных. Собственно, этим опытом он и поделился, что для более масштабных проектов, по его мнению, гм плохо подходит. С моей колокольни, ему в уровень люди тоже должны отвечать, а не мы. Но может вы считаете себя лучшими программистами, чем коко, вот я и спрашиваю. Примеров промышленного использования гм мы тоже не знаем, поэтому, скорее всего, профи его не используют не просто так. Вот профи говорит почему, не грех, в общем-то, и прислушаться. Так мне кажется.
Ага, при том что коко ничего не сказал о том что такое "масштабный проект"
Вот есть список наиболее популярных игр сделанных на гамаке:
https://www.yoyogames.com/showcase
Есть же, например Hyperlight Drifter немаленький на мой скромный взгляд. Тот же Death Gambit, Katana Zero.
По-моему это отличный показатель того как довольно большие игры (не прототипы) делаются на Game Maker.
Если коко имеет в виду что на гамаке не сделть Дарксоулс какой-нибудь или неебичнскую MMORPG - ясное дело, что инструментарий не для такого.
Но тот же Hollow Knight на гамаке осилить можно запросто, например.
У меня вот так кстати картинка выглядит с шоу кейсом.
> Hyperlight Drifter немаленький на мой скромный взгляд. Тот же Death Gambit, Katana Zero.
Это все мелкие игры. Катана Зиро намного меньше Ринго того же, к примеру.
Общего назначения - точно нет. Я не понимаю в анонимных функциях, кложурах, предикатах, меня бесит даже цикл foreach. Я не умею работать с системами версионирования типа git'а, хотя эту поддержку в ГМ Студию прикрутили уже давно, не знаю ни одного паттерна и мне не о чем говорить с HR-менеджером любой конторы с зарплатой выше $1000 в месяц. Это тупо другой путь.
А в контексте конкретно геймдева и конкретно инди - да. Как оказалось, уже даже между инди и не инди геймдевом гигантский разрыв. Поэтому я попросту не уловил контекста, когда Коко начал говорить о каких-то больших проектах. Я не понял к чему вообще упоминать всю эту монструозную корпоративщину, потому что на Гамине котируют инди-игры. Только после твоего пояснения я вообще понял что он говорил о своей собственной области.
А что ты подразумеваешь под программированием?
1) Скорость написание заранее известного кода?
2) Умение придумывать и адаптировать алгоритмы?
3) Умение оптимально спроектировать архитектуру проекта?
Может быть по П1 коко и силён, но судя по тому что он пишет про гамак п2 и п3 вызывают большие вопросы.
Ну и так между нами. Не нужно делать десятков экспериментов для придумывания механики. Если разработчику это нужно - значит у него мало опыта в придумывании этих самых механик. Вот чем нас поразил коко в последнее время? Стратегия? Карточная игра? Это прям пиздец новые игровые механики на которые нужно десяток раз переписывать код?
> Вот чем нас поразил коко в последнее время? Стратегия? Карточная игра? Это прям пиздец новые игровые механики на которые нужно десяток раз переписывать код?
Мы говорили вроде про программирование, нет? Вы же сами вроде напираете на то, что это разные вещи, программирование и геймдизайн (создание игр). Опуститься до обсирания игр друг друга мы всегда успеем.
Ты сперва поясни что такое программирование? Там много аспектов есть.
Есть программисты-болваничики которые просто стругают код по алгоритмам которым их учиили.
Есть теоритическое программирование - разработка алагоритмов и адаптация их для различных платформ.
Есть прикладные программисты - которые эти алгоритмы адаптируют и оптимизируют под конкретные платформы.
Есть архитекторы ПО, которые не пишут код напрямую, а проектируют блоки и дают рекомендации по использованию тех или иных прикладных методов и языков.
Так вот кого ты имеешь в виду? Я вот лично являюсь архитектором ПО. Учился по этой специальности N лет и сейчас работаю в этой области, конкретно - архитектурой фронтенда. У меня нет большого опыта работы с IDE и кодом напрямую, т.к. мои задачи как правило на более высоком уровне абстрактций чем писать код.
Чё там коко делает я в душе не ебу. Судя по всему просто говнокодит изо всех сил как учили в каком-нибудь колледже.
Ну все, скатились до личных оскорблений.
Это и правда не оч вежливо было.
Не знаю зачем йео набрасывает, у меня нет задачи померяться кто лучший программист.
Кстати, кочевники начинались как real-time герои меча и магии, а подобием стратегии стало когда после нескольких итераций я понял что в джем такой концепт не уложится, отсюда и кривоватое управление.
Я критиковал это ещё тогда, и парадокс в том что тебе кажется что Гамак связывает руки (и ноги), а мне кажется что на Гамаке я бы успел за джем сделать всё что по кочевникам задумал ты. Надо бы эту гипотезу как-нибудь проверить... с таймлапсом, пост-мортемом и всеми делами.
Пункт 5 потерял.
Щас офигеешь. Только что я обнаружил что в ГМС2 можно назначать вручную какие-то НОМЕРА объектам при нажатии CTRL+SHIFT+цифры, и вызывать эти самые объекты по CTRL+цифре. Помимо того что воркспейсы и окна в них переключаются по CTRL+TAB.
Вот мой последний прототип на GML
Если будет свободное время посмотри и скажи что бы ты сделал по другому. Конкретно там проблема в большом количестве стейтов у персонажа и врагов и в том, что для сущностей Actor и Enemy мне пришлось дублировать много кода касающегося стейтов, потому что при наследовании возникло бы больше проблем чем решилось бы. Там много 4-5 строчных скриптов, но без хоть какой-то структуры я бы очень быстро запутался во всех стейтах, поскольку это прототип и я добавлял и удалял разные стейты, эксперементируя с механиками.
Это зря. Сейчас тебе популярно объяснят, что ты дебил и все делаешь не так. Мне даже в код не надо смотреть для этого.
И чего? У меня комплексов нет, а получить код ревью от разработчика с многолетним опытом работы с движком это самое полезное что может быть для личного роста.
> Судя по всему просто говнокодит изо всех сил как учили в каком-нибудь колледже.
Расти.
> 0_o ЛОЛ Я, кажется понял, коко на каждое событие отдельный скрипт делает отсюда у него и пригорает.
Вот тебе товарищ выше уже ответил, собственно. А тебя первый же срипт в степе именно такой. Так что все, говно-программист ты, теперь не отмоешься никогда.
Битва проиграна.
А можно еще раз поподробней для тупых. Предполагается писать весь код в рамках одного метода прямо в окне ивента?
Да я не против
> Предполагается писать весь код в рамках одного метода прямо в окне ивента?
Прости, я не знаю, что такое метод. И как надо писать не знаю тоже. Но сейчас товарищи объяснят тебе, не переживай.
Я вообще половину слов из вашей дискуссии не понимаю. Я когда читаю подобное, думаю, блять, как я игру-то вообще сделал с такими знаниями. Но для меня главный авторитет и вдохновитель это сб. Над его кодом и знанием математики весь гд.ру ржет годами, при этом даже софтрендер его побить никто не смог. Поэтому для себя я решил, что это все не так важно.
Но в рамках текущего диалога, они просто набросятся сейчас на твой код и все. Хороший он, плохой, я не знаю. Но явно не такой как у них. А этого, как известно, достаточно.
Ару
А в чём состояли эксперименты с механиками? Что именно ты менял и какого эффекта хотел достичь? Типа отключить/включить волджампы/дэши? Или что-то более глобальное?
Я добавлял и выпиливал разные traversal механики типа гарпуна, двойного прыжка, планировались еще подтягивания. Дэш был в трех разных вариантах - блинк, рывок в сторону курсора и просто горизонтальный кувырок. Ну и т.к. прогрессия должна была как в метроидвании, то это надо было динамически включать и выключать по мере сбора разных абилок. В общем, очень не хватало полиморфизма и необходимости помнить где какие константы лежат, отсюда и обилие комментариев
Такие вещи я обычно оставляю на менеджмент глобальных переменных, которые транслируются в локальные були объекта (нужно если комнат в проекте больше одной).
Я реализую сразу все механики, потом включаю/выключаю руками или создаю пикапебльные объекты.
Я пока бегло глянул проект. Теперь понятно, почему ты решил что гамак не подходит для больших проектов =)
Чисто с точки зрения архитектуры и закладывания в будущее выглядит хорошо. С точки зрения юзабельности - не очень. В общем, не такая тут парадигма, которая используется в тех инструментах что ты привык. Можно и поговорить и про подохды разработки на GameMaker, раз ты более менее в теме.
При работе с гамаком вся функциональность и логика объекта обычно прописывается в самом объекте без выноса в скрипты. В GMS1.4 можно было на одно событие создать два куска кода чтобы разбить длинный код на блоки. В GMS1.4 Это убрали и поэтому иногда приходится писать портянку или бить на пару скриптов (но не пару десятков как у тебя). Тут основаная идея как раз в том, что объект - это УЖЕ файл который разбит на все необходимые события и кода в них будет не очень много.
Скрипты обычно реализуют общую универсальную функциональность, которая много где используется и далее не меняется или меняется целиком. Например, получение повреждения (как игроком, так и противником), создание вылетающей цифры при повреждении или текста при взятии предмета.
Самый большой кусок функциональности ложится как правило на игрока. Там имеет смысл дробить на куски, но не так мелко как это сделано в твоём проекте. Да и у тебя в проекте не уверен что подробнео оптимально, например скрипты по контролю анимации можно было бы в один объединить. В идеале я бы создал дата-структуру(по сути это была бы моя модель) и скрипт который по ней ходит и сам знает для каких состояний какие спрайты включать. В итоге я бы сделал всего два-три скрипта на все случаи жизни для любого из объектов.
Инпуты реализовывать в функциональность игрока тоже не очень правильно ИМХО, т.к. они могут использоваться в интерфейсах. Я когда-то давно делал ACS систему (Awesome Control System) которая менеджит весь инпут со всеми проверками как по клаве так и по геймпаду, умеет сохранять настройки в отдельный файл и загружать их, а конфигурируется примерно как контролы в Unity). До сих пор юзаю эту систему, уже лет 5 наверное. Она у меня гуляет из проекта в проект и практически не меняется =)
Если я хочу попробовать другую механику главного персонажа - я дублирую объект игрока и дописываю что нужно прямо в него, потом просто удаляю ненужный из двух вариантов.
Наследование лично я применяю обычно для общего поведения, в котором есть 100% известные механики. Для этого создаю объект-прототип, в котором это поведение прописываю. Например, у врага точно известно что он получает дамаг, что он взрывается, что у него есть максимальное ХП. Вот это всё идёт в прототип. Далее враги-наследники прототипа - каждый реализует свою логику внутри себя без выноса чего-то в скрипты. Если мне нужно проверить механику - я дублирую объект и меняю его как хочу. Когда я понимаю, что объекты наследники реализуют одно и то же поведение - я выношу его в протоип.
Платформы и стены я так же делаю через наследование. Платформа - более общий прототип, не пропускает игрока с одной стороны, стена не пропускает игрока со всех сторон - она наследуется от платформы. Ну это если у меня есть платформы вообще.
Какие-то вещи удобно декомпозировать на разные объекты. Я порой делаю отображение UI противника отдельным объектом, потому что потом проще описать его поведение чем химичить что-то у кого-то в draw событии.
Ну и согласно сабжу поста, многие переменные имеет смысл выносить в Variables Definitions, тогда настройку скоростей и высот прыжков можно делать прям в редакторе комнаты без открытия скрипта инициализации и переключения в контекст написания кода. Вот тебе и быстрые эксперименты и тюнинг механики.
В итоге примерные правила такие:
1) Общие прототипы с общей функциональность
2) В скрипты отправляется сквозная функциональность (которая обычно решается аспектами в аспектно ориентированном программировании)
3) Частности реализуются внутри объектов
4) Тесты механик = клоны объектов
---------------------------------------------------
В общем, путь доскональной декомпозиции на каждый чих - это не путь Game Maker, хотя это необходимое условие для программирования в сложных языках. Но это всё из-за синтаксической мишуры приходится разбивать всё на более простые блоки, а IDE должна обеспечивать быструю навигацию по этим блокам. В GameMaker этой мишуры нет, поэтому код проще и читать его просто, особенно если адекватно именовать переменные.
Если интересно, я тебе скину потом исходинк своего пост-конкурсного проекта.
Спасибо за ответ по теме, то что надо. Только дошли руки прочитать и ответить.
Не совсем понял. То есть если у меня стейт машина, я пишу код всех стейтов прямо в окне STEP-ивента, даже если по всей логике каждый стейт делает разные вещи? Можно было бы привыкнуть, если бы внутри ивента были какие-то маркеры, по которым можно было прыгать к нужным кускам кода, а так - немного дико. Навигация сильно затрудняется, ведь нельзя по названию метода (скрипта) сразу перейти в нужной логике.
Я использовал скрипты двумя способами:
Согласен, местами переборщил с дроблением. Но тут сложно правильно предугадать заранее в каком месте код будет расширяться, поэтому я дробил по максимуму, чтобы каждый скрипт отвечал за что-то свое. Ты предлагаешь интересный, но не самый очевидный подход с дата-структурой. Это как раз пример необходимости рефакторинга - сразу такое вряд ли кто-то стал бы делать, а потом уже слишком трудно менять - останутся какие-то хвосты в виде неиспользуемых переменных, которые надо будет по очереди проверять руками нужны они еще или нет. Но при определенное сноровке сделать можно, хотя и не так удобно как в visual studio, например.
Я тоже обычно делаю инпут отдельным сервисом, но с гамаком раньше не имел дела и своих наработок не было. А инпут - это последнее с чем хочется заморачиваться в прототипе. Тут впринципе все прозрачно и я не вижу проблем с ним даже в потенциально большом проекте - все хорошо абстрагируется.
Хах, ну это настолько просто и элегантно, что я даже как-то не додумался. Опять же, будет работать только если весь код написан напрямую в объекте.
Преимущества наследования сильно порезаны в GML, потому что нет возможности переопределить или дополнить какую-то часть поведения родителя. По крайней мере я не нашел как это сделать без костылей. Отсюда получается, что в прототипе будет только ОЧЕНЬ ограниченный набор общих действий.
С платформами я так и сделал - тут проблем не возникло вообще. Очень удобно в этом плане прямо в редакторе видеть где что.
Здесь тоже все логично, главное не запутаться в порядке обработки их событий гамаком.
Теоретически удобно, но учитывая что в гамаке туго с рефакторингом - получается, что окошко определений этих variable definitions - это еще одно место, которое нужно иметь ввиду при внесении изменений в код. То есть с одной стороны проще, с другой стороны еще одна специфичная черта, к которой нужно привыкать в гамаке. Настолько специфичная, что даже ты о ней узнал только на днях.
Декомпозиция - не требование каких-то языков программирования, а воплощение естественного для человека желания упрощать процессы, чтобы держать их под контролем. Чем меньше скоуп, тем меньше вероятность накосячить, тем быстрее идет работа. Я никого не заставляю делать так, как мне удобно, но по своему опыту я знаю насколько такие подходы эффективней, поэтому стараюсь идти этим путем везде. Я избалован возможностями средств, которые предоставляют ооп-языки и ориентированные на них среды разработки, поэтому интуитивно ищу и пытаюсь имитировать их в гамаке. Когда не получается, для меня это как удар по голове - ощущение того, что весь проект у тебя под контролем сменяется необходимостью для каждого объекта помнить где и в каких событиях у него какая логика, какие переменные он определяет какие системы использует. Тогда как в vscode, например я в одном хоткее от всей нужной информации.
Декомпозиция упрощает изменение кода. И что бы не говорил ксит - без этого в нормальном проекте очень тяжко. Простейший пример - даже понятные имена переменных не всегда приходят в голову сразу, а только когда создал их, попользовался, и понял что для нее есть более подходящее имя. В привычной среде я нажму одну кнопку и без проблем переименую переменную, метод или класс и не буду париться что я попутно мог переименовать похожие переменные во всем проекте.
В общем, еще раз спасибо, что нашел время посмотреть мой код - подчерпнул из твоего ответа пару идей, которыми воспользуюсь если вдруг еще раз столкнусь с гамаком, может и поменяю свое мнение.
Пока да, так. Как я уже упоминал, во второй студии порезали функционал в котором можно было код дробить в самом объекте. В режиме DnD может и можно - там в события добавляются кнопки, которые выполнят код и этих кнопок можно было создать несколько и каждой назначить комментарий. Во второй студии всё событие обткрывается в одном табе и пока никак. При этом не завезли даже элементарных сворачиваний блоков, увы.
Лично на моей практике прям много кода выходит только на объект игрока и на боссов (т.к. у них более сложное поведение)
Если правильно оформить скрипт, то он может контроллировать количество входных параметров(+опциональные) и давать подсказку по параметрам в автокомплите. Как оформлять - есть в доках. Т.к. язык слабо типизированный то какого-то более жёсткого контроля как в том же JS ожидать не приходится.
Я перегнул про отсутствие рефакторинга. Он может возникнуть, но мне кажется не так глобально и с основном он касается игровой логики, а не кода. По крайней мере у меня обычно так.
Не совсем понимаю что ты хочешь наследовать такого особеннго. Ребёнок наследует все события родителя и его Variables Definitions, а так же участвует в обработках всяких with {}, collision_ фукнциях если в них указан его родитель.
Полиморфизм тоже есть. В GMS2 прям показаны серыми залоченными события родителя и там же правым кликом можно выбрать одну из опций: переписать событие или дописать. Тогда создаётся отдельное событие конкретно для этого объекта в котором можно использовать event_inherited() для вызова кода события родителя. Вставлять можно в любое место, так что тут функциональность тоже гибкая. Можно что-то доопределить до вызова этого кода или наоборот переопередлить после.
Новые события которых нет у родителя, осталются только у потомка, разумеется.
Так что вроде всё точно так же как везде работает.
Ну и Variables Definitions тоже наследуются и могут быть перезаписаны у потомков. Это что касается объектов.
Но ведь в GMS2 можно наследовать и комнаты. Настраиваешь какой-то единый формат, камеру, контроллеры. Наследуешься и меняешь игровой контентв. Но и камеру и формат тоже можно менять. Как мне кажется это гибкий механизм и этот потенциал я ещё не раскрыл до конца.
На днях я о ней узнал потому что справку давно не курил и не следил за изменениями. Примерно 10 последних месяцев работал с GMS.1.4 допиливая проекты для стима, так что не в курсах был.
А вообще эти variables definitions работают скорее как param в юнити. Это способ создать сущность для перезаписи в редакторе комнаты. Я думаю, что это первичное их назначение. То есть нет смысла прям все переменные туда заталкивать.
Во-во-во. У меня точно такая же ситуация =) Я избалован удобствами гамака, поэтому в средах для ООП языков я точно так же интуитивно пытаются имитировать решения из гамака. И очень печалюсь когда понимаю сколько времени у меня уйдёт на их реализацию.
Возможно, есть пути более простые, ХЗ, но для этого нужно иметь невъебенный скил и года работы с IDE.
Только руками
А как это делается "нормально", а не "сильно порезанно"? Разве есть способ унаследовать поведение и переопределить только его часть, а не разбивать специально на код до того что хочешь переопределить (1) и/или код после (2), и уже в середине прописывать отличие? Гугл выдаёт что нету, а если писать вот так:
https://stackoverflow.com/questions/23517609/how-to-override-parts-of-a-method-of-a-base-class-in-c-sharp
, то в Гамаке этот подход с модульными вызовами работает абсолютно одинаково.
А декомпозицию я не критиковал как таковую.
> То есть у чуваков даже на юнити были проблемы с рефакторингом потому что они не клонировали что-то существующее, а делали механику путем проб и ошибок. И получилась крутая, свежая игра.
Классный вброс. Чем дальше в лес, тем веселее у вас. То есть на гамаке нельзя путем проб и ошибок? А 2Д платформер Селесте это пример игры, которую нельзя на гамаке сделать?
> Вы с кситом заранее знаете как будут выглядеть все механики в игре, но есть огромный пласт разработчиков которые идут путем эксперементов.
Помимо кстита есть куча разработчиков на гмакере, чего они только ни делают, какого только успеха ни добиваются.
Хорошо, что я программированием не стал заниматься, конечно. Реально что ли что-то с мозгами там происходит в процессе, не знаю.
Я уже устал писать об этом. Сделать на гамаке можно любую игру, да. Но в большинстве случаев все преимущества скорости теряются после двух недель работы потому что в нормальном коде изменения делать проще чем перекликивать сотню обьектов.
Да ниче не происходит. Обычное желание докопаться до истины почему люди так пиарят движок который связывает их по рукам и ногам.
Ну я только за себя могу говорить, понятно. Я ни разу не программист и других ИДЕ не нюхал даже. Но ни разу я не столкнулся ни с какими сложностями при разработке 2Д игры. И Ринго не самая мелкая игра, там довольно много разных механик и всего такого. Уж сколько времени я потратил на тестирование разнообразных битэмапных механик за эти годы - и не сосчитать. И никогда я не упирался ни во что, все было легко, просто и весело.
Поэтому я не спорю ни с чем, ибо не разбираюсь, но когда вот так вот вдруг начинают опускать движок, начинает пригорать тоже. Мне он удобен для моих нужд. Может нужды не велики, конечно, как ты скажешь, но тут и вопрос у меня, а у кого они больше из местных?
Ок, реально крупную игру, да еще и в команде, не вытянуть на гамаке. Но почему ты пытаешься представить его как НЕУДОБНЫЙ инструмент, я не знаю. Вот тебе три автора игр, я, хейзер и ксит, которые на нем работают и говорят, что он именно УДОБЕН. Не плох, а ХОРОШ. Почему ты не котируешь наше мнение? Ну мы ведь не самые последние разрабы тоже, пусть в других ИДЕ не шарим на должном уровне, но уж в своем родном-то разбираемся поди?
Вот ты все правильно расписал и я с тобой во всем согласен. Тебе он удобен для твоих нужд он на 100% подходит. То же самое с хайзером и кситом. Но ты в отличие от них не постишь гневные вбросы о других движках и не бросаешься религиозными фразами типа "программирование не есть геймдев" в ответ на легитимные претензии об отсутствии в гамаке простейших кодерских удобств.
Только тут не согласен. Я не опускал движок, наоборот был бы рад если бы мне показали как можно делать вещи которые мне нужны. После смерти флеша я всерьез рассматривал гамак как альтернативу. Купил его и сделал пару прототипов, но остановился на js, потому что без рефакторинга мне там реально не удобно и медленно. Думал тут знатоки подскажут что я делал не так, но судя по ответам я просто закоренелый программист и в связи с этим гамак мне противопоказан.
Сейчас все свелось к тому, что я пытаюсь развести ксита на адекватность, чтобы он выключил свой комплекс мессии и как и ты признал наличие альтернативных подходов к разработке.
Может я пропустил, но не видел конкретного случая, к которому ты бы ожидал подсказки. Расскажи - подумаю.
Ты уже ответил в своем обычном стиле. Если мне надо постоянно менять код то я неправильно делаю игры
Для того чтобы я что-то подобное говорил, сначала надо было чтоб я пообещал кого-то учить делать игры. А я просто выразил мнение, и рассказал свою практику. Why so serious.
По кнопке F12 ты переходишь в тот ресурс (объект, скрипт, спрайт, звук, что угодно), в названии которого у тебя сейчас текстовый курсор. В ГМС2 это работает по нажатию средней кнопки мыши на названии объекта.
Не-а. Ты так рассуждаешь, будто чужой опыт взят не из практики, а некоего гипнотизированного магического скудоумия и выученной беспомощности.
То есть там даже нельзя сделать свой собственный плагин с GUI? Только сидеть в загородке песочницы и ждать, пока его завезут?
Да, и игру тоже сделать нельзя. Можно расходиться, мы всех обманули.
Что такое плагин? В ГМе нет плагинов, но есть экстеншены, подключение внешних DLL и шейдеры, пиши что хочешь.
Это когда тебе нужен такой редактор для продуктивной работы над игрой, который не заложили в стоковый движок.
Какие-то добавили окошки, через которые можно менеждить что-то мышкой. У самого рук не было сделать то же самое?
Я поня и
А я думал, что всё это время переписывался с человеком :)
Огромное спасибо, парни. В голос смеялся. От души.
Лично для меня, этот тред был весьма познавательным.
Думаю, что любой IDE вырабатывает у человека некий своеобразный стиль мышления, который очень хорошо проявляется в таких вот диалогах.
Так дело то не в IDE, это называется "Парадигма программирования". Не хватает только чтоб какие-нибудь функциональщики прибежали и сказали
В общем, когда пытаешься применять какую-то парадигму в неподходящем для этого инструментарии - возникает боль. У коко своя с попыткой реализовать ООП паттерны в гамаке. А у меня своя от того что я не вижу просто и удобного функционала моей гамако-парадигмы в движках которые заточены под серьёзный ООП.
Смешно то что выбор парадигмы никак не влияет на конечный результат кроме скорости разработки =)
Коко о другом говорил, если что.
Коко тупо тролил, если что =)
Сомневаюсь что он вообще гамак трогал, а если трогал, то простенький пример делал разве что.
Не соглашусь что тупо троллил, но старые привычки всё портят, кодерские фичи кажутся важнее чем они есть.
Не все делают игры по одному шаблону. Почему ты не можешь понять, что то, что не нужно тебе может быть нужно другому разработчику, потому что у него другой подход к созданию игры.
Ты констатируешь непонимание, которого на самом деле нет. Есть много разных подходов, но это не значит что они равноценны и одинаково эффективны. Другое дело, что я не делал РТС, потому что меня эта тема не особо занимала, поэтому у нас нет общего контекста.
Вот именно что подходов много, но ты избрал такую риторику будто только твой подход верный и продолжаешь гнуть эту линию. Ты сам говоришь что тебе не интересно делать что-то кроме стандартных вещей и раз тебе это не интересно, то в гамаке это не нужно.
Просто время ещё не пришло. Не надо путать это с рамками движка. Я вообще занимаюсь геймдевом слишком мало относительно того, что я в нём должен делать. В следующие годы будет понятно о чём я вообще.
То есть ты авансом себе дал право затыкать всех кто с тобой не согласен?
Если бы я хотел тебя затыкать, я бы так и сказал, и просто не говорил бы ничего больше. Я же не знал, что всё, что я скажу, будет восприниматься в штыки, и толща наростов личного опыта столь велика у некоторых местных творческих персон. Поэтому и понадобятся годы, я это понял только сейчас. Спасибо за это понимание.
На что годы то понадобятся я так и не понял. На укрепление своего эго еще парой десятков клонов?
Ага. Все ж знают что я делаю только клоны.
Не хочешь отвечать, зачем было поднимать эту тему тогда?
Годы понадобятся на то чтоб я освободился от тупых ИРЛ проблем, не дающих мне делать игры как надо.
И ещё я пытался донести некую мыль "о ненужности фреймворков в том виде в котором они есть".
У меня нет уверенности что их использование действительно эффективно. Они как бы все одинаковые... Так да не так, есть много отличий в ньюансах между ними, на изучение которых уходит время. А бывает что ты просто не находишь нужный функционал. Функцию sign или длинну вектора, в ИГРОВОМ, мать его фреймворке. Или начинаешь двигающийся зацикленный фон делать вручную при помощи двух спрайтов. Хотя по логике в ИГРОВОМ движке такие банальные вещи должны быть реализованы и вызываться просто иницализацией со спрайтом. По моему мнению и выходит что разбираться и дописывать примерно столько же времени занимает как если просто на ЯП-е с нуля писать. В первый раз как минимум. А во второй ты понимаешь что сделал всё хуёво и снова допиливаешь что нужно. В общем это бесконечный процесс, и по-моему он не очень правильный.
То есть если ты ниибца программист, как коко, например то написание своего движка чисто под свои нужды на чистом JS будет немногим дольше, чем использования всяких фазеров. Правда потом может встать вопрос как это говно портировать на плойку, закопаться на два месяца в документации и на костылях впилить это в свой движок =)
В этом мне и нравится подход у конструкторов - что там вообще весь минимум есть. То есть ты не будешь охуевать от того что у тебя нет элементарных функций, потому что обычно кто-то поохуевал до тебя и рассказал разработчикам как бы хотелось чтобы было и сабж этого треда тому подтверждение.
Чего-то я не слышал, чтобы какая-то крупная студия делала игру на гамаке. Крупнейшие студии пилят свои движки, так как это самое выгодное решение, студии поменьше используют анрилы-крайзисы, кто-то и юнити не брезгует. Но про крупные проекты на гамаке чего-то не слышал.
Вроде бы очевидно, что если программист хочет расти в профессии, то ему нужно изучать новое и быть в тренде рыночных предпочтений. Ну и конечно же от гамака нужно отказываться как можно раньше, ибо это тупиковый путь развития.
Однако почему у программистов бомбит каждый раз, когда они видят даже упоминание гамака, я не очень понимаю. Да, есть такой инструмент для недопрограммистов вроде меня, на нем можно (как минимум) делать 2Д игры. Ну это просто факт, не отмахнешься от него. Любые игры до 32-х битной эры игровых приставок можно сделать на гамаке. Большинство из рассуждающих (не в этом треде, а вообще) дальше спектрума еще не всегда двинулось в плане выпущенных игр. Но каждый раз посыл такой "а? в вашем гамаке даже такой херни нет?! хахаха! ну и дно! вот я молодец, что сижу на ххх". Ну супер, конечно. Не надо сидеть на гамаке, если можешь на нем не сидеть.
Не очень понятно опять же, зачем продвигается тема вообще программирования применительно к созданию 2Д игр (ну вот уровня гаминатора хотя бы). Как известно, сб даже математику не особо хорошо знает, не говоря уже про геометрию. А ничего, собрал свой 3Д софтрендер. Так что если мы все-таки про мелкие авторские игры, то это один разговор, если про Лару Крофт, то другой. Но про Лару Крофт я не знаю кто здесь может всерьез рассуждать, хотя может и может конечно кто-то.
В общем, чтобы делать 16-битные игры как на Сеге мощного инструментария и сильных математических (не говоря уже про конкретно программистских) знаний не нужно. Ну и учитывая, какие игры мы все здесь делаем, довольно забавно читать все эти рассуждения каждый раз.
Так то да, но это ПРОГРАММИСТ, а не разработчик игр. Это две большие разницы, которые многие просто не замечают. Типа только ПРОГРАММИСТЫ могут делать игры и если ты не ПРОГРАММИСТ, то большую игру никогда не сделать, особенно на гамаке =)
Тут я могу лишь догадываться, что дело РАНЬШЕ было в кроссплатформенности. То есть если ты планируешь бизнес и выход на всякие плойки, нинтенды и хуящики то гамак шёл мимо. Сейчас это уже далеко от реальности и Гамак имеет нужный функционал для билдов на эти платформы.
Ну и для 3Д игр гамак плох - это очевидно. Так что если 3Д игра то лучше как раз смотреть в строну юнити, анрилов и кукурузисов.
Есть Hyperlight Drifter и Death Gambit которые не маленькие. Так что если автор задумал большую 2Д метроидванию или 2Д адвенчуру, например, то почему нет то? Я считаю, что в этом случае Гамак один из отличнейших выборов.
По закону жанра yeo теперь должен объявить Gamin Battle Royal на тему "кто круче программирует" =)
Геймдизайнит. Программирование для математиков.
Срется в коммах. Геймдизайн для игроделов
Справедливо.
205 комментариев срачика? Неплохо-неплохо, как в старые добрые, гаминчик торт. :-D
Сайт будто расцвел))
Изучаю GM, Решил ещё раз перечитать пост, чтоб лучше вникнуть в суть вопроса.
PS хотя в комменты лучше не окунаться :D