Flash/Animate действительно классный тул для подготовки 2d ассетов – множество разработчиков использовали его как полноценный игровой редактор задолго до появления юнити. Да и юнити для этих целей во многом уступал. Были случаи, когда игра с флэша уже была портирована на юнити, но в качестве редактора уровней все равно выступал флэш. А swf – классный формат. Открытый, компактный, поддерживает векторную-растровую графику, иерархии объектов, анимации, код. Отлично подходит как контейнер ассетов для 2d игр. Почему-то все время забывают, что есть актуальный инструмент, позволяющий пользоваться всем этим добром с комфортом – openfl/swf. В прошлом месяце как раз свежая версия вышла. Весь код, реализующий флэшовый апи и позволяющий воспроизводить мувиклипы в рантайме – часть движка openfl, транспилируется в cpp/c/js в зависимости от целевой платформы и предпочтений. Для своих игр продолжаю пользоваться swf как контейнером для ассетов.
Если реальная цель соответствует заявленной – структурировать хаос большого количества окон, то для ее достижения гораздо лучше подходят виртуальные рабочие столы.
Ну, навигация по файлам не управляется через это расширение, например. При этом у VSCode для многого есть свои горячие клавиши и предусмотрен флоу работы только с клавиатурой. Я мучился какое-то время, но постепенно настроил все необходимые горячие клавиши, теперь пользуюсь совершенно без мышки. Самая большая боль была – расширение для гита, но после того, как наткнулся на kahole/edamagit – процесс устаканился окончательно. Правда, у меня еще кое-что при помощи AHK накручено для полной гармонии. Если будет вопрос, как что-то конкретное сделать с клавиатуры – пишите, может подскажу из собственного опыта.
Но ведь vscode-neovim – это и есть фронтэнд к настоящему неовиму. Какую еще более "полную нативную" навигацию выбы хотели? Да, телескоп работать не будет, но что касается навигации по тексту редактора – она работает так же, как в вашем сетапе вима. Или вы про то, что она должна быть зашита в основу программы на уровне дизайна архитектуры? Такое было, но не взлетело, хотя какое-то время подавало надежды.
У меня сложилось впечатление, что ваш конструктор решает в основном задачу "освоение бюджета". У вас шаги прописаны: импорт модели, натягивание текстур... Это очень прикладные задачи, которые нужно учиться делать в настоящих инструментах. Это не "вход разработку", это "имитация бурной деятельности". В чем смысл шага "импорт своей модели"? Она не "своя", а какая-то выданная воспитателем. С таким же успехом ее можно было захардкодить в платформу. Если же дети сами что-то лепят в блендере и экспортируют, то оказывается, что у них уже есть "тяжелая среда" и ее кто-то установил. Я даже представляю, как такой франкенштейн мог получиться. Сначала появляется учебная программа по дисциплине "разработка игр". Там в требованиях написано: ... должен уметь: - импортировать модели, - накладывать текстуры ... Потом возникает идея адаптировать эту программу для детей младшего возраста, при выборе инструментов успешно доказывается, что реальные инструменты не подходят, поэтому нужно выбить бюджет и сделать свое, без фатального недостатка. Этот "горе-тренажер" точно так же, без попытки осмыслить реальные потребности, отправляется в разработку с требованиями, скопированными из программы без привлечения сознания. И вот имеем что имеем.
Веб-игры, в которые нельзя поиграть без регистрации? Спасибо, но нет. Достаточно движеов, в которых можно делать вот все вот это и еще всякое, и которые позволяют использовать результат где угодно, а не только на своей платформе. Armory | 3D Content Creation Tools – прямо в блендере. Godot, Defold, Unity. Знакомить детей с геймдевом в мертворожденном инструменте, мне кажется – только портить им мотивацию.
Вероятно то, что измерять каждую модель, чтобы надежно узнать ее размер согласно ISO, стоит дороже 100 г. колбасы и дороже логистики возвратов. Точнее, это про продавца. Производитель при этом может быть в Китае, не представлять о существовании ISO и лишь смутно догадываться о существовании мира, где пишут не иероглифами. Его эти проблемы вообще не волнуют. Я не представляю, как вы покупаете обувь и что у вас с ногами. Помимо размера (длина стопы) есть еще куча параметров: ширина, подъем, форма колодки, пальцев. Даже обувь правильного размера может быть жутко неудобной.
Полностью соглашусь с генеральной мыслью: привычки определяют очень многое. Почти все. Но некоторые выводы из нее получились частными и поэтому бесполезными в универсальном плане. Например, панели и место на экране – для кого-то с большим монитором – способ по умолчанию ограничить область видимого фокуса (я в юности подсознательно шрифт в IDE побольше ставил, видимо, чтобы проще было концентрироваться на куске кода, который помещается в экран и в рабочую память). Альтернатива комплишнам – наизусть помнить все апи всех используемых классов. Тоже очень сомнительная "разгрузка" в очень многих кейсах работы с кодовой базой. В некотором смысле, происходит подмена понятий: минималистичный интерфейс, собственный конфиг без перегруженных сборок (spacemacs, astrovim) преподносятся как простота. Но эта простота не учитывает сложности пути, который нужно проделать, чтобы оказаться с простым конфигом, подходящим именно тебе. Тяжелые сборки – это просто гид по возможностям софта и расширений. Противоположный путь "наращивания" функционала от голого конфига, особенно для неофита, окажется ресурсно намного дороже. Дороже на ту цену, которую просто не имеет смысла платить в современном мире. Ведь упрощение – это тяжелая работа по обучению, формированию привычек. Поэтому в моменте она всегда будет усложнением по отношению к привычной манере работы здесь и сейчас. А упрощать жизнь она может начать в столь отдаленной перспективе, о которой многие просто не задумываются.
По поводу важности затрат сил, а не времени; привычках и оптимизации – много хорошего понаписано в книгах Максима Дорофеева, использующего понятие "мыслетоплива".
По поводу советов для работы над привычками упущено, наприер, освоение слепого десятипальцевого.
Информационная служба хабра опять постит не приходя в сознание. По ссылке (про которую можно подумать, что она относится к "перспективам RISC-V") на самом деле сообщение, в котором:
Линус ругается, что в тексте сопроводительного письма с PR съехало форматирование вложенных списков, и в этом контексте рекомендует разобраться автору с настройками своего текстового редактора. Эта чать к расту отношения не имеет.
Сетует, что автоформаттер раста может в определенных ситуациях импорты в одну строку слепить.
А это точно помощь? Пример с ракетой выглядит как мусор. Чтобы исправить форму предлагает добавить текстуру. Чтобы добавить "подушку" предлагает подвинуть вверх кропнутую картинку. Нижняя часть светлая и легкая, т.е. уже выполняет в некотором смысле функцию подушки, а сама ракета уже смещена вверх. Скорее всего, нейросеть посчитала, что изображение цельное и не имеет продолжения за границами блока. Хотя человеку очевидно, что если крупнутую картинку подвинуть вверх, добавив отступ снизу, выглядеть это будет дико. Да еще и ракета под текст залезет. Можете показать отредактированное в соответствии с рекомендациями изображение?
Почему-то взгляд со стороны на любителей "меньше перемещать руки" выглядит так, будто они предлагают выбросить мышку в окно. Извините, не удержался. Зачем же в абсолют-то? Давайте попробуем посмотреть вот с какой стороны: во время работы (ну, пусть, с кодом) каждый раз, когда вы меняете органы управления, у вас отъедается кусочек внимания. Если у вас на подкорке сидит альтернативный способ того же действия, но без смены управления – этот кусочек внимания остается доступным для основной задачи.
Расширяя постепенно список усвоенных действий, вы каждый раз немного добавляете мозгу ресурса для работы над основной задачей. Конечно, если мы говорим о смене парадигмы (переход на модальные редакторы – "vim плагин"), то в начале будет резкое проседание. Так же и с десятипальцевым – слом старых привычек тыкать любым пальцем по началу будет отъедать большой ресурс. Но после переломного периода начнется плавный рост, который в долгосрочной перспективе даст огромный буст.
Структура вашей работы не является какой-то необычной, практически все, что вы перечислили можно комфортно делать с клавиатуры. Смена привычек и освоение всех необходимых действий, конечно, займет много времени. Возможно, не один год. Но преимущества начнут появляться гораздо раньше. Не повезло с этим путем лишь тем, кто по роду деятельности не имеет возможности настраивать свое рабочее место.
При использовании мышки как основного инструмента во всяких IDE несет дополнительные негативные факторы, особенно, если речь идет о действиях закопанных в иерархические менюшки. Подробнее, можно посмотреть ссылки: Закон Фиттса — Википедия, Hick's law - Wikipedia
Поэтому, с учетом стремления минимизировать смену органов управления, в браузере у меня еще стоит плагин, так что я вовсе не предлагаю избавляться от мыши.
И характер работы такой что нужно больше думать и прыгать по коду чем вводить текст.
Почему-то взгляд со стороны на любителей "меньше перемещать руки" выглядит так, будто это ради скоростинаборатекста. Не буду говорить за всех, только за себя: скорость ввода текста – это последнее, о чем я думал, осваивая слепой десятипальцевый, vim, emacs, AHK. Для меня важно именно то, что в деятельности нужно больше думать. А думать – это фокусировать внимание. А прыжки руками до мышки, поиск нужной кнопочки, прицеливание – все эти действия внимание кушают. Следовательно, мешают думать. По моим ощущениям, очень сильно мешают думать. Вы не представляете, какой это кайф – не быть "суетливым в движениях" во время размышлений и перемещений по коду, и именно ради этого стоит инвестировать свое время во все эти "причуды". Для меня ребус окончательно сощелкнулся, когда я узнал о расширении edamagit. Теперь для работы с VSCode мышка не нужна вовсе и это ощущается как пару плашек оперативки в мозг воткнули.
По уму, конечно, это тоже надо бы настроить. Но по факту мне лень, и это те редкие случаи, когда я действительно таскаю руки до реальных стрелок. К счастью, основную часть времени я провожу в софте, где это не нужно. Пожалуй, работа с комментариями в браузере, да в коммандной строке фара – этим ограничиваются случаи, когда мне нужны стрелки с модификаторами. Во всех остальных программах, в которых я работаю с текстом, альтернативы намного удобнее. Ах, и да, у меня есть маппинги для отдельных кейсов. Например, в селекторе окон по win+tab hjkl тоже перемаплены на стрелки.
Мне вот чаще нужно что-то в тексте проверить, поправить, удалить, вставить... или по каталогам побегать, файлы покопировать, поудалять.
Это все отлично работает с home row. На самом деле, vim-like модальные режимы c поддержкой easy motion или аналога превращают прыжки и правки по тексту в сплошное удовольствие.
Всегда было интересно, что делают пользователи таких клавиатур, если, условно, в ближайшие 10 минут нужны только клавиши навигации? Так и держат обе руки на F и J или постоянно выцеливают двух-трех-клавишные комбинации?
Пользователь ноутбучной клавиатуры (к счастью, без цифрового блока и максимально близкой к стандартной 75%). Ага, так и держу. И вообще стрелками практически не пользуюсь. Софт, которым пользуюсь большую часть времени и так поддерживает hjkl (браузер, редакторы, ide), для остальных программ hjkl с зажатым контролом превращаются в стрелки.
А пользователи хабра обычно выступают против публикаций, авторы который вообще не вникают в то, что пишут. Но кого это волнует? Бэйтный заголовок и погнали. В оригинальном материале речь идет о запросе блокировки сгенерированных PR/code review от других пользователей в своем репо. То есть речь не о "принудительном использовании" а о включении "принудительного неиспользования для других".
Вы когда-нибудь целенаправлено разбивали сырое куриное яйцо? В этой же ситуации вас бы устроил в качестве альтернативы результат упавшего и разбившегося яйца?
Flash/Animate действительно классный тул для подготовки 2d ассетов – множество разработчиков использовали его как полноценный игровой редактор задолго до появления юнити. Да и юнити для этих целей во многом уступал. Были случаи, когда игра с флэша уже была портирована на юнити, но в качестве редактора уровней все равно выступал флэш.
А swf – классный формат. Открытый, компактный, поддерживает векторную-растровую графику, иерархии объектов, анимации, код. Отлично подходит как контейнер ассетов для 2d игр.
Почему-то все время забывают, что есть актуальный инструмент, позволяющий пользоваться всем этим добром с комфортом – openfl/swf. В прошлом месяце как раз свежая версия вышла. Весь код, реализующий флэшовый апи и позволяющий воспроизводить мувиклипы в рантайме – часть движка openfl, транспилируется в cpp/c/js в зависимости от целевой платформы и предпочтений.
Для своих игр продолжаю пользоваться swf как контейнером для ассетов.
Если реальная цель соответствует заявленной – структурировать хаос большого количества окон, то для ее достижения гораздо лучше подходят виртуальные рабочие столы.
Ну, навигация по файлам не управляется через это расширение, например. При этом у VSCode для многого есть свои горячие клавиши и предусмотрен флоу работы только с клавиатурой. Я мучился какое-то время, но постепенно настроил все необходимые горячие клавиши, теперь пользуюсь совершенно без мышки. Самая большая боль была – расширение для гита, но после того, как наткнулся на kahole/edamagit – процесс устаканился окончательно.
Правда, у меня еще кое-что при помощи AHK накручено для полной гармонии.
Если будет вопрос, как что-то конкретное сделать с клавиатуры – пишите, может подскажу из собственного опыта.
Но ведь vscode-neovim – это и есть фронтэнд к настоящему неовиму. Какую еще более "полную нативную" навигацию выбы хотели? Да, телескоп работать не будет, но что касается навигации по тексту редактора – она работает так же, как в вашем сетапе вима.
Или вы про то, что она должна быть зашита в основу программы на уровне дизайна архитектуры? Такое было, но не взлетело, хотя какое-то время подавало надежды.
У меня сложилось впечатление, что ваш конструктор решает в основном задачу "освоение бюджета".
У вас шаги прописаны: импорт модели, натягивание текстур... Это очень прикладные задачи, которые нужно учиться делать в настоящих инструментах.
Это не "вход разработку", это "имитация бурной деятельности".
В чем смысл шага "импорт своей модели"? Она не "своя", а какая-то выданная воспитателем.
С таким же успехом ее можно было захардкодить в платформу.
Если же дети сами что-то лепят в блендере и экспортируют, то оказывается, что у них уже есть "тяжелая среда" и ее кто-то установил.
Я даже представляю, как такой франкенштейн мог получиться.
Сначала появляется учебная программа по дисциплине "разработка игр".
Там в требованиях написано: ... должен уметь: - импортировать модели, - накладывать текстуры ...
Потом возникает идея адаптировать эту программу для детей младшего возраста, при выборе инструментов успешно доказывается, что реальные инструменты не подходят, поэтому нужно выбить бюджет и сделать свое, без фатального недостатка.
Этот "горе-тренажер" точно так же, без попытки осмыслить реальные потребности, отправляется в разработку с требованиями, скопированными из программы без привлечения сознания.
И вот имеем что имеем.
Веб-игры, в которые нельзя поиграть без регистрации? Спасибо, но нет.
Достаточно движеов, в которых можно делать вот все вот это и еще всякое, и которые позволяют использовать результат где угодно, а не только на своей платформе.
Armory | 3D Content Creation Tools – прямо в блендере. Godot, Defold, Unity.
Знакомить детей с геймдевом в мертворожденном инструменте, мне кажется – только портить им мотивацию.
Вероятно то, что измерять каждую модель, чтобы надежно узнать ее размер согласно ISO, стоит дороже 100 г. колбасы и дороже логистики возвратов. Точнее, это про продавца.
Производитель при этом может быть в Китае, не представлять о существовании ISO и лишь смутно догадываться о существовании мира, где пишут не иероглифами. Его эти проблемы вообще не волнуют.
Я не представляю, как вы покупаете обувь и что у вас с ногами. Помимо размера (длина стопы) есть еще куча параметров: ширина, подъем, форма колодки, пальцев. Даже обувь правильного размера может быть жутко неудобной.
Полностью соглашусь с генеральной мыслью: привычки определяют очень многое. Почти все.
Но некоторые выводы из нее получились частными и поэтому бесполезными в универсальном плане.
Например, панели и место на экране – для кого-то с большим монитором – способ по умолчанию ограничить область видимого фокуса (я в юности подсознательно шрифт в IDE побольше ставил, видимо, чтобы проще было концентрироваться на куске кода, который помещается в экран и в рабочую память).
Альтернатива комплишнам – наизусть помнить все апи всех используемых классов. Тоже очень сомнительная "разгрузка" в очень многих кейсах работы с кодовой базой.
В некотором смысле, происходит подмена понятий: минималистичный интерфейс, собственный конфиг без перегруженных сборок (spacemacs, astrovim) преподносятся как простота. Но эта простота не учитывает сложности пути, который нужно проделать, чтобы оказаться с простым конфигом, подходящим именно тебе. Тяжелые сборки – это просто гид по возможностям софта и расширений.
Противоположный путь "наращивания" функционала от голого конфига, особенно для неофита, окажется ресурсно намного дороже. Дороже на ту цену, которую просто не имеет смысла платить в современном мире.
Ведь упрощение – это тяжелая работа по обучению, формированию привычек. Поэтому в моменте она всегда будет усложнением по отношению к привычной манере работы здесь и сейчас. А упрощать жизнь она может начать в столь отдаленной перспективе, о которой многие просто не задумываются.
По поводу важности затрат сил, а не времени; привычках и оптимизации – много хорошего понаписано в книгах Максима Дорофеева, использующего понятие "мыслетоплива".
По поводу советов для работы над привычками упущено, наприер, освоение слепого десятипальцевого.
Не будет. Перекатывайтесь.
Информационная служба хабра опять постит не приходя в сознание. По ссылке (про которую можно подумать, что она относится к "перспективам RISC-V") на самом деле сообщение, в котором:
Линус ругается, что в тексте сопроводительного письма с PR съехало форматирование вложенных списков, и в этом контексте рекомендует разобраться автору с настройками своего текстового редактора. Эта чать к расту отношения не имеет.
Сетует, что автоформаттер раста может в определенных ситуациях импорты в одну строку слепить.
А это точно помощь?
Пример с ракетой выглядит как мусор. Чтобы исправить форму предлагает добавить текстуру.
Чтобы добавить "подушку" предлагает подвинуть вверх кропнутую картинку. Нижняя часть светлая и легкая, т.е. уже выполняет в некотором смысле функцию подушки, а сама ракета уже смещена вверх.
Скорее всего, нейросеть посчитала, что изображение цельное и не имеет продолжения за границами блока. Хотя человеку очевидно, что если крупнутую картинку подвинуть вверх, добавив отступ снизу, выглядеть это будет дико. Да еще и ракета под текст залезет.
Можете показать отредактированное в соответствии с рекомендациями изображение?
Почему-то взгляд со стороны на любителей "меньше перемещать руки" выглядит так, будто они предлагают выбросить мышку в окно. Извините, не удержался.
Зачем же в абсолют-то? Давайте попробуем посмотреть вот с какой стороны: во время работы (ну, пусть, с кодом) каждый раз, когда вы меняете органы управления, у вас отъедается кусочек внимания. Если у вас на подкорке сидит альтернативный способ того же действия, но без смены управления – этот кусочек внимания остается доступным для основной задачи.
Расширяя постепенно список усвоенных действий, вы каждый раз немного добавляете мозгу ресурса для работы над основной задачей. Конечно, если мы говорим о смене парадигмы (переход на модальные редакторы – "vim плагин"), то в начале будет резкое проседание. Так же и с десятипальцевым – слом старых привычек тыкать любым пальцем по началу будет отъедать большой ресурс. Но после переломного периода начнется плавный рост, который в долгосрочной перспективе даст огромный буст.
Структура вашей работы не является какой-то необычной, практически все, что вы перечислили можно комфортно делать с клавиатуры. Смена привычек и освоение всех необходимых действий, конечно, займет много времени. Возможно, не один год. Но преимущества начнут появляться гораздо раньше. Не повезло с этим путем лишь тем, кто по роду деятельности не имеет возможности настраивать свое рабочее место.
При использовании мышки как основного инструмента во всяких IDE несет дополнительные негативные факторы, особенно, если речь идет о действиях закопанных в иерархические менюшки.
Подробнее, можно посмотреть ссылки: Закон Фиттса — Википедия, Hick's law - Wikipedia
Поэтому, с учетом стремления минимизировать смену органов управления, в браузере у меня еще стоит плагин, так что я вовсе не предлагаю избавляться от мыши.
Довольно популярное решение в около-вим-конфигурациях – замапить на jj или kj.
Почему-то взгляд со стороны на любителей "меньше перемещать руки" выглядит так, будто это ради скорости набора текста. Не буду говорить за всех, только за себя: скорость ввода текста – это последнее, о чем я думал, осваивая слепой десятипальцевый, vim, emacs, AHK.
Для меня важно именно то, что в деятельности нужно больше думать. А думать – это фокусировать внимание. А прыжки руками до мышки, поиск нужной кнопочки, прицеливание – все эти действия внимание кушают. Следовательно, мешают думать. По моим ощущениям, очень сильно мешают думать.
Вы не представляете, какой это кайф – не быть "суетливым в движениях" во время размышлений и перемещений по коду, и именно ради этого стоит инвестировать свое время во все эти "причуды".
Для меня ребус окончательно сощелкнулся, когда я узнал о расширении edamagit. Теперь для работы с VSCode мышка не нужна вовсе и это ощущается как пару плашек оперативки в мозг воткнули.
По уму, конечно, это тоже надо бы настроить. Но по факту мне лень, и это те редкие случаи, когда я действительно таскаю руки до реальных стрелок. К счастью, основную часть времени я провожу в софте, где это не нужно. Пожалуй, работа с комментариями в браузере, да в коммандной строке фара – этим ограничиваются случаи, когда мне нужны стрелки с модификаторами.
Во всех остальных программах, в которых я работаю с текстом, альтернативы намного удобнее.
Ах, и да, у меня есть маппинги для отдельных кейсов. Например, в селекторе окон по win+tab hjkl тоже перемаплены на стрелки.
Это все отлично работает с home row. На самом деле, vim-like модальные режимы c поддержкой easy motion или аналога превращают прыжки и правки по тексту в сплошное удовольствие.
Пользователь ноутбучной клавиатуры (к счастью, без цифрового блока и максимально близкой к стандартной 75%). Ага, так и держу. И вообще стрелками практически не пользуюсь. Софт, которым пользуюсь большую часть времени и так поддерживает hjkl (браузер, редакторы, ide), для остальных программ hjkl с зажатым контролом превращаются в стрелки.
А пользователи хабра обычно выступают против публикаций, авторы который вообще не вникают в то, что пишут. Но кого это волнует? Бэйтный заголовок и погнали.
В оригинальном материале речь идет о запросе блокировки сгенерированных PR/code review от других пользователей в своем репо. То есть речь не о "принудительном использовании" а о включении "принудительного неиспользования для других".
Вы когда-нибудь целенаправлено разбивали сырое куриное яйцо?
В этой же ситуации вас бы устроил в качестве альтернативы результат упавшего и разбившегося яйца?
О, PouchDB прикольная штука. Возьму на заметку.
Браузерный Local storage? Не лучшее решение для основного хранилища, но пусть так.