Mighty Final Fight. Vol.0
volume 0
-3 :: -2 :: -1 :: 0 :: 1 :: 2 :: 3
Предупреждение!
Хочу еще раз подчеркнуть несколько важных моментов и больше к ним не возвращаться.
Цель данного цикла: поделиться опытом создания битэмапов на гейм мейкере (8.0 Pro).
Плюсы: в итоге мы получим работающий битэмап.
Минусы: не все будет сделано оптимально, наверняка какие-то вещи будут решаться через одно место и так далее. То есть воспринимать эти статьи как туториалы по изучению гейм мейкера (ГМ) не стоит. В то же время, я прошу старших товарищей поправлять меня, указывать на ошибки, подсказывать оптимальные решения. Таким образом новички не будут учиться неправильным приемам, и все мы наберемся опыта.
Общие моменты
Подразумевается, что вы минимально знакомы с инструментом. Я не буду начинать с основ и рассказывать вам, что такое комната, как создать объект и прочие базовые вещи. Однако стоит остановиться на некоторых вещах, чтобы прояснить мое понимание и подход к созданию игр на ГМ.
1. Комнаты
Я воспринимаю комнату, как часть игры, принципиально отличающуюся по функциональному назначению.
Например:
1) Титульный экран
2) Заставка перед и после уровня
3) Непосредственно игровой уровень
4) и так далее...
Так как я использую готовые бэкграунды (то есть не собираю их из тайлсета), то редактором комнаты (в котором расставляются объекты и собирается по кирпичикам бэкраунд) не пользуюсь.
Соответственно, любой игровой уровень происходит всегда в одной и той же комнате.
2. Объекты
Методологически, я разбиваю все, что будет в игре на отдельные сущности и для каждой создаю object.
Например:
1) Главный герой (ГГ)
В большинстве битэмапов существует выбор персонажа. Однако разные персонажи это один и тот же игровой объект "Главный герой". Персонажи будут различаться характеристиками (сила удара, количество энергии, спрайты и т.д.), но суть остается прежней.
2) Враг
Враги бывают разных типов, но это то же самое как разные персонажи, предоставляемые на выбор игроку. При описании игровой логики мы будем проверять, например, столкновение с врагом. И если все враги описаны одним объектом, то и проверять столкновение нужно будет только с копиями этого объекта.
3) Интерфейс
Это тоже отдельный объект, посредством которого мы будем выводить на экран энергии ГГ и врагов, количество набранного опыта и так далее.
4) Бэкграунд
Хотя в гейм мейкере существует отдельный вид объекта background, я рекомендую использовать обычный игровой объект и привязывать к нему спрайты с задниками.
5) и так далее...
Важно понимать, что описанный object, это, условно говоря, эталон, с которого в игре будут создаваться копии. Например, если вы захотите посчитать сколько врагов у вас в текущей игровой комнате, надо будет воспользоваться функцией instance_number(obj), которая посчитает количество копий указанного объекта в комнате.
3. Спрайты
Я экспериментировал с разными подходами к анимации персонажей и пришел к собственному способу вывода картинок на экран. В свое время я расскажу вам о необходимости "хитрого пути" в данном случае. Пока лишь скажу, что анимации персонажей вне игры лучше хранить в виде стрипов, а добавлять в игру в один спрайт. То есть абсолютно все кадры для одного персонажа будут лежать в одном спрайте ГМ.
4. GML
Мы будем использовать только встроенный язык ГМ -- GML, поэтому из всех действий (actions) объекта нам понадобится только Execute a piece of code (вкладка control > code).
При создании комнаты (спрайта, объекта и т.п.) она автоматически нумеруется. То есть первая созданная комната по умолчанию называется room0. Я настоятельно рекомендую не забывать про порядковый индекс (в данном случае, 0) при переименовывании, так как по этому индексу удобней и проще обращаться к объектам через функции. Нумерация идет сквозная и не учитывающая удаленные объекты, в связи с чем в дальнейшем можно легко запутаться в индексах, если удалять их из названия объекта.
Из общих моментов это, наверное, все.
Ресурсы
В первом приближении мы попытаемся реализовать боевую систему Mighty Final Fight (MFF), для чего, по минимуму, нам понадобятся следующие спрайты:
Анимации ГГ
Анимации врага
Бэкграунд первого подэтапа
На этом приготовления можно считать законченными, а в следующем выпуске мы разберем боевую систему MFF по частям, чтобы приблизительно понимать что именно и как мы будем реализовывать.
- 06 февраля 2012, 16:01
Добавь какую-то картинку в шапку, пожалуйста, так пост будет симпатичнее выглядеть, например, на главной :)
Хорошо ))
И под кат, видимо, надо убрать. Сейчас сделаю после перекура.
я говорил, что я буду критиковать по программированию)
этот абзац по идее создаст у непрограммистов неправильно представление о классах. Объектами в программировании являются экземпляры класса, в то время как класс это описание набора свойств и методов. Ты же называешь свои объекты классами, не вяжется, путаница получается. Переименую пожалуйста в класс или тип или как-то по другому, но только не объект. Или убери вставку о классах в программировании. Непрограммисты все равно не поймут, а программистам диссонанс создаст.
Вот! Спасибо! Ты поправляй меня сразу же!
Надо будет все исправления в подвале статьи записывать, или переписывать по результатам критики.
Как лучше, кстати?
Напиши, что объекты это абстрактные сущности, реализующие некоторое поведение. Думаю, этого хватит.
имхо, фраза "асбстрактные сущности" для многих будет слишком.
Ок, укоротим до просто "абстракции" :)
да зачем?) объект это объект, конкретный экземпляр кокретного типа, так непрограммисту все гораздо понятнее)
Осталось объяснить непрограммисту про "типы" и "экземпляры" и всё пучком :)
Не надо объекты переназначать на описание классов. Нехорошо это. Классы, это классы, а объекты, это конкретные экземпляры классов.
я именно об этом. http://gamin.me/blog/indie-fishki/7115#comment-44191
Ну так всё логично: класс описывает, объект класса реализует. Я ничего не переназначал.
Ты не шаришь, в ГМе "объекты" имеют значение "класс" ООП, тогда как "объект" ООП это в терминологии ГМа "экземпляр объекта". То же самое относится к Козинаке и другим мейнстримщикам от геймдев-погромирования.
Та я давно в курсе.
м-м. Ну да, у Гамака свой, особый путь
Это правда!
- атрибутов и методов, ты имел в виду?
Чёрт, не успел :)
исправил, опечатался)
например: герой, враги, интерфейс, бекграунд etс это классы, в которых описаны различные свойства и методы, которыми обладают их экземпляры.
в то время как наше протеже, конкретный враг, видимый нами интерфейс, конкретный бекграунд - это все объекты, то есть экземпляры классов.
так понятнее картина?)
Погоди. Перечитал еще раз. В ГМ это называется объект, а я его вижу как класс. Вроде все правильно?
Уходить от названий ГМ тоже наверно не верно.
GM зло...
выхода два: либо убрать упоминание про программирование, либо разъяснить ситуацию в расхождении с терминологией.
по идее GM создает объект, без предварительного описания класса, это ведь не программирование. то есть можно так и написать, что с точки зрения программистов Game Maker создает готовый объект без описания родительского класса.
А в GM есть какие-то части туториала по этому поводу? Если да, то проще всего скопировать инфу оттуда с указанием авторства и оставить подобные неточности на совести авторов GM.
Мы в ответе за тех кого научили)
Против инструмента не попрёшь
аналогию либо проводить, либо не проводить, от этого суть определений "объект" и "тип объекта" не изменится, поэтому надо выражаться максимально грамотно)
Ну, с учётом того, что yeo описывает создание конкретно beat'em'up'а, то мы вообще можем помочь ему, подогнав use case и диаграммы классов, которые он потом с нашей помощью адаптирует для GM.
никогда не работал в GM. не знаю каким образом там реализована вся эта система наследования.
сложилось такое представление: создаешь объект, описываешь все его свойства (и методы, если вообще там есть), где-то там в глубине движка создается "класс" данных (скорее всего таблица в БД), а потом можно создавать копии на основе этого объекта. система жуткая конечно
Вряд ли таблица, скорее там просто интерпретатор, в котором крутится фабрика классов. Вся объектно-ориентированная модель железобетонно залита ещё при компиляции самого GM :)
может быть, не спорю, в метапрограммировании не силен)
даже скорее всего именно так
Я за то, чтобы по максимум помочь yeo с терминологией и теорией программирования. И диаграммы тоже будут полезны, я их на гамине вообще ни разу не встречал.
Но сейчас, к сожалению, на моем далеком нефтегазодолларовом острове уже почти полночь, а завтра как всегда рано вставать, так что отправьте меня спать...
Споки :) Завтра ринешься в пучину обсуждения с новыми силами
мне еще свою статью на такую же тему (разве что другая платформа и будет шмап) писать)
спасибо)) лучше бы в итоге это все почистили)
P.S. Чо-то хрень какая-то =/ Поток мыслей.
в общем стандартный механизм наследования. разве что классы назвали объектами
вообще очень сложный абзац
сначала разберу второе предложение. смотри, получается что ты берешь игровые объекты - делишь на сущности - создаешь из них объекты. Ты как-то неправильно выразил свои мысли
а по первому предложение можно так
как прочитаешь всё, параллельно с исправлениями начни чистить наши комменты, слишком много никому не нужного флуда
мне кажется, что под объектом в GM все же подразумевается тип объекта. Потому что объект это все же конкретная сущность, как ручка на моем столе или кружка, а не все подобные ручки и кружки.
туда же. замени вид на "тип"
этот абзац все разъясняет, но путаницу наверху все равно поправь.
Не понимаю, зачем нужно создавать отдельные объекты для интерфейса и фона.
Делал что-то на ГМ больше года назад, если честно, сейчас уже и не помню, почему я в итоге отказался от использования background для задников. Но какая-то причина точно была ))
Ну а для интерфейса, мне кажется, очевидно, что нужно использовать отдельный объект. Может быть в дальнейшем это станет понятно, а может я и ошибаюсь.
нашел интересную аббревиатуру "MFF", что означает?
Mighty Final Fight скорее всего :)
что бы не означало, аббривиатура "MILF" гораздо интереснее.
Так и знал что будете ржать над этим ))
Ну вы понаписали про объекты.) Мутные дебри программирования. Сам с классами не умею работать.
Все, что нужно знать об объектах в гм (на мой взгляд):
Объект - это понятие. Чашка, ложка, лапоть. У него есть свойства и свое поведение. Но в игру мы добавляем не объект, а его образец. То есть, экземпляр объекта. Все образцы имеют свойства объекта.
Однако может быть такая ситуация: есть три объекта разных врагов. Однако ж они одинаково реагируют на удары ГГ. Чтобы не писать код для взаимодействия с каждым отдельным врагом, делаем следующее: создаем пустой объект obj_enemy, и у остальных объектов ставим его в parent (делаем его родительским). Далее пишем код только для взаимодействия с obj_enemy, автоматически все взаимодействия будет переноситься и на "деток".
Описание твое мне понравилось, но выделять родительский объект я бы не стал. Прежде всего из-за косяков. И из-за увеличения количества объектов (на мой взгляд, не нужного в данном случае).
Я буду читать все комментарии, прежде чем писать.
Я буду читать все комментарии, прежде чем писать.
Я буду читать все комментарии, прежде чем писать.
Я буду читать все комментарии, прежде чем писать.
ты сейчас описал один из постулатов объектно-ориентированного программирования)
проблема тут в терминологии, ведь слово объект во всех словарях трактуется однозначно: Объе́кт (лат. objectum — предмет) — предмет, явление или процесс, на которые направлена предметно-практическая и познавательная деятельность субъекта (наблюдателя). то есть объект и в общечеловеческой и в программистской терминологии это экземпляр класса, но никак не сам класс объектов. за это авторам GM жирный минус.
Так. Давайте еще разок про объекты, классы и так далее. Как правильно написать, чтобы никого на запутать?
В ГМ идет описание объекта, но в игровой комнате создается копия объекта (instance в их терминологии).
Насколько я понимаю, в нормальном программировании есть класс, а создаются экземпляры класса.
То есть в сравнении с ГМ (гм - программирование):
объект - класс
instance - объект (экземпляр класса)
Я правильно понимаю?
instance это и есть экземпляр в переводе терминов.
Очень сложно говорить что-то, не зная, как оно внутри GM.
Вероятно, там стандартная ОО-модель. Когда мы описываем объект, то мы говорим, что да, действительно будет создан объект. Объект класса, который уже написан в самом GM. По сути мы создаём объекты стандартных гамаковских классов, задавая им уникальные параметры. С этой точки зрения программист на GM может оперировать лишь объектами классов и в терминологии нет расхождений.
Ну да.
Описание объекта - класс.
Instance (экземпляр, копия) - объект.
Особых конфликтов в терминологии нет, просто описание объектов производится, видимо, через ключевое слово object и в речи упрощается до просто "создаёшь объект", "мой объект" и т.д. На самом деле есть "описание объекта" и "экземпляр".
Такая формулировка подойдет?
Объекты в ГМ это аналоги классов из языков программирования. То есть когда вы создаете object в исходнике ГМ, вы фактически создаете новый класс с присущиму ему свойствами.
В игровой комнате при этом вы будете создавать экземпляр класса -- instance.
Методологически, я разбиваю все, что будет в игре на отдельные сущности и для каждой создаю object.
Важно понимать, что описанный object, это, условно говоря, эталон, с которого в игре будут создаваться копии. Например, если вы захотите подсчитать сколько врагов у вас в текущей игровой комнате, надо будет воспользоваться функцией instance_number(obj), которая посчитает количество копий указанного объекта в комнате.
Нет. Почему нет - см. мой комментарий ниже
Так. У ГМ есть класс. Мы создаем объект этого класса. А в игру что добавляем? Экземпляр объекта? Или как?
У GM есть класс, который мы условно назовём Atom (не хочу называть его GameObject, чтобы не вносить дополнительную путаницу). От него наследуются различные компоненты конструктора: спрайты, экшены, контролы. Вся иерархия классов уже придумана авторами GM. Когда мы создаём что-то в редакторе GM, то создаётся экземпляр (объект) соответствующего класса, будь то кнопка или спрайт.
Т.е., перефразируя тебя:
У ГМ есть класс. Мы создаём объект этого класса. Гамак добавляет его в игру.
Да, это я понял. А в игре-то что создается в итоге? Если объект ГМ это уже экземпляр класса.
Нет, "объект ГМ" это скорее упрощение для пользователя. То есть будем считать "объект ГМ" типом данных. Значит, в игре создаётся экземпляр класса "объект ГМ"
Я собственно хотел донести мысль, что при создании объекта в игре, создается по факту его копия. А не он сам.
По gamemaker'у есть довольно подробная справка, которая даже переведена на русский. Можно просто взять описание оттуда:
Добавил картинку и убрал под кат.
Картинка убила конечно :))
Ржачная штука! :)
картинка что надо)
Так, братцы. Что-то мы уходим куда-то не туда, мне кажется.
Может я просто уберу фразу про программирование и дело с концом? Чтобы никого не путать. А то я боюсь, что мы можем уйти в дебри, и это только оттолкнет новичков.
Что если оставить так:
Методологически, я разбиваю все, что будет в игре на отдельные сущности и для каждой создаю object.
Важно понимать, что описанный object, это, условно говоря, эталон, с которого в игре будут создаваться копии. Например, если вы захотите подсчитать сколько врагов у вас в текущей игровой комнате, надо будет воспользоваться функцией instance_number(obj), которая посчитает количество копий указанного объекта в комнате.
Норм
Исправил.
Спасибо за терпеливое объяснение, кстати говоря.
You welcome (:
67 комментариев, из них 65 по классам и объектам))
ты продолжай статью
Пацаны вообще котята: пока читал комментарии, раз пять для себя уяснил все непонятные для меня моменты ООП (объекты, классы...) и столько же раз эти непонятные моменты замутнялись.
Да, очень надеюсь на продолжение. МОжет быть потому, что чертовски люблю бит-эм-апы и даже хочу сделать такую на гм как раз +_+
Да.. но сначала надо закончить платформер
Конкретно меня интересует вторая часть, по коду)
Вопрос по юзабилити статей.
Понятно, что вначале идет содержание на все выпуски цикла или оно незаметно?
Может стоит его (меню) по-другому переделать?
Честно, мне нравится, ка это делает Козинака.
Наверное, стоит избавиться от спойлера. Если выйдет громоздко, оставить ссылки на предыдущую и последующую статьи.
У Козинаки мне тоже нравится. Но тут слишком много пунктов, и я хотел бы давать осмысленное заглавие, а с таким количеством постов уместятся только порядковые номера, а это думаю бессмысленно.
Может быть, предыдущая/следующая будет лучше.
Надо подумать.
Порядковые номера, это вполне себе осмысленно. Главное, что нужно от навигации, когда ты читаешь один из Vol. это возможность найти первый пост, предыдущую и следующую часть. Полоса с цифрами вполне это позволяет. А подробные названия можно уже заглянув прочесть.
А можно всплывающими подсказками оформить: -1 0 и так далее
Отличная идея! Завтра тогда переделаю меню.
Исправил меню. Пока вставил только циферки, получилось не очень, по-моему. Но пусть будет так пока.
А по-моему, здорово выглядит. Будет ещё лучше, когда постов будет под полтора десятка (а, судя по подробности изложения, будет).
P.S. Номер текущего поста оставляй без ссылки.
Задолбаюсь обновлять меню, если еще и без ссылки убирать на текущую статью. Думаю в конце цикла пройдусь по всем статьям и сделаю как надо.
Я тут впервые, и не сразу обратил внимание. Исправился, все осмотрел. Но так как я очень ленивый и думаю, что имею представление обо всем этом, интересуюсь GML-частью статьи.
А так-то очень подробно всё, с объяснениями. Мне все нравится!
В следующем выпуске будем делать масштабирование, титульное меню (старт-контролс) и сменное управление. Ну и добавим игровой шрифт из спрайта.
А потом уже займемся разбором боевой системы.
У меня будет сильно заточено на битэмап, поэтому для платформера, боюсь, эти статьи тебе мало сгодятся.