• Tantramantra и магия проектирования
    +1
    Движок мог быть любой, я тут больше про мета-подход говорю. А сами примеры из Unigine, да. Кстати, как раз год назад вышла его комьюнити-версия для бесплатного использования.
  • Tantramantra и магия проектирования
    0
    Тоже нормально :)
  • Дом в лесу. Работа с освещением в Unity 3D
    +1
    Для коллизий оптимальнее делать отдельную модель/модели (не особо экономно по времени, да), а также пользоваться коллайдерами-примитивами (что по сути входит в этап блокинга). Это не так критично при относительно простых моделях, как тут, но стоит учитывать в перспективе.
    GetComponent'ы стоит всё-таки кэшировать, чтобы не было фризов, когда они вдруг попадутся вне редкого события/условия. Так сказать, формирование правильной привычки.
  • Почему я не покупаю новый ноутбук, а работаю на Sony Vaio семейства SVE c 2013 года
    0
    У меня первым ноутбуком был Compaq с дискретной графикой. Простой девайс, с экраном формата 3 на 4, практически всё что нужно — работало. В итоге у него то ли мост полетел, то ли что — приходилось надавливать при включении, какое-то время помогало. А когда уже перестал включаться, то всё-равно храню — штука приятная, и, вероятно, как-нибудь получится реанимировать.
    Второй ноутбук, который сейчас имеется, тоже от HP, 14-го года. У него не много памяти (4 Гб), карточка dual graphics и процессор A10. Его я уже стараюсь не таскать без необходимости, а клавиатуру использую выносную, почти не пользуясь встроенной — по ней куда бодрее и удобнее колотить. Ну и в целом девайс вполне устраивает, допустим ту же память преимущественно пожирают вкладки браузера, чем что-либо ещё. Использовать браузер с умом — вот и всё, что обычно требуется. Видеокарта — для разработчика даже полезно работать со средней карточкой, начинаешь думать об оптимизациях.
    Система помощнее — это хорошо, но если объективно, для большинства задач хватает довольно незатейливого железа.
  • 7 заповедей любого инженера
    +2
    Какие-то обобщения ради обобщений. Нет бы взять практическую задачу и описать свои мысли применительно к ней.
  • Как и ожидалось, в полночь Adobe Flash превратился в тыкву
    +2
    А что, кто-то запрещает сделать элементарную казуальную игрушку, которая запускается через файл, а не из браузера? Или что, без размещения на конгрегейтах и ньюграундсах художник не художник?
    Тот же Adobe Animate, допустим, экспортирует в html5, webgl и так далее. Так и в чём проблема, кроме того, что ажиотаж вокруг бразуерных порталов давно затих, всё поделено между крупными игроками и уже совершенно не та ситуация, что была раньше.
  • Как и ожидалось, в полночь Adobe Flash превратился в тыкву
    0
    А с чего бы умирать целой среде разработки, если речь шла всего лишь о том, чтобы убрать поддержку плеера из браузеров.
  • Как и ожидалось, в полночь Adobe Flash превратился в тыкву
    0
    В том и дело, что когда формат закрытый — там может быть всё что угодно, и пойди докажи обратное. То есть можно утверждать и то, что есть дыры, и то, что их нет. И всё с равными шансами может не соответствовать действительности.
    А у прочих монополистов по сути и не было другого выбора — им оно надо, добавлять flash и обеспечивать его поддержку, на том основании, что он видите-ли популярный и пользователям надо. Эти самые пользователи на них же первых начнут орать, когда что-то не работает, а не на Adobe.
  • Как и ожидалось, в полночь Adobe Flash превратился в тыкву
    +1
    Java — открытая технология, flash закрытый. Всё просто. Apple первые встали в позу, чтобы банально не зависеть от Adobe — в этом основная причина отказа от flash в браузерах. Прочим то без разницы — всё-равно с монополистами дело иметь, так или иначе, да хотя бы с той же Apple.
  • Как собрать паука в Godot, Unigine или PlayCanvas
    0
    Ну дело как раз в том, что «полноценная» она не всегда нужна.
  • 5 игрушек, чтобы ребёнок почувствовал программирование
    +2
    всё проще
    image
  • Биом, демоверсия игры на Godot
    0
    Ну так eevee или графический движок и так быстро рендерят. А cycles — в любом случае дело не быстрое.
  • Биом, демоверсия игры на Godot
    0
    Было бы ради чего
  • Биом, демоверсия игры на Godot
    0
    Ну, Ryzen7 и 1050 — это, конечно, довольно запредельно :)
  • Биом, демоверсия игры на Godot
    0
    Спасибо за информацию. Значит дело во встроенной графике, действительно.
  • Биом, демоверсия игры на Godot
    0
    Ну, во-первых, всё ещё не ясно, что уберут, а что нет. К тому же позже могут вернуть в любой момент, да и в целом никто не заставляет использовать 4-ку, ведь 3-ка никуда не денется и может развиваться отдельно.
    Во-вторых, 4-ка всё-таки больше про vulkan, который не является панацеей, потому как многое железо просто его не потянет. Вот как моя карточка, допустим. Поэтому мне особо незачем менять 3-ку на 4-ку, если я хочу уровень графики gles3, а его там не окажется.
  • Биом, демоверсия игры на Godot
    0
    Ну да, естественно гигабайты имелись в виду :)
  • Биом, демоверсия игры на Godot
    0
    Понятно. А что за конфигурация, если не секрет?
  • Биом, демоверсия игры на Godot
    +1
    Спасибо.
    Оно не случайно Вангеров напоминает :) тут в целом собраны некоторые их основные механики.
    У меня, кстати, Radeon HD8670m, AMD A10, 4Мб оперативки. Gles3 с тенями в fullscreen более менее сносно работает в Windows 8.1 (видеоролики записываю на машине помощнее, чтобы чуть большее разрешение и запись не съедала fps). Альтернативной ОС стоит Manjaro KDE Plasma, там с тенями уже похуже на свободном дайвере работает (проприетарные пока не пробовал ставить, dual graphics — это в принципе проблемная штука, но, допустим, Godot и разные версии Blender'а с текущим драйвером уже юзабельны в Manjaro), но с выключенными тенями в целом нормально. До недавней переустановки системы тут была комбинация Windows 7 и Deepin. В Win 7 работало примерно так же, как на 8.1, а вот Deepin был тормознее чем Manjaro.
  • Биом, демоверсия игры на Godot
    0
    Добавил сборки под linux и win32 на gles2 рендере. Какие-то шейдеры отвалились, но более менее подправил частицы и некоторые материалы.
    Как-то так выглядит gles2 версия:



  • Биом, демоверсия игры на Godot
    0
    По всей видимости не тянет gles3-рендер. Но у Godot есть ещё gles2, просто там как минимум отвалятся частицы при конвертировании и нужно будет их переделать. Попробую тогда собрать вариант на gles2.
  • Биом, демоверсия игры на Godot
    0
    Залил туда сборку для win32. Мне просто конкретно её негде проверить, напишите — работает ли.
  • Биом, демоверсия игры на Godot
    0
    Ну тут стандартная сборка Godot для windows. Просто не уточнял как собираются для 32. Видимо, там нужно просто галочку Binary Format — 64 Bits снять. Если так, то получается могу собрать для 32.
  • Биом, демоверсия игры на Godot
    –1
    Так и попросили бы у разработчиков Godot шаблоны сборки под Эльбрус.
  • От складных телефонов к растягивающимся экранам
    0
    Скорее уж смартфоны в перспективе сожмутся до габаритов волшебной палочки, которая умеет в более продвинутое альтернативное управление, хотя бы голосом, и нечто вроде голограмм.
    А гибкие дисплеи в рамках современных технологий — это не серьёзно. Просто у этого есть продающий вау-эффект, поэтому покупатели найдутся. Я уже видел желающих, которые ничего даже слышать не хотят против — дай им, и всё, как дети.
    Были вот складные телефоны, например. Я с такого прямо начинал — подарили. Когда взял позже обычный, то не понял, зачем складные вобще были нужны — в обычном всё было куда оптимальнее.
    Или вот сейчас, когда диагональ смартфонов проскочила какой-то разумный уровень и начинает расти куда-то не туда. Притом сразу у всех производителей, почти не оставляя вариантов. Вот чем их 5 и 5.5 не устраивали? Как по мне — самый комфортный диапазон, мне больше не нужно. Как и не нужны никакие складные или гибкие.
    Вот потребитель хочет новаций ради новаций, хочет 7 дюймов и сгибать в трёх местах — пусть, только это какой-то излишний жир, давайте называть вещи своими именами. Не все прорывы одинаково полезны. Не все из них влекут за собой действительно глобальные качественные изменения.
  • Механики ловушек и интерактивных объектов в Godot Engine. Часть 2
    +1
    Просто в различных примерах, да и в исходниках, любят писать наглядным образом, везде используя $… Но есть вот такие нюансы, малозаметные пока подобных обращений в коде немного и они не начинают массово скапливаться в цикле.
  • Механики ловушек и интерактивных объектов в Godot Engine. Часть 2
    +2
    Подобные способы взятия узлов ($AnimatedSprite, $Timer и прочие $...) стоит кэшировать, например:
    onready var this_sprite = $AnimatedSprite
    onready var for_timer = $Timer

    чтобы обращаться к ним так:
    this_sprite.play(«show») вместо $AnimatedSprite.play(«show»)

    Становится менее наглядно, но следует помнить, что каждый такой $… аналогичен вызову get_node() и при использовании в цикле потери времени на это могут стать заметными. Попутно от подобного кэширования дополнительная польза на будущее, если целевой узел вдруг сместится в иерархии, то не надо будет править пути к нему по всему коду.
    А так, вне циклов, обращения через $… более оправданы, в том плане, что так проще/нагляднее и потери могут быть почти неощутимы.
  • Комментарий из публикации, перенесённой в черновики.
  • Микрокосм, демоверсия
    +1
    Ну я про это и говорю, что когда ведёшь серию материалов, то у неё может сформироваться уже какая-то аудитория, которой это так или иначе интересно.
  • Микрокосм, демоверсия
    0
    Просто есть разные подходы — показывать только уже исключительно законченную вещь либо показывать итерации. У этого всего есть свои определённые плюсы/минусы. К тому же, допустим, прототипы на то и прототипы, что не все из них имеет смысл развивать в нечто большее.
  • Микрокосм, демоверсия
    0
    Рад слышать.
  • Комментарий из публикации, перенесённой в черновики.
  • Демо-версии Невангеров для Unigine и Godot
    +1
    Ёмко.
    Кстати, соглашусь с важной ролью ограничений, благодаря которым появляются специфические геймплеи или способы реализации чего-то внутри игры, организации пространств и так далее. Собственно, в статье и описаны различные подходы к устройству прототипа, которые выросли в процессе разработки из специфики того или иного движка. Да и в целом сама полигональная графика и её пайплайны тоже выросли из ограничений, потому как считать реалтайм 3д через «честные» воксели — драматически непроизводительно. Или вот такой особый «переходный» поджанр, как 3d игры с фиксированной камерой и пререндеренными задниками. Да даже в эпоху 2д тоже хватало своих «нечестных» трюков и ухищрений, чтобы обходить ограничения и добиваться адекватной производительности.
    Тоже в качестве C# движка рассматриваю Stride как один из интересных вариантов. Потому как в Unity на шарпе замечательно всё писалось и хотелось бы чего-то подобного. Вот почему и взялся за Unigine, в котором эта возможность тоже есть, хотя пока в основном описано невизуальное использование скриптового языка. Но опыт Unity туда хорошо переносится. В Godot, напротив, выбрал всё-таки внутренний GDScript, потому как из нескольких скриптовых языков в движке я лучше возьму тот, который лучше проработан и интегрирован. Тем более отличия от шарпа не такие большие, чтобы это было какой-то прям проблемой — пишешь себе логику и пишешь.
  • Демо-версии Невангеров для Unigine и Godot
    0
    Как мне кажется, повышению интереса к движку способствуют разрабатываемые на нём проекты, в том числе силами самих разработчиков движка. Может даже чисто демонстрационные. Чтобы наглядно показать пайплайны, инструментарий. Опять же — лишние инфоповоды, вроде новостей из дневников разработки, но не касаемо самого движка, а каких-то прототипов на его основе.
    Лучше всего даже каких-то супер-простых, от которых новоприходящим разработчикам проще моддить свои проекты. Даже в том же Unity не сразу к этому пришли — относительно недавно (хотя на сайт к ним давно не заглядывал) на сайте появились официальные мини-проекты с разбором отдельных элементов, вроде простой гонки, шутера и так далее.
    Я просто вспоминаю, как начал делать игры на том же Flash именно после того как нашёл где-то на Kongregate пошаговое руководство по написанию простой леталки. В итоге около десятка игр на эту платформу написал. Хотя, конечно, сам интерес к разработке на Flash изначально появился не от наличия туториала, а по иным причинам, но без существования этой точки старта я в то время, наверное, продолжал бы использовать Blitz3d или ушёл в какие-то другие среды разработки.
    В случае со входом в Blitz3d тоже попалась некоторая обучалка возможностям и примеры сборки чего-то простого. А на Unity можно было относительно просто вкатиться благодаря сторонним мини-прототипам в асстет-сторе, пока не было расписанных пошаговых официальных.
  • Демо-версии Невангеров для Unigine и Godot
    +1
    Просто когда у движка на официальном канале последнее видео годовой давности, а прочие аж 7-летней, то это как-то не очень способствует популяризации. Тем более, что какие-то новые версии они выкатывали не 7 лет назад и как раз есть повод поснимать каких-то новых видео/туториалов и всякого подобного.
  • Демо-версии Невангеров для Unigine и Godot
    +1
    Ну, редактор у NeoAxis довольно страшноват, если честно. Документации всего ничего, развивается всё как-то очень тихо и медленно. Pbr вроде и заявлен, но на скриншотах оно так не выглядит. Что ещё. Разработка только под Windows. Как бы и опенсурс, но лицензия с требованием упоминания в титрах. Просто не увидел каких-то преимуществ, кроме некоторого количества готового полезного инструментария. Есть наверное какие-то скрытые плюсы, но тут всё упирается в наличие желания рассматривать данный вариант.
    Просто с тем же Godot на поле опенсурс движков конкурировать почти нереально, а это ещё не вышла 4-ка.
    Скорее я посмотрел бы на Stride, где C# в качестве основного языка, инструментария немного, но как-то целостно и приятно всё выглядит. Или на вот буквально на днях вышедший Cocos Creator 3D, который тоже развивается и кажется перспективным. Правда у двух последних пока не наработана база примеров/исходников и туториалов.
  • Демо-версии Невангеров для Unigine и Godot
    0
    Игра, кстати, классная. Играл на PsOne. И музыку помню до сих пор.
  • Open-source бандл
    0
    Есть приложения ещё проще, вроде VirtualDub (по крайней мере когда давно им пользовался он был проще) http://virtualdub.sourceforge.net/
    Плюс попадались какие-то совсем двухкнопочные склеиватели, сейчас уже и не вспомню. А так, тот же Shotcut довольно просто позволяет всё это делать минимально разобравшись.
    Ещё в Blender можно склеивать видео, если открыть его окошко VideoSequencer, хотя там потребуется разбираться, как правильно добавить контент на пространство монтажа. Зато там можно относительно удобно склеивать видео из последовательности изображений, а не только сами куски видео.
  • Open-source бандл
    0
    При чём здесь ютуб? Это пояснительные мини-видео, весом как гиф-файлы.
  • Итеративный геймдизайн, Godot и мир маленьких планет
    +1
    Ну да, то моя статья была тоже.