Dilma писал(а):
Я уже с пару десятков раз наверное писал, что hiasm не пригоден для написания игрТолько HiAsm - да, не пригоден, но при комбинированном подходе - вполне: https://docs.unrealengine.com/latest/INT/Engine/Blueprints
Хотя метод построения схемы отличается визуально и функционально от HiAsm, свою задачу выполняет так же хорошо как и HiAsm, упрощает построение логики и абстрагирует тебя от всех сложностей C++, но и не лишает тебя всех прелестей оного.
Dilma писал(а):
А вот ваша задача - встраивание в Unity, MSVS, IntelliJ и т.п. - как мне кажется уже очень далека от этого. Схема более понятна, на то она и схема
Библиотека элементов - хочешь вставь элемент прямиком в код, хочешь, создай схему в существующем проекте, схема после сборки соберётся в единицу трансляции и вуаля, если нужен новый элемент, прямо тут и сейчас добавь его и используй дальше.
Из других участков кода, ты можешь взаимодействовать с "кубическим" кодом как с обычным, в общем, комбинированный подход.
Но согласен, здесь требуется дополнительный разбор полётов, насколько это может быть полезным при разработке, как будет проходить тестирование, сборка проекта из различных систем сборок и насколько востребованно и позволит ли увеличить эффективность написания кода.
Но зато, это сможет привлечь новых пользователей, которые пока незнакомы с ЯП, учатся, либо просто им нужно быстро что либо сделать.
В общем, вариантов много
Почему бы технологии HiAsm не выйти за рамки текущего понимания HiAsm? Быстрее, сильнее, лучше, понятней, гибче, удобней
Так что да, я не придерживаюсь классической идеи развития HiAsm, возможно из-за этого у нас недопонимание возникло.