Господа, сегодня начинаю делать свой

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

Не с нуля, готов GD-документ. Ещё ничего не программировал и не рисовал, только текст. Решил рискнуть и делать на GMS 2.3, так что будет и обзор/разбор фич (буду смотреть впервые). Будет круто наличие чувака на стриме который уже щупал 2.3 и будет говорить чё нового.

Дата время стрима: 7.11.2020 в 21:~~ по МСК.

Herzenrg
07 ноября 2020, 14:16
1
9

134 комментария

А как же Гаминатор?

Ахренеть какой диздок громадный и подробный...

Так, что-то типа Binding of Isaac / КОНИ2 получается, да?
Не ясно - уровни делятся на одноэкранные уровни или нет. Было бы понятнее, если структуру уровней описать вначале.

Уровни одноэкранные будут. Так же как у локомалито в Solar Gladiator

Воровать — плохо.

???

Наверное про то, что структура с оружием и перками (хоть насколько я понял и случайно?) но сильно напоминает Hades с тамошним оружием и перками богов.

Why some Hades weapons glow purple - Polygon

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

Оружия у меня всего три штуки и это по большей части стиль игры. Если в hades есть перки богов - это чистое совпадение.

Наверное неизбежно, что игроки будут проводить параллели с Hades

Будут, но там роглайк как я понимаю, а не боссфайты.

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

Enter the gungeon, например ещё есть с сюжетом и интересным оригинальным игровым миром..

Я в Hades только боссфайты видел и судя по набору боссов - это просто рандомные персонажи из греческой мифологий. Мой концепт строится практически полностью на Божественной Комедии Алигьери.
По крайней мере большую часть я брал именно оттуда. И ещё игрой Dante's Inferno, которая по тем же мотивам.

GD-документ просто шикарен. Я столько не смогу продумать заранее не создав некоторую часть игры, много вещей не учту пока не сделаю где-то 10-50% игры.

Постримил, попробовал GMS2.3

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

То что можно ресурсы как угодно группировать - вроде бы интересная фича, но спорная:
1) Разрабам пришлось накостылять менеджер порядка загрузки комнат
2) Разрабам пришлось накостылять режимы просмотра по типам ресурсов, чтобы свихнувшийся от счастья разработчик не умер от хаоса, который он создаёт
3) Если раньше префиксы (spr_, obj_ и прочие) имели рекомендательный характер, то сейчас ИМХО без этого вообще никак.
4) Пользователям теперь придётся думать как организовать свою работу
5) Разрабам пришлось накостылять не очень удобные селекторы для выбора того какой ресурс создать
6) А чтобы пользователи не заёбывались пользоваться этими селекторами сделали супер-окнос плитками где выбираешь тип ресурса и количество которое ты хочешь сделать.
7) Перетаскивание объектов в список события для добавления события столкновения не работает. ХЗ баг это или фича.

Очень много спорного тут, как будто функционал натянут за уши и непонятно для чего собсно.

Скрипты - заебись просто.
1) Возможность наконец-то создавать собственные функции у которых аргументы имеют человеческие понятные имена.
2) Скрипты автоматически инициализируются в глобальном скоупе, так что всю инициализацию и глобалы выносить туда и больше ничего нигде ни у кого не вызывать. Лично для меня это означает что я могу упразднить o_loader из своих проектов
3) Правда не понятна последовательность инициализации этих скриптов
4) Переменные как функции (мне знакома по JavaScript) чудо как хороша. Позволяет упрощать код в сложносочинённых конструкциях проверки столкновений с разными типами объектов, например. НУ и отличная замена userevent с осмысленными именами на этот раз

Структуры - круто, а вот структуры-объекты с методами я пока ХЗ как применять. Ну и теперь все объекты структуры и всё что возвращало id объекта теперь возвращает структуру как я понял. По крайней мере теперь просто так other.myvar написать не получится. Только other.id.myvar. Так поди скоро и self вернётся, ЛОЛ.

Исключения пока не очень вдохновляют. Может я чего-то не понимаю, но зачем ловить ошибки? Если ты знаешь что в этом месте ошибка может возникнуть, то не проще ли её блять исправить? А не обрамлять в try/catch и прочее...

Сиквенсы странная тема. Для катсцен идеальная вещь. Судя по тому что туда можно добавлять события и навешивать скрипты - довольно мощная штука должна быть.

Переделали окно спрайтов. Чё-то я не понял зачем. И так вроде норм было. Ощущение что там можно как временные кривые юзать...

Не без багов всё это дело. Один раз у меня событие на сохранилось. Один раз маска коллизии сам сбросилась в точку в левом верхнем углу. Оба раза как дурак по 10-15 минут пытался понять в чём прикол.

1) Возможность наконец-то создавать собственные функции у которых аргументы имеют человеческие понятные имена.

Это да. Раздражает в GMS1, когда забыл, что значить argument3 и скроллишь вверх по коду, чтобы вспомнить что там подписано рядом с аргументом)

4) Переменные как функции (мне знакома по JavaScript) чудо как хороша. Позволяет упрощать код в сложносочинённых конструкциях проверки столкновений с разными типами объектов, например. НУ и отличная замена userevent с осмысленными именами на этот раз

Это вообще хорошо звучит! userevent тоже как argument, не всегда сразу понятно, что это значит.

4) Переменные как функции (мне знакома по JavaScript) чудо как хороша.

Функциональное программирование вообще чудо как хорошо! :3

а вот структуры-объекты с методами я пока ХЗ как применять.

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

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

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

Функциональное программирование вообще чудо как хорошо! :3

Мне не нравится. И lisp и ruby вспоминаю с содроганием. В первом случае ещё и килотонны скобочек из-за чего кажется что твой код тебе всё время лыбится. Причём мерзенько так "Ну чё, ска, ищи теперь где ты скобочку не закрыл!"

В целом мне и JS не очень нравится из-за замыканий. Когда в цикле обработку делаешь всё время голову ломаешь как туда не попасть. Это хорошо что в какой-то из ES версий ввели let.

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

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

Ruby не про ФП. Ну оно там немножко есть (а где его сейчас нет, даже в консервативную Java лямбды завезли), конечно, но не больше, чем в каких-нибудь Python или JavaScript. В Lisp'ах это тоже не главное, разве что за исключением диалекта Clojure.

Когда в цикле обработку делаешь всё время голову ломаешь как туда не попасть.

И это проблемы конкретно JS, а не ФП.

А «высосанный из пальца геморрой» — это таскать туда-сюда координаты между всякими point_direction и lengthdir_x/y, вместо пары методов в строчечку.

Я тут подумал, вроде выходит что есть и минусы у тотальной "структуризации". Если тебе нужно point_direction от заранее неизвестной точки, то как его тогда вызвать? Создавать новую точку на базе старой? Оверхед, особенно для степа. Вычислить её в существующей, вызвать от неё, и потом вернуть предыдущее? Странно и оверхед.

Возьмём вот одну строку из 193 строк ивента Step в объекте o_boss_diamond из Void Source:

angl_diff=angle_difference(main_can.direction,point_direction(x, y-470, o_player.x, o_player.y))

И здесь конкретно:

point_direction(x, y-470, o_player.x, o_player.y)

Как это было бы на структурах данных?

Да, мы сразу же сделаем point_direction2(position, o_player.position), сократив количество аргументов с четырёх до двух. Но! y-470 постоянно пересчитывается, и результат этого вычисления не записывается в переменную. Теперь придётся хранить это значение, хотя известно, что мы его один раз использовали и можем выкинуть. Но прежде чем хранить, его надо вычислить. Получается уже так:

position_up.y = position.y-470
point_direction2(position_up, o_player.position)

Для такой миграции по проекту придётся:

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

И всё это ради читаемости кода, который никто читать не будет?

В случае с lengthdir_x и lengthdir_y уже всё намного лучше - вот тут действительно получится уменьшить и код, и вычисления. Не будет больше никаких тупых:

var _x=x+lengthdir_x(_dist,_dir);
var _y=y+lengthdir_y(_dist,_dir);
var _part_dir=point_direction(x, y, _x, _y);

Будет так: (при условии что мы добавим статичный Translate к структуре данных)

_point.Translate(_dist,_dir);
var _part_dir=point_direction(position, _point);

Одна беда - стандартных структур данных или названий под это не завезли, и поэтому в исходниках разных разработчиков это будет то point_translate, то Vector2.Add, то Position2D.move, то ещё какая-нибудь комбинация более-менее релевантных слов. Тут уж если нацеливаться, то на задание хорошего тона всему сообществу разработчиков вообще в целом. Вот это было бы прям круто, да.

Мне казалось, что если уж человек выбирает высокоуровневый движок с динамическим языком с заведомым оверхедом на ~всё, он не должен париться насчёт преждевременной оптимизации (причём необоснованной – чтобы всерьёз считать оверхед, надо как минимум примерную спецификацию VM знать), но эх.

Я тут подумал, вроде выходит что есть и минусы у тотальной "структуризации".

Конечно, серебряных пуль вроде всё-таки не бывает. Однако бывают из сплава с высоким содержанием серебра :) Ну то есть, если условно в 90% ситуаций плюсы, а в 10% минусы (и то не самые значительные), то овчинка стоит выделки.

Возьмём вот одну строку из 193 строк ивента Step

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

Завести под этими названиями дополнительные переменные.

Да тоже не нужно. вместо отдельного position_up просто position.translated(0, -470) в аргументе. И «храниться» ничего не будет при достаточно умном GC.

А надо брать не одну, а весь релевантный блок, где она используется

Кто "она"? Вот тебе весь ивент.

if intro==false
if y-20 >= global.ground{
gravity=0;
vspeed=0;
global.camera_shake_count=20;
global.camera_shake_border=20;
global.camera_shake_rot=0;
global.camera_shake = true;
intro=true;
}

left_wing.x=x;
left_wing.y=y-20;
right_wing.x=x;
right_wing.y=y-20;
if closed_2==false{
main_can.x=x;
main_can.y=y-470+vspeed;
}

if closer_1==false
    if intro==true{
    if left_wing.direction<115
        left_wing.direction+=1;
    if right_wing.direction>245
        right_wing.direction-=1;
    if left_wing.direction>=115
        if right_wing.direction<=245{
        left_door.image_speed=1;
        right_door.image_speed=1;
        alarm[2]=room_speed*2;
        alarm[3]=room_speed*2;
        alarm[1]=room_speed+random(room_speed);
        rotation=true;
        closer_1=true;
        }
    }

left_door.x = lengthdir_x(520, left_wing.direction+16) + x;
left_door.y = lengthdir_y(520, left_wing.direction+16) + y-20;
right_door.x = lengthdir_x(520, right_wing.direction-196) + x;
right_door.y = lengthdir_y(520, right_wing.direction-196) + y-20;

left_prop.x=left_door.x;
left_prop.y=left_door.y;
right_prop.x=right_door.x;
right_prop.y=right_door.y;

if intro==true{
if instance_exists(o_player){
angl_diff=angle_difference(main_can.direction,point_direction(x, y-470, o_player.x, o_player.y));
} else {
angl_diff=angle_difference(main_can.direction,point_direction(x, y-470, global.death_player_x,global.death_player_y));
}

if closed_2==false
if angl_diff-1 > 0
    main_can.direction -=1
else if angl_diff+1 < 0
        main_can.direction +=1
}

if rotation==true{

//левый пропелер
if left_prop_in_out==true{//затягивает
if left_prop_rotation_speed < 5
        left_prop_rotation_speed += 0.2;
    left_prop.image_angle+=left_prop_rotation_speed;
    if instance_exists(o_player){
    left_danger_distance = point_distance(left_door.x, left_door.y, o_player.x, o_player.y);
    if left_danger_distance < 300{
        if o_player.x > left_door.x
            o_player.x -=2;
        else if o_player.x <= left_door.x
            o_player.x +=2;
        
        if o_player.y > left_door.y
            o_player.y -=2;
        else if o_player.y <= left_door.y
            o_player.y +=2;
    }
    }
    var _dir=random(360);
    var _dist=300;
    var _x=left_prop.x+lengthdir_x(_dist,_dir);
    var _y=left_prop.y+lengthdir_y(_dist,_dir);
    var _part_dir=point_direction(_x, _y, left_prop.x, left_prop.y);
    part_type_direction(particle1, _part_dir,_part_dir, 0, 0);
    part_type_orientation(particle1, _part_dir,_part_dir, 0, 0, 0);
    part_type_speed(particle1, left_prop_rotation_speed, left_prop_rotation_speed, 0, 0);
    part_type_size(particle1,1,1,-0.01,0);
    part_particles_create(left_bubble, _x, _y, particle1, 1);
}else{//выталкивает
if left_prop_rotation_speed > -5
        left_prop_rotation_speed -= 0.2;
    left_prop.image_angle+=left_prop_rotation_speed;
    if instance_exists(o_player){
    left_danger_distance = point_distance(left_door.x, left_door.y, o_player.x, o_player.y);
    if left_danger_distance < 300{
        if o_player.x > left_door.x
            o_player.x +=2;
        else if o_player.x <= left_door.x
                if o_player.x-2 > view_xview//защита от выбрасываения за экран
            o_player.x -=2;
        
        if o_player.y > left_door.y
            o_player.y +=2;
        else if o_player.y <= left_door.y
            o_player.y -=2;
    }
    }
    var _dir=random(360);
    part_type_direction(particle1, _dir, _dir, 0, 0);
    part_type_orientation(particle1, _dir, _dir, 0, 0, 0);
    part_type_speed(particle1, -left_prop_rotation_speed, -left_prop_rotation_speed, 0, 0);
    part_type_size(particle1,0.4,0.4,0.01,0);
    part_particles_create(left_bubble, left_prop.x, left_prop.y, particle1, 1);
}
//правый пропелер
if right_prop_in_out==true {//затягивает
if right_prop_rotation_speed < 5
        right_prop_rotation_speed += 0.2;
    right_prop.image_angle+=right_prop_rotation_speed;
    if instance_exists(o_player){
    right_danger_distance = point_distance(right_door.x, right_door.y, o_player.x, o_player.y);
    if right_danger_distance < 300{
        if o_player.x > right_door.x
            o_player.x -=2;
        else if o_player.x <= right_door.x
            o_player.x +=2;
        
        if o_player.y > right_door.y
            o_player.y -=2;
        else if o_player.y <= right_door.y
            o_player.y +=2;
    }
    }
    var _dir=random(360);
    var _dist=300;
    var _x=right_prop.x+lengthdir_x(_dist,_dir);
    var _y=right_prop.y+lengthdir_y(_dist,_dir);
    var _part_dir=point_direction(_x, _y, right_prop.x, right_prop.y);
    part_type_direction(particle2, _part_dir,_part_dir, 0, 0);
    part_type_orientation(particle2, _part_dir,_part_dir, 0, 0, 0);
    part_type_speed(particle2, right_prop_rotation_speed, right_prop_rotation_speed, 0, 0);
    part_type_size(particle2,1,1,-0.01,0);
    part_particles_create(right_bubble, _x, _y, particle2, 1);
}else{//выталкивает
if right_prop_rotation_speed > -5
        right_prop_rotation_speed -= 0.2;
    right_prop.image_angle+=right_prop_rotation_speed;
    if instance_exists(o_player){
    right_danger_distance = point_distance(right_door.x, right_door.y, o_player.x, o_player.y);
    if right_danger_distance < 300{
        if o_player.x > right_door.x
                if o_player.x+2 < view_xview+view_wview//защита от выбрасываения за экран
            o_player.x +=2;
        else if o_player.x <= right_door.x
            o_player.x -=2;
        
        if o_player.y > right_door.y
            o_player.y +=2;
        else if o_player.y <= right_door.y
            o_player.y -=2;
    }
    }
    var _dir=random(360);
    part_type_direction(particle2, _dir, _dir, 0, 0);
    part_type_orientation(particle2, _dir, _dir, 0, 0, 0);
    part_type_speed(particle2, -right_prop_rotation_speed, -right_prop_rotation_speed, 0, 0);
    part_type_size(particle2,0.4,0.4,0.01,0);
    part_particles_create(right_bubble, right_prop.x, right_prop.y, particle2, 1);
}

}//rotation

//уничтожение
if hp<=0 {
rotation=false;
alarm[1]=-1;
alarm[2]=-1;
alarm[3]=-1;
if closed_2==false {
closed_2=true;
explosion_count = 20;
alarm[4] = 50;
global.timer_count_up = false;
//boss rush mode
scr_BossRush_complete();

}
}

Оптимизировать особо нечего. Ну будет 160 строк вместо 200, almost write-only кода.

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

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

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

Тут согласен.

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

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

20% строк имеет смысл убирать, но не такой ценой.

Это если вот с нуля уже строить некий суб-фреймворк под ГМС2.3, то его можно приспосабливать там, где ещё никакой код не написан.

Оптимизировать особо нечего. Ну будет 160 строк вместо 200, almost write-only кода.

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

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

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

Прямо сейчас тыкаюсь в C#, пытаясь написать генератор подземелья и да, важность декомпозирования прям всей своей душенькой прочувствовал.

Очень сильно бросается в глаза два гигантских куска кода для левого и правого пропеллера.
Это же вроде всего один раз написать можно было о_0

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

Очень сильно бросается в глаза два гигантских куска кода для левого и правого пропеллера.
Это же вроде всего один раз написать можно было о_0

Можно. По-хорошему надо было создать отдельный объект пропеллера, создать два экземпляра таких объектов и ими управлять. Этот код писал Ловикс, который ещё только учился, и скорее всего я ему это сказал, но зачем переделывать код который уже работает? Он настолько не важен, что я его второй раз вижу в жизни, уже после релиза игры, это после трёх лет разработки.

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

то за время, пока эта декомпозиция будет проведена на одного босса, можно было бы закодить двух-трёх других. Я приводил в пост-мортеме:

401 объект с кодом игровой логики

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

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

Но так не бывает. Если десятками лет, даже ААА-студии, с нуля ваяют десятки надмозговых фреймворков, значит реюзабельность так уж и важна? Что одного босса, что цельной системы?

А вы хотите этого когда в хобби-проекте без бюджета программистов всего двое, из которых постоянно активен всего один.

"качество получаемых на практике результатов, а не на качество кода"
да какого хрена это у вас противоположные взаимоисключающие качества?

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

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

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

Опять в бессмысленных спорах на гамине уйма комментов...

да какого хрена это у вас противоположные взаимоисключающие качества?

Я говорил, на что был сделан упор в проекте, который я вёл, а не о противоположности качеств.

мозг сам требует написать код один раз и застрелить больше никогда в него не влезать

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

никаких ресурсов - ни временных, ни мыслительных ты не освободил

Мне нравится как, по мере ухода в глубину дискуссии, я оказываюсь должен уже что-то освобождать, соответствовать чьим-то представлениям, ожиданиям и чаяниям. Это как считать чужие деньги почти, только считать чужие ресурсы времени/сил/творчества. По́лно вам, господа, таким заниматься.

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

"что-то освобождать" - ну без освобождения ресурсов дискуссия вообще смысла не имеет. Главный тезис сопротивления аккуратности же простота и скорость, не?

Простота, скорость и аккуратность написания кода - всё это одинаково вторичные цели. Первичная - сделать игру.

не цели, а способы

Вторичные способы.

нормально "визионера" в очередной раз макнули

А «высосанный из пальца геморрой» — это таскать туда-сюда координаты между всякими point_direction и lengthdir_x/y, вместо пары методов в строчечку.

Можешь привести пример конкретных задач? Типа "так было", а с использованием собственных классов "так стало"

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

var min_dist=-1, min_dir=0;
for(var i=0;i<4;i++) {
  var _dst = point_distance(x,y,target.x+lengthdir_x(64,i*90),target.y+lengthdir_y(64,i*90));
  if min_dist==-1 then
    min_dist=_dst;
  else {
    min_dist=min(min_dst,_dst);
    if (min_dist==_dst) then min_dir=i;
  }
}

Я бы хотел увидеть упрощённую версию этого кода при помощи конструкторов.

конструкторов

А ещё лучше - деструкторов! Ты о чём? XD

Было бы:

point_distance2(position, target.position.translated(64, i*90));

А что такое position?
Что такое target.position?
Что такое translated?
Что такое point_distance2?

Я тоже так могу всю игру "в строчечку" написать

make_the_game()

То есть реально мне ещё ко всем объектам нужно будет добавить переменную position и инциализировать её с значениями x,y. А потом ещё в step каждому объекту так же прописать переприсвоение значений.

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

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

То есть реально мне ещё ко всем объектам нужно будет добавить переменную position и инциализировать её с значениями x,y. А потом ещё в step каждому объекту так же прописать переприсвоение значений.

Предполагается, что это могло бы быть добавлено в движок. То есть x и y должны стать просто ссылками на position.x и position.y (так же как speed, direction, hspeed, vspeed – по сути property вокруг векторной velocity). Раз уж экземпляры стали структурами, а не просто номерком.
Если не добавлено – просто сделать родительский объект для всех «позиционированных», который будет заниматься переобсчётом. Это ты делаешь один раз, а потом в строчечку записывается много кода в разнообразных наследниках. Немного медленно запрягаем, зато быстро едем!

И ещё лично я не проверял сможет ли translated вернуть векторную структуру.

По идее должны смочь как-то так:

Point = function(_x, _y) constructor {
    x = _x;
    y = _y;
    static translated = function(_other) {
        return Point(x + _other.x, y + _other.y);
    }
}

Предполагается, что это могло бы быть добавлено в движок.

Предполагается, что в движок могла бы быть добавлена функция make_the_game(). А так приходится работать с тем что есть, даже если где-то там это сделано лучше. И уже сам решаешь с чем будет удобнее работать - с собственными классами или "сложными" встроенными средствами. Я не сторонник оптимизации ради оптимизации. Конечная цель то игры делать.

И спорно всё это на самом деле. Я как разработчик с парой десятком сделанных игр могу сказать так:
1) Упрощённый движок - это плохо, потому что не хватает функционала (с этим и так многие согласятся). Такое я наблюдал в Stencyl для флеша когда-то очень давно.
2) Слишком навороченный с кучей потанцевала типа создания собственных классов - тоже плохо. Точнее это плохо когда тебя принуждают их создавать и нет ничего готового. Это идеология всяких там фазеров, фликселей и прочих полуфабрикатов. Это очень сильно запутывает и отвлекает от процесса создания игры.

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

Если не добавлено – просто сделать родительский объект для всех «позиционированных», который будет заниматься переобсчётом. Это ты делаешь один раз, а потом в строчечку записывается много кода в разнообразных наследниках. Немного медленно запрягаем, зато быстро едем!

Только ты забываешь что при этом если я переписываю Step родительского объекта, то мне нужно сделать event_inherited() иначе магия не сработает. Не буду рассказывать как легко это проебать. Спасибо, конечно, но я, пожалуй, более надёжным point_distance воспользуюсь LOL.

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

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

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

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

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

Меня в godot сильно отталкивает редактор сцен:

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

В остальном показывает себя очень толково с "дизайнерской" части, все нужное работает из коробки (ну, прямо вообще все, гамак позавидует)

Да ладно =)

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

А в GMS нет этих шероховатостей. Чему завидовать то?

И что насчёт платформ?
XBOX, PS4/5, Nintendo?

пока много шероховатостей с интерфейсом левелэдитора и нормальной работы с тайлсетами ждать придется до следующего года

А импорт из, например, Tiled не рассматриваешь как вариант?

много шероховатостей с интерфейсом левелэдитора и нормальной работы с тайлсетами ждать придется до следующего года.

Хотелось бы подробности услышать про шероховатости и нормальную работу...

Тайлы и левел эдитор это одна из слабейших частей UX годо сейчас, об этом отлично знают и разработчики.

"Gilles Roudiere, who commented on the video too, got hired to work on editor UI and UX. His work should involve redesigning the tileset system. Can't say if it'll be ready for Godot 4.0, but it's planned."

Это один из приоритетов, но пока он откладывается из-за переноса движка на новый рендеринг, релиз которого перенесся на 21 год.

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

Мне лично очень кайфого в нем разбираться, и на фановом уровне "запилить прототип" quality of life заметно выше аналогов, но для продакшена пока еще не нужен, тут хейз правильно выразился. К очень многим платформам дистрибуции придется самому или с помощью проектов с гитхаба API приколхозить

Не услышал ответ по существу. Система работы с тайлсетом не идеальна, но она успешно ВЫПОЛНЯЕТ свои основные функции.

Проблемы портирования на другие платформы находит тот, кто хочет их найти. Годо не обязан из под коробки работать со Стимом или другими площадками. Сейчас пожалуй есть все, чтобы без опасений выходить на продакшн.

Сейчас пожалуй есть все, чтобы без опасений выходить на продакшн.

Всего нет ни в одном движке. Берите конкретную игру, прикладывайте к движку, смотрите, чего не хватает, и сможете ли это доделать сами.

Скажи это godot - разработчикам игор, в Стиме.

Не понял тебя.

Юзеры Godot, например, жалуются на глюки с физикой. В моей игре физика не нужна, и мне это не помеха для продакшна. А кому-то будет помеха.

Я знаю о чем ты, об объектах, которые при большой скорости проваливаются в static-объекты. Это не проблема, она решается тонкой настройкой физических тел, а именно конкретных величин: масса, скольжение, шероховатость и т.п

Спасибо, кэп. Я работал с физикой в разных движках, и те, кто жалуется, тоже работал. Проблемы именно в реализации, а не в разработчике.

Пожалуйста. Обращайся. 😉

Не всегда при большой. Бывает физику просто клипует.

К очень многим платформам дистрибуции придется самому или с помощью проектов с гитхаба API приколхозить

Справедливости ради UWP вроде годот поддерживает из коробки. Но это ещё проверять нужно, работает ли там весь функционал. Ксит тоже как-то купил UWP модуль для гамака, а потом ещё год пинал разработчиков чтобы они его доводили до ума. Да, в GMS модуль UWP платный, но в отличие от модулей для нативного XBOX,PS,Nintendo покупается один раз. Нативные модули покупаются по подписке на год за 800 баксов. По слухам Йео такой брал и там тоже было не всё гладко. Эхх, где сейчас Йео... Вспоминаю времена когда он говно за лошадьми убирал и перетирал в перерывах за тру-инди-дев =) А теперь вырос парень, стал свои проекты издавать, миллионы зарабатывать... Забил на плебеев и инди-тёрки.

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

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

Один из основателей движка (когда тот был платный) как раз шарит по консолям, он и является главным "third-party" из той страницы мануала. Godot давно умеет во все консоли текущего поколения, но экспорт-код только по рецепту (как и везде).

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

Ну так допинал же. 10 релизов в год - планка взята.

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

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

Зато там (в haxeflixel порте) есть обширная коллекция типовых фич для ретро-игр,

т.е. с акцентом на геймдизайн

Я вообще не в курсе всего этого треда, но неужели на гамаке нет чего-то вроде:

return directions.Select(d => new Tuple<int, Point>(point_distance(target, target + d),d)).Min().Item2;

Где дирекшнз завели один раз заранее:

static Point[] directions = new Point[]{
    new Point(0, 1),
    new Point(1, 0),
    new Point(0, -1),
    new Point(-1, 0)};

А Point - это какой-нибудь класс для работы с целочисленными векторами. Что-то в таком духе:

public class Point
{
    private int X;
    private int Y;
    public Point(int x, int y)
    {
        this.X = x;
        this.Y = y;
    }
    static override Point operator + (Point a, Point b)
    {
        return new Point(a.x + b.x, a.y + b.y);
    }
}

Из коробки ничего нет, но начиная с 2.3 можно изобразить, что мы тут и обсуждаем. См. мой пример ниже.

Кстати, у тебя смещение всегда на 1, надо умножать точку на 64 :3

64 - это размер тайла?
Поиск путей работает с экранными координатами?
Да и вообще, зачем четыре раза искать путь, если можно найти кратчайший путь до конечной точки и отойти по нему на один шаг назад?
ААааа-ааа-а-а!

Короче, скорее всего, Хейзеру не нужны все эти выкрутасы с классами, просто потому что он прокачал скилл дебага до 82+ и теперь ему не важно, насколько понятно написан код, с которым ему нужно работать. Наверно, это лучший вариант, когда пишешь игру на время (для конкурса, например) и не можешь позволить себе на пару минут задуматься, нельзя ли этот же код написать лучше.

Некогда над кодом задумываться, надо игру делать!

Да и вообще, зачем четыре раза искать путь, если можно найти кратчайший путь до конечной точки и отойти по нему на один шаг назад?

А куда «назад»? Я так понимаю, это задача «найти ближайшую к объекту клетку, соседнюю с целью».

Некогда над кодом задумываться, надо игру делать!

Надо. Поэтому я сделал 10, а ты - 0.
Код никто не оценит в отличие от игры.

Код оценят. Но геймдевелоперу важно мнение игроков об игре, а не программистов о коде.

Короче, скорее всего, Хейзеру не нужны все эти выкрутасы с классами, просто потому что он прокачал скилл дебага до 82+ и теперь ему не важно, насколько понятно написан код, с которым ему нужно работать.

Мне не нужны эти выкрутасы, потому что я сторонник бритвы Оккама. Мне проще работать с одним понятием класс, а не плодить их как кроликов. Я выбираю из того что ускорит мне разработку. Конкретно эта реализация в GMS2.3 не ускорит ни разу.

Да и вообще, зачем четыре раза искать путь, если можно найти кратчайший путь до конечной точки и отойти по нему на один шаг назад?

Только если это если поиск пути по тайловой плитке или меш-графу.

Ясно. Я думал, что поиск на сетке.

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

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

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

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

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

Это если игра строится на сетке(пошаговая, например) то там имеет смысл так делать, пожалуй.

Я не могу привести примеры «так стало в GML», потому что сейчас не пользуюсь GML. Могу привести, как стало при портировании на Godot, пойдёт? Два примера: расчёт координат для треугольника области видимости у врага; зеркальное переворачивание кусков уровня со всеми объектами в нём (из моей головоломки Reverside).
Для твоего кода могу предложить так:

var min_dist = MAXINT;
var min_pos;
for (var i = 0; i < 4; ++i) {
  var point = target.position.translated(Point(64, 0).rotated(i * 90));
  var dist = position.distance_to(point);
  if (dist < min_dist) {
    dist = min_dist;
    min_pos = point;
  }
}

Или вообще так, если присыпать немножко ФП (жаль, краткого синтаксиса для лямбд нет):

var point = range(4)
    .map(function (i) {
        return Point(64, 0).rotated(i * 90).translated(target.position);
    })
    .minimumBy(function (p) {
        return position.distance_to(p);
    });

Кратко, изящно, лучше декомпозировано и легче расширяемо.

Для твоего кода могу предложить так:

То есть написать две строки кода вместо моей одной - это по-твоему "в строчечку"?
При этом нагородить ещё сторонних классов, помнить о них и поддерживать. ЛОЛ, конечно.

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

Кратко, изящно, лучше декомпозировано и легче расширяемо.

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

"Расширяемо" - это отдельная тема. Как показывает практика, потанцевал раскрывается в 0.0001% случаев, т.е. почти никогда. Обычно или ничего не поддерживается или всё переписывается заново на новых технологиях с новым потанцевалом.

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

Я топлю за упрощение и декомпозицию кода, группировку его на логически связанные кусочки, которые легче окинуть взглядом и в которых сложнее сделать ошибку. Сокращение объёма — лишь одно из возможных проявлений, увлекаться им до степени гольфинга тоже не стоит.

выглядит как нелепая хрень. Потому что императивное, пошаговое программирование интуитивно более понятное для геймдева.

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

"Расширяемо" - это отдельная тема. Как показывает практика, потанцевал раскрывается в 0.0001% случаев, т.е. почти никогда.

В процессе прототипирования что-то модифицировать и добавлять приходится постоянно же.

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

Декомпозиция кода = больше сущностей, а значит и связей. Допустить ошибку проще. Отлаживать чуть легче. Декомпозиция никогда не пахнет упрощением. То есть если у тебя есть

c = 1+1;

А ты упрощаешь это в

class digit {
  value = 0;
  add = function(b) {
    this.value+=b;
  }
}

var a = new digit();
a.value=1;

var c = new digit();
c.value=1;
c.add(a.value);

Куча потенциала - можно столько полей добавить и методов! А толку то?

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

Я хочу игры делать, с чем успешно справляюсь. Даже если нужно фигачить лапшу на переменных да циклах.
Пока что не видел НИ ОДНОГО инструмента, в котором было бы делать игры так же удобно как на GMS, хотя согласен, что потанцевала там бывает больше и расширяемости - тоже.

Тот же godot, например, при всей его типа потенциальности не позволяет экспортировать игры на консоли (кроме UWP как я понял). Нахер мне этот инструмент нужен?

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

А ты упрощаешь это в

Straw man fallacy.

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

Тот же godot, например, при всей его типа потенциальности не позволяет экспортировать игры на консоли

Позволяет.

Видел я эту ссылку уже. Там только через Third-party. Маленький кэп позади меня подсказывает что это довольно далеко от термина "позволяет". Это отсутствие встроенного функционала. И ещё непонятно как это работает и работает ли вообще.

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

ЛОЛ. Грамотный код - штука чисто субъективная, которая сильно зависит от задачи. Любой код можно назвать неграмотным и придумать куда лучше концепцию. При том что код - всего лишь инструмент чтобы делать настоящие вещи. Любишь ты время на ерунду тратить.

Честно говоря, я уже устал всё это обсуждать. Видно что ты гик-программист и у тебя нет вообще готовности обсуждать геймдев. А слушать твои нелепости я больше не собираюсь. Добро пожаловать в мой игнор-лист!

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

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

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

Декомпозиция кода = больше сущностей, а значит и связей. Допустить ошибку проще.

Странно такое слышать, ты же вроде работаешь в вебе и вроде рассказывал, как какую-то из игр делал с использованием архитектуры presentation слоя, не помню, MVC или MVP.

Ты разве тогда не почувствовал бенефитов от того, что они меньше зависели друг от друга, а значит и реже ломались?

Ты когда-нибудь отлаживал JS скрипты?
Когда тебе в консоль насрали стек последних событий от твоего кода до jquery и ты в душе не ебёшь то ли ошибка jQ, то ли у тебя то ли ещё где. В sass и pug с которыми я работаю последние несколько месяцев точно такая же шляпа.

С одной стороны и проще отлаживать. С другой - не проще. Это спорный момент. Порой я декомпозирую код, а потом жалею об этом. Например, бывает, с CSS файлом на 10000 строк работать проще чем со 100 CSS файлами по 100 строк. Ещё раз повторяю - очень много зависит от задачи, которую решаешь.

То что там что-то меньше зависит от чего-то - это всё иллюзия, которую придумали программисты для аргументации своего важного труда. Если головой думаешь, то можешь и без декомпозиции написать код части которого мало зависят друг от друга и хорошо отлаживаются. Основные преимущества декомпозиции больше носят бизнес-цели чем практические:
1) Легче понимать DOD (definition of done)
2) Распараллелить работы, поддерживать контекст
3) Переиспользование кода

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

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

Мне часто говорят что GMS плох. Что там нет того и того. И что вот на другом инструменте всё делать проще, быстрее и удобнее. Если так, то готовые игры ваши при этом где? Или не так просто, быстро и удобно получается все эти парадигмы реализовывать? Я очень мало готовых игр вижу от тех, кто громче всех об этом кричит. Зато я вижу их от тех, кто молча делает своё дело. Для меня ЭТО показатель того как правильно делать и программировать, а не вскукареки от диванных теоретиков, которые два раза в жизни hello world написали и типа дохуя специалисты.

Только оказалось что у меня послезавтра проект на XBOX one релизится, а у него всего одна игра недоделана на его супер-движке.

Не, ну это ты не с того конца-края начал. Во-первых, послезавтра у тебя на Иксбокс уже вторая игра релизится, а в запасе ещё как минимум третья. Во-вторых, (жаль ты свой сайт уже снёс), за прошедшие 15 лет ты сделал уже порядка 20 вполне законченных игр. Да, первые из них были совсем бредовыми, типа Мемори Танка, но дальше было лучше. За Брейн Сторм Йойошники тебе должны были дать первое место в одном из своих конкурсов времён экспортера на PlayStation Portable, но игру дисквалифицировали как слишком профессионально сделанную. Было? Было.

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

Какой из этого можно сделать вывод, глазами внешнего наблюдателя? Вы просто пытаетесь выкинуть весь его опыт как не релевантный, потому что он не похож на ваш; считая что какую-то силу в дискуссии имеет поябедничать "ой он на спервадобейся намекает" - так он имеет полное право. Даже я имею меньшее на это право, чем он, во всяком случае как соло-разработчик. А как цифровой издатель и лидер нескольких инди-команд, я могу только фейспалмить.

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

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

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

Вы просто пытаетесь выкинуть весь его опыт как не релевантный, потому что он не похож на ваш

Где-то загрустили кватернионы.

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

Давай разделим тезисы во избежании терминологической каши:.
1) Количество завершённых проектов говорит о том, что был опыт, что совершались ошибки и извлекались выводы. Не ошибается тот, кто ничего не делает =) Количество завершённых проектов позволяет делиться вполне релевантным опытом по сравнению с тем опытом, который был получен при написание сферического кода для супер-движка не вышедшей игры (хотя такой код может быть грамотным, хорошим, надёжным и всё такое что вы любите говорить)
2) Количество завершённых проектов не говорит о том что автор этих проектов программист-гений, а говорит о том что конкретно его практики позволили эти проекты завершить. И если он не делал декомпозицию кода каждые 3 дня - значит это не обязательное условие для разработки игр. Если он использовал goto для своей игры - это говорит, что в принципе можно это использовать чтобы получить конечный продукт и никто от этого не умрёт.
3) Количество завершённых проектов не говорит о том насколько успешен разработчик и какое влияние он оказал на индустрию и культуру видеоигр. На это влияет много факторов и если количество завершённых проектов является таким фактором, то боюсь, даже в первую сотню не входит.

Конечно, меня тут зашеймили что я код неправильно пишу. Но я пишу его на GMS где нет функционального программирования того же. А те фичи которые появились в 2.3 не позволяют без рисков(в силу своего опыта) использовать некоторые продвинутые практики (такие как векторы). Определённые люди в треде пытаются мне потыкать пальцем в то, что я не прав и пишу ненадёжный, неграмотный код, при том что я на GM/GMS сделал 20 игр и знаю этот движок почти вдоль и поперёк. В качестве "божественного инструмента" мне пытаются впарить какой-то Godot, который экспортит под консоли только с левыми костылями, а фичах на сайте первым стоит скрин с подписью "Gorgeous 3D graphics" с графикой из 2005 года.

Весёлый тред, чё сказать XD

Совсем забыл сказать
zLGhllr

Сэр, у вас GODOT подчеркнут🤣

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

Определённые люди в треде пытаются мне потыкать пальцем в то, что я не прав и пишу ненадёжный, неграмотный код, при том что я на GM/GMS сделал 20 игр и знаю этот движок почти вдоль и поперёк.

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

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

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

это всегда как-то ну очень враждебно воспринимается

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

Схема победы в споре по Кситилону lrSUuQg

Провозглашается защищаемое положение. Например:
- "кватернионы не нужны"
- "теория музыки не нужна"
- "программирование в разработке игр не нужно"
Провозглашаются некие абстрактные критерии успешности, выбор которых носит исключительно волевой характер. Соответственно:
- "Я сделал сто игр"
- "Я композитор Электрик Хайвейс"
- "Я выпускаю игры на Иксбоксе, а где ваши игры?"
Устанавливается связь между провозглашаемым положением и критерием успешности - тем самым предполагается, что это неким образом должно что-то доказать. Так то:
- "Кватернионы не нужны. Ведь я с сделал сто игр без них"
- "Теория музыки не нужна. Ведь я, например, композитор "Электрик Хайвейс" и при написании ею не пользовался
- "Программирование в разработке игр не нужно. Я вот выпускаю игры на иксбоксе, а где ваши игры, если вы программист?"

Всё. Оппонент низвергнут, низложен, Тевтобургский лес, а где ваши игры.

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

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

А насчёт программистов смотри какая ситуация выходит. Для понятности я экстраполирую на плотническое ремесло. Живёт себе такой плотник, который уже 10 домов построил. Иногда получалось не идеально ровно. Иногда что-то ломалось. Иногда он ходил их чинить. Он извлекал опыт и каждый следующий дом он строил лучше,познавая хитрости своего ремесла и возможности своих инструментов. А потом как раз этот мужик решил в компании мастеров рассказать про то как он строит дома. Под каким углом правильно гвозди забивать, с какой силой и т.д. Где-то из конца комнаты доносится голос чувачка:

Эээ, мужик, так ты неправильно дом строишь. Если гвозди забивать молотком, держа его не рукой, а ногой - будет гораздо эффективнее! Ты задействуешь больше потенциала своего тела и прокачаешь свой скил! А вообще настоящие тру-современные грамотные плотники давно так не делают как ты.... Они забивают гвозди пилой! Прикинь, да! Кладут пилу полотном на гвоздь и сильно бьют кулаком пока гвоздь не забьётся! Ты не представляешь сколько тут потенциала! Не нужно тратить время чтобы поменять инструмент - напилил и тут же забил!

А потом плотник, который 10 домов построил говорит:

Это всё очень интересно. Но скажи, сколько домов ты уже построил, используя эти новые технологии?

Чувачок смущается, опускает взгляд в пол, молчит секунды 3 и потом с возмущением вскрикивает:

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

А насчёт программистов смотри какая ситуация выходит

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

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

Это элемент гиперболы был, скорее. Совсем всерьез это лучше не воспринимать.

Да это всё понятно, аналогия понятна, только дело в том, что она также не доходит до конца. Дом-то построить можно, но главное, чтобы кто-то в нем поселился вообще.

Будем считать, что дома качественные и надёжные, годные и подготовленные для проживания. А будет ли там кто-то вообще жить - это уже зависит от риелтеров, которые смогут или не смогут найти покупателя. Конечно, плотник может забегать во все трактиры своего города с криком "Я ПОСТРОИЛ ДОМ! ПОКУПАЙТЕ ЕСЛИ ХОТИТЕ". Но это не очень этично как мне кажется. Продавать должны продавцы, а не плотник.

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

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

Ну если использовать эту аналогию, то вот такая будет более верной:
Живёт себе такой плотник, у которого есть верный камень, которым он забивает гвозди, а сколотым краем – стругает доски. За долгие годы работы камень отполировался, идеально лёг в руку, а ещё приучил быть внимательнее, чтобы нечаянно не схватиться за острый край. При помощи этого камня плотник построил уже несколько сараев и домиков, ведь забивание гвоздей в строительстве – не главное, нужно по меньшей мере ещё дерево добыть и конструкцию придумать.
Проходил мимо чувачок, который где-то работает инженером, но для себя мастерит максимум скворечники. Заинтересовался, как мастера умудряются в одиночку домики возводить, посмотрел и удивился – как же так?
— Мастер, неужели ты всё время пользуешься этим камнем? Ведь изобрели столько полезных инструментов, облегчающих жизнь!
На что усталый мастер матом послал чувачка:
— Наши предки тысячи лет использовали камни, а от этих новомодных штук докажи сперва, что польза мне будет! К чему мне эти ваши молотки – попадать сложнее и от ручки занозы остаются! К чему мне шуруповёрты и гвоздомёты – ещё электричество тянуть, шарахнуть может и платить за него! Ты сам-то хоть один дом построил, перед тем как их советовать? А своим верным камнем я построил ДЕСЯТЬ домов!

Понаписали притч на новый Антроподжем: "Создай игру по своему любимому комменту с Гамина!"

Хорошая тема :D

Живёт себе такой плотник, у которого есть верный камень, которым он забивает гвозди, а сколотым краем – стругает доски.

Дальше можно не читать, потому что прям со старта начинается заведомое представление собеседника нелепым отщепенцем, а себя Д'Артаньяном.

Всё это лирика.

Ну исходная аналогия с забиванием гвоздей пилой намного нелепее была.

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

Кому надо с вами спорить, лол.

Классuka. «Три дня я гналась за вами, чтобы сказать, как вы мне безразличны»

Это было из чувства глубокого (и незапрошенного) соболезнования к заблуждающимся.

А по существу-то не возражаешь, всё прикапываешься к тону вместо сути.

По существу (обсуждать технические нововведения GM 2.3 и области их применения) «ваш» же лагерь традиционно быстро устал и переключился на личности «сперва игор наделай» ¯\_(ツ)_/¯

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

доказали

Hahaha, oh wow

не влекущая за собой больше профита чем требует затрачивать сил

Надо ещё несколько раз это повторить для повышения убедительности доказательства.

хорошо бы чтоб это ввели в движок из коробки

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

Можно. А нужно ли - не обосновано.

Кому надо с вами спорить, лол.

Главное, что гамин в очередной раз был "спасён" от обсуждения программирования

Честно говоря, не понимаю.
Почему программисты просто не говорят в таких случаях: "я программист, я так вижу"? о_0

Потому что другие программисты при этом говорят "ты видишь неправильно".

Иногда они даже говорят: "Ах, ты ещё видишь?!.."

Ну а дальше бокс, прямо как в твоём посте.

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

Варнинги Кситилона. Кто-то на них обращает, кто-то - нет.

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

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

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

(пока умные на юньке игры пишут)

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

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

Это вот ты да, релизнул одну на Стим. Очень странную, настоящее инди.

Безумцем вы хотите представить меня (это уже традиционно) и Хейзера - ну вот после этой фразы только, да, появляется уже такое желание

Git не нужен, а не кватернионы.
Дорабатывай свою теорию.

... а могли бы конкурс уже начать

Пока спор не закончится - никакого конкурса! Иначе опять придется игры делать.

... а кто-то мог бы и сиськи рисовать😈

Ну так ж я это... работаю над этим!

yZgEA7r

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

И вот теперь непонятно, все внезапно успокоились потому что тема себя исчерпала или потому что Разери показал сиськи...

Сиськам очень сложно противостоять... Разери победил

Кажись ты два телесных цвета перепутал местами.

Не придирайся, он все еще учится.

Передумал подтрунивать, мне обратная связь очень важна.

Если сильно интересно, то вот:

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

astEF7l

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

Можно, но только без впаривания левых движков и хуёвых практик.
Я был бы не прочь поглядеть на какой-нибудь GMS проект Юри, где она успешно использует свой подход со словами "вот, гляди как я делаю, разве не круто?".

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

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

Я вообще не приветствую чисто теоретический опыт в форме "инстина в последней инстанции". Хочешь показать мне что кастомные объекты в GMS2.3 позволят сократить код и писать его надёжно и отлажено - покажи проект тогда. Мануальные теоретики - тоже забавные ребята порой. Не так чтобы часто, но и не раз в жизни сталкиваюсь с тем что программа работает не так как написано в мануале. Далеко ходить не надо. Функционал того же xboxlive, описанный в справке GMS идёт по пизде и по факту в обычной версии GMS на реальной консоли тупо не работает. Работает только в определённой версии, которую можно получить только через саппорт.

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

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

Ок, здорово, что у тебя именно такой опыт. Значит мне не везло с реальными проектами.
Видимо, крутая фирма, которая не жопит деньги на рефакторинг, тесты и прочее. Потому что обычно жопит XD

То есть написать две строки кода вместо моей одной - это по-твоему "в строчечку"?

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

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

достаточно будет получить только направление

В таком случае:

cell_x = target.x mod 64
cell_y = target.y mod 64
nearest_dir = 90 * ((4 - ((cell_x < cell_y)?1:0 + (64 - cell_x < cell_y)?1:3)) + 1) mod 4

А теперь это нечитаемо

Суть в том что примерно одинаково нечитаемо с остальными двумя способами.

4) Пользователям теперь придётся думать как организовать свою работу

Что это значит?

2) Скрипты автоматически инициализируются в глобальном скоупе, так что всю инициализацию и глобалы выносить туда и больше ничего нигде ни у кого не вызывать. Лично для меня это означает что я могу упразднить o_loader из своих проектов

Спорный плюс. Раньше можно было зайти в первую комнату и там посмотреть в Creation Code, либо в конкретный скрипт инициализации Всего. А теперь ищи-свищи по ВСЕМ скриптам проектам, что ты там где инициализировал и не пересеклись ли имена ещё между собой незапланированно.

7) Перетаскивание объектов в список события для добавления события столкновения не работает. ХЗ баг это или фича.

Такое было?!

По крайней мере теперь просто так other.myvar написать не получится.

Приведи пример, непонятно.

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

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

Что это значит?

Какие папки заводить и как хранить ассеты. Конечно, никто не мешает делать так же как было и ГМС2.3 даже предлагает по умолчанию такую структуру.

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

Спорный плюс. Раньше можно было зайти в первую комнату и там посмотреть в Creation Code, либо в конкретный скрипт инициализации Всего. А теперь ищи-свищи по ВСЕМ скриптам проектам, что ты там где инициализировал и не пересеклись ли имена ещё между собой незапланированно.

Раньше тоже было спорно. Я, например часто комнаты дублирую, а в GMS2 ещё и наследую. Мне нахер не сдался там код, который должен вызываться один раз за всю игру, а именно - на старте. Кроме того лезть в creation code дико неудобно. Именно потому я его последний раз использовал лет 6 назад.

Такое было?!

Да, в GMS2.2 можно драг-н-дропом объекты из панели ресурсов переносить в список событий чтобы автоматом создать событие столкновения с ним. Можешь даже в GMS7dev это проверить.

Приведи пример, непонятно.

Я сам не очень понимаю пока чем это чревато. Могу привести цитату из обновления пока что

uLKV9ng

По логике other.myVar должно вроде прокатить, т.к. other содержит в себе структуру. Лично я всегда использовал второй вариант, т.к. считал что other - это что-то типа ссылки на объект и мне в любом случае нужно брать id чтобы не профакапиться.

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

Вот это жесть о_О

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