Всё ещё учусь работать в Game Maker (GMS 1.4.9), параллельно участвуя в конкурсе на GCup.
FFYESw3

pD3RuF8
1)Немного неприятно, то что разрешение экрана и FPS нужно менять в каждом уровне отдельно,
по логике это должно выноситься в опции и быть общим для всех уровней.
2)Также немного прокачал рисование персонажа для кастомизации, хотя возможно это всё будет лагать при 60 FPS на слабом ПК, я не уверен:
OS8NXfD

551 комментарий

Всё-таки обычная физика лучше, чем вручную писать, и криво получаются отталкивания и лишняя трата сил)
и много кода
dPP4KCn

Да уж. Читая все вышенаписанное, наверное реально уже GMS (Game Maker Studio) более-менее хорошо изучить ;) Не совсем понял - что за обычная физика и чем хуже - когда её вручную пишешь. Есть твой же собственный способ о котором ты писал про рисование. Если что-то не умеешь сам - делай как делают другие :))) Но тут проблема в том, что невозможно всегда делать как делают другие. И вот ты уже как раз столкнулся с такими проблемами. То есть рано или поздно тебе придется и что-то свое писать, а не только делать как делают другие или использовать готовые решения. Именно поэтому движки с открытым кодом лучше, чем движки с закрытым. Но тут, как говорится, каждый волен впадать в любые крайности. Не хотел ничего плохого сказать про GMS и твой выбор изучать его. С чего-то ведь надо начинать. И конечно, поскольку знаний программирования, как я понял у тебя не слишком много (не хочу конечно обидеть, если что извини), и изучать глубоко программирование тебе не интересно, то вот так и будет - вечная дилемма - или использовать чужие (но не всегда такие, как тебе хочется) решения или пробовать писать свои (но это гораздо сложнее если делать на таких движках как GMS). Опять же, не хочу никого обидеть. Это лишь моя личная точка зрения, я не пытаюсь никому ничего доказывать :)))) Я вот тоже (если мой опыт тебе будет интересен) - сначала изучал готовый движок (но правда там был открытый код), но когда я его изучал (DelphiX - такой движок), то знаний у меня было слишком мало. Первая игра на нем была Road2City - дорога в город. Делал её несколько лет. Зато когда закончил - знаний было уже достаточно чтобы начать писать свой движок. И потом уже все игры делал с использованием своего движка. Движок был сначала Delphi Direct X (написанный практически с нуля). DelphiX - был для 7 DirectX, Delphi DirectX уже для 8.1, а fle game engine уже написал на c++ и работает он под DirectX 9.

Понятно что у каждого свой путь. Но лично у меня был вот такой опыт. Потом уже (чисто профессионально) писал движки для сайтов или делал сайты на готовых движках (но чаще дорабатывал). Также писал разные другие веб приложения. Сейчас вот последние 2-3 года уже заинтересовался не только dektop приложениями, но и html 5 играми (на javascript). Лично я предпочитаю движки с открытым исходным кодом, просто потому что мне так понятнее и удобнее.

Вот такие мысли. Заранее прошу простить если кого-то чем-то задел или обидел. У каждого своя личная точка зрения и не надо обижаться на чужие :))))

рано или поздно тебе придется и что-то свое писать, а не только делать как делают другие или использовать готовые решения. Именно поэтому движки с открытым кодом лучше, чем движки с закрытым.

Не поэтому. На Гамаке с закрытым исходным кодом прекрасно можно писать свою физику. А лучше движки где есть свой язык программирования, чем движки где своего языка программирования нет - это отличие полноценного игрового движка Гейм Мейкера (и, кстати, Годота) от конструкторов сред разработки опирающихся на языки общего назначения, типа Юнити и Анриала. К чести последнего, когда-то свой скриптовый язык у него был, но уже нет, увы.

Мне сложно судить, т. к. мой опыт работы с GM стремится к нулю. У вас он вижу намного намного выше. Но я высказал мнение. И мне кажется, что по сути оно правильное. Если исходный код движка открыт - то решения делать проще, чем на движке с закрытым - писать код, который обходит те или иные ограничения. Выше очень много было сказано про разные движки :)))) И каждый, кто хорошо знаком с тем или иным движком обязательно докажет, что его движок - лучше. Вы по сути это и делаете сейчас. ;) Однако посмотрите на цитату которую вы процитировали с другой точки зрения и сравните со своим личным опытом. Вы всегда использовали готовые решения в GM (и GMS) ? Или все же больше и чаще писали что-то свое ???

Если исходный код движка открыт - то решения делать проще, чем на движке с закрытым

Количество различных применений движка не настолько большое, чтобы постоянно приходилось что-то решать или обходить ограничения.

Вы всегда использовали готовые решения в GM (и GMS) ? Или все же больше и чаще писали что-то свое ???

Для этого надо посчитать все решения во всех проектах, а их много - и решений, и проектов. Ну в среднем могу сказать что бывало и так и так, и не сказать что редко одно или другое. Свою систему коллизий я писал только в платформерах, и то не для всего, а только точечно, и опять же на встроенных функциях проверки столкновений по заданным линиям. Свою отрисовку интерфейса надо, безусловно, писать везде и всегда - нет ведь готовых интерфейсов где уже всё выводится как твоей игре надо. Поиском пути я не занимался никогда, потому что не работал в жанрах где это нужно. Но если бы начал, то вполне мог бы приспособить тот поиск методом "A*", который туда уже встроен. И так далее.

Что вообще есть готовое решение, а что неготовое? Где грань?

Анимация кадров изображения подряд - это готовое, а анимация их в зависимости от того куда смотрит персонаж - неготовое? Но ведь я написал это "неготовое" на основе другого готового - мне в языке программирования Game Maker Language дают возможность задать любую другую логику переключения кадров, и я просто пишу:

image_index = character_direction*4 + image_index_current

И получается что я поменял порядок отрисовки, без какого-либо переписывания движка игры, и в то же время не превозмогая какие-то страшные горы ограничений. Таких примеров можно привести много - того что можно сделать обладая встроенным скриптовым языком, для движка с закрытым исходным кодом. Потому что исходный код движка это всего лишь машина, а заставить её работать как нужно позволяет промежуточный скриптовый язык.

Именно поэтому количество готовых и неготовых решений, использованных мной, ничего не скажет, да и не послужит аргументом в пользу своих самописных движков. Это количество будет говорить только о том, каких жанров игры я делал - более просто реализуемые в движке, или менее просто реализуемые.

Я имел в виду буквально - то есть все то, что можно нагуглить. Хорошо, собственно я не пытался никого переубедить. Каждый пользуется тем, что ему ближе, понятнее и удобнее (и еще тысяча причин :))) ). Лично мне ближе движки, где код можно "потрогать" - просто потому что можно реализовать те или иные особенности лучше понимая как оно устроено изнутри. Кроме того, движки с открытым кодом не дают вам быть зависимым от движка. Легко можно перейти на другой. В случае с движками закрытого кода - GM, Unity 3d - вы целиком и полностью зависите от движка. И будет сложно сделать что-то что движок не позволяет. За вашу жизнь в геймдеве вы просто не делали игр, у которых были бы такие возможности, которых нет в движке. Я не говорю, что это плохо или что-то подобное. Просто лично мне всегда интересно знать что и как устроено изнутри. Именно поэтому я выбираю движки с открытым кодом и они ближе. Ну а вам это неинтересно :))) Вам интереснее делать игры используя только те возможности, которые движок предоставляет. Ну а то, что касается самых простых задач - наподобие вывода интерфейса - эти задачи не настолько сложные, чтобы движок мог чем-то помочь. По сути он в данном случае не играет вообще никакой роли :))))

В случае с движками закрытого кода - GM, Unity 3d - вы целиком и полностью зависите от движка.

Как будто это что-то плохое)), для меня куда хуже с нуля движок писать, ведь разработка простой инди игры может растянуться в 2-4 раза дольше. И да, кому-то ближе движки делать, кому-то игры) Я сейчас хочу наоборот ещё больше упростить разработку, чтобы только скриптинг уровней писать, а основные модули чтобы уже были готовы, раз и навсегда, что-то типа Bitsy, только более навороченная, но всё также должна ускорять разработку коротеньких инди проектов.

Скорее в 20-40 раз, если не в 200-400 =)
Очень много рисков при отладке. А поддержку платформ и прикручивание чужого API (тот же Steam API) тупо заебёшься делать.

То что юзеры гамака полностью зависят от движка, а тру-программисты - нет. Это иллюзия. На деле точно такая же зависимость от "движка", которым выступает язык программирования и среда разработки. Начать с того что синтаксис любого языка беден в силу своей формализованности чтобы быть понятным комплиятору. Вот на естественном языке можно сказать гораздо больше! Можно слова местами переставлять, например, использовать склонения, спряжения, делать мелкие отчепятки.

А в том же Си ты никогда не сможешь написать того что можешь написать на Асме. А на асме порой невозможно сделать то, что делается распайкой платы.

Вот хочу я картинку за один такт процессора обрабатывать. Может ваш Си или JS это сделать, на чём угодно? Хуй-то там. Фуууу, дерьмо-фреймворк и дерьмо-язык!

А ещё я хочу чтобы у меня один бит принимал три значения, а не два. И чтобы можно было быстро управлять троичной системой, а не двоичной. Ваши процессоры интел и амд - говно, раз такое не могут.

Ебать, сколько ограничений я нашёл в этих ваших хвалёных фреймворках! Вот вы целиком зависите от вашей железки и его набора инструкций!

Вот вы читате и думаете что я сошёл с ума, что вам и в голову не придёт использовать троичную систему вместо двоичной или никогда не понадобится картинку за такт процессора обрабатывать. Так вот нам, юзерам гамака точно так же не придут в голову какие-то супер-редкие задачи, еле связанные с разработкой игр. В контексте работы с гамаком задача "останавливать апдейт но не останавливать рисование" - как раз одна из таких ненужных и бесполезных. Там просто другими категориями и абстракциями мыслить нужно и не пытаться проектировать и писать код так как вы привыкли в языках общего назначения.

Я считаю, что тема "зависимости от движка" на этом должна быть закрыта

А поддержку платформ и прикручивание чужого API (тот же Steam API) тупо заебёшься делать.

Лол, я это не учитывал, тогда реально в десятки раз сложнее)

Отладка тоже очень много времени сжирает. Учитывая, что в "нормальных тру-пацанских движках" ты порой не можешь вообще нормально инспектировать некоторые структуры данных (текстуры, сложносочинённые поля объектов).

Кроме того, движки с открытым кодом не дают вам быть зависимым от движка. Легко можно перейти на другой.

Серьёзно? Давайте возьмём вот таблицу игровых движков с Википедии, отфильтруем её по типу лицензирования, и посмотрим с чего на что можно пробовать перейти:

https://en.wikipedia.org/wiki/List_of_game_engines

С движка файтингов на движок шутеров? Точно нет. С языка FreeBASIC в одном движке на язык NScripter в другом? Вообще никак.

Нет игровых движков, которые разрабатываются бесцельно.

Каждый движок решает свой ряд задач, и именно потому неуместно считать Юнити адекватным для двухмерных игр, как и Гамак для трёхмерных. И даже если бы все они были с открытым исходным кодом, это бы никак не помогло переходить с одного из них на другой.

В случае с движками закрытого кода - GM, Unity 3d - вы целиком и полностью зависите от движка.

В случае с процессорами Intel или AMD - вы целиком и полностью зависите от аппаратной архитектуры которую никак не можете поменять. Почему люди не делают свои процессоры? Потому что существующих хватает. Так и с движками.

мне всегда интересно знать что и как устроено изнутри. Именно поэтому я выбираю движки с открытым кодом и они ближе. Ну а вам это неинтересно :)))

Да нет, мне это интересно, но только в формате экскурсии, а не чтоб писать это всё руками заново самому. Я так-то и процессор когда-то 8-битный проектировал, в учебном проекте. Я действительно знаю как это делается, и при наступлении зомби-апокалипсиса могу вытравить печатную плату с какими-нибудь несчастными 1МГц тактовой частоты, правда для этого нужна элементная база из уже существующих микрочипов, реализующих логические операции, мультиплексирование и синхронизацию. Но это всё не про нашу реальную жизнь на сегодняшний день.

Я время от времени продолжаю разрабатывать игру для NES, известную у нас как Денди. Это порт на неё, нашего Замка Невозврата 1. Хотите расскажу в отдельном посте?

Вам интереснее делать игры используя только те возможности, которые движок предоставляет.

"Вам интереснее делать игры которые максимум заработают всего лишь несколько миллионов долларов и соберут всего лишь сотни тысяч отзывов в Стиме. Не более чем! Вы ограничены вот такой вот скучной планкой, потому что не хотите смотреть на движки с открытым исходным кодом!"

Я время от времени продолжаю разрабатывать игру для NES, известную у нас как Денди. Это порт на неё, нашего Замка Невозврата 1. Хотите расскажу в отдельном посте?

Я бы это почитал, ибо мне до сих пор интересна разработка игр на NES, хотелось бы самому что-нибудь там написать. Хотя есть один интересный конструктор NES, забыл название, который упрощает разработку, потом хочу как-нибудь приобрести его.

точно)
Ты на нём делаешь Замок Невозврата?!

Нет, я использую злостную связку древней магии, куда не ступала нога обычного человека.

http://hype.retroscene.org/blog/282.html

Именно это мне позволяет смотреть на аргументы типа "свой движок лучше всего" с очень большим (потому что обоснованным) скептицизмом.

Жесть) Я лучше NES Maker потом куплю)

Не совсем понял - что за обычная физика и чем хуже - когда её вручную пишешь

Я не совсем разобрался, но похоже там есть библиотека физики что-то типа Box2D (а может и она и есть)
а вручную, это что-то типа, когда сам определяешь с какой скоростью нужно отталкиваться объектам и в какую сторону, и поскольку я с математикой совсем не дружу, то получается не так хорошо, как могло получиться у математика.

Я только хотел предостеречь от надежд, что движок все сделает за тебя :))) Такого не бывает. И даже если тебе говорят - вот движок - в нем все делается легко или по крайней мере так кажется, то, поверь мне, такого не бывает. Ты всегда захочешь сделать так, как до тебя никто не делал и поэтому движок тут будет не помощник, а скорее обуза :)))) Понятно что есть набор функционала, который позволяет сделать типовую 2d игру и GM за глаза этого хватает. Например можно сделать игру на html5 в GM. Вопрос только: зачем ? Если все то же самое можно сделать просто в блокноте и браузере :)))) Так что движок - а именно GM не всегда может быть тем инструментом, который поможет тебе сделать игру своей мечты (ну или игру которую бы ты смог сделать). И даже если там есть какой-то функционал из коробки, я не уверен, что все это тебе пригодится. Движок в данном случае будет тебя не поддерживать, а ограничивать. Те кто к нему привык, понятно на это закрывают глаза. Ну а если приходит человек со стороны, имеющий другие взгляды, то ему становится очевидным, что ни GM, ни Unity 3d не являются движками мечты :))) Это инструменты, но даже если рассматривать их просто как инструменты, то и тут мы наткнемся на грабли. Все дело в том, что совершенных движков в природе не существует. И в случае движков с закрытым кодом мы попадаем в клетку. Нас ограничивают настолько, что мы уже не сможем сделать все так, как захотим. Понятно что каждый выбирает сам, в какие рамки он себя загонит. И я лишь высказываю свою точку зрения и ни в коем случае не считаю, что игры надо делать на чем-то одном и этот инструмент - самый лучший. Надо попробовать все. Просто из того, что я умею и знаю я сделал для себя именно такие выводы. Движок с открытым кодом - всегда лучше. Операционные системы с открытым кодом - тоже лучше. Да и вообще чем меньше ограничений, тем лучше. А ограничения, увы, есть всегда и везде.

Для меня, как художнику, на самом деле даже Unity3d и GMS сложен, потому-что очень много приходиться программировать, а в случае с движком с нуля это "много" может растянуться до бесконечности)
По части открытого кода, мне не нравится, что там часто куча разрозненных библиотек или тонна неоткомпилированных файлов, в которых надо ещё научиться разбираться, и ещё надо поставить тонну сторонних инструментов, мне нравится когда в одном инструменте всё и сразу или хотя бы порог вхождения должен быть делом 5 минут для не программиста, у меня например даже Visual Studio на винду не поставлена и другие внешние компиляторы не ставлю, не влезая глубоко в дебри программирования)

Если рассматривать движок для художника и пытаться на нем сделать что-то что движок не позволяет, да еще не обладая достаточным уровнем знаний. Вот как раз пост https://gamin.me/posts/21100 где я задался вопросом подобного рода. То есть что мы все делаем, когда наши представления оказываются бесполезными.

Вообще, если вспомнить, то из движков с открытым кодом, кажется есть один, что мне нравится - Годот.
Благо там почти все инструменты внутри, даже кодинг (кроме рисования спрайтов). Но пока сильно не пытался его изучать, закончить бы со старыми проектами на Unity и GMS для начала, а там посмотрим)

Чем больше движков знаешь, тем лучше, выбрать какой-то один - трудно, тем более не обладая достаточными знаниями ни по одному из них. Не зная хорошо программирования и прочее и прочее. Соглашусь с тем, что Unity и GMS были созданы программистами для непрограммистов. Только вот проблема любого движка - это то, что его сначала надо изучить :)))) Если пытаться решать с наскока, то можно лишь писать простейшие прототипы с задействованием самого простого функционала, который есть из коробки. Но я хотел высказать вот какую мысль. Все движки - это как "каша из топора". То есть любой движок в той или иной мере это "топор", а кашу мы вынуждены варить используя его сами :))))

Чем больше движков знаешь, тем лучше

Или можно всю жизнь произучать движки, но так и не сделать ни одной игры. Или ни одной успешной игры,
которая, если не принесёт много денег, то принесёт много фанатов или благодарных людей.
Время не резиновое, к сожалению.(

Что значит рисование спрайтов?

Я имею ввиду что спрайты надо рисовать отдельно, забей, это можно было даже не писать) это не придирка, просто меня приучили Game Maker и Tic-80, что можно спрайты рисовать прямо в редакторе, но это не критично, в Юнити и Годоте я не прошу, чтобы ещё и сделали внутренний редактор спрайтов.)

Отвечу, что можно. Я уже тебе дааавно это объяснял и показывал. В Godot есть возможность создания объектов, как через редактор, так и через код. Единственно, в редакторе все настраивается, через инспектор, в котором все настройки ноды видны, а в коде все необходимое нужно прописовать самому.

Если тебе нужен пиксельный редактор в движке, то есть плагины. Цельных две штуки, правда они не имеют широких возможностей, как в паинте, но развиваются.

Рисовать спрайт через код проще некуда:

var image = Sprite.new()
image.texture = blablabla
image.rect = bla
#и так далее

Я про редактор. А так да, видел там специальные функции рисования в годоте (не создавая отдельный объект), там действительно лучше с этим, чем в юнити.

И в случае движков с закрытым кодом мы попадаем в клетку. Нас ограничивают настолько, что мы уже не сможем сделать все так, как захотим. Понятно что каждый выбирает сам, в какие рамки он себя загонит.

Надо сказать что это действительно со мной произошло, и в довольно серьёзном масштабе. В начале 2019 года надо было релизить игру на Иксбокс, а сделать я этого не мог потому что Microsoft поменял API не предупредив об этом YoYoGames (владельцев Гамака). В итоге я как дурак писал в техподдержку подробнейшие отчёты на английском, ждал несколько месяцев, пока они починят привязку Гамака к этому API, хотя теоретически мог бы сам в Visual Studio переписать нужную мне часть движка. Однако, здесь речь не о том чтоб сделать игру, и игра которую я сделал, определённо заняла бы долгие годы вместо чтоб уже быть выпущенной даже с такой задержкой и принести вполне ощутимые, как для пост-СССР, деньги.

Увы. От такого никто не застрахован. Случиться может что угодно. Завтра все перейдут на linux или еще какую-то новую ОС. Вообщем да. И тут вы правы - не играет роли открытость/закрытость, а скорее какие-то совершенно малозависящие от наших усилий факторы.

Показать старые комментарии
Написать комментарий