MrMouseSE

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

Итак, билд0_0_3. И reFUCKtoring!

Честно говоря это стало для меня неожиданностью. Вернее не сам рефакторинг, его-то я как раз ожидал (изначально всё начиналось, если кто помнит, так, что рефакторинг был лишь делом времени), а вот то, что назреет так быстро - нет. Как я уже говорил в пред. посте - основная проблема нодального программирования в ГРОМОЗДКОСТИ. Адовой, неподъемной громоздкости. В этом отношении GMS2 ещё и проигрывает той же UE4, где можно зафигачить всё более-менее наглядно:

и это реально - НАГЛЯДНО и более-менее понятно. В GMS2 же всё куда как хуже: парадигма расположения блоков в GMS - сверху вниз, в итоге в каждом действии у вас будет вот такая партянка:

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

Честно говоря - я не очень уверен, что условия в нодальном GMS2 удобней и читабельней, чем в GML (game maker language):

но совершенно очевидно, что из-за своей громоздкости работать с ними - невозможно.

Итак, рефакторинг! Почему и что привело? Я уже показывал скрин obj_player - там я делал всё на уровне свойств объекта (create,step,collision, etc), что, как уже писал - не удобно с точки зрения того, что постоянно приходится переключаться между закладками и невозможно охватить части функции целиком. Поэтому у меня и встал вопрос: как это всё свалить в кучу, чтобы можно было сразу охватить всё, что происходит.

и тут я подложил себе большую свинью. В силу собственной невнимательности (я как-то сумел себя убедить, что добавлять свойства к объекту - какая-то сложная процедура, а не просто " obj_player.speed_bost = 1 ") я решил всё пихать в global. ... Тут со мной злую шутку сыграла память про типы переменных, типа глобал/локал... короче говно худшее! По-правильному - надо всё пихать в свойства объекта и передавать именно объект в любые другие места! По сути же - я делаю тоже самое! Но пихаю все свойства в объект "global", вместо того, чтобы пихать свойства плеера в объект плеера: "obj_player", в моём случае. Ну и как видно на гифке - листинг хромает. Например

if (keyboard_check(ord("S")) = false) && (keyboard_check(ord("W")) = false)

можно и нужно записывать как:

if !keyboard_check(ord("S")) && !keyboard_check(ord("W"))

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

Второе худшее говно в представленном листинге, что я, по сути, ебашу функции непосредственно в условии. Т.е. все вот эти

lobal.speed_boost -= global.impulse_value/global.mass_value*global.bc*2;
global.vert_speed_axelerate = -global.impulse_value/global.mass_value*global.bc*2;
global.fuel_tank -= 2;

надо сворачивать в отдельные функции и лишь вызывать из кода, чтобы не захламлять сам листинг, а называть функцию как-то так: vertical_axelerate_increase, vertical_axelerate_decrease, left_axelerate_increase, right_axelerate_increase и т.д. И передавать в них как раз-таки объект, а в самой функции выковыривать из него то, что непосредственно нужно. А так как я - делать не нужно...

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

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

ну и текущее состояние:

добавил счётчики скорости с псевдографикой, указывающей направление движения, дистанциометр :D и бак.

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

настраивается область, диапазон значений, шаг приращения.

ну и для разнообразия пара возможностей

работает слева направо, потому что я живу в РФ, а тут всё слева направо.

листинг:

код в красной рамке на скрине отрисовывает обводку для индикатора. Не делайте так! Ебашьте спрайт и вызывайте один раз. Я это сделал для наглядности. Но оставляю для упоротых, типа меня :D

вызов скрипта:

Юзайте! Хотя кого я обманываю, никому это не нужно :D Но подписчики откуда-то взялись...

Новые горизонты и открытия :D один товарищ мне объяснил, что не понял о чем посты, но ему они дико не нравятся. Это успех, я считаю!

Погнали!

1) самое дикое, что мне не нравилось в первой итерации прототипа - задник. Статичный бэк. Поэтому им я и занялся сразу, как только основная механика заработала. Так как никаких коридоров и прочего энвайромента у меня по задумке нет - я зафигачил точки (типа звёзды) зафигачил все их белыми, хотя стоило бы, наверное, спектр разнообразить... Жаль, что додумался до этого только сейчас.

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

2) корабль полностью обездвижил и начал двигать и ебать всленную вокруг статичной модельки плэера. Оч. удобное решение (стандартное решение, которое я не реализовал сразу в силу своей недальновидности и желания поскорее реализовать задумку доступными инструментами, не делайте так...). Впрочем, как я уже говорил - у нодального программирования есть только один плюс - порог вхождения. И не нужно его упускать или нивелировать сложными решениями. Сделайте прототип из говна и палок лишь бы работало и посмотрите, что получилось, тогда будут идеи как это улучшать... ну по крайней мере остро встанут кое-какие вопросы, которые позволят спрашивать гугол о чем-то кроме "я кирилл, как сделать игору".

3) этот пост полностью посвящен исправлениям и только им. Поэтому и третий пункт о том же:

вот так выглядит первый шаг на пути к адеквату. Я впихнул общий пул функций в одну сущность для движения и расчётов по нему. В данный момент (билд0_0_2) это только личинка, но архитектурно эта личинка на несколько порядков лучше того дерьма, которое было изначально. Сюда же суём все вычисления и отрисовки по ним. Т.е. эта сущность, по сути, всё, что связано с геймплеем непосредственно... Физика мира :D

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

4)Просто в графическом виде условия - жутко неудобны:

неудобны они во-первых дикашарым размером, который сжирают на экране. Ну как, блять, КАК if ... then ... может занимать ебучую десятую часть воркспейса!?.

а условий всегда будет много: 1)счётчики, 2) нажатия, 3) коллизии, 4) события, 5) подсчёт результатов событий, 6) переключатели... тысячи их! И это, фактически основной инстумент, который придётся использовать (в самом начале разработки) а тут такое... Просто представьте, как вы будете разбираться вот в таком дерьме, оформленном нодально:

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

ебанутое условие, если честно, но воплотить его нодально...

Крч, встань и иди, юный кирилл условия - то самое время для отказа от костылей. Это довольно просто для усвоения, быстро, экономит ОВЕРДОХУЯ воркспейса, по сравнению аналогом из нод. Главное - не путайся!

Ну и геймлей билда:

Сучьи крутилки, отвалились от астеров! Блять...

З.ы. и да, я починил Fatal Error, прости @HartMagic :(

Предыдущий пост почти вышел в ноль. Я считаю - это успех.

Погнали!

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

Итак!

1) основная механика, как можно было догадаться из гифки - летать и уклонятся от астеров. Скроллер, никаких инноваций. Для этого мне потребовалось: плэер, астероид, бэкграунд, взрыв/анимация гибели (дада, она есть, несмотря на фатал ерор), огоньки маршевого... да нахуй, вот скрин!

и это - пиздец! Пиздец в том, что GMS2 подталкивает к созданию сущностей. Сам движок намекает: надо сделать что-то - ебашь объект, чувак. Ебанутая идея, если честно. Например info и info_rotor - это объекты эффекта определения астера, вот эти полупрозрачные штуки (одна вращается и как бы... дышит)

нахуя я сделал три объекта для астероида? Ну потому что в нормальном для GMS пайплайне ты создаешь объект и присваиваешь ему спрайт... один... а функция дроу при этом уже работает через жопу. Поэтому движок сам провоцирует насоздавать 100500 объектов. Ебанутая идея, если честно. Благо у меня триал и в один прекрасный момент GMS2 мне просто поставил ультиматум: too much object, BUY ENGINE, SUKA! Но был послан, а я взялся за ум и угандошил половину объектов. А мог бы просто их не создавать...

2) движение корабля.

по сути это и есть вся игра: нажатие кнопки врубает боковой двигатель, удержание - проигрывает кадры анимации работы, коллизия с астерами заканчивается Fatal Error'om уничтожает плэера. Что я могу сказать... Ну, перво-наперво - делать так _НЕ НАДО_! Но для прототипа - сойдёт. Основная причина, почему так делать не стоит - хреновая читаемость такого решения. Функции по сути дополняют друг друга, но при этом лежат в разных вкладках... ебанные вкладки Как я уже говорил - лучше писать код руками, вот яркий пример:

коллизия с астером уничтожает объект плэеера (не уверен, что это хорошее решение, возможно имеет смысл просто вырубать отрисовку). Долбанные ноды умеют Destroy Instance, но это самовыеб! А уебашить соседа уже не получится - надо добавлять ему свою ноду... В итоге - нужно делать отдельный каскад дестроев... дерьмище, короче, адовое. А вот кодом можно уебать любому уничтожается что удобно.

3) навигация по экрану. Это отдельный вопрос, который тоже навязывает движок со своей нодой Jump To (перемещение объекта в координаты). В итоге я сделал экран, он, естественно конечен и можно сделать так:

слева - конец экрана, если что... Это бред и вообще хреновая идея. Корабль двигать вообще не надо! Нет ну кому как, конечно... как говорится "что не двигается - двигать и..." А кроме того - пришлось мутить какую-то дичь с камерой, наследованием объектов, привязке камеры к плэеру... короче мрак, бессмысленный мрак.

4) уже было но... Из-за сраных обжектов на все сущности у меня встал вопрос... Очень остро, блять, встал: КАК ПРИКРУТИТЬ КРУТИЛКИ К АСТЕРАМ? Это, на сегодняшний день, самый большой ебантизм, который меня заставила сделать нодальная система:

я создаю астер и впихиваю в него кучу переменных, чтобы он, сука, летел. Но, так как, астеров много и они генерятся постоянно - я не могу просто взять и привязать к нему эффектики по х и у через ноды. Потому что одинаковые объекты различаются по ID и если привязку осуществлять через имя вроде obj_barier (я хз почему он барьер, ну да и хуй с ним) то привязываться будет к чему попало и как поало. Пришлось изъябываться и впихивать в обводки все те же самые переменные... Я почти презираю себя за это! В итоге - вместо одной сущности я создаю 3, которым насильно впихиваю одинаковую модель поведения... хотя мне нужно просто отрисовывать три разных спрайта враз... Вообще это общая проблема именно нодального программирования в GMS2 (а может и не только в нём). Ты создаешь объект и подспудно ожидаешь, что управляешь именно им в его кишочках, а не другими объектами. И это рождает множество ошибок подхода. Впрочем, возможно, я просто недостаточно эгоцентричен...

5) шок и трепет! По мере разработки встал вопрос читаемости надписей, само собой. И я, как человек незнающий столкнулся с вопросом как это реализуется в рилтайме в движке. Гугол привёл меня к факту, что решения нет и нужно писать скрипт. Пичаль. (поясню на всякий - читаемость обеспечивается контрастной обводкой по контуру букв, чтобы независимо от фона текст выделялся).

Как-то так... геймплейно особо изменений между билдами нет, гифочка

По-прежнему Fatal Error...

Первый пост собрал за час -10 рейтинга, я считаю - это успех!

Погнали! Как я и говорил - разработка на ГМС2 с нуля. Всё, что я сделал в двигле до того, как начал - скачал и выполнил половину урока из официального тутора. После чего подумал - да ебись оно всё конём сам разберусь и начал.

Как я и говорил - первый пост был вводный (я ошибся с названием, билд там вообще лишний). Поэтому никакой конкретики там не было. Кроме того, с чего я начал прежде чем полез в эту клоаку разработку. Если буду с чем-то сравнивать - знайте, я сравниваю с Unity3d, с ним я немншк знаком и приходится периодически работать. Итак, GMS2.

1) нодальное программирование и интерфейс. Это самая большая жопа, с которой я столкнулся на сегодняшний день. Выглядит эта жопа вот так:

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

2) навигация. Я не могу однозначно сказать, что она плоха, но и хорошей назвать её довольно сложно. Однако совершенно точно - чем больше сущностей в проекте - тем пиздецовей становится адЪ. Вот так выглядит окно переменных объекта:

9 переменных, Карл! Всего 9... Это первый и самый главный, я считаю, совет: сразу! СРАЗУ! заводите все переменные в обычном виде. Для этого есть Execute Code, который представляет из себя окно для написания кода (лежит в common. Демонстрацию внешнего вида самого движка я намеренно упустил, для этого есть тутор.):

для примера, вот так выглядит окно с 24 переменными:

это дико-безумно экономит пространство и добавляет +100 к эргономике. Гораздо легче становится навигация. А заводить переменные проще простого: вместо ноды Assign Variable или Set Global Variable в Execute Code пишется имя переменной и присваивается значение, либо (если переменная юзается по всему проекту global.var_name = , соответственно.

Ах да, удобное: достаточно тыкнуть два раза в любой объект в Resource и экран телепортнёт с центровкой на эту штуку.

3) вкладки. Очень сильно задалбывают вкладки. Захламляют строку и приходится их закрывать. Кроме того интерфекс движка начинает подтормаживать из-за количества ресурсов в Workplac'e. Это не сильно напряжно, но...

4) я стараюсь и (поработав с GMS2 всем советую) - переводить по-максимуму все нодальные структуры в код. Это помогает учится кодингу, собственно. Но... иногда НИХРЕНА НЕ ПОНЯТНО как функция будет писаться! Помогает хелпина и встроенный текстовый движок. Но на некоторые вещи я пока не нашел ответа. А на некоторые ответы чрезвычайно неочевидны! С другой стороны кое-что реально проще сделать наглядно, например - set direction имеет наглядную розу ветров:

5) у каждого объекта есть список действий и код, который с ними соотносится открывается в отдельном экране. Это неудобно. Вообще! Код всегда занимает отдельную вкладку и приходится переключаться туда-сюда иногда ради одной функции.

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

6) встроенный редактор. Пиздец! Реально - пиздец. Нет, он не плох. В нем можно рисовать и делать анимированные спрайты, но... Но это боль, хотя, возможно, у меня фотошоп головного мозга.

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

Заключение: движок реально простой. Пол часа на туторы с параллельным опробированием - и уже можно что-то мастрячить. Геймплей первого дня (не помню сколько ушло часов, но большая часть - на арт.

Умирать нельзя! вот как-то так...

Привет! Сперва я хотел вести что-то вроде девблога, чтобы в первую очередь себя к дисциплине приобщить. Но, посмотрев на набигающих на сообщество кириллов с "чем убить воркрафт с нуля без смс и регистрации?" - решил, что нужно нести хорошее доброе и вечное. И ничего не мешает совместить приятное с полезным и раскрыть кое-какие вопросы, которые буду встречать (исключительно свой опыт).

Итак! Я надеюсь, что это будет интересно, поэтому перво-наперво задаюсь вопросами: "что я делаю?", "зачем" и "почему я делаю так"? По крайней мере именно это меня интересовало бы, будь я читателем.

Что? Ну это почти риторический вопрос. Я делаю игру, само собой. Но не только. Это мой первый проект. Поэтому он несёт больше образовательный смысл. Я поставил себе цель - небольшой скроллер с более-менее уникальной механикой и постепенно буду её воплощать.

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

Почему? Почему GMS2 и 2д? *конь в ванной с огурцами.jpg* Мне лично нравится пиксельарт и 2д, это первая причина. Вторая - создавать 3д игру скроллер - довольно дикая дичь и я просто не представляю зачем, если 2д вполне справится со своей задачей. А гмс2 мне приглянулся нодальным программированием из коробки. Конечно, даже на момент принятия решения я понимал, что на нодальном прогинге далеко не уедешь (правда я не ожидал, что придётся переобуваться так быстро) и придётся так или иначе осваивать классическое стучание пальцами по клаве. Собственно это и было одной из причин - получить инструмент, который можно юзать сразу и с его помощью переучиваться.

Так как этот пост - вводный, то я начну с вопроса о "чем убить вокрафт". Я знаком в той или иной степени с UE, Unity3d, GMS2, Ogre (адовый ад, хочу забыть этот кошмар), бегло смотрел такие движки как Shiva... и ещё кой-чего по мелочи, но не суть. Что я хочу сказать сразу: выбор движка, я считаю, очень важный этап в жизни каждого кирилла который требует определённых усилий. Если подходить к вопросу грамотно и адекватно - то двигло должно максимально удовлетворять потребности. Но и переизбыток функционала, зачастую, нафиг не нужен, ибо влечёт за собой иногда всякое. Но, для начинающего кирилла разработчика это скорее из области влажных фантазий. Поэтому в общем случае лучший ответ - ебашь на юнити возьми тот движок, что приглянулся, попробуй на нём, а дальше, узнав, что конкретно для твоего проекта не хватает - переедешь. Почему это имеет место быть? Потому что почти все движки на сегодня (которые я видел) в той или иной степени способны на всё. По крайней мере тот функционал, который реально реализовать в первом проекте - вполне потянут.

А теперь минутка нудятины! Если ты решил стать настоящим кириллом придумал делать игору, которую джва года ждёшь и не можешь дождаться - начни вот с чего:

1) идея игры. Это, во-первых - основная механика. Т.е. то, чем будет заниматься игрок большую часть времени. Скроллер - уворачиваться от препятствий. Шутер - бегать и стрелять. Платформер - прыгать и стрелять/бить... и т.д. и т.п. Нужно продумать именно идею механики, как её играть.

2) сеттинг. Обычно сеттинг вытекает из идеи, после того как вы её... Боже, что я пишу... Короче, сеттинг часто приходит сам. Но не факт. Когда будет основная механика - именно исходя из неё следует продумать в какой среде это будет наиболее органично смотреться.

3) дополнительные механики. Когда будет сеттинг, подходящий основной механике - наступит время охуенно гениальных идей разнообразить игровой процесс. И именно сеттинг поможет вам в этом. Игра про езду по пустоши на консервном ведре, когда безниза на донышке? Допом можно грабить корованы собирать мусор и бустить тачку. Платформер о рэмбо, уничтожающем вьетнамцев - допом можно грабить корованы замутить магазин, где менять снарягу ГГ.

4) детали. После того как всё из всего вытекло остается только снять перчатки и предложить другу. Детализация мира - это, безусловно, важный процесс и очень захватывающий (мира игры, я имею ввиду). Но это далеко не первостепенная штука в геймдеве. Очень большой ошибкой будет ввязываться в неравный бой за красоту с голой жопой (в смысле не биться с голой жопой, а когда у тебя голая жопа... а похуй! не важно!). А вот когда тылы прикрывает реализованная механика и продуманный сеттинг - станет заметно легче. Они подскажут на какие вещи стоит обращать внимание, а какие - проигнорировать. Это вообще беда всех кириллов Если вы кинетесь в детализацию, когда у вас не будет даже механики - вам пизда врядли вы сможете сохранить душевное равновесие в процессе переделок. Это можно почувствовать только на собственных яйцах, когда черенок детских грабелек, на которые ты, мой юный кирилл, прыгнешь со всей дури, предскажет тебе судьбу в виде "всё хуйня - переделывай"... боль... страдание... Короче - не делай так! Ни за что. Если ты хочешь сделать игру - детализация должна идти в конце. Переделать скетчи и заглушки гораздо проще и быстрее, чем перерисовывать ГГ/анимации/эффекты, когда они уже были "финал". А переделывать придётся инфа 146% в 70% случаев. Тем более, если ты - кирилл это твой первый раз.

5) ЦА. Целевая аудитория - это вообще, по-хорошему то, с чего надо начинать... но мы же всерьез не рассматриваем вариант с релизом... Но подумать об этом стоит для расширения кругозора. Кто и почему будет в это играть? С ЦА всё сложно. Нужно представлять хоть что-то про рынок и чаянья пользователей. Но если уж совсем мозгов нет не знаешь - то есть два варианта: 1) друзья. Спроси у них. И если тебе повезло и твои друзья - маргинальные мудаки, которые всегда рады смешать тебя с дерьмом не бояться сказать неприятную правду, то можно будет, опираясь на их мнение, сделать что-то играбельное; 2) интернет, конечно же. Тут тебе, юный кирилл, всегда объяснят, почему стоит избавить планету от своей никчемной персоны в чем слабые стороны проекта и как его сделать востребованнее.

Именно так я подошел к разработке: идея, сеттинг, доп.механики, детали... а на ца мне поебать, если честно про ЦА думать пока рано.

Ну вот и всё для нулевого поста!

Вопросы в коменты. План публикаций: буду постить билды с картинками и болью, с которой я в них сталкивался. Проект только начат, но запасик в 5 постов у меня есть. Пока!