Титан среди Титанов

VHCbS4N

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

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

Итоговый список выглядит так:

  1. черепаха (6 + 1 + 1 + 1 + 1 + 1 + 1) 1.71
  2. echa (1 + 3 + 2) 2
  3. Kozinaka (1 + 1 + 7 + 2) 2.75
  4. Ailurusfulgensphobia (4 + 2 + 1 + 2 + 6 + 4 + 2 + 2) 2.875
  5. Herzenrg (1 + 1 + 1 + 5 + 2 + 15 + 3) 4
  6. 4mlr (4 + 5 + 1 + 5 + 5) 4
  7. Armagon (1 + 5 + 5 + 6) 4.25
  8. coco-bongo (12 + 1 + 1) 4.6
  9. Likantrop (2 + 1 + 2 + 3 + 6 + 2 + 16 + 8) 5
  10. Rubel (2 + 4 + 7 + 1 + 11) 5
  11. myHazards (3 + 19 + 3 + 1 + 6 + 9 + 4 + 3 + 7 + 2 + 11) 6.18
  12. DarkDes (12 + 7 + 7 + 8 + 9 + 7 + 1) 7.28
  13. Dreik (18 + 8 + 9 + 1 + 3 + 9 + 6) 7.7
  14. stray_stoat (1 + 22 + 3) 8.66
  15. Мурка (14 + 8 + 22 + 8 + 1 + 2) 9.16
  16. alexsilent (5 + 4  + 1 + 28) 9.5

186 комментариев

А в руках у Титанов среди Титанов - Титанические-из-Титанических инструментов для вершения Титанических-из-Титанических дел:

  1. черепаха - C/C++, SFML
  2. echa - Game Maker
  3. Kozinaka - C++
  4. Ailurusfulgensphobia - Game Maker
  5. Herzenrg - Game Maker и один раз бездвижковый HTML5 (Unity был на LD, не на Гаминаторах)
  6. 4mlr - Game Maker
  7. Armagon - Flash
  8. coco-bongo - Unity, Phaser
  9. Likantrop - Game Maker
  10. Rubel - Flash, Game Maker, OpenFL, Haxe, Pico-8
  11. myHazards - Game Maker
  12. DarkDes - Game Maker и один раз Unity
  13. Dreik - Game Maker
  14. stray_stoat - бездвижковый HTML5, QSP и чуть-чуть RPG Maker
  15. Мурка - Game Maker
  16. alexsilent - Stencyl, Tic-80, Blitz Max, Unity, Bitsy, Game Maker

А значит:

  1. Game Maker - 11
  2. Unity - 3
  3. Pico-8 - 2
  4. HTML5 - 2
  5. Всё остальное

Места, которые занимают игроделы на Гамаке: Второе+

Места, которые занимают игроделы на Юнити: Восьмое+

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

Ключевой вопрос - всё ли что черепаха делал на SFML, можно было сделать и на Гамаке? Деритесь.

И не забывайте кидать лопаты! Кидайте пока ловлю, потом проверять не буду и промахнётесь!

Еще можно заметить такую тенденцию, что у гмако-чемпионов в среднем больше игр!

Потому что на гамаке все делается быстро, легко, удобно и (как доказали только что титаны) на высшем уровне! Преклоняюсь перед великим Марком Овермарсом, давшим путевку в жизнь и мне в том числе!!

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

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

И тут я отсылаю зрителей к своему недавнему комментарию: https://gamin.me/posts/21276?comment=278683#comment_278683

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

самая всем очевидно качественная и многообещающая игра всех гаминаторов за шесть лет занимает 15 место

Ну, это вброс. Тут многие даже не назовут о какой ты игре сейчас.

ну если ты не считаешь, что она лучшая, тогда пусть: самая всем, кроме Ксита, очевидно качественная и многообещающая игра всех гаминаторов за шесть лет)

нее. AnnTenna.
запилить игру на рпгмейке продающуюся в стиме! а рейтинги котенка в стиме? а дрянька на олдгеймз и смоллгеймз?! Антенна это СБ современности

Дрянька начата в 2008 году, а свой отзыв на почту я писал по ней где-то в 2012. Такая себе современность, но титаном назвать можно, хоть это уже не контекст Гаминаторов.

Это сверх-троллинг такой, да? Ты подмигни что ли как-нибудь.

Кто это Долин?

> многообещающая игра всех гаминаторов за шесть лет занимает 15 место

Если это Сундук Хейзера, то даже ты сам не отдал ему первое место...

А малец я не помню, чтобы побеждал. Там еще куча КОДов ведь без победителей. Может он чаще там участвовал.

"сам не отдал ему первое место"

потому что любовь - она не в циферках.
Помним ли мы бумажное подземелье, ждем ли его так как выхода Сундука?

А кто-то ждет выхода Сундука?

Я надеюсь, ты угораешь там, сидя за клавой.

ждем ли его

Оно и так где только не, куда ещё ждать?

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

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

манипуляторы массовым сознанием

Гамин очень ценен именно тем, что тут типичные массовые потребители если и сидят, то не преобладают. Это нишевая статистика, по нишевым ценителям. Тут можно только дальше раздувать "а вот есть ещё нише-нишевые special snowflakes". Есть конечно.

Приветствую составление тобой своего, правильного рейтинга геймдизайнеров.

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

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

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

И опять я отошлю к своему недавнему комментарию: https://gamin.me/posts/21276?comment=278683#comment_278683

Ну все, начали высасывать из пальца "почему Гамак для конкурсов лучше".

Инквизитору нужно, чтобы все движки кроме гамака были сожжены.

parsec> Почему, когда выходит новость о новой версии какого-либо языка, на ЛОРе начинается джихад в комментариях га n>5 страниц?
makoven> Потомучто мальчики выбирают языки как девочки парней: их много снуёт вокруг, у каждого свои плюсы и минусы, а любовь надо отдать одному единственному. Иногда двум-трем. И уж если выбрирать (язык) то такой, с которым будет более-менее приятно сношаться длительное время на регулярной основе, получая взамен максимум выгоды.
makoven> Поэтому неудевительно, что подружки, выбравшие другого (технологию) так и норовят поиздеваться над тобой. Это они так завидуют и пытаются убедить сами себя в правильности своего выбора.

На Юнити тоже. Добавил Фейзер.

я кстати не Flash использовал, а Stencyl (на чистом флеше не делал игр и Action Script не знал)
ещё использовал Tic-80 и Blitz Max (а вот Pico-8 на конкурсах никогда не юзал, вроде, только изучал)
(хотя насчёт Tic-80 тоже не помню точно, использовал ли в конкурсах, забыл...)

А Daring Do? На Стенсиле?

Хорошо, добавил.

да)

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

651RxdE

я с этим борюсь, спавня обьекты кодом х)
(ну кроме например стен каких-то)

Блин, я думал это решаемо) например какую-то просто кнопку зажать дополнительную Т_Т

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

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

Как уже успел заметить Раззл, в актуальной версии ГМа такой проблемы нет.

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

Да ладно, и в Ринго тоже? А как же тот самый балкон работает? Стены-то хоть ставил?

Нет, редактор комнат девственно чист у меня всегда.

Объекты и все прочее я добавляю в Creation Code комнаты, а комнаты делятся по функционалу: титры, опции, игровой мир, выбор сейва и т.д. Вся игра по сути происходит в одной комнате, где я кодом расставляю все в зависимости от локации. А координаты и прочие атрибуты того, что нужно расставить, я храню в экселе, из которого макросом собираю .тхт (фактически как бд). А в игре в гриды их собираю вначале и потом обращаюсь. Очень удобно. То есть все данные у меня в "бд" экселя лежат.

Это ж как же плотно надо всё планировать до и тестировать после. Стальная методология!

Почему? Наоборот, цифру в экселе поменял и все готово.

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

Ответил ниже.

Если многоугольники, то я пару часов назад Алексу сделал код, который как раз к этому случаю очень сильно относится. Собрал на ГМ8.1 демку.

https://www.dropbox.com/s/jw8n8wyjcphihma/FreeformWall.gm81?dl=0

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

Запустил на студии. А в чем смысл демки?

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

То есть стены в этом случае ставить вообще не надо, только один объект "все стены" на всю локацию (если она не огромная, для пиксель-артных игр-то 1000x300 вполне).

Но конечно можно ставить мелкие стены отдельно, если прокатит обойтись одними ими.

Да, работает все гладко, класс. В своем случае с жрпг я делал вот такой спрайт-маску, а в экселе писал, что в такой-то локации такой-то спрайт является маской )

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

Ага, напугали когда-то пресайз коллиженами. Причем, вроде, сама справке ГМа и пугает ими, типа, медленно.

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

Вот в жрпг как раз ) Там я делал уже как-то по другому через пресайз коллижн хитрого спрайта.

Ну и конечно прикол в том всегда, что когда я смотрю чужой код или читаю ваши рассуждения о программировании (даже на гм) у меня через три строчки в голове появляется туман ))

Я точно так же читаю чужие обсуждения кода на том же ГМе. Все что-то своё лепят. Но этот код, я думаю, модифицировать уже не понадобится, для заявленной цели. Буду рад если он на что-то сгодится.

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

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

Там суть в том что проверяется 8 кругов вокруг центра, все на одинаковом расстоянии. И какой срабатывает, такой и отталкивает персонажа назад на 1 пиксел в противоположном направлении.

Z5Ci4YM

Синее расстояние - это third (одна треть от ширины спрайта), зелёное - это sixth (одна шестая, это радиус каждого круглого детектора коллизии).

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

LbVnKNu


Запихать все тайлы в инфу массива, и сделать мини-скрипт столкновения,
точнее взять со своей старой игры на Tic-80


Хах, идентификатор картриджа - 999!

Чего? )) Опять как-то по другому надо было делать? ))

Ничего не говорю, как надо, просто удивляюсь такому подходу. А в чём профит по сравнению с тем, чтобы в редакторе комнат расставить? Со стороны выглядит, как куча нудной ручной работы в этом самом экселе, но я могу чего-то не понимать.

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

Сейчас у меня есть простая таблица, в которой написано, что в такой-то локации, в такой-то точке построй такой-то многоугольник.

А ты предлагаешь как сделать? Навырезать на каждый случай спрайтов-стен и руками их выставлять в 60-ти комнатах?

о_О ого, я думал вся эта красота в редакторе сделана

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

Ну допустим. Но стены-то ты кодом спаунишь?

Да. Там довольно хитрая у меня система. Я задаю координаты, а потом в игре создаю временный спрайт на основе этих координат и втыкаю его как стену.

SFML не подвел. По сути это вариант "нет движка /свой движок", ведь sfml, как известно, не движок. И этот вариант выбирают примерно все мои инди-кумиры - Тарас, Бобров, DarkGod, авторы других крутых рогаликов. А гамак с юнити - да, выбор большинства, но успеха не гарантирует.

Ах, если бы было средство, гарантирующее успех...

Это средство — движок, который используют FromSoftware. Сами посудите — у них с 2009 года что ни игра — то успех. Но они не дураки и движком не делятся. Хотя могли бы на порядок увеличить количество хороших игр, просто разрешив лицензировать их движок сторонним разработчикам. Очень эгоистично с их стороны 😠

Для версии нулевых фромовского движка таки есть возможность каждому попробовать свои силы на ПК. http://www.hardcoregaming101.net/sword-of-moonlight-kings-field-making-tool/

Это для нишевого успеха!

sfml, как известно, не движок

На итч.ио написано "Made with SFML", уже лучше чем ничего.

Черепаха, какой язык ты используешь-то в итоге?

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

С++/sfml использовал только для Metrodrome и Смолы, для un и Lucid был С с прямым использованием win32 API. А сейчас вот учу относительно новый Zig, на ГБР использую Zig/OpenGL, пока что такое комбо очень сильно нравится.

Крайне диковинно. Zig не пишу, так как тут о Гаминаторах тема. Си добавил, спасибо за инфу.

сейчас вот учу относительно новый Zig

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

Ну, мне лично очень нравится, он сохраняет все хорошие стороны Си, при этом устраняя сложности связанные с препроцессором и undefined behavior. Comptime исполение кода - крутейшая фича. Это все равно если бы макросы Си были написаны в самом Си. Навскидку, там еще хороший error handling, стандартная библиотека довольно полная и приятная.

Я смотрел еще на насколько языков для изучения после использования Си на протяжении наскольких лет, все имеют какие-то изьяны. Rust неплох, но скорость компиляции просто неприемлема лично для меня. Crystal, Nim - выглядят очень интересно, но они к сожалению garbage collected. Про С++ просто ничено не буду писать, просто отвратительный язык с точки зрения удовольствия писания, после ~5 лет использования просто выворачивает когда вижу С++ код. Jai от Блоу жду, но вот уже несколько лет никак не дождусь.

При том что я сам Си евангелист, если так могу сам назваться, Zig это почти точно как я себе представляю Си без всех его кучи изьянов.

Прикольно, спасибо.

И сильно сырой?

Comptime исполение кода

это вроде constexpr из C++?

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

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

А что за баг кстати?

Просто тот же Nim, хоть уже и 1.x, до сих пор вроде какое-то стрёмное глюкалово

А на D ты не писал никогда?

Баг совсем незначительный, сложно случайно словить, вот к нему Issue на Гитхабе: https://github.com/ziglang/zig/issues/6768. Zig я бы уже смело назвал 1.0, если кто-либо бы спрашивал моего мнения.

D не пробовал, нет. Насколько знаю, там ведь тоже GC?

Спасибо. Сразу видно ленивое вычисление логических операций)

там ведь тоже GC?

вроде можно без коллектора, но врать не буду

GC в D, строго говоря, опционален и может быть отключён, но бóльшая часть стандартной библиотеки после этого начнёт подтекать.

Настоящий сишник всегда пишет свою стандартную библиотеку

А потом поднимает на смех ГМщика который пишет полторы собственные функции чтоб дополнить встроенный функционал до нужного в конкретной игре. Лалки. :yak:

Comptime исполение кода - крутейшая фича.

Пример использования из твоей практики можно?

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

Тут всё слишком абстрактное и одноразовое, математика ради математики.

Например, у меня почти все сущности (различные structы) на уровне имеют поле disposable: bool, которое если true, то я хочу такую сущность убрать из ArrayListа на уровне и заодно подчистить всю динамическую память сущности.

Можно бы такую проверку и подчистку сделать 10 раз для каждого типа сущностей, а-ля для Enemy:

var enemies: std.ArrayList(Enemy) = undefined;

...

var i: usize = 0;
while (i < enemies.items.len) {
    if (enemies.disposable) {
        enemies.orderedRemove(i).deinit();
    } else {
        i += 1;
    }
}

Тоесть 10 раз копи-пастить тот же самый код, подменяя Enemy на Particle например.

А сейчас если использовать comptime слово, можно написать дженерик функцию для чищения какого-либо угодного comptime-известного типа:

pub fn entityDispose(comptime Entity: type, comptime disposable: []const u8, entities: *std.ArrayList(Entity), deinit_fn: anytype) !void {
    var i: usize = 0;
    while (i < entities.*.items.len) {
        if (@field(entities.*.items[i], disposable)) {
            deinit_fn(entities.*.orderedRemove(i));
        } else {
            i += 1;
        }
    }
}

И потом вся чистка 10 гипотетических типов обьектов сводится только к 1 вызову функции на обьект:

try entityDispose(Enemy, "disposable", &enemies, Enemy.deinit);
try entityDispose(Particle, "disposable", &particles, Particle.deinit);

...

При этом использование функции entityDispose на несуществующем типе, или типе у которого не будет поля disposable - сгенерирует compile time ошибки, что очевидно в разы лучше чем если бы игра вывалилась где-то уже у игрока.

if (@field(entities.*.items[i], disposable))

ой, это же жабаскрипт :-)

Например, у меня почти все сущности (различные structы) на уровне имеют поле disposable: bool, которое если true, то я хочу такую сущность убрать из ArrayListа на уровне и заодно подчистить всю динамическую память сущности.

А в каком контексте ты хочешь убирать сущности с disposable==true? Это тебе нужно делать между уровнями, между неигровыми вещами типа катсцен, в конце? ArrayList хранит текущий список struct'ов, я так понял.

подчистку

Ты имеешь в виду то что обычно пишут в деструкторы классов?

!void

Это новый тип данных такой?! XD Видимо часть какого-то нового хитрого синтаксиса?

try entityDispose(Enemy, "disposable", &enemies, Enemy.deinit);
try entityDispose(Particle, "disposable", &particles, Particle.deinit);

...

Хм... А нельзя ли, скажем, унаследовать struct'ы от некоего абстрактного, или имплементировать интерфейс IDisposable (правда это уже C#, но вдруг есть аналогичные приёмы) и делать что-то вроде такого?

foreach (Entity e in Entities)
    if (e.Disposable)
        e.Dispose();

Такую подчистку делаю на каждом игровом фрейме. Это чтобы разделить по премени чистку разных обьектов и их логику. Да, храню structы в ArrayListaх в этом примере.

Это новый тип данных такой?! XD Видимо часть какого-то нового хитрого синтаксиса?

Нет !void - это синтаксический сахар, означает что функция возвращает union либо voidа, либо какого-нибудь errora. Может быть, например, у функции-конструктора врага, быть return type !Enemy если в ней есть код, который может бросить ошибкой в рантайме.

Хм... А нельзя ли, скажем, унаследовать struct'ы

В Zig, как и в Си, нету наследования, что по моему мнению жирный плюс. Иначе получился бы очередной недо-С++. Как по мне метапрограммирование разнородное намного приятнее и изящнее решает проблему генерализации, чем ОО-парадигма, которая в теории изящна но на практике часто выливается в написание простыней из тысячей строчек кода.

Спасибо за пояснения. Довольно премудро это всё.

ОО-парадигма, которая в теории изящна но на практике часто выливается в написание простыней из тысячей строчек кода

Я вот не знаю, опять что ли ввязываться в холивор по поводу "ОО-парадигмы"? Я практик чего-то объектно-ориентированного в ГМе, но не знаю чего именно - недавно вот оказалось, что если в унаследованном объекте (классе) не имплементируется какой-то из унаследованных членов, то это тогда не наследование, но если остальные члены автоматически наследуются, а часть других оверрайдится, то что это вообще такое?

В моей практике нет никаких простыней из тысяч строк кода - ни обусловленных чем-то ООПшным, ни обусловленных чем-либо ещё другим. "Приятнее и изящнее" это то что я сказал бы про GML не во всех, но в очень многих случаях по сравнению с C#, частично JS и особенно Java.

Пока что получается:

foreach (Entity e in Entities)
    if (e.Disposable)
        e.Dispose();

Против:

with o_entity//это общий предок всех "подчищабельных" объектов
    if disposable
        dispose()//ну или event_perform(ev_destroy, 0) если прям по-умному

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

constexpr в ГМе, к сожалению, не имеется, и на горизонте ничего подобного не видно. Отлов ошибок в compile-time это конечно круто, нет вопросов.

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

Согласен, на этом и предлагаю остановиться, и вообще жалею что бросил сюда свои мысли по поводу ООП. Это не более чем мои собственные мысли, а они не многое значат :) Peace

Это было не лишним, наоборот очень интересно узнать, как там всё выглядит изнутри. Извини если задел.

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

var _count = 0;
with(o_Enemy) {
   if (isBoss) _count ++;
}
show_debug_message("Boss Count: "+string(_count));

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

//стартовый код
Power = 5;

//step код
var _power = Power; // костыль чтобы передать данные силы урона
with(o_Enemy) {
 HP -= _power;
}

Для работы с вызвавшим:

with(obj){
other.h_speed
}

Для передачи чего-то всем:

with(all)

ещё можно как ксит писал:

obj_name.h_speed

обращаться...

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

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

А как эта задача по-умному решается методом композирования?
Без ромбовидного наследования и интерфейсов? о_0

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

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

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

Делаем компонент, реализующий телепортацию, делаем компонент, реализующий стрельбу. При создании сущности даем ей оба компонента.
Так это работает в Юнити, например.

ромбовидное наследование / всякие костыли с интерфейсами / дублирование кода

Опять эти мифические монстры, которых в ГМе нет. (последнее есть, когда руки кривые/мало времени)

Я уже начинаю подозревать что происходящее в нём описывается как "полу-ООП с полу-ECS".

Ну так вопрос не от гмщика был. Гмщику я бы на тот же вопрос ответил "дублирование кода / отказ от наследования и переделка всего на композицию".

SFML это низкоуровневая библиотека с функциями вида "создать окно", "получить событие ввода", "нарисовать треугольник" "добавить объект треугольника в список на отрисовку" для тех кто не хочет возиться с уровнем ОС. Бобров, например, SDL использует, который примерно того же уровня.

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

На всякий случай напомню: перечислялись Титанические-Из-Титанических инструментов, не обязательно движки. Я же там и HTML5 вписал - это не движок, а язык разметки.

Титанический Win32 API как волшебная палочка лучшего инди-геймдевелопера Гаминаторов... уххх. Даже не знаю что страннее, это, или то что "раздают" инди-игру Cave Story на клиенте от создателей Анриала. Какие-то понятия из разных миров. Но игры есть, и это главное.

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

Блин, точно. Значит меняю с "не на Гаминаторе" на "один раз Юнити". И увеличиваю с 2 до 3 счётчик.

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