Как стать автором
Обновить

О, «Герои»? Дайте две! Как я писал очередной браузерный клон легендарной стратегии, в который уже почти* можно играть

Уровень сложностиПростой
Время на прочтение14 мин
Количество просмотров35K
Всего голосов 191: ↑191 и ↓0+191
Комментарии79

Комментарии 79

Безумству храбрых поем мы песню (с).

Удалось немного поиграть. Конечно, игра жутчайше, адски глючит и лагает, но то, что это вообще работает, поражает воображение.

Конечно, игра жутчайше, адски глючит и лагает

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

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

Я как-то мечтал о подобном, но юнити еще тогда не знал, и хотел на WPF. Ведь в игре много интерфейсов! Такая классная технология и так жаль, что не кроссплатформенная.

canvas в смысле внутреигровой или который html canvas?

Который HTML <canvas>. В движке сейчас используются только DOM-узлы для представления всей графики.

А мб стоит переписать на WebGL (или сразу на Three.js :-))?

Конечно, можно, только что значит "переписать"? Если имеется в виду переписать движок, то в этом нет необходимости — за графику там отвечает хорошо если 15% всего кода.

Ну да, графику я и имел в виду.

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

Я работал с Phaser. Это целый комбайн размером с сам HeroWO. Например, у него есть физический движок (расчет столкновений и прочее). Тащить его только ради рисования текстур как-то не камильфо (для звуков уже есть своя вполне адекватная подсистема) — это можно делать и без всяких библиотек.

Только у вас миллион нод и проблемы с клампингом, а у phaser 60 fps и прочая инфраструктура для game dev. Дело-то конечно ваше.

Фазер очень просто скомпилировать без физики и др. ненужных модулей: https://github.com/photonstorm/phaser3-custom-build
В минимальной сборке можно довести получить меньше 150 КВ gzipped

Славяне могут вдыхать жизнь в героев до бесконечности. Восхищает и удивляет.

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

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

Команда HotA - закрытая донельзя и базируется на оригинальных "Героях", так что "официальным" такой проект никогда не станет и пределы роста у него весьма ощутимые. Реальнее было бы вкладываться в VCMI или fheroes2, но там совсем другой стек и свои тараканы, о чем неплохо написано тут.

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

Нужно действовать поэтапно. HotA — это надстройка над SoD. Когда будет полная поддержка SoD, то добавить "ребаланс и фичи" не составит труда.

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

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

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

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

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

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

Смысл добавлять столько всего нового, если сама игра нормально не работает?

Вы ошибочно считаете, что я специально тратил время на добавление нестандартных для "Героев" функций. Это не так. Проект писался с нуля, а потому очень многие функции получились сами собой, просто потому, что они были заложены при проектировании. С точки зрения кода разница между картами с 2 уровнями или 22 — никакой. То же самое с битвой — хоть два героя, хоть десять, хоть поле 15×11, хоть 30×20. Да, на данный момент нет подходящей графики и баланса, но их легко добавить, если в движке нет фундаментальных ограничений.

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

Простите, если показался излишне резок.

Просто как показал печальный опыт упомянутых выше проектов, пока сама основа движка не будет сделана на совесть, эти продукты никогда не станут восприниматься игроками, как нечто стоящее. Free Heroes 2 был заложен ещё до 2010 года. И после ~10 лет разработки он так и не приблизился к вменяемому состоянию. И был заброшен в середине 2010-ых. Как думаете, почему? И дело здесь не только в угасании интереса разработчиков. Просто проект стал тонуть в бесконечных багах, которые разработчики не могли исправить. На той стадии в движке нормально не работало ничего. От интерфейса и логики игры, до рендеринга и ИИ.

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

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

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

У вас есть фича - возможность битвы 3х1 на большом поле. В оригинале такой возможности нет. При этом мы все согласимся, что и интерфейсно, и гемплейно, и по балансу оригинальные homm3 очень далеки от совершенства и существует масса интереснейших механик, которые бы им пошли на пользу, но которых в оригинале нет. Однако, если в достаточной мере увлечься внедрением новых механик, получится игра, которая должна будет называться не "герои меча и магии 3 в браузере" а "herowo". В русской транслитирации звучит не слишком то благозвучно!

В какой степени вы видите должным балансировать между подражанием классике и внесением новизны?

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

Ответа на этот вопрос нет, но вся соль в том, что HeroWO на него и не пытается ответить и не делает за вас этот выбор. В текущей версии все улучшения — косметические, но даже их можно убрать магическим переключателем "Classic" (https://herowo.game/?classic) и игра станет неотличимой от SoD, вплоть до криво расставленных элементов UI.

Задача HeroWO — дать простор для творчества, а не использовать его. Согласитесь, не использовать имеющийся простор проще, чем использовать неимеющийся :)

Однако, если в достаточной мере увлечься внедрением новых механик, получится игра, которая должна будет называться не "герои меча и магии 3 в браузере" а "herowo".

Функционал геймплея предоставляется модулями, как то H3.js ("Heroes 3"). В H3 сейчас нет возможности запустить битву с 3+ участниками, но модуль может сделать это элементарно. Вы при запуске сами решаете, в какую модификацию хотите играть, никто вам "улучшенных Героев" навязывать не будет.

В русской транслитирации звучит не слишком то благозвучно!

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

Круто, серьёзно.

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

НЛО прилетело и опубликовало эту надпись здесь

то одновременные ходы отключаются и ход начинается сначала.

А это не тоже ли самое? Только еще и с машиной времени.

А это не тоже ли самое? Только еще и с машиной времени.

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

То есть отключение одновременных ходов никакой информации вам не добавляет. Но дает пространство для абьюза машины времени.

Что из этого хуже или лучше это уже другой вопрос.

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

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

Автоматическое отключение по расстоянию на самом деле звучит как интересная альтернатива откату хода как такому себе последнему рубежу.

Мне кажется можно откатывать менее чем на ход.
Ну как минимум если 3 игрок увидел 5, то ходы 1,2 игроков можно не трогать.

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

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

еле отлип от сайта через 2 часа :D

Z-координата (глубина/дальность от глаз пользователя) вычисляется неясным образом.

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

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

Очень круто! завидую белой завистью. В 2016 году тоже начинал подобный проект, но пошел другим путем. Делал игру без серверной части. У меня была цель сделать максимально аутентично. Для того что бы поиграть нужно было иметь оригинальный файл с ресурсами, который нужно было загрузить в браузер. Там он парсился(локально, без отправки на сервер). Для отрисовки использовал WebGl- во первых это работало намного быстрее, во вторых позволяло использовать все оригинальные графические решения, например вода анимировалась честным colour cycling, цвета флагов подставлялись динамически, и так далее. К сожалению потом стало намного меньше свободного времени и проект забросил. успел сделать только до состояния что отображается карта, по которой можно походить героем и пособирать ресурсы. Как раз недавно откопал на битбакете исходники, думал не опубликовать-ли их, но почитав понял что они слишком ужасны что бы кому-то показывать. Раздумываю над тем не написать-ли статью про "анатомию" героев- в каком формате хранятся какие ресурсы, как их можно распаковать и как отрисовать в webgl.

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

Это тупиковый подход, если планируешь хоть немного расширять оригинал (а такое желание возникнет рано или поздно, инфа 100%). Например, в картинки нельзя добавить 8-битный альфа-канал и 24-битный цвет. А уж парсить бинарные данные на JavaScript...

Для отрисовки использовал WebGl- во первых это работало намного быстрее, во вторых позволяло использовать все оригинальные графические решения, например вода анимировалась честным colour cycling, цвета флагов подставлялись динамически, и так далее.

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

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

Вам я предлагаю дописать красивую воду — или, для начала, отрисовать мини-карту :)

Раздумываю над тем не написать-ли статью про "анатомию" героев- в каком формате хранятся какие ресурсы, как их можно распаковать и как отрисовать в webgl.

Что за вопрос, это же Хабр! Больше статей о "Героях", хороших и разных!

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

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

А уж парсить бинарные данные на JavaScript...

Не все так плохо, там есть ArrayBuffer в котором это делать достаточно комфортно.

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

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

для начала, отрисовать мини-карту :)

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

Очень круто.
Но немного печалит TLDR. А именно сочетание "Неограниченное число всего на свете" и "багов полно и все тормозит".
Напоминает анекдот "а теперь мы попробуем со всей этой фигней взлететь".
Мне кажется, что прототип, не столь богатый функционально, но рабочий, было бы проще разработать и в дальнейшем развивать.


У нас был тренер по аджайлу, который очень любил рассказывать историю про Скрепыша. Что Микрософт вбухала в этого анимированного помощника кучу сил, научила его разговаривать разными голосами, делать смешные ужимки, использовать кучу разных персонажей… Но в итоге он оказался никому не нужным. "Если бы" — заключал тренер — "Микрософт выкатила концепт с гораздо меньшим количеством кул фич, и увидела что не взлетело, то сэкономила бы себе кучу ресурсов".

Напоминает анекдот "а теперь мы попробуем со всей этой фигней взлететь".

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

Как я уже отвечал выше, не нужно считать, что я специально тратил время на добавление нестандартных для "Героев" функций. Текущий вариант — это и есть минимальный прототип.

Ну… вы смотрели код в репозитории? На ваш взгляд, его качество действительно можно охарактеризовать как "фигня"?

Нет, не смотрел. Мой комментарий был вообще не про код. Слово, которое вас так обидело, относится не к коду, а к анекдоту. Который вы, судя по всему, не знаете, хотя у него борода длиннее экватора.


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


Как я уже отвечал выше, не нужно считать, что я специально тратил время на добавление нестандартных для "Героев" функций. Текущий вариант — это и есть минимальный прототип.

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

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

Пятая часть же хорошая была... И вроде по деньгам в плюс вышла.

а снова и снова переигрывают только в третью часть

Четвертые и пятые тоже имеют своих поклонников. На упомянутом в статье forum.heroesworld.ru раздел по 5ым вполне себе живой.

там по комменту раз в три месяца, можно считать что вообще все форумы там мертвы

Интерпретируемый язык сам по себе сократит время разработки

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

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

Вы что-то путаете. Тесты пишут для программ на любых языках.
Если вы про статические анализаторы ("работу компилятора"), то они уже есть, их писать не надо. "Баги в продакшене" опять же есть у программ на любом языке. Компилятор — это не волшебный удалитель багов.

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

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

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

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

Вы так старательно пытаетесь натянуть сову на глобус, что это даже умиляет :)


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


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

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


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

Лучше, чем вы думаете

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

Что-то глупости какие-то вы пишите. Возможно вы никогда не сталкивались со статическими анализаторами.


Если в стат. анализаторе метод потребует строковый аргумент в нижнем регистре, который должен быть не пустым и содержать ссылку на класс в системе и являться значением одной из констант в классе, то передав его из юзерспейса он накидает кучу ошибок, что аргумент является string, однако требуется что-то вроде non-empty-lowercase-string & class-string & Class::CONST_*, однако проверки на это сделаны в коде не были.

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


Если вы намекаете на то, что я не прав в части


Если говорить конкретно о выбранных автором JS и PHP, то там всё очень плохо с этим.

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

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


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

Он же не знает, что именно будет передано в качестве параметра

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

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

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

Вудуш одобряет :) Вам бы в команду HotA Crew.

Вы походу переоцениваете открытость команды HotA Crew)

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

Да, ПКМ должен работать. Мака не имею, проверить не могу, увы.

Похоже, я что-то не так делаю, но в "Классическом" режиме дальше выбора карт продвинуться так и не удалось...

А так низкий поклон за монументальный объем работ по любимой стратегии.

П.С. Интересно, кто-то соберется сделать аналог по не менее гениальному но куда менее известному M.A.X.? Я бы поучаствовал...

Ну я создавал автору issue, он отвечает, так что видимо это приемлемая для него альтернатива.

Я не против GitHub. На форуме для многих нехабровчан должно быть проще, только и всего.

О, я тут случайно застукал своего ребенка играющего в HMM 3. 19 лет ребенку. Игра старше его. Так что даже молодежь играет!

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

Есть вариант, что z-координата ни что иное как обозначение подземки. 0/1 или четное/нечетное. можно там поиграться попробовать

Зарегистрируйтесь на Хабре, чтобы оставить комментарий