Визуальное программирование это что такое
Визуальное программирование
Визуальное программирование — способ создания программы для ЭВМ путём манипулирования графическими объектами вместо написания её текста.
Языки визуального программирования могут быть дополнительно классифицированы в зависимости от типа и степени визуального выражения, на следующие типы:
Визуально-преобразованные языки являются невизуальными языками с наложенным визуальным представлением (например, среда Visual C++ для языка C++). Естественно-визуальные языки имеют неотъемлемое визуальное выражение, для которого нет очевидного текстового эквивалента (например, графический язык G в среде LabVIEW).
В современных разработках делаются попытки интегрировать подход визуального программирования с программированием потоков данных (англ. dataflow programming ), чтобы иметь непосредственный доступ к состоянию программы для онлайновой отладки, или автоматизированная генерация и документирование программы. Языки потоков данных также позволяют делать автоматическое распараллеливание, которое может стать одним из величайших достижений программирования в будущем. [1]
Содержание
Графические, или визуальные, языки программирования
Это незаконченный список, который может быть никогда не будет удовлетворять каким-либо стандартам по своей завершенности. Вы можете дополнить его, ссылаясь на источники.
В SFC программа описывается в виде схематической последовательности шагов, объединённых переходами.
Почему визуальное программирование и D3NE могут быть Вам полезны
Визуальное программирование позволяет описывать процессы в графическом виде, в отличии от текстового представления, где нужно приложить дополнительные усилия, чтобы мыслить так, как это должен выполнять компьютер. Звучит многообещающе, но попробуем разобраться в сути и выяснить, почему Вам стоит это попробовать.
Само по себе программирование подразумевает не только процесс написания кода, но зачастую на это тратится большая часть времени при разработке. Только представьте, сколько усилий приходится тратить на то, чтобы держать в голове множество правил и спецификаций к конкретному языку программирования, вместо того, чтобы сосредоточиться на решаемой проблеме. Особенно может раздражать разнообразие синтаксиса в языках: где-то нужна точка с запятой, где-то не нужны фигурные скобки, где-то вообще ни одно выражение не обходится без скобок. Что уж и говорить о холиварах, напоминающие религиозные споры.
Кадр из сериала «Кремниевая долина»
Часто советуют начать разработку ПО с графического описания будущей системы, ее компонентов и связей между ними, чтобы на ранних стадиях определить более выгодную структуру системы и минимизировать возможные проблемы в будущем. Графическое представление легче для понимания, чем текстовый вариант, но может иметь свои ограничения, к тому же это все равно придется переводить в понятный компилятору код. Конечно, на маленькие приложения (какими они могут казаться вначале) это не распространяется, можно сразу приступить к написанию кода, но проблема все равно остается — нужно думать в рамках определенного языка программирования. Тем более, когда вы это делаете в давно приевшемся вам императивном стиле.
Программисты по своей сути должны быть ленивыми, чтобы находить выгодные способы решения задач и не тратить силы на рутину, тем более, глядя на тенденции увеличения сложности ПО. Именно это стимулирует рождение парадигм, языков программирования и абсолютно новых, казалось бы, и малоизвестных инструментов визуального программирования.
Зачем и где применяют визуальное программирование
Одним из первых инструментов, более известных и дружелюбных для рядового гражданина, можно считать Scratch. Он предназначен исключительно для образовательных целей, так как представляет собой те же блоки кода, только обернутые в разноцветные пазлы. Практической пользы нет никакой, если вы уже умеете писать код.
Похожий инструмент от Google под название Blocky
Существует другой вид визуального программирования, более полезный на мой взгляд, это Data-flow programming. Он не такой гибкий как предыдущий и служит некоторой надстройкой для программирования процессов определенной тематики. Его суть состоит в манипуляции данными, передаваемыми между блоками (узлами).
Пример редактора узлов из Blender
Преимущество такого подхода в следующем: не нужно думать о том, что происходит с данными в узлах, а лишь знать, что они делают, получают на вход и отдают на выходе. Остается лишь выбрать нужные узлы и соединить их между собой линиями, по которым без особого затруднения можно понять, что и с чем связано.
Редактор узлов в Blender — именно тот случай, когда используется программирование потоков данных для управления рендерингом, создания шейдеров и текстур. Такой подход в 3D моделировании и рендеринге достаточно популярен, так как никому не хочется писать код, а создавать инструкции для нелинейного управления данными необходимо.
Также известный всем в сообществе 3D моделлеров это Substance Designer, который позволяет создавать 3D материалы по принципу, описанному выше.
Редактор для создания материала в Substance Designer
Хотя в официальных источниках упоминания о программировании нету, в нем используется самый настоящий data-flow. Наверное, это такой маркетинговый ход — не говорить о том, что может отпугнуть.
Итак, разобрались в том, почему визуальное программирование используется в 3D моделировании, но как насчет тех сфер деятельности, где без умения писать код не получится сделать достаточно функциональный продукт? Казалось бы, если умеешь писать код, то просто нужно развивать этот навык, но нет — именно в геймдеве одними из первых стали применяться инструменты для программирования без кодинга. С одной стороны, это было выгодно для популяризации геймдева среди тех, кого отпугивает код лишь одним видом, с другой — прогресс не стоит на месте и даже гуру программирования надоело ставить пробелы вместо табов чтение тысяч строк кода и его поддержка, и они решили попробовать новые методики описания логики и процессов.
Многие знают UE4 с его Blueprint’ом. Это уже не просто data-flow, а что-то большее, так как позволяет формировать инструкции, которые будут выполняться не за один проход, а в течении всего жизненного цикла.
Пример вывода строки по событию
Например, в нем есть узлы для отправки событий. Подключенные к ним узлы выполняются только в тот момент, когда срабатывает событие. Получается очень удобно, не нужно оперировать какими-то объектами и методами, а просто провести соединение от выхода к входу.
Существует еще много отдельных инструментов для визуального программирования (чаще их позиционируют как среда графического программирования), но они не так привлекательны, имеют узкую направленность или вовсе более похожи на конструкторы, чем на инструменты программирования.
Общие аспекты разработки редакторов узлов
Допустим, однажды вы увидели как делают магию программируют с использованием какого-то редактора с блоками и линиями. К вашему удивлению это оказалось именно тем, что позволит воплотить вашу идею (скажем, какой-то продвинутый генератор диалогов, которые представить в виде обычного графа не получится).
Главное, от чего будет зависеть процесс разработки — платформа и технологии. В последнее время много чего можно сделать прямо в браузере, пусть даже пожертвовав производительностью, что в большинстве случаев никак не отразится на качестве приложения (в ином случае asm.js/wasm в помощь). Одна из особенностей таких приложений — они могут быть встроены в другие нативные приложения. Выбор инструментов и языков программирования должен быть в интересах разработчика, чтобы сделать процесс разработки более комфортным и эффективным и снизить вероятность выстрелить себе в ногу появления проблем.
Определившись с платформой и языком, было бы хорошо использовать готовые решения (в нашем случае речь идет о редакторе узлов), но и здесь не все гладко.
Есть несколько вариантов:
Что такое D3NE
D3 Node editor (D3NE) — это JS библиотека для создания редакторов узлов для решения задач визуального программирования. Библиотека полностью берет на себя работу по отображению и обработке узлов. Использует D3.js и Angular Light
На GitHub Wiki доступен туториал, а также подробное описание всех компонентов и терминологии, используемой в библиотеке (вики на англ. и возможны грамматические ошибки, поэтому буду рад помощи в их исправлении)
Все началось с одного проекта (так он и лежит в draft’ах), в котором появилась идея применить что-то похожее на UE4 Blueprint, только с поправкой на то, что нужен просто data-flow. Среди готовых open source решений на JS не оказалось подходящих: критериями были внешний вид и необходимые возможности (например, разные типы сокетов, чтобы ограничить подключение несовместимых выходов и входов). Если первое еще можно было как-то подправить извне, то добавление второго могло бы вызвать проблемы, тем более если структура и исходный код оставляют желать лучшего.
Так и началось написание кода и формировании этого как отдельной библиотеки. Да, да, именно написание кода, без планирования и проектирования, хотя заранее было неизвестно что в итоге это будет из себя представлять (из-за чего не раз приходилось исправлять свои же ошибки).
К счастью, спустя несколько месяцев после начала разработки удалось дойти до полностью работоспособной версии с необходимыми компонентами для обеспечения гибкости при создании редакторов. Но это не значит, что это финал. Скорее, контрольная точка, после которой нужно стремиться к улучшению того, что уже имеется, и внедрению необходимых возможностей.
Как применить в своем проекте
Для начала нужно выяснить, необходимо ли это вам. Конечно, попробовать для себя кое-что новое никогда не помешает (если это не навредит здоровью 🙂 ), но при решении реальных проблем стоит подумать.
Лучше один раз увидеть, чем… в общем посмотрите примеры:
Пример кастомизации в стиле UE4
Рассмотрим основные компоненты, которые нужны для создания минимально работоспособного редактора
Это такие разъемы, которые могут представлять собой входы или выходы и необходимы для соблюдения правильности их подключения между собой. Назначив входам и выходам этот сокет, можно быть уверенными, что пользователь не сможет передать туда не те данные (вернее, он только назначает связи). Также есть возможность совместить сокеты для подключения между входами и выходами разного типа.
Узлы обычно представляют прямоугольниками (но можно это изменить в пределах вашей фантазии и возможностей CSS и HTML). Они могут иметь входы, выходы и контролы. Входы и выходы представляют сокеты и расположены в левой и правой части узла соответственно (опять таки вы можете их расположить как угодно, используя шаблоны).
Контролы нужны для того, чтобы добавлять в узлы произвольные элементы, а из них можно назначать данные к узлу на момент работы в редакторе (не при обработке данных). Например, с помощью простого поля ввода можно положить значение в узел, которое потом использовать при обработке.
Компоненты нужны для того, чтобы редактор знал какие в нем можно добавлять узлы и как их обрабатывать, а именно необходимы для поддержки импорта/экспорта. Используются так называемые билдеры и воркеры, обычные функции с соответствующим ключом, которые задаются при создании компонента (и должны находиться в одном месте).
Билдер отвечает за создание экземпляра узла — в функции вы создаете экземпляр, добавляете к нему нужные входы, выходы и контролы. Создается это именно программным путем, а не через конфиги (обычно такие реализации находил), чтобы позволить повторное использование, к примеру, контролов, а то и наследование узлов.
Воркер в качестве параметров дает вам входы, выходы и объект с данными узла (не экземпляр, который создается в билдере, а то, что из него достали через toJSON). Входной массив содержит данные, которые пришли на вход из другого узла и массив с выходными данными, в который вы должны положить данные, зависимо от того, что должен делать узел)
Один из основных объектов, который управляет всем вышеперечисленным с целью отображения и взаимодействия с пользователем. Ему передаются идентификатор, компоненты, контекстное меню.
Служит для обработки данных в узлах. Особенность в том, что ему нужны только данные, экспортированные из редактора, таким образом можно выполнять обработку узлов вовсе без наличия редактора (например, есть его реализация на С++). Именно этот компонент библиотеки отвечает за обход узлов, определяя с какого нужно начать обработку, вызывает ваши воркеры, передавая в них входные данные, полученные от предыдущих узлов. Может работать с асинхронными функциями, что не может не радовать на фоне поддержки браузерами async/await. Более того, за счет асинхронной обработки может параллельно выполнять несколько узлов.
Заключение
Как видим, визуальное программирование хоть и призвано заменить написание кода, но довольно редко используется в настоящий момент. Наверное потому, что многие скептически относятся к идее программирования мышкой. Это отчасти справедливо, так как большинство задач в разработке ПО привычнее будет решить на каком-либо языке программирования, чем использовать недостаточно проверенный инструмент.
Суть прогресса состоит в том, чтобы находить более выгодные пути в решении каких-либо задач. Так и в случае с визуальным программированием предоставляется возможность описывать процессы в легком для понимания представлении и достаточном уровне абстракции. Но в это же время нельзя избавиться от исходного кода, так как он является основой для всего этого.
Чтобы убедиться в этом и проверить, как говорится, на себе все описанные возможности, вы можете построить на основе D3NE свой редактор визуального программирования.
Тема 8.Основы визуального программирования
Цель
Познакомиться с принципами и основами технологии визуального программирования.
Задачи
Оглавление
Средствами визуального программирования обычно решают задачи построения пользовательского интерфейса и упрощения разработки приложения путем замены метода «написания программы» на метод конструирования.
Концепция визуального программирования реализована во многих современных средах разработки программных систем. Все ведущие фирмы, создающие средства для программирования и конструирования имеют системы, поддерживающие технологию визуального программирования.
Так, например, фирма IBM наиболее полно реализовала концепцию визуального программирования в среде VisualAge Smalltalk.
VisualAge представляет собой объектно-ориентированное средство разработки, включающее набор визуальных интерактивных инструментов, библиотеку готовых компонент и набор средств для построения клиент-серверной среды.
Поддержка графического интерфейса, предоставляемая готовыми компонентами, отвечает CUA (Common User Access) спецификациям и содержит ряд расширений для организации гибкого ввода-вывода в сложных формах и таблицах. Библиотека готовых компонент предоставляет также поддержку устройств мультимедиа, коммуникаций через протоколы APPC, TCP/IP, NetBIOS, программных интерфейсов CICS External Call Interface, EHLLAPI, Message Queue Interface (MQI), работу с реляционными базами данных семейств DB2, Oracle, Sybase и многое другое.
Фирма Microsoft, разрабатывая концепцию.NET Framework, создала Visual Studio.NET Enterprise Architect 2003, в которой реализовала все последние достижения в области программирования и в частности, в технологии визуального программирования.
Фирма Borland Software Corporation является первой компанией, открывшей независимый путь к.NET с Delphi 7, межплатформенной средой быстрой разработки приложений (RAD) для платформы Windows. Характерной чертой Delphi 7 является возможность разработки и развертывания корпоративных приложений. Это позволяет разработчикам создавать корпоративные приложения, от концепции к готовому продукту, еще быстрее с использованием нового UML™-дизайнера и технологии Model Driven Architecture™ (MDA™).
Мы рассмотрели роль и место визуального программирования в области современного программирования. Теперь перейдем к рассмотрению конкретных приемов и методов, относящихся к визуальному программированию. Рассмотрим использование компонентов и приемов визуального программирования в рамках Visual Studio.NET Framework фирмы Microsoft.
Основы визуального программирования
Сегодня принято визуализировать интерфейсы программного обеспечения. Визуализация снимает проблемы «общения» пользователем с программным продуктом. Графические изображения на элементах управления позволяют пользователю интуитивно разбираться в назначении этих элементов.
Возможно, именно наличие визуальных средств построения интерфейсов в таких языках, как Microsoft Visual Basic и Delphi, а также создаваемые с помощью этих языков визуальные программные интерфейсы, закрепили за ними термин «визуальное программирование». Безусловно, существует много других аналогичных продуктов (Visual C++, Borland C++ начиная с версии 4, Symantec Visual Cafe, C++ Builder и др.), но они не смогли завоевать такой популярности, как Visual Basic и Delphi. Именно благодаря Visual Basic, мир узнал о возможности визуального построения интерфейсов программ для Windows.
Визуализируемой моделью в Visual Basic и Delphi является окно (форма, диалог) Windows, а не код программы.
Обычной практикой является визуализация работы с элементами интерфейса, когда в качестве объектов визуализации рассматриваются визуальные компоненты, из которых состоят формы (окна и диалоги) интерфейса программы. Но и операторы программы можно рассматривать как объекты визуализации. В этом случае параметры операторов и функций программы можно настраивать при помощи окна свойств (PropertyBox), а сами операторы и функции хранится в списковой форме (табличной форме).
Рис.8.1. Визуализация разработки кода программы
Рис.8.2. Средства визуального программирования
Другим примером визуализации создания кода программы может служить процесс создания макро программ в Microsoft Excel (рис.8.3).
Рис.8.3. Диалог MS Excel при автоматической записи действий пользователя
Визуализируемой моделью в данном случае является рабочий лист Excel, в котором программист выполняет действия по обработке данных. Программный код пишется автоматически в фоновом режиме, при этом происходит описание в операторах языка VBA (Visual Basic for Application) всех визуальных действий пользователя.
Окно свойств Properties присутствуют, но не в самом рабочем листе, а в среде VBA (рис.8.4). Окно инструментов при выборе объекта Module выключается, но в случае редактирования программного кода для каждого программного объекта появляется раскрывающийся список со свойствами, методами и событиями, т.е. в каждой строке записи макроса в отдельности имеется возможность выбора или смены текущей команды макроса.
Пример получаемой программы, вызов которой в рабочем листе Excel можно организовать по командной кнопке или непосредственно по имени записанного макроса, приведен на рис.8.4.
Рис.8.4. Результат автоматической записи программного кода как протокола действий пользователя
Применение визуального программирования при построении интерфейса приложения в Visual Studio.Net
Рис.8.5. Визуальное программирование средствами Visual Studio.NET
Методы элементов программируются пользователем «вручную», но и тут имеются визуальные помощники: после двойного щелчка по элементу управления в конструкторе автоматически открывается окно редактора кода и автоматически пишется заголовок процедуры обработки события. Боле того, после набора имени объекта автоматически появляется список свойств и методов объекта (рис.8.6). Таким образом, процесс написания программного кода также частично визуализирован.
Рис.8.6. Визуализация свойств и методов объекта
Кроме элементов управления, как правило, в интерфейсе приложения присутствуют и другие стандартные компоненты, реализация которых также поддержана средствами визуального программирования, например, стандартные диалоговые окна.
Рис.8.7. Пример стандартного диалога
Рис.8.8. Программирование стандартных элементов средствами Visual Studio
Концепция.NET Framework и Visual Studio.NET предоставляют в распоряжение программистов огромную библиотеку объектов, ускоряющую процесс разработки приложений. Многие объекты в этой библиотеке имеют визуальное представление и дают возможность назначения свойств объекта в режиме конструирования с помощью окна Properties или диалогов с мастером-построителем.
Выводы
Визуальное программирование предусматривает создание приложений с помощью наглядных средств.
Средства визуального программирования обычно решают задачи построения пользовательского интерфейса и упрощения разработки приложения путем замены метода «написания программы» на метод конструирования.
Визуальное программирование обладает достоинством наглядного представления информации и гораздо лучше соответствует природе человеческого восприятия, чем методы традиционного, текстового программирования. Однако практически все визуальные средства нуждаются в дополнении функциями, которые не могут быть представлены в виде графических конструкций и требуют текстового выражения.
Концепция визуального программирования реализована во многих современных средах разработки программных систем. Все ведущие фирмы, создающие средства для программирования и конструирования имеют системы, поддерживающие технологию визуального программирования.
Visual Scripting: будущее уже наступило?
Эту статью можно рассматривать как обзор-рассуждение на тему визуального программирования. У меня самого больше опыта создания игр на Unity, в Unreal Engine 4 я новичок, поэтому мы будем говорить о самом явлении визуального программирования в целом, а не только о UE.
Немного истории, или коротко о визуальном программировании
Мы не будем слишком глубоко уходить в историю, но знайте: визуальные языки как таковые появились очень давно, задолго до того, как увидел свет визуально прекрасный Unreal Blueprint. Проанализировав концепцию визуального программирования более внимательно, мы увидим, что она базируется на парадигме программирования потока данных (dataflow programming). Этот подход был придуман еще в 70-х годах прошлого века. Он заключается в том, что любую программу можно представить в виде орграфа, который отображает поток данных между компонентами программы (по сути, это та же блок-схема). К сожалению, эта парадигма сейчас находится весьма далеко от трендовых течений, но мы можем вернуться к ней в период расцвета визуального программирования.
Стремление к визуализации алгоритмов у человека зародилось практически одновременно с появлением самого понятия «алгоритм». Оно происходит от естественного желания точнее определить и обозначить свои цели и действия. Кроме того, визуализация помогает лучше постигать задуманную идею и развивать её. Например, иероглифическая запись в пирамиде «Мумифицировать следует вот так…» вполне может считаться визуализацией алгоритма.
Если же говорить о программировании, то первое, что приходит в голову — это блок-схема, самый явный пример визуального программирования. В бытность студентами на первых лабораторных работах вы, возможно, не выполняли задания на компьютере, а чертили и сдавали блок-схемы на бумаге.
За блок-схемами (по крайней мере, в те времена, когда я учился) следовал Pascal, а после него — божественный Delphi. Когда я первый раз увидел Delphi, то был поражен: я мог сделать простую программу, написав 10 строк кода (еще 20 генерировал сам Delphi, но кого это волнует). По сути, Delphi, Visual Basic и другие среды, в которых тогда все активно работали, были первыми массовыми примерами визуального программирования. Да, большую часть кода ты писал сам, но уже можно было прокидывать события, изменять данные и делать интерфейс через удобные UI.
Наверное, процесс визуального программирования был так притягателен, что люди заболевали кнопкофилией… Между прочим, скрин из программы 2008 года, из статьи «Интерфейс, за который нужно убивать»
Современная концепция визуального программирования
Откуда вообще взялось это желание — писать программу без кода? Ну, во-первых, есть мнение, что код — это сложно. Это магия. Это страшные закорючки, в которых без оператора матрицы не разобраться. Но при всем этом программирование — это здорово, престижно и, как правило, приятно с финансовой точки зрения. Отсюда возникает желание быть программистом, которое сталкивается с нежеланием или боязнью писать код (и ленью, куда уж без нее). Поэтому мы всегда ищем инструменты, которые обладают мощным функционалом, но при этом просты в освоении. Этот процесс прослеживается везде: упрощение концепции ПО, упрощение интерфейсов, упрощение веб-сервисов и тому подобное. Кстати, эти же процессы происходят и при эволюции «обычных» языков программирования. Достаточно сравнить COBOL и Python.
Очевидно, вы выберете правую сторону, по крайней мере, она приятна для глаз
Кроме вышеперечисленных причин, визуальное программирование отлично подходит для обучения. На мой взгляд, это одно из лучших его применений. Визуализация позволяет лучше понимать алгоритмы и взаимосвязи классов и функций.
Рассматривая современные средства визуального программирования, необязательно сразу лезть в 2017 год. Есть хороший проект Google Blockly, главная функция которого — образовательная. Небольшой обзор этого языка уже был на Хабре. Blockly очень интересен и отлично подходит для обучения детей программированию, его вполне можно использовать для школьных занятий. Хотя, лично на мой взгляд, «пазловая» система языка не позволяет сразу ощутить все связи вашей программы. Приходится распутывать пазл, как клубок.
Если брать последние десять лет, то можно отметить довольно много попыток реализовать удобную и эффективную систему визуального программирования, хотя взлететь пока что не удалось ни одной. В любом случае, технический прогресс — на стороне визуальных языков. Мощности и технологии сейчас такие, что вы можете без проблем отрисовывать в браузере любые конструкции, используя сглаживание и разные визуальные эффекты.
Производительность среднего компьютера тоже увеличилась: сейчас можно без проблем запускать Unity или Unreal Editor и не бояться, что ваш ПК задымится. Эти изменения привели к появлению нового слова в визуальном программировании — Unreal Blueprint.
Нереальные чертежи
Откуда пошло название
Blueprint – визуальный скриптовый язык, который позволяет написать логику игры без применения языков программирования. По крайней мере, так он себя заявляет. Проект состоит из узлов (nodes), которые соединены линиями передачи данных. Каждый узел может представлять функцию, событие, оператор и так далее.
Примеры узлов в Blueprint
Когда я впервые увидел эту систему, я был в восторге. Это выглядело безумно просто и элегантно. При этом программа читалась так же легко, как блок-схема. Можно было, едва взглянув, понять, что делает алгоритм.
Пример сортировки. Выглядит вполне нормально
С точки зрения визуального программирования, Blueprint – это великолепно проработанная концепция, которая, вероятно, ускорит развитие данной технологии. При этом до него уже существовали системы типа Unity Playmaker, но, на мой взгляд, они далеко не так хорошо реализованы и служат просто небольшой надстройкой над кодом. В данный момент уже начали появляться другие решения с подобной технологией, например, инструмент для создания SQL-запросов — VAX. В статье автор указал, что идея пришла к нему как раз после знакомства с Blueprint.
На мой взгляд, создание игр — это та сфера деятельности, где визуальное программирование можно использовать по-настоящему эффективно. Если мы возьмем простую головоломку или аркаду (подчеркиваю: простую), её можно разбить на элементарные геймплейные блоки, которые разработчик переписывает снова и снова в каждом проекте (ну, или просто копирует). Почему бы не создать библиотеку этих элементарных блоков? Именно с ними вы и работаете в Blueprint. Более того, уже сейчас можно разделить функционал между программистами и геймдизайнерами. Одни будут писать начинку для блоков, а другие — соединять их в готовый функционал.
Будущее еще не наступило.
При всей приятности Blueprint я не нашел крупных проектов, сделанных исключительно на нем. Есть пара продуктов от небольших команд, и они, по большей части, совсем «мелкие». Судя по всему, в данный момент невозможно создать серьезный проект на «чистом» Blueprint, обязательно нужно будет писать код на С++.
Кроме того, возникают проблемы с реально большими блоками нашего чертежа. Писать плохой код можно даже в мощном инструменте визуального программирования, поэтому, если вы не будете продумывать свои алгоритмы, то получите что-то такое…
Это, конечно, преувеличение, но поверьте: в Blueprint можно сделать нечто ужасное, что захочется немедленно сжечь. Кроме того, даже хорошо структурированный проект может занимать очень много места и походить на осьминога, который хочет вас сожрать.
Конечно, весь проект состоит из отдельных классов, но большие алгоритмы все равно выглядят странно и страшно.
Реализация A* одним из пользователей движка. Взято с форума по Unreal Engine.
Как вы видите, не все так просто. Игры все еще нельзя делать одним кликанием мышки, программы нельзя писать без кода, но мы постепенно приближаемся к таким технологиям. Главный вопрос — хорошо это или плохо? Так или иначе, будущее еще не наступило.