Главная Юзердоски Каталог Трекер NSFW Настройки

Gamedev

Ответить в тред Ответить в тред
Check this out!
<<
Назад | Вниз | Каталог | Обновить | Автообновление | 90 50 29
Scratch-тред. Первый в этом десятилетии. Панславянский. Твой. Аноним # OP 26/04/21 Пнд 23:13:58 740172 1
кот.png 70Кб, 400x289
400x289
1619468035770.png 50Кб, 813x656
813x656
1619468035777.png 70Кб, 516x801
516x801
1619468035789.png 34Кб, 467x389
467x389
Scratch - это облачно-ориентированная система создания игор для детей. И в то же время - это принципиально отличающийся от модных блюпринтов способ визуального программирования.
Тем не менее (1), угореть по скретчу можно и под сраку лет.
Тем не менее (2), есть офлайн-клиент, есть возможность конвертнуть проект в HTML5, а затем через ноду.жс конвертнуть в екзе. Что делает скретч совместимым с классическими условиями ТВГ (запускаемые без интернетов файлы). А значит, можно со скретчем на ТВГ вкотиться.

Собсна, сам виновник торжества доступен онлайн без СМС и регистрации https://scratch.mit.edu/ (но регистрация даёт возможность хранить свои поделия в облаке и автоматически расшаривать там же)
Документация https://ru.scratch-wiki.info/wiki/Блок
Конвертер проектов в ХТМЛ5 https://sheeptester.github.io/htmlifier/
Туториал по превращению веб-приложения в отдельное экзэ https://code.tutsplus.com/tutorials/introduction-to-html5-desktop-apps-with-node-webkit--net-36296
Вот примеры, что вообще там можно сваять https://www.youtube.com/watch?v=_fLhibzK5Cw
Аноним 27/04/21 Втр 09:30:37 740193 2
Аноним 27/04/21 Втр 09:50:22 740195 3
>>740172 (OP)
Очень классная штука чтобы детей приучивать к гейм деву, для обычно анона слишком уж примитивно.
Аноним 27/04/21 Втр 12:43:29 740210 4
1619516607492.jpg 203Кб, 1000x998
1000x998
>>740195
> слишком уж примитивно
И ЧСХ, раньше было больше функционала. Но в трёшке многое убрали. Штука примитивная, но для многих это может быть вызовом (могу ли я сделать сложное на примитивном?)
Аноним 27/04/21 Втр 16:18:01 740223 5
>>740210
>могу ли я сделать сложное на примитивном?
я так игру про башню делать начал
Аноним 27/04/21 Втр 16:24:53 740224 6
>>740210
Согласен, к примеру на твг сделать игрульку на этом конструкторе хорошая идея.
Что интересно чекнул форум, вроде куча сообщений, и есть ощущение что всё развивается, что огромный плюс, ведь на твои грабли уже наступили и быстрее решать поступающие баги, и больше времени уделять контенту.
Аноним 27/04/21 Втр 17:55:14 740235 7
1619535313548.png 99Кб, 1785x840
1785x840
>>740223
>>740224
Особенно интригует, что там искаропки редактор векторной графики. Что роднит это всё с флешем и делает ещё быстрее быструю двухнедельную разработку игор.
Аноним 27/04/21 Втр 18:01:42 740236 8
1619535701669.png 18Кб, 480x350
480x350
Бамп Аноним 01/05/21 Суб 20:39:58 740634 9
1619890798628.png 7Кб, 141x128
141x128
В общем, я долгое время хотел создать RPG про котов, ежей, летучих мышей, волшебников, машинки и еду, и сегодня пожалуй не начну этого делать. В этом треде не буду отписываться о результатах. Сразу скажу, что я нихрена не умею, кроме как таскать модификаторы кривых Безье в векторных редакторах, поэтому буду бампать рандомом. В качестве языка для разработки выбрал Скратсч. Посмотрим, что у меня выйдет.
Аноним 02/05/21 Вск 14:07:25 740709 10
>>740172 (OP)
Ну хз, я даже в констракте когда кубики расставляю уже чувствую себя дебилом, а тут уж совсем для детишек программирование какое то. Обучатся наверно круто, но что то серьезное делать, увольте
Аноним 03/05/21 Пнд 18:32:55 740924 11
Аноним 17/05/21 Пнд 05:38:48 743522 12
Пробовал mBlock.Эта хуета помимо самой программы создаёт ещё дохуища фоновых процессов которые низуёво системы нагружают и даже самая простенькая аркадка виснет
Аноним # OP 18/05/21 Втр 12:28:45 743702 13
>>743522
Удивительно, даже у никому не нужного скретча есть клоны.
Аноним 18/05/21 Втр 12:45:26 743707 14
>>740172 (OP)
Ты уж меня извини, но у меня моментально глаза вытекли от такого цветового оформления.
Аноним # OP 18/05/21 Втр 13:01:39 743708 15
1621332096239.png 306Кб, 600x525
600x525
>>743707
Не извиню. Косарь отдай.
Аноним 18/05/21 Втр 13:19:38 743711 16
>>743702
Сейчас, наоборот, тренд на no-code движки.
Аноним # OP 18/05/21 Втр 20:40:06 743757 17
>>743711
Скорей бы уже сделали движок на нейросетях, шоб кнопка ЗДЕЛОТЬ ЗОЕБИСЬ посередине зеленая.
Аноним 05/02/22 Суб 13:14:52 789442 18
Мне кажется скрэтч очень недооценен. Я видел их площадку, там такие охуевшие игры порой делали. Так что крутой тред, мне нравится
Аноним 05/02/22 Суб 13:16:22 789444 19
image.png 279Кб, 640x498
640x498
Аноним 05/02/22 Суб 14:18:10 789461 20
>>789444
Кнопка не зелёная. Низачот.
Скретсщ Аноним 19/09/22 Пнд 19:33:04 831942 21
1663605183133.png 104Кб, 880x782
880x782
1663605183144.png 140Кб, 1032x919
1032x919
1663605183146.png 25Кб, 497x489
497x489
С укоризной, св[...].png 51Кб, 576x566
576x566
Лолбамп!
Аноним 19/09/22 Пнд 23:33:17 831975 22
1663619596790.png 74Кб, 614x653
614x653
Скретч никто не воспринимал всерьёз, и я тоже. И оказывается, его и не надо было воспринимать.

Оказалось, что в Беркли запилили Snap! -продвинутый форк масачусетского скретча с объектами первого класса и метапрограммированием. Кароч, если и делать игоры то в снэпе.
https://snap.berkeley.edu/snap/snap.html
Аноним 19/09/22 Пнд 23:42:00 831977 23
1663620119832.png 43Кб, 595x496
595x496
Комментарии прямо в пикче.
Аноним 20/09/22 Втр 01:20:23 831981 24
Опу 5 лет и он делает первые шаги в программировании?
Аноним 20/09/22 Втр 08:49:31 831991 25
>>740172 (OP)
Скрэтч это база.
Помню, что недолго пользовавшаяся здесь популярностью разработчица и мыслительница под псевдонимом Штумоз тоже восхищалась этим продуктом и требовала у правительства Украины выделить ей гранты на развитие специальной версии Скрэтча для украинских школьников. Но поскольку она пишет на русском и считает США врагом человечества, правительство Украины предпочло финансировать убийства мирных жителей, а не образовательные проекты...
Аноним 20/09/22 Втр 14:12:15 832019 26
>>743702
>никому не нужного
Скретч используют в школах (где-то).

>у скретча есть клоны
Не путай клоны и проекты на одном движке.
https://en.wikipedia.org/wiki/Blockly
>Blockly is used in several notable projects, including:
>MIT's Scratch, visual programming environment for education
https://developers.google.com/blockly
https://github.com/google/blockly

>>831981
>первые шаги в программировании
Чисто по приколу, почему бы не попробовать? Для саморазвития программисту нужно пробовать новые инструменты, даже если они кажутся детскими, лишними или устаревшими. Тем более что в данном конкретном случае это просто, язык-то императивный.
Аноним 20/09/22 Втр 14:24:05 832020 27
fuuuu.png 6Кб, 572x128
572x128
>>831975
Какая же гадость. Фу. Отвратительно. И ведь фактически это та же самая строка императивного кода, только ты не можешь изменить его как строку, ты вынужден мышкой таскать блоки и глазами искать нужные тебе блоки, а не прямо из головы писать что захочешь.

Нет, если хочешь делать программы графически - нужна какая-то другая парадигма. Точно не императивная. Если от императивной парадигмы не избавиться (машинные коды в любом случае императивны), то императивный код нужно писать как текст. А графически перемещать блоки следуя другой парадигме...
Аноним 20/09/22 Втр 19:35:13 832073 28
>>832020
ты какую-то хуитивность развёл, уходи в движкосрач
Аноним 20/09/22 Втр 19:50:37 832083 29
wtf.png 11Кб, 572x128
572x128
>>832073
Тебя серьёзно устраивает такой дизайн? Тут 5 (ПЯТЬ!) уровней вложенности, две пары которых имеют одинаковый цвет, а нарисованы они двухпиксельной (ДВУХ! ПИКСЕЛЬНОЙ!) рамкой с мерзким размытием, ещё больше портящей и без того плохие цвета, смешивая всё в кашу.

А теперь главный вопрос: ЗАЧЕМ нужно было делать эту кислотную гирлянду из 5-уровневой башни прямоугольников, если текст на этой картинке можно напечатать за считанные секунды, если ты уже умеешь печатать хотя бы двумя пальцами не глядя на клавиатуру?

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

Я не говорю, что "визуальное программирование" вообще не нужно, нет, у него есть свои области применения. Также, я думаю, возможно придумать или использовать другую парадигму, в которой визуальность будет иметь куда больше смысла, чем в императивной парадигме (т.е. вместо "if ... then ... else ..." будет что-то другое).

А в данном конкретном случае, я надеюсь, можно пофиксить косяки Скретча изменением стандартной цветовой темы и увеличением полей (margin) блоков (сверху и снизу как минимум). Можно ведь? Можно?..
Аноним 20/09/22 Втр 19:59:15 832086 30
>>832083
На картинке ошибка, я перепутал блоки 4-го уровня с блоками 5-го уровня, т.к. торопился. Но это только наглядно показывает, как легко запутаться в этом представлении кода.

Также я знаю, что цвета в Скретче не обозначают уровень вложенности - цвета обозначают только тип блока. Вот конструкция "if then else" - жёлтенькая, а условное выражение "key = w" - зелёненький шестиугольник. Проблема в том, что это кислотные цвета и они никак не помогают прочитать код и понять его смысл, а только мешают (в таком исполнении).

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

И это я на обычном старом LCD мониторе. На OLED будет в разы хуже, т.к. у OLED выше насыщенность цветов.
Аноним 20/09/22 Втр 21:02:17 832098 31
1663696935772.png 41Кб, 486x456
486x456
1663696935796.png 34Кб, 461x442
461x442
1663696935798.png 28Кб, 468x444
468x444
1663696935800.png 29Кб, 449x441
449x441
>>832020
> Какая же гадость. Фу. Отвратительно.
Это всё рефакторится. Главное - уметь.
>>832019
> Чисто по приколу, почему бы не попробовать?
Именно так.
>>831991
> Скрэтч это база.
А Snap! - это надстройка над базой. Причём неплохая. Теперь это Снэп-тред.
>>832083
> Тебя серьёзно устраивает такой дизайн?
Не устроил. Поэтому я перешёл со скретча на Snap! Смотри скока разных стилей.
> А теперь главный вопрос: ЗАЧЕМ
ПОТОМУ ЧТО ХОЧЕТСЯ. НУ ВОТ ХОЧЕТСЯ И НИЧЕГО С ЭТИМ НЕ ПОДЕЛАЕШЬ.
Аноним 20/09/22 Втр 21:06:35 832099 32
>>832020
> нужна какая-то другая парадигма. Точно не императивная.
> А графически перемещать блоки следуя другой парадигме
В снэпе можно складывать блоки в функциональной парадигме: шапка, хвост, каррирование, все дела. Просто я сам императивщик, в функционалку не умею. Это не минус языка. Это мой минус.
Аноним 21/09/22 Срд 10:30:49 832167 33
>>832099
>функциональной парадигме
Так она не сильно отличается от императивной, если я ничего не путаю. Вот декларативную парадигму было бы круто реализовать визуально, чтобы собирать из кубиков не решение задачи, а описание задачи, которую нужно решить компьютеру. Сравни, например, HTML код и WYSIWYG редакторы веб-страниц: вместо необходимости вручную описывать все теги и их свойства, ты просто мышкой "рисуешь" всё, что хочешь видеть на своём сайте, и компьютер сам находит способ сделать то, что ты хочешь, без необходимости ковыряться в коде. Вот это реально мощный инструмент, в отличие от перемещения мышкой команд императивного/функционального языка. Ты же не будешь говорить, что перемещение мышкой голых HTML тегов и их свойств было бы лучше (быстрее, удобнее, проще для новичков и т.д.) WYSIWYG редактора? Не спорю, иметь возможность править исходный код как он есть важно, но для конкретной задачи (сделать веб-сайт) и конкретных условий (ты нуб и тебе не важна оптимальность кода, важен только результат) WYSIWYG намного лучше ковыряния тегов, пусть даже мышкой с красивыми цветными прямоугольниками вокруг кусочков кода.

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

>>832098
>Поэтому я перешёл со скретча на Snap! Смотри скока разных стилей.
А что, в скретче нет выбора тем? Лол, за столько лет не сделали такую базовую фичу, которая есть в любом текстовом редакторе с подсветкой синтаксиса...

>ПОТОМУ ЧТО ХОЧЕТСЯ.
Да это понятно, как развлечение - хорошо, не спорю, но практической ценности для рядового клавиатурного мага не видно, все прикладные заклинания куда лучше печатать с клавиатуры, чем составлять из кубиков...

>Snap! is a broadly inviting programming language for kids and adults that's also a platform for serious study of computer science.
По официальному сайту не ясно, можно ли компилировать код во что-то серьёзное или это такая же веб-платформа для создания детьми примитивных игрушек и "проведения серьёзных научных исследований" (каких?)...
Аноним 21/09/22 Срд 10:38:47 832169 34
>>832167
> Хм, в общем-то редакторы игровых сцен и являются WYSIWYG редакторами для какого-то внутреннего декларативного языка
Правильно заданный вопрос имеет в себе ответ. Молодец, ты сам догадался до ответа. Не нужно требовать декларативности там, где она не нужна. Декларативность поставляется именно инструментами редактирования объектных иерархий (сцен, окон, страниц, уровней и т.п.)

Я надеюсь с этим вопросом мы разобрались и не будем в дальнейшем жаловаться на слабую декларативность визуальных языков?
Аноним 21/09/22 Срд 10:46:23 832171 35
>>832167
>serious study of computer science.
>проведения серьёзных научных исследований
Блин, перепутал, там говорится "серьёзное ИЗУЧЕНИЕ компьютерных наук (а.к.а. информатика)", т.е. это просто инструмент для обучения программированию.

>можно ли компилировать код во что-то серьёзное
Похоже, что можно:
>codification of Snap! programs to text languages such as Python, JavaScript, C, etc.

>>832169
>не будем в дальнейшем жаловаться на слабую декларативность визуальных языков?
Нет, будем. От идеального визуального языка я бы хотел удобной комбинации высокоуровневых систем и возможности разработки сверху вниз, начиная с пустышек. Типа чтобы можно было бы сказать: "вот есть такая-то штука и вот такая-то, как они работают я пока понятия не имею, но они должны иметь такие-то свойства и так-то друг с другом взаимодействовать". В ООП это возможно, но выглядит не слишком наглядно (куча текста в куче отдельных файлов), хотелось бы видеть визуальную репрезентацию своих классов...

А то пока что всё, что я вижу - это примитивные низкоуровневые конструкции "если А, тогда Б+В", которые разрабатываются снизу вверх и поэтому удобнее пишутся вручную, чем собираются из блоков.
Аноним 21/09/22 Срд 10:49:53 832173 36
>>832167
А ещё, кстати, декларативность в скретче/снэпе обеспечивается С-формой С-блоков, они как бы охватывают группу блоков, содержащуюся внутри, как круги Эйлера вышеупомянутые. И снэп дополнительно подкрашивает цепочки С-блоков двумя оттенками их базового цвета. Всё наглядно, всё видно, что откуда и куда идёт в императивной цепочке задекларированных блоков.
Аноним 21/09/22 Срд 10:53:12 832175 37
>>832171
> я бы хотел удобной комбинации высокоуровневых систем
> возможности разработки сверху вниз, начиная с пустышек
Ну создавай свои блоки, добавляй в них код, затем из своих блоков создавай код более высокого уровня. Всё есть. (В снэпе).
> вот есть такая-то штука и вот такая-то, как они работают я пока понятия не имею, но они должны иметь такие-то свойства и так-то друг с другом взаимодействовать
Именно в таком ключе.
> хотелось бы видеть визуальную репрезентацию своих классов
Ну блоки же.
> А то пока что всё, что я вижу - это примитивные низкоуровневые конструкции
Ты видишь то, что хочешь видеть. Хорошо. Как мне тебе это продемонстрировать на блоках? Давай ТЗ.
Аноним 21/09/22 Срд 11:20:53 832181 38
>>832173
>С-блок
О, кстати, а там можно эти блоки сворачивать, то есть временно скрывать их содержимое? В современных редакторах текстового кода обычно есть возможность свернуть блоки кода в одну линию: редактор временно скрывает часть строк, отображая слева на линейке, какая часть строк скрыта. Это бывает удобно, хотя, если честно, хорошо написанный код скрывать не нужно. Можно даже последовательно скрывать разные вложенные уровни кода, например, если у тебя длинный каскад из if/for/while.

>>832175
>Ну создавай свои блоки, добавляй в них код, затем из своих блоков создавай код более высокого уровня.
Не понял, так можно объединять между собой пустышки или нельзя? В ООП возможен такой подход: описываем свойства и методы класса и сразу же вызываем их из другого класса, но пока класс пустой, он ничего не делает, это "пустышка". В последствии наполняем методы класса кодом и система начинает работать.

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

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

>Ты видишь то, что хочешь видеть.
Я вижу готовый низкоуровневый код.

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

Опять же, сравни с рисованием. Когда ты видишь чужой рисунок, ты понятия не имеешь, как его рисовали. Но некоторые художники записывают и выкладывают процесс рисования, и ты можешь изучить его и понять пайплайн и некоторые базовые трюки. Так и здесь, только вместо частей рисунка - "рисуются" части программы.
Аноним 21/09/22 Срд 11:49:19 832191 39
1663750159210.png 33Кб, 444x305
444x305
ООП, воспроизведённый по мануалу.
Аноним 21/09/22 Срд 14:03:14 832230 40
1663758194268.png 36Кб, 1000x589
1000x589
>>832181
> А вот сверху вниз рисовать легко, но печатать код сложно, потому что в отличие от картины код не лежит перед тобой в общем и целом как на одном холсте, он разбросан то тут, то там. Исправить это можно было бы визуальным программированием, совместив его с классическим текстовым кодом, но я пока не видел годных реализаций и Snap! не выглядит как такая реализация.
Теперь я понял. Годная реализация должна выглядеть так:
1. Код состоит из стыкуемых элементов, стыкующихся в нескольких направлениях (далее блоки), подобно кругам Эйлера.
2. Код начинается в центре и заканчивается по краям готовой фигуры, образованной блоками кода (назовём её - модуль).
3. Свёртка вида: Каждый модуль может быть свёрнут в одну фигуру или развёрнут на отдельный холст, для изменения кода в нём.
4. В развёрнутых модулях входы и выходы для данных находятся в соответствующих блоках, а у свёрнутого модуля входы и выходы на границе его блока-представления.
5. Входы - кружочки. Выходы - точечки.
6. Работа с кодом должна вестись с клавиатуры:
- Таб/шифт+таб - циклически переключаться между входами выбранного блока.
- Пробел: на присоединенной паре вход-выход - переход к следующему (выходному) блоку ( с шифтом переход ко входному блоку); на неприсоединённом блоке - выпадающее меню вставки блока.
Аноним 21/09/22 Срд 15:42:29 832242 41
1663764149201.png 36Кб, 459x470
459x470
1663764149222.png 36Кб, 434x461
434x461
1663764149222.png 13Кб, 745x86
745x86
1663764149224.png 21Кб, 354x318
354x318
>>832181
> запиши видео, как ты составляешь программу из блоков сверху вниз
Видео хлопотно. Вот серия скринов. Я обнаружил, что нет очевидных функций минимума и максимума. Окей, я запилил свои. Создание своего блока - это по сути создание метода.
Command - это императивный метод, то есть команда, то есть вызываемая в потоке команд. подразумевается, что это аналог void-метода, но в параметрах можно указать выходные данные "out" или в терминологии снэпа - upvar.
Reporter - это как бы геттер поля, но у него нет поля, он просто сообщает некое значение, в этом смысле он как бы типизированный метод (в смысле, не void) но он не может по умолчанию встроиться в поток вызова команд. Однако в снэпе есть делегаты (ринги) и репортера можно обделегировать, для этого есть команды run (синхронная) и launch (асинхронная).
Predicate - это по сути репортёр, но для логических значений.

Вполне себе гибкая система, ИМХО. Держим в уме, что система не для полноценного продакшона, а для обучения ньюфагов, и для прокрастинации олдфагов.
Аноним 21/09/22 Срд 16:43:07 832250 42
1663767786880.png 86Кб, 916x697
916x697
Любые блоки под себя напилить можно. Я продолжаю клепать годот-лайк блоки. Что тут у нас? Конструкт/деконструкт вектора2, умножение вектора на скаляр, и аналог годотовского move_and_slide.
Аноним 21/09/22 Срд 17:17:06 832256 43
>>832250
>vec2 0 0
>vec2 0 0
>vec2 0 0
Изобрети уже константу Vector2.ZERO, лол.
Аноним 21/09/22 Срд 19:15:54 832269 44
1663776952599.png 84Кб, 912x657
912x657
1663776952619.png 15Кб, 447x262
447x262
1663776952619.png 19Кб, 451x258
451x258
1663776952619.png 32Кб, 505x439
505x439
Аноним 21/09/22 Срд 21:23:58 832296 45
1663784637194.png 20Кб, 314x212
314x212
1663784637205.png 4Кб, 221x124
221x124
Словари вошли в чат
Аноним 22/09/22 Чтв 03:05:39 832313 46
>>832242
Спасибо за разбор.

>Command
>Reporter
>Predicate
Их роли легко понять по названиям и скриншотам кода, так что можно было не объяснять.

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

>Входы - кружочки. Выходы - точечки.
Неинтуитивно. Было бы лучше обозначать выходы как стрелочку/галочку, направленную наружу фигуры, а входы - как стрелочку/галочку, направленную внутрь фигуры. Ну или нарисовать пупырышки и вмятинки как в Scratch/Snap блоках, а-ля паззлы: пупырышек - выход, вмятинка - вход. Но я бы всё же оставил натягивание ниток как у GraphNode, чтобы сами ноды можно было размещать как угодно.
Аноним 22/09/22 Чтв 15:19:18 832348 47
1663849158383.png 117Кб, 1359x868
1359x868
1663849158397.png 89Кб, 1358x869
1358x869
Итак, пасаны. Я джва дня изучал вопрос и наконец могу на скринах показать, в чём разница.
Итак, откиньтесь на спинку кресла, и представьте, что в годоте вместо вот этих вот граф-нод (пик1) в качестве визуального скрипта скретч-лайк модулярный композит (пик2).

Как тебе такое, Хуан Линецкий?
Аноним 22/09/22 Чтв 16:23:15 832357 48
Один маленький шаг для человека, и огромный - для сообщества.
Аноним 22/09/22 Чтв 21:44:50 832392 49
>>832348
>представьте, что в годоте вместо вот этих вот граф-нод (пик1) в качестве визуального скрипта скретч-лайк модулярный композит (пик2)
Во-первых, принципиальной разницы в коде нет, это всё та же императивщина, которую яждизайнеру не понять, у него мозг на это не натренирован.

Во-вторых, у нод с ниточками куда больше гибкость и потенциал, который, увы, в Годо так и не раскрыт. Нужны ноды более высокого уровня, принимающие на вход сущности высокого уровня, а не вещественные числа и даже не векторы. Если я не ошибаюсь, в этом суть блупринтов УЕ и процедурных нод Блендера.

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

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

Яждизайнер же не справится с твоим кодом, каким бы внешним видом он ни был бы представлен. Он понятия не имеет о векторах, вещественных числах и всём таком нашем кодомартышечном. Он знает только, что нажатие клавиш должно перемещать фигурку по экрану и ему нужно описать это каким-то образом, не вдаваясь в детали реализации. Ни ноды Годо, ни блоки Скретча не позволяют ему этого сделать, заставляя учить коды и матан.
Аноним 22/09/22 Чтв 22:48:59 832404 50
>>832392
> Если я не ошибаюсь, в этом суть блупринтов УЕ
Ошибаешься. Завтра то же самое в блупринтах выложу.
> и процедурных нод Блендера
Тоже ошибаешься. Блендер открой. Всё на тамошних нодах так же: входы, выходы, типы данных.
> Суть скретча в том, чтобы детям не приходилось бороться с синтаксическими ошибками в коде
Нам нужны новые годотеры. Отлично!
> Код в стиле скретча не решает проблему яждизайнера, которому не хочется разбираться в кодинге, но хочется, например, заставить персонажа двигаться.
Посочувствуем нашему вымышленному яждизайнеру. И не перезвоним ему.
Аноним 22/09/22 Чтв 22:50:58 832406 51
>>832404
> Ошибаешься. Завтра то же самое в блупринтах выложу.
А пока что просто скажу. УЕ парадоксальным образом ещё больше программистских правил нарушает, там куча синглтонов, синглтонов, блять, за которые с собеса на галеру выгоняют! На каждый чих - синглтон.
Аноним 22/09/22 Чтв 22:55:02 832408 52
1663876502652.png 438Кб, 1118x657
1118x657
>>832392
> ноды более высокого уровня, принимающие на вход сущности высокого уровня, а не вещественные числа и даже не векторы
Высокий уровень пиздабольства на входе.
Аноним 23/09/22 Птн 02:31:45 832440 53
>>832404
>Нам нужны новые годотеры. Отлично!
Ты имеешь в виду пятилетних детей? Потому что визуальные скрипты из Годо убрали по той простой причине, что новичкам, которые попробовали GDScript, уже не нужны были никакие визуальные языки. А пятилетние дети пусть продолжают сидеть на скретче, Годо им не нужен и Годо они не нужны, пока не подрастут. Годо за лёгкость освоения новичками, но не для совсем маленьких детей. Совсем маленькие пусть вон, в Роблокс свой играют.

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

>>832408
Я УЕ никогда не ставил, но по скриншотам видел там какие-то высокоуровневые ноды. Алсо лапшиз что-то здесь упоминал про них. Не спорю, что и там можно векторы пересобирать, но зачем? Это как микроскопом гвозди забивать. Лучше создать высокоуровневые сущности и менять отношения между ними кликами мыши.

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

Вот в Blender Game Engine было какое-то отдельное окошко (Game Logic?) со связями ниточками: "событие - условие - действие", и это самостоятельный от скриптов на питоне инструмент, а не попытка изобразить питоновые скрипты в виде лапши. Почему-то в Годо его нет, хотя логично было бы иметь, вместо этого пытались полностью заменить скрипты визуальной лапшой и закономерно провалились...
Аноним 23/09/22 Птн 06:53:33 832450 54
Мини-игра на UP[...].mp4 567Кб, 880x600, 00:01:06
880x600
>>832440
>Blender Game Engine
>событие - условие - действие
Таки да, я был прав, до сих пор есть.

>>832348
>Как тебе такое, Хуан Линецкий?
Сделал играбельную мини-игру на UPBGE вообще без программирования, даже "визуального". И таким способом можно реализовать множество игровых механик, а для остального есть полноценный Python: программист, если нужно, пишет сложные системы/модули на Python, а геймдизайнер настраивает логику и вводит циферки в понятные даже гуманитарию менюшки.

Как тебе такое, Блочный Код Скретчевич?

И таки возвращаясь к Годо, потому что ты сам затронул эту тему здесь: Годо заставляет прописывать всю базовую логику кодом на GDScript, но зачем? Что дадут эти бесконечные бездумно копипастные if event.is_action_pressed("bla_bla_bla"): just_do_that_damn_thing_already(you_stupid_bastard) или ещё хуже, каскады из if colider... а-а-а, блин, я даже не могу навскидку сказать, какой там код для проверки столкновений, хотя я минимум джва года ковыряюсь в Годо, пытаясь сделать игру. То есть да, там много способов проверить столкновения, но просто взять и проверить нельзя, нужно сделать кучу действий в редакторе и потом ещё обязательно написать несколько строк по сути бойлерплейт кода. Не говоря уж о том, что соединения между событиями (сигналами) и обработчиками не визуальные, они "где-то там" - либо в инспекторе ноды, либо в самом коде (на практике - где угодно, то есть вообще где угодно, ищи давай, вилкой ищи, вот тебе 9000 файлов с отборным кодом, ищи давай connect-ы).

Короче говоря, BGE и его Logic Bricks незаслуженно забыты, хотя конкретная реализация менюшек не такая уж удобная, если честно. Интересно, можно ли реализовать аналог в Godot, особенно после выпиливания визуальных скриптов? Через тул скрипты можно сделать менюшку, но может ли аддон в рантайме реализовать то поведение, которое юзер нащёлкал в этой кастомной менюшке? Чтобы всю тривиальную логику (обработчики клавиш, столкновений, таймеров и т.п.) совсем без кода делать. А если ещё и обработчики сигналов визуально ниточками связывать на некой глобальной карте проекта (процедурной, Код Блочный, процедурной карте проекта!), вообще кайф был бы, я бы ловил оргазм от созерцания архитектуры своего проекта (после того, как проблевался бы с неё и отрефакторил, ведь я сейчас даже не знаю её толком - проекты мои умом не понять, в байтах не измерить)...

Как же хочется аддончик написать, ну почему я такой прокрастинатор, разве я многого хочу...
Аноним 23/09/22 Птн 13:17:33 832490 55
>>832440
> Вот как в Годо такие сущности создавать я не понял.
Я понял, но это неважно, потому что визуальный скрипт будет удалён, ставить его аддоном никто не будет, он мертворожден.
> То есть да, я могу создать свою ноду для дерева сцены, у которой будут поля для кастомных ресурсов и куча параметров. Но это не имеет отношения к визуальному языку.
Имеет. Всё тоже самое ты можешь сделать и там. Ну, как сказать? Нет ,не всё. Если бы над модулем работали, то мог бы всё, а на данный момент можешь базовые типы экспортами подключить. И всё это коряво и неочевидно организовано, что я сам наверное единственный, кто случайно нашёл этот функционал.
> Визуальные скрипты живут в каком-то своём мирке, не связанном с деревом сцены и нормальными скриптами.
Неверно. Они в том же мирке живут и прекрасно взаимодействуют со всеми остальными компонентами.> Как я их использовать вообще должен
Возвращаемся к п.1. Если бы их не дропнули, я бы ответил read the docs, однако теперь да, ответ - никак.
Аноним 23/09/22 Птн 13:25:30 832491 56
>>832450
> хотя конкретная реализация менюшек не такая уж удобная, если честно
Кстати да. Юзабилити очень важна. Даже если на блоках кодить, не таская их мышкой, а например, переключаясь стрелками между блоками в цепочке и нажимая хоткеи для вставки блоков (press F to add Respect block) - то уже будет ощущение удобства.
> эти бесконечные бездумно копипастные if event.is_action_pressed("bla_bla_bla"): just_do_that_damn_thing_already(you_stupid_bastard) или ещё хуже, каскады из if colider...
Рано или поздно на любом уровне абстракции ты упрёшься, переходя от абстракций к реализации, с голым машинным нутром, которое сугубо императивно. И тебе придется именно длинными цепочками ифов проверять все свои нажатые клавиши.

Либо один раз сделать общую функцию, в которой это всё делается мерзким копипастом и спрятано от твоих высокоуровневых абстракций
Аноним 23/09/22 Птн 13:59:19 832494 57
>>832491
>И тебе придется именно длинными цепочками ифов проверять все свои нажатые клавиши.
Ты видео не смотрел, верно? Где там "длинные цепочки ифов"? Где там хотя бы строчка кода? Там только логические связи "если W - двигай вперёд". Вот почему нельзя везде так делать? Это же удобно.

>переключаясь стрелками между блоками в цепочке и нажимая хоткеи для вставки блоков - то уже будет ощущение удобства.
Ага, а если вместо стрелочек набирать названия блоков и нажимать enter, то будет уже не просто ощущение удобства, а самое настоящее удобство. Ой, только это будет уже обычный текстовый редактор с автодополнением, вот ведь какое неожиданное совпадение.
Аноним 23/09/22 Птн 14:18:01 832498 58
1663931881677.png 118Кб, 1000x721
1000x721
>>832494
> Где там "длинные цепочки ифов"?
Под капотом твоей связки "если W - двигай вперёд". Об этом речь.
> просто ощущение удобства, а самое настоящее удобство
Вкусовщина.
Аноним 23/09/22 Птн 14:19:05 832499 59
>>832498
Блять, макаба, что ты творишь!?
Извините, это пикча из ньюсача.
Аноним 23/09/22 Птн 15:21:48 832504 60
>>832499
>>832498
Да у тебя не только пикча из ньюсача...

>Под капотом твоей связки "если W - двигай вперёд". Об этом речь.
facepalm.jpg
Мы, кажется, обсуждали, с помощью какого инструмента лучше делать игры для непрограммиста? В чём смысл твоего "под капотом всё равно код", если с точки зрения пользователя он код не пишет?

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

А в БГЕ ты именно логику навешиваешь, а не код.
Аноним 23/09/22 Птн 16:47:51 832516 61
>>832504
> Вот БГЕ- это написание кода мышкой. Да, код обёрнут в серые коробочки с линиями, но это код, портянка из инструкций воображаемому дурачку.
> А в скретч ты именно логику навешиваешь, а не код.
Сможешь обеснить разницу? Я - не вижу.
Аноним 23/09/22 Птн 16:49:45 832517 62
>>832516
Покуда меня не зачислили в тролли, всё же разверну свою мысль: ящитаю, что любая визуальная не-код-система - это всё равно код.
Основной смысл не-код-системы - быть понятной дурачку. Однако это не помешает поработать в ней "умнячку".
Аноним 23/09/22 Птн 18:10:49 832529 63
>>832516
>Сможешь обеснить разницу?
Вот здесь у тебя >>832348 не просто кучка блоков, а композиция по определённым правилам, которые понять можно только уже зная принципы программирования. Вот у тебя вызов функции, в него вставляются не просто какие-то числа, а целые конструкции, которые ещё нужно найти на палитре блоков, выбрать и заполнить, да не абы как, а всё по правилам. Такой инструмент предоставляет неограниченные возможности, т.к. является полноценным языком программирования, но чтобы им научиться пользоваться, нужно научиться программировать, чего новички и яждизайнеры активно пытаются избежать. Поэтому скретч хорош для обучения детей программированию, но плох в качестве замены программированию.

Здесь >>832450 я показал, что можно собрать целую игру совсем без программирования, только натягивая ниточки слева направо, выбрав сначала "сенсор" и "актуатор". С этим справится любой, даже не зная основ программирования, достаточно объяснить ему суть. Да, впрочем, и объяснять ничего не надо - из названий ясно, что сенсор реагирует на какие-то события, а актуатор совершает какое-то действие. Что мы хотим сделать? Сдвинуть кубик по оси Y в ответ на нажатие кнопки W. Выбираем сенсор "клавиатура" и актуатор "движение", в первом вводим букву W, а во втором вводим любое число в поле с буквой Y. Соединяем сенсор с актуатором ниточкой и готово - теперь кубик двигается куда мы сказали по нажатию указанной кнопки. Продолжаем путём повторения этих очевидных действий, постепенно изучая методом тыка свойства разных сенсоров и актуаторов. Даже логические блоки, "контроллеры" понять совсем не сложно, контроллер И ждёт срабатывания всех подключённых сенсоров (сенсор А и сенсор Б), контроллер ИЛИ ждёт срабатывания любого из сенсоров (сенсор А или сенсор Б), и т.д. Разве что про XOR придётся погуглить, т.к. это искусственное слово. Так вот в этом всём нет никакого кодерства, ты не пишешь код - ты просто создаёшь связи между двумя/тремя классами сущностей. Да, эта система имеет ограничения и будет неудобна для сложной логики, но она не ставит своей целью заменить программирование целиком и не ставит целью обучать программированию. Её цель - упростить описание логики для тех, кто не хочет разбираться в программировании.

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

А в случае с логикой БГЕ нет никакого языка. Ты не составляешь выражения из кубиков, ты только создаёшь простые подключения между некими приборчиками. Вот если вставить провод в одну розетку, загорится красная лампочка, а если в другую - зелёная, ну и где тут язык? Ты не выражаешь свою мысль на каком-то языке собеседнику (компьютеру), ты только настраиваешь умные приборчики, чтобы они работали так, как ты хочешь. Если у тебя под рукой не окажется нужного приборчика - тебе придётся идти к папе-программисту с просьбой создать приборчик, потому что сам ты его никак не создашь. А папа-программист придёт и объяснит глупому компьютеру на его странном и непонятном тебе языке, как должен работать недостающий приборчик, компьютер подмигнёт и у тебя появится новый приборчик для создания связей с уже имеющимися.

Сразу предупреждаю, речь не идёт о создании связей между нодами визуальных языков в Godot/UE/Blender. Легко обмануться из-за внешнего подобия. Визуальные языки - это именно языки, ты создаёшь на них языковые конструкции, с помощью которых выражаешь свои мысли компьютеру. Ты можешь строить длинные многословные выражения, а можешь рубить короткие фразы, но это всё твоя речь на языке. В описанном выше случае нет никакой речи, есть только ограниченные подключения между фиксированными системами. На визуальном языке можно реализовать подобное (создав множество высокоуровневых конструкций и площадку для их подключения между собой), но не наоборот.

>не помешает поработать в ней "умнячку"
А это ничего не значит. Взрослый может выкладывать длинные осмысленные тексты детскими кубиками - это язык. Но если взрослый будет соединять между собой лампочки и розетки, он не сможет связать и двух слов, потому что в лампочках и розетках нет языка, они не выражают никаких слов, из них не создать осмысленных языковых конструкций. Т.е. от ума пользователя суть инструмента не меняется.
Аноним 23/09/22 Птн 18:44:05 832532 64
Попробую продемонстрировать наглядно.

Если ты почувствовал нажатие кнопки W, тогда возьми из свойств кубика его текущее смещение, извлеки из него Y-компоненту, прибавь к ней число 0.05, затем верни полученное значение обратно в Y-компоненту смещения, а само смещение верни в свойства кубика, чтобы он обновил своё положение на экране на новое.

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

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

А теперь сравним с этим:
[кнопка] W => [движение.y] 0.05
Что это? Может показаться, что это тоже какой-то язык (потому что я записал это буквами языка), но нужно заметить, что это единственная возможная фраза, её нельзя построить как-то иначе, нельзя вставить внутрь неё что-то ещё и ничего из неё изъять. Это просто натянутый провод между устройством "кнопка" и устройством "движение.y", у которых выставлены ручки в положение "W" и "0.05" соответственно. Как бы ты ни дёргал за провод и как бы ни крутил ручки, ничего другого ты не сделаешь. Ты не составляешь выражения, не пишешь текст, даже не выкладываешь кубики - ты просто настроил два прибора, между которыми есть соединение одним проводом. Всё. С этим даже обезьяна справится, если сможет удержать в своих лапах провод и попасть в отверстие разъёма, а значения на ручках можно и по умолчанию оставить вообще. А вот если посадить ту же обезьяну за печатную машинку или даже выдать ей в лапы кубики с буквами - осмысленного она ничего не напечатает, ведь в её мозгах нет языка с его правилами. Мы можем попытаться обучить обезьяну правилам языка и она даже что-то запомнит, но зачем нам это делать, если для решения бытовых задач обезьяны достаточно двух приборов и одного провода? Справится и без обучения языку...
Аноним 23/09/22 Птн 19:07:56 832534 65
Аноним 24/09/22 Суб 20:38:57 832617 66
1631907609936.png 4Кб, 649x85
649x85
>>832532
Понятно, какую мысль ты пытался донести, но с формальной точки зрения все может быть не так.
Может оказаться, что язык А можно писать только такими конструкциями (тогда возьми из свойств кубика его текущее состояние), а все остальные попытки будут заканчиваться синтаксической ошибкой компиляции.
С другой стороны, обилие спецсимволов в языке B не гарантирует, что их нельзя сочетать ебанутым образом, как в каком нибудь J, а это вполне реальный у ученых, не эзотерический/шуточный язык.
Аноним 26/09/22 Пнд 21:01:46 832810 67
>>832617
>язык А можно писать только такими конструкциями
>не гарантирует, что их нельзя сочетать ебанутым образом
При чём тут это? Речь шла о том, что является языком, а что - нет.

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

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

Но я тут подумал ещё, и всё не так просто, как кажется. Есть такая тема - полнота по Тьюрингу. Если система полна по Тьюрингу - она может выполнить любую задачу, которую способен выполнить компьютер. Так вот полнота по Тьюрингу обнаруживается в самых необычных местах - даже игра "Жизнь" с её примитивными правилами является полной по Тьюрингу, т.е. в ней возможно собрать эмулятор компьютера, записать в него программу и получить результат (и вроде бы даже уже делали простые компьютеры в игре "Жизнь"). Вполне возможно, что "logic bricks" в BGE тоже полны по Тьюрингу (без использования скриптов на Питоне) и из них можно собрать любую программу, включая эмулятор компьютера. Тогда утверждение, что logic bricks не являются языком программирования, будет звучать довольно странно...

С другой стороны, мы же говорим о языках. Вот HTML является языком программирования (декларативным), хотя не обладает полнотой по Тьюрингу. Многие другие языки программирования тоже не обладают полной по Тьюрингу, т.к. не нуждаются в ней для решения задач, ради которых они были созданы. В то же время игру "Жизнь" нельзя назвать языком программирования, хотя она и решает любые задачи, точно так же, как нельзя назвать языком программирования горсть транзисторов или красную пыль в Minecraft (тоже полна по Тьюрингу). Т.е. нужно смотреть в определение "языка" и ориентироваться на него, а не на выполнимость задачи каким-то инструментом. Даже если logic bricks позволяют решить любую задачу, это не язык программирования, даже не визуальный язык.
Аноним 26/09/22 Пнд 21:11:00 832811 68
>>832810
Ну так оба примера являются языком.
>[кнопка] W => [движение.y] 0.05
>Что это? Может показаться, что это тоже какой-то язык (потому что я записал это буквами языка), но нужно заметить, что это единственная возможная фраза
Это язык, в котором возможна единственная фраза. А еще бывает алфавит, состоящий из одной буквы.
Аноним 27/09/22 Втр 00:39:43 832836 69
>>832811
>Это язык, в котором возможна единственная фраза
Абсурд. Лень аргументировать...

>алфавит, состоящий из одной буквы
Ты про азбуку Морзе? Это просто форма записи обычной латиницы или кириллицы точками и тире. Наш текст здесь на форуме тоже хранится как нули и единицы, но читаем мы буквы алфавита из 33 букв, а не из двух.
Аноним 27/09/22 Втр 01:07:26 832841 70
>>832836
>Абсурд
Наука. Тоже лень аргументировать. Читай https://ru.wikipedia.org/wiki/Формальная_грамматика
В принципе это несильно отличается от комбинаторики и множеств. Множество может быть пустым, с одним элементом, со счетным кол-вом элементов, с бесконечным кол-вом. Так что ничто не мешает существовать языку с одной-единственной допустимой фразой.
>Ты про...
Нет, я про алфавит из одной буквы {A}. Из него можно составлять слова А, АА, ААА...
Также могут быть алфавиты, где составляющими элементами будут слова. Например, Ту, Ту Ты, Ты Ту Ты и т.д.
Я обнаружил в Scratch фатальный недостаток Аноним 28/09/22 Срд 12:43:57 832947 71
Он сделан не мной.

Поэтому я сделаю свой графический язык. Вот какие вводные я разработал на данный момент:
1. Блоки монохромны. Любые цвета расцениваются как синтаксический сахар. Блочная программа должна без потери смысла распечатываться на монохромном принтере или вывестись на монохромном дисплее.
2. Главный атрибут блока которым он отличается от других - его форма. На форму в моей концепции завязано всё.
3. Поток выполнения прописывается сверху вниз.
4. Поток вычисления выражений прописывается слева направо.
5. За поток выполнения отвечают блоки команд: Заголовки, концевики (терминаторы), возвраты (репортеры в терминологии скретча), сегменты (С-блоки в треминологии скретча).
6. За поток вычисления отвечают блоки выражений: типы, операторы.
7. Блоки типов символизируют в первую очередь типы данных. Фундаментальные (bool, byte, char, int, real (single, double, decimal). Производные, например string является производным от char и олицетворяет массив символов. Составные: object - первый и главный составной тип, олицетворяющий ООП и являющийся предком любых объектов. Его форма - прямоугольник (box) и своей формой он олицетворяет очевидно боксинг, возможность упаковать в object любой другой тип данных.
Аноним 28/09/22 Срд 13:15:26 832951 72
>>832947

7.2. Во вторую очередь блоки типов это функции, возвращающие значение.
8. У каждого блока в середине есть как минимум одно гнездо для вставки либо текста, либо другого блока. Гнёзда символизируют значение для фундаментальных типов, либо параметры инициализации для составных типов. Вместо блоков-сеттеров скретча, я объединяю концепцию сеттера с этими гнёздами внутри. В скретче нужно поставить специальный блок-сеттер, выбрать в выпадающем списке требуемое имя переменной, и затем в гнездо вставить устанавливаемое значение. У меня же будет так: создаваемый на холсте блок типа это уже геттер с сеттером внутри себя. Внутри блока мы вписываем (или вставляем блок-)-значение. Сам же блок снаружи себя возвращает хранящееся в нём значение. концепция переменных здесь тоже применима (и есть), но об этом ниже.
Аноним 28/09/22 Срд 13:36:58 832952 73
1664361418537.png 49Кб, 1006x369
1006x369
1664361418548.png 41Кб, 723x322
723x322
>>832951
9. Блоки стыкуются с операторами справа налево, как сказано в п. 4. Соответственно, у блоков и операторов есть важное графическое качество, которыми они отличаются между типами, но схожи между блоком типа и блоком оператора. У блоков типа уникальная для их типа форма, имеющая вертикальную симметрию. У блоков бинарных операторов вертикальная но инверсная симметрия так, что справа и слева стыкуются без зазоров два однотипных блока. У операторов унарных соответственно симметрия нарушена так, что с одной стороны форма для стыковки с блоком, а с другой стороны форма для стыковки либо со следующим оператором, либо с гнездом во внешнем блоке. Это лучше показать на примере. На пикрелейтеде 1 показано выражение ( 2 + 3 ) * 5 возвращаемое значение типа int. На втором пике изображена ложь, тип bool.

И кстати!
10. Но лучше этот пункт повыше закинуть в концепте: Форма фундаментальных блоков исключительно из прямых линий, без кривых. Для лучшей начертаемости от руки. Производные блоки программист может уже нарисовать какие хочет, но для хорошего стиля кодинга рекомендуется тоже рисовать формы из прямых отрезков.
Аноним 28/09/22 Срд 14:36:55 832955 74
1664365014646.png 89Кб, 883x778
883x778
1664365014665.png 26Кб, 555x295
555x295
1664365014665.png 41Кб, 996x346
996x346
>>832952
11. Тернарных операторов в моей концепции нет. Взамен них существует другой механизм. Каждый типовой блок можно объявить как функцию. Блоку выдаётся свой холст, на котором можно задать точку входа, аргументы, и возвращаемый результат. Этот механизм позволит описывать как функции не только тернарные операторы, но вообще, фундаментальные языковые конструкции, типа циклов можно будет описать как сегментом (C-блоком) так и функцией.
Например, на пикче 1 в псевдоскретче некий сегмент, из трёх блоков, первый задаёт список (массив) int, второй задаёт цикл, который этот массив с помощью третьего блока заполняет значениями от 0 до 9. Этот же псевдокод можно изобразить блоком на пикче 2. Тут показан блок с двумя гнёздами-входами и названием. Это функция, которая делает то же самое, создаёт массив с заданными границами и возвращает его.
Аналогично, функцией мы можем описать тернарную операцию, пик 3. Блок возвращает int, о чём говорит его форма, имеет три входа, bool и два int на правду и ложь соответственно.
Аналогично можно описать любую требующуюся конструкцию.
Аноним 28/09/22 Срд 14:59:59 832956 75
>>832955
12. Как сказано в п. 8, у блоков есть только гнёзда для вставки. Нет гнёзд так сказать "выпуклых", как в скретче. Соответственно, возникает вопрос, как на предыдущей пикче блок add знает что есть x и что есть i? Ответ в том, что у холста, на котором мы рисуем блоки, будет легенда. В ней мы перечисляем используемые на холсте переменные. Когда будет написан редактор, составление легенды будет автоматизированным. Ты бросаешь на холст блок if, и в легенде генерируется переменная i в формате:
> модификатор_доступа тип имя_блока.имя_переменной [= значение_по_умолчанию]
Поскольку у нас на дворе 21 век, в моей концепции я отталкиваюсь от ООП-парадигмы, а хначит холст - это неймспейс или фрагмент неймспейса, и холст содержит классы. Каждый блок-начало на холсте - это описатель создаваемого в неймспейсе класса, поэтому переменные в легенде принадлежат конкретным классам. И опять же, не переменные это, а члены класса. Но для простоты, по заветам инфоцыган я обесняю "для новичков", хех. Допустим, наш вышенарисованный for расположен в методе CreateList класса MyClass, тогда переменные x, i из пикчи сверху будут созданы в легенде следующим образом:
> private list<int> MyClass.CreateList.x
> local MyClass.CreateList.for1.i = 0
Переменная x как видим объявлена приватной в области видимости класса, а вот переменная i объявлена локальной в области видимости блока for которому автоматически выдано имя for1, имена блоков можно менять для читаемости программы, но следует помнить, что это не имена переменных и язык не будет иметь инструментов чтобы ссылаться на эти имена. А может быть будет. Как пойдёт.
Аноним 28/09/22 Срд 15:02:02 832957 76
>>832956
> Ты бросаешь на холст блок for
Ну это прямо надо пофиксить. Сорян, аноны, хуярю текст на энтузиазме, вычитываю диагонально. За ашыпки извените.
Аноним 28/09/22 Срд 16:01:10 832960 77
>>832957
Не переживай, всё равно никто это не читает.
Аноним 28/09/22 Срд 16:58:09 832964 78
Аноним 28/09/22 Срд 17:20:48 832966 79
1664374848767.png 84Кб, 1102x626
1102x626
>>832956
На данный момент я пытаюсь вывести различимые и достаточно простые в рисовании блоки типов. Формы должны хотя бы немного отражать суть типа. Хотя, конечно, отталкиваюсь всё равно от скретча. Bool - шестиугольник, или иначе говоря блок с двумя треугольными краями и прямоугольной серединой.
Числовые типы отталкиваются от скретчевого кружочка, но поскольку кружочки запрещены в моём концепте, то целочисленный тип, int - это блок с одним плоским зубцом, далее real, single - в зубце одна дырка, double - в зубце две дырки, decimal - внутри острый зубец, образующий символ сигмы, а если смотреть сбоку, то напоминает букву М - money.

И тут очень органично решился вопрос с приведением типов. На пикче 1 мы берём целое 10 и прибавляем дробное 0.5 с одиночной точностью, используем оператор + целого типа, что неверно, и действительно, мы видим, что в состыковке образовался зазор, значит, что-то мы делаем неправильно. При сложении int и single результатом будет single, значит нам нужно взять сингловый +, но там зазоры будут ещё толще при попытке впихнуть в него int.

Что делать в таком случае? Решение очевидно. Операторы можно и нужно динамически подстраивать под входные типы и каждая получившаяся форма будет символизировать приведение типов. На входе int и single? чтож, мы приводим int к single и возвращаем single. Как показано на пикче 2.

Ну и конечно же, любое выражение можно свернуть в блок, как на пикче здесь >>832952 или вынести на отдельный холст в виде функции, что улучшит читаемость.
Аноним 28/09/22 Срд 21:05:10 832975 80
1664388310417.png 52Кб, 416x479
416x479
>>832966
Пока что вырисовывается что-то типа такого:
Аноним 28/09/22 Срд 21:07:23 832976 81
>>832975
Чота с такими амбициями пора из гд в пр перекатываться.
Аноним 28/09/22 Срд 21:57:02 832979 82
1523776160476.png 805Кб, 631x637
631x637
>>832966
Предлагаю называть ТИКЕТ
Аноним 28/09/22 Срд 22:02:19 832980 83
>>832979
Хаха! Почему бы и нет.
Аноним 29/09/22 Чтв 16:02:08 833000 84
>>832841
>Так что ничто не мешает существовать языку с одной-единственной допустимой фразой.
Допустим, ты прав. Тогда почему распространено мнение, что животные не обладают способностями к речи? Даже обучение обезьян языку жестов было поставлено под сомнение, хотя обученные обезьяны умели правильно использовать до сотни слов и даже объединять слова в простые осмысленные выражения. У многих животных есть сигнальная система, в которой есть множество сигналов, несущих вполне конкретный смысл, животные могут передавать информацию этими сигналами. Даже у растений, у которых нет нервной системы (но есть гормоны, рецепторы, актуаторы, передача сигналов), есть способы общения между отдельными индивидуумами как одного вида, так и разных, и даже способы взаимодействия с насекомыми-опылителями. По твоим словам, это всё - языки, и почти всё живое владеет каким-либо своим языком, принятым у конкретного вида или в конкретной популяции. Почему тогда мы не воспринимаем это как языки и даже подвергаем сомнению обучаемость обезьян языку жестов?
Аноним 29/09/22 Чтв 16:32:41 833002 85
>>833000
> почему
> животные не обладают способностями к речи?
У них нет отвечающей за речь нейросети в мозгу.
Можете скринить, вангую, когда учёные наконец изобретут нейроинтерфейсы, они смогут присоединить к обезьянам внешний речевой центр, скопированный у человека - и обезьяны заговорят.
Аноним 29/09/22 Чтв 19:21:15 833014 86
>>833002
>отвечающей за речь нейросети
>присоединить к обезьянам внешний речевой центр, скопированный у человека
Надеюсь, ты так шутишь.

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

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

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

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

>учёные наконец изобретут нейроинтерфейсы
Нейроинтерфейсы давно существуют. Втыкаешь электроды в мозг и обучаешь человека ими пользоваться, чтобы нейроны перестроились (на это уйдут месяцы). Если воткнёшь достаточно прицельно, то обучаться придётся меньше. А если нужно управлять дистанционно (сделать биодрон), то задача проще, если сможешь воткнуть электрод в подходящую структуру - организм будет воспринимать импульсы с электрода как собственные желания и выполнять их. Только вот никаких универсальных интерфейсов вроде USB не будет, архитектура не та - нужно обучение, никакого тебе plug and play в мозге не предусмотрено. Т.е. разъём на башке сделать можно, но обучаться придётся для каждого девайса независимо, а это минус несколько месяцев жизни. Так что в случае обезьян единственный рациональный способ - протянуть их собственные нервы к коре, авось сама как-нибудь обучится управлять. А все эти сказки про импланты в мозг, не требующие адаптации (вставил и сразу пользуешься), возможны только с каким-то искусственным мозгом, специально разработанным для поддержки plug and play устройств. Биологический мозг, если тебе так понятнее, захардкожен под конкретную задачу.

Но это всё не относится к нашей теме - можно ли считать языком систему, которая допускает всего одно действие? Может, с формальной точки зрения и можно, но с бытовой это не может считаться языком. Иначе нажатие кнопки на выключателе света - это тоже язык с единственной возможной фразой "измени своё состояние на противоположное", так что ли? Тогда все люди поголовно являются программистами, а ещё и куча животных (да и растение может нажать на выключатель, только очень медленно). Давай не доводить до абсурда, а то так можно бесконечно спорить.
Аноним 29/09/22 Чтв 22:20:03 833020 87
1664479203847.png 79Кб, 672x607
672x607
А я тут осознал, что Snap! имеет фишки функциональных языков. Балуясь со снэпом я наконец начал понемногу понимать суть ФП. Так глядишь и лисп освою!
То что раньше делал циклами начинаю уметь делать на маппинге списков. Так же в снэпе искаропки имеются блоки для отрезания головы и хвоста у списка, для пришивания головы к списку. Функциональщина!
Аноним 29/09/22 Чтв 22:23:56 833021 88
>>833014
> Надеюсь, ты так шутишь.
Надейся. Но вангование заскринь. Ну всё, я ушол, у меня там снэп на созвоне. Обнял.
Аноним 29/09/22 Чтв 23:31:09 833023 89
>>832960
>всё равно никто это не читает
Я прочитал его графоманию. Мне тоже нравится идея изобретения нового языка программирования и я тоже когда-то подумывал сделать свой собственный визуальный язык программирования, но потом забросил эту идею из-за её практической бесполезности (по крайней мере для меня самого, ведь я могу писать на готовых языках, а визуальные мне неудобны из-за связанного с ними дрочения мышки; вот на смартфоне могло бы быть удобно).

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

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

>распечатываться на монохромном принтере или вывестись на монохромном дисплее
Зачем тебе печатать код на бумаге или читать/писать его на e-ink дисплее? Ты извращенец или просто хочешь изобрести язык "для всего и для всех"? Сделай лучше хороший язык для конкретной задачи, чем плохой - для любой. Кроме того, обозначение цветом - это, обычно, подсказка, без которой код остаётся читабельным; если твоё устройство не поддерживает цвет, тебе будет не очень удобно, но ты всё же сможешь читать и писать код. Совсем другое дело, когда цвет несёт в себе уникальную информацию (которую другим способом узнать нельзя) - вот это плохо, в первую очередь из-за существования дальтоников, людей с плохим или неправильным восприятием цветов.

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

>сегменты (С-блоки
В нормальных языках это называется блоком:
https://ru.wikipedia.org/wiki/Блок_(программирование)
https://en.wikipedia.org/wiki/Block_(programming)
Но если ты называешь инструкции блоками, тогда логично было бы называть блоки кода группами, потому что их основная задача - группировка множества инструкций таким образом, что снаружи эта группа воспринимается как одна инструкция. А вообще, лучше б не выдумывал свои собственные термины... Ты же язык программирования хочешь сделать, а не новую терминологию.

>Фундаментальные
>Производные
>Составные
Опять же, по-моему, ты напутал.
https://ru.wikipedia.org/wiki/Примитивный_тип
https://ru.wikipedia.org/wiki/Тип_данных

Алсо, не забывай, что кроме классов (данные + функции), существуют ещё и записи (агрегатный тип данных):
https://ru.wikipedia.org/wiki/Запись_(тип_данных)

>>832951
>У каждого блока в середине есть как минимум одно гнездо
А как же процедуры и функции без аргументов? Особенно если ты замахиваешься на ООП, в котором метод без аргументов достаточно часто используется, чтобы объект выполнил какую-то работу сам с собой.

>>832952
>У блоков типа уникальная для их типа форма
Понятно, создавать новые типы в твоём языке будет нельзя - ведь уникальных форм на всех не хватит.

>У блоков бинарных операторов вертикальная но инверсная симметрия так, что справа и слева стыкуются без зазоров два однотипных блока.
Ты же в курсе, что могут быть операторы, принимающие на вход данные разных типов? Примеры: умножение вектора на скалярную величину и сложение целого типа с вещественным типом. Или у тебя даже такие простые операции потребуют явное приведение типов?

А что на счёт несимметричных операторов? Для примера, вектор можно разделить на скаляр, но скаляр нельзя разделить на вектор. Языки с поддержкой перегрузки операторов (будет у тебя такая поддержка?) позволяют создавать новые несимметричные операторы. Для примера, можно создать оператор "+", складывающий строку с числом и возвращающий строку, к которой дописано число (в некоторых языках такое в стандартной библиотеке).

>Для лучшей начертаемости от руки.
Совсем с ума сошёл, ты хочешь писать свой велосипедный код на салфетках в кафе? Или ты мечтаешь о том, как будут учить твоему языку в школах?

>>832955
>на пикче 1
>двумя гнёздами-входами
Уже видно изъяны твоей концепции. Во-первых, по факту это обычный императивный текстовый язык со смешной обводкой вокруг текста. Вместо этого было бы куда лучше визуально отображать операции с тем же list x так, чтобы вместо унылых буковок были только весёлые стрелочки и квадратики. Ну серьёзно, вместо x.add(i) должно быть что-то вроде стрелочки от i к x, но не в виде портянки, а графически. Ты же сделал обычный текстовый код без подсветки синтаксиса, но с обводочкой.

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

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

>>832956
>не переменные это, а члены класса
Поля класса, по сути, и есть переменные.

>>832966
>мы приводим int к single и возвращаем single. Как показано на пикче 2.
Лол, на пикче ты возвращаешь int. Сам запутался в собственном велосипеде и не заметил этого.

>читаемость
Выскажу своё мнение: текущий дизайн твоего кода имеет низкую читаемость. Подсветка цветом int/float в обычном текстовом коде лучше твоих рамочек. Да и то, эта подсветка делается только для констант, а переменные не нужно подсвечивать - они должны говорить о своём содержимом самим своим названием, а также быть объявлены близко к месту своего использования. Короче, ты изобрёл какую-то бесполезную фигню, пятое колесо велосипеда. Без обид, не хочу тебя демотивировать, но это реально не нужно.

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

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

>>832976
>пора из гд в пр перекатываться
Там его сожрут успешные 300кк/наносек кодомакаки на попсовых языках, которых волнует только работа на галеру. Будет ли его велосипед полезен галере? Нет, не будет. Значит, ему не место в /пр/. А здесь он может пилить свой велосипед в контексте какого-нибудь игрового движка, или сделать свой игровой движок на основе своего велосипеда. Мы посмотрим и посмеёмся над его попытками, но не так жестоко, как в /пр/, все ж свои.
Аноним 30/09/22 Птн 00:08:11 833024 90
>>833023
> Надеюсь, ты сделаешь его для готового движка типа Godot или хотя бы для компиляции в существующий язык типа C
Именно так и хочу сделать. Транслятор в существующий язык. На большее меня не хватит, увы.
Все советы и претензии принял к сведению. Щас буду думоть.
Настройки X
Ответить в тред X
15000
Добавить файл/ctrl-v
Стикеры X
Избранное / Топ тредов