Нижняя – тоже неплохая. Но мне она показалась немного скучноватой. А такие детали типа коровы в ванне и елок в горшке – они скорее взрослых развлекут. Мелкие, мне кажется, на такие детали вообще внимания не обращают. Вот например, если бы толпа народу в разных костюмах, позах и со смешными инструментами или там замок с кучей окошек... Ну, короче, типа охотников Брейгеля (и вдохновленной им Дотремер) – вот такие детали мелким пойдут огого. Среднюю в таком разрешении, конечно, не особо разглядишь, но персонажи все выразительные и "чайлдиш" стиль отлично передан – уверенная рука чувствуется. И компоновка листа тоже весьма профессиональная. Очень наивно полагать, что "рандомный мимокрокодил" или первоклассник сможет сделать что-то похожего уровня.
Да отличные картинки. Вы зачем-то свое чувство прекрасного пытаетесь выдать за объективные характеристики. Мне, например, нижняя картинка меньше всех нравится. То, что вы считаете их уровнем "ученика первого класса" скорее говорит о том, насколько вы в вопросе ориентируетесь.
Что я только что прочитал? В какой среде термин ARPPU используется как синоним среднего чека? (Просто проверьте в гугле значение термина). Вы LTV посчитали для платящих и сравниваете с CPI. Что вы тогда под CPI понимаете?
Так что проблема надумана и затеняет главную - обучение от длинных текстов и формулировпния мыслей на письме.
Но разве в статье говорится не о том, что "надуманная" проблема может являться фактором, влияющим на главную – умение воспринимать сложные тексты и формулировать мысли на письме? То есть, когда ребенок учится писать рукой – он "раскачивает мозговую мышцу", которая в будущем, при работе над текстом с клавиатурой, и даст больший резерв для [полезной] нагрузки.
Minecraft - выроз из конкурсного проекта Нотча, вроде как 800кб
Infiniminer, a block-based open-ended mining game first released in April 2009, inspired Persson's vision for RubyDung's future direction. Ну в википедии же написано даже.
Vampire Survivors - клон древних топдауншутеров, с урезанными возможностями
Ну вам же написали, чего именно клон вампиры. Зачем возражать неправильно? Во-первых, разработчик сам в интервью говорил, чем именно вдохновлялся, во-вторых, общего по механикам с crimson land (а много вы еще подобных древних топдауншутеров знаете?) только то, что орды нечести со всех сторон прут. Кстати, метод "творческой ампутации" – тоже хороший способ придумывать игры. Можно взять одну механику из множества механик большой игры и сделать из нее отдельную игру поменьше.
Не проверял, но предполагаю, что с vscode-neovim могут быть проблемы, как и вообще с любой интерференцией горячих клавиш. Также предполагаю, что памяти сэкономится не слишком – основная ее часть все же тратится на прикладной код и пользовательские данные, а не на "браузерное ядро". С другой стороны, наверно это очень здорово работает с каким-нибудь ультрапортативным устройством, на котором можно использовать всю мощь рабочей машины с десятками и сотнями гб оперативы.
Elisp/emacs – максимально кастомизируемая рабочая среда. Haxe – непревзойденное покрытие целевых сред и interop-а. Zero-overhead синтаксический слой абстракции над чем угодно – Abstract.
За haxe не стоит никого "с маркетингом", поэтому он не на слуху. Нюансы, разумеется, есть. Но языку 20 лет, готовится к релизу 5 версия. На нем написан ряд весьма успешных проектов, есть компании, работа которых полностью построена на этой технологии. Если называть эту технологию сырой – вылизанных просто не существует.
По функционалу я вообще думаю конкурентов найти сложно. В какой плоскости функционал вас интересует? Могу подсказать.
Смотрю что для десктопа этот Haxe использует либо WxWidgets
В самом haxe вообще нет gui – это язык/транспилятор. На нем написан ряд gui фреймворков, каждый из которых может использовать свой подход к кроссплатформенности. Если говорить про haxeui, то он реализует слой абстракции с переключаемыми бакэндами. То есть, gui реализованные на haxeui можно запустить поверх: openfl, wxWidget, html, pixi.js, kha. Можно просто собрать приложение всеми способами и сравнить, какой лучше подходит. В этом случае сборка с wxWidget будет работать только на десктопе, но все остальные способы можно так или иначе запустить везде. Openfl/nme бэкэнды при этом самые универсальные. Они содержат в себе SDL и графический апи поверх него. Код на haxe в этом случае транспилируется в c++, слинкуется с этими библиотеками и будет рисовать кнопки через openGL на любой платформе с фолбэком в софтверный рендер, никаких внешних доп зависимостей при этом не потянет.
В вашем случае тоже можно посмотреть на вариант из моего комментария выше. Апкшка чистого проекта под 2 архитектуры была около 10 мб, если память не изменяет. Дополнительных зависимостей не тянет, код транспилируется в плюсы и линкуется с библиотекой, построенной вокруг SDL. Для веба просто транспилируется в js. Есть и другие варианты сборки.
А в какой плоскости проект? Кроссплатформу довольно комфортно и на относительно слабом железе можно делать на haxe + openfl. Если приложение чисто UI, то с HaxeUI, если более широкоразвлекательного толка, то с HaxeFlixel, хотя и у самого openfl достаточно богатый апи.
Да, как выше упомянули – haxe. Точнее, openfl/nme. Если код на вменяемом as3, то проблем быть особо не должно. Загрузка ассетов из swf поддерживается со всеми анимацими. Синтаксически haxe очень близок к as3, есть даже автоматическая конвертилка (хотя руками код допиливать все равно скорее всего придется). Openfl/nme практически полностью воспроизводят flash апи начиная от мувиклипов, масок и graphics.beginFill и заканчивая Stage3D. Компилируется подо все – web, мобилы, десктоп. Консоли тоже, но там с нюансами. По производительности и визуальному качеству намного превосходит ruffle, насколько я могу судить.
Ну в принципе вот так бывает: Motion Twin. Там у них во Франции даже специальная форма юрлица существует для таких затей. Ничего, вроде успешно справляются. Хотя размеры команды конечно ограничены при такой форме.
В указанной строчке поцедура присваивания. Тип переменной – инстанс класса. Тип, возвращаемый парсером – Anonymous Structure, но сигнатура –Dynamic. Тип Dynamic специальный, но для наглядности его можно сравнить с Any в ts, для него не работают проверки типа в момент компиляции, но это не делает значения совместимыми между собой. Если хочется использовать результат работы парсера напрямую, как контейнер данных, то для этого можно использовать typedef.
Ну, например, приватные переменные кое-где начинаются с _, в остальных местах нет. Я даже не про форматирование. В целом, стиль написания очень разношерстный: где-то используются сеттеры, где-то поля, где-то функции-акцессоры. Много неиспользуемого кода.
Не обязательно пенять на иишку, человек тоже может накопипастить что-то со стековерфлоу, конвертировав синтаксис в нужный язык. Проблема с иишкой в том, что такой результат она выдает намного дешевле. От человека действительно требуется понимание и контроль. Так вот, в данном решении всего этого не хватает. Решение здесь неаккуратное и глючное. В прод такое совать нельзя, в основной репо проекта коммитить тоже не стоит. Бизнес готов платить многаденяк за человека, который умеет контролировать иишку, а не за человека, которого самого надо контролировать. А сотни неиспользуемых строк закоммиченных в общий репо могут стоить намного дороже привнесенного решения, создавая дополнительную когнитивную нагрузку на команду.
Без текста тестового сложно что-то оценивать, иногда там бывают важные детали, которые легко пропустить. Иногда команда просто хочет человека, который попадает под "культурный контекст". Задание по косвенным признакам выглядит достаточно объемным, причем требуется выполнить его на определенном языке, поэтому сложно сказать, что именно важнее: понимание языка или, например, знание определенных алгоритмов. В код я разумеется не вчитывался, но конкретно в вашем случае случае могу сделать следующие замечания:
так делать ни в коем случае нельзя с точки зрения языка. Результат работы парсера – анонимная структура, она не совместима с типом класса. Приложение просто падает на этом месте на любом статическом таргете, а на html работает по стечению обстоятельств.
Плавающий кодстайл и значительное количество странного, неиспользуемого кода намекает на значительный вклад аишки. Аишка стоит существенно дешевле программиста на "высокой вилке", а если выход сопоставим, то зачем платить больше?
Чисто визуально клики срабатывают тоже так себе – близко к границам (пикселя 3–4 на глаз может соседний объект удалить...
Проблема в том, что клавиатура - противоестественна.
Так прокачайте под себя. Во-первых, сейчас есть отдельный класс устройств – самодельная механика (не обязательно самому, можно заказать готовую), который обладает двумя важными свойствами:
расположение клавиш можно выбрать какое угодно, сейчас популярны сплиты вообще без функциональных клавиш;
программируемый контроллер, который позволяет настраивать срабатывания как угодно; от использования слоев до тап-данса;
Во-вторых, можно пойти по-лайтовому и взять AHK, попробовать понастраивать всякое:
а Ввод чем хуже
У меня вот, например, вообще на Win+j настроен. Это оказалось настолько естественнее далекой кнопки, что привыкать вообще не пришлось.
Я понял ситуацию ровно наоборот: у них был стек и идея игры, которую (предполагаю) можно было попробовать запустить наивно "в лоб" на текущем стеке. С реактом не работал, но все, что нужно по минимуму: функция-апдейт, которая будет вызываться фиксированное количество раз в секунду (30–60 fps подойдет) и возможность менять координаты десятку png-шек из этой функции. Алгоритм можно было адаптировать из примера по ссылке (первая из поисковика по запросу вывалилась). Если знать, как на текущем стеке делать эти вещи, то адаптация решения для "попробовать" должна занять от силы пару часов. Но это решение командой было отброшено на предварительном обсуждении из-за "тормознутости реакта", а в ход пошли тяжеловесные игровые движки, муки интеграции, билды по 800 мб и прочие ужасы, от которых волосы шевелятся. А кончилось все:
ведь мы так и не довели игру до продакшена.
Если цель была – опробовать технологии для внедрения сложных игр в приложение на реакте, то решение может и оправданное. Если же просто зашипить "флапи берд"...
Может показаться неочевидным, но если речь идет о конкретной ситуации в конкретной компании, то разрабатывать сервис быстрее/дешевле на том языке, который знает разработчик/команда, а не на том, который в тестах гугла набрал больше попугаев. И даже если какой-то инструмент объективно лучше подходил для решения задачи, то для бизнеса может оказаться выгодным выбор того, который знает/любит команда.
Нижняя – тоже неплохая. Но мне она показалась немного скучноватой. А такие детали типа коровы в ванне и елок в горшке – они скорее взрослых развлекут. Мелкие, мне кажется, на такие детали вообще внимания не обращают. Вот например, если бы толпа народу в разных костюмах, позах и со смешными инструментами или там замок с кучей окошек... Ну, короче, типа охотников Брейгеля (и вдохновленной им Дотремер) – вот такие детали мелким пойдут огого.
Среднюю в таком разрешении, конечно, не особо разглядишь, но персонажи все выразительные и "чайлдиш" стиль отлично передан – уверенная рука чувствуется. И компоновка листа тоже весьма профессиональная. Очень наивно полагать, что "рандомный мимокрокодил" или первоклассник сможет сделать что-то похожего уровня.
Да отличные картинки. Вы зачем-то свое чувство прекрасного пытаетесь выдать за объективные характеристики. Мне, например, нижняя картинка меньше всех нравится. То, что вы считаете их уровнем "ученика первого класса" скорее говорит о том, насколько вы в вопросе ориентируетесь.
Что я только что прочитал? В какой среде термин ARPPU используется как синоним среднего чека?
(Просто проверьте в гугле значение термина).
Вы LTV посчитали для платящих и сравниваете с CPI. Что вы тогда под CPI понимаете?
Но разве в статье говорится не о том, что "надуманная" проблема может являться фактором, влияющим на главную – умение воспринимать сложные тексты и формулировать мысли на письме? То есть, когда ребенок учится писать рукой – он "раскачивает мозговую мышцу", которая в будущем, при работе над текстом с клавиатурой, и даст больший резерв для [полезной] нагрузки.
Infiniminer, a block-based open-ended mining game first released in April 2009, inspired Persson's vision for RubyDung's future direction. Ну в википедии же написано даже.
Ну вам же написали, чего именно клон вампиры. Зачем возражать неправильно? Во-первых, разработчик сам в интервью говорил, чем именно вдохновлялся, во-вторых, общего по механикам с crimson land (а много вы еще подобных древних топдауншутеров знаете?) только то, что орды нечести со всех сторон прут.
Кстати, метод "творческой ампутации" – тоже хороший способ придумывать игры. Можно взять одну механику из множества механик большой игры и сделать из нее отдельную игру поменьше.
Как раз по теме статьи – Chasing the Thousand-Hour Game.
Не проверял, но предполагаю, что с vscode-neovim могут быть проблемы, как и вообще с любой интерференцией горячих клавиш.
Также предполагаю, что памяти сэкономится не слишком – основная ее часть все же тратится на прикладной код и пользовательские данные, а не на "браузерное ядро".
С другой стороны, наверно это очень здорово работает с каким-нибудь ультрапортативным устройством, на котором можно использовать всю мощь рабочей машины с десятками и сотнями гб оперативы.
Elisp/emacs – максимально кастомизируемая рабочая среда.
Haxe – непревзойденное покрытие целевых сред и interop-а. Zero-overhead синтаксический слой абстракции над чем угодно – Abstract.
За haxe не стоит никого "с маркетингом", поэтому он не на слуху. Нюансы, разумеется, есть. Но языку 20 лет, готовится к релизу 5 версия. На нем написан ряд весьма успешных проектов, есть компании, работа которых полностью построена на этой технологии. Если называть эту технологию сырой – вылизанных просто не существует.
По функционалу я вообще думаю конкурентов найти сложно. В какой плоскости функционал вас интересует? Могу подсказать.
В самом haxe вообще нет gui – это язык/транспилятор. На нем написан ряд gui фреймворков, каждый из которых может использовать свой подход к кроссплатформенности.
Если говорить про haxeui, то он реализует слой абстракции с переключаемыми бакэндами.
То есть, gui реализованные на haxeui можно запустить поверх: openfl, wxWidget, html, pixi.js, kha.
Можно просто собрать приложение всеми способами и сравнить, какой лучше подходит.
В этом случае сборка с wxWidget будет работать только на десктопе, но все остальные способы можно так или иначе запустить везде. Openfl/nme бэкэнды при этом самые универсальные. Они содержат в себе SDL и графический апи поверх него. Код на haxe в этом случае транспилируется в c++, слинкуется с этими библиотеками и будет рисовать кнопки через openGL на любой платформе с фолбэком в софтверный рендер, никаких внешних доп зависимостей при этом не потянет.
В вашем случае тоже можно посмотреть на вариант из моего комментария выше. Апкшка чистого проекта под 2 архитектуры была около 10 мб, если память не изменяет. Дополнительных зависимостей не тянет, код транспилируется в плюсы и линкуется с библиотекой, построенной вокруг SDL. Для веба просто транспилируется в js. Есть и другие варианты сборки.
А в какой плоскости проект? Кроссплатформу довольно комфортно и на относительно слабом железе можно делать на haxe + openfl. Если приложение чисто UI, то с HaxeUI, если более широкоразвлекательного толка, то с HaxeFlixel, хотя и у самого openfl достаточно богатый апи.
Может, в процессе портирования пятой части втянетесь, а потом на юнити уже не захочется.
Да, как выше упомянули – haxe. Точнее, openfl/nme. Если код на вменяемом as3, то проблем быть особо не должно. Загрузка ассетов из swf поддерживается со всеми анимацими. Синтаксически haxe очень близок к as3, есть даже автоматическая конвертилка (хотя руками код допиливать все равно скорее всего придется).
Openfl/nme практически полностью воспроизводят flash апи начиная от мувиклипов, масок и graphics.beginFill и заканчивая Stage3D.
Компилируется подо все – web, мобилы, десктоп. Консоли тоже, но там с нюансами. По производительности и визуальному качеству намного превосходит ruffle, насколько я могу судить.
Ну в принципе вот так бывает: Motion Twin. Там у них во Франции даже специальная форма юрлица существует для таких затей. Ничего, вроде успешно справляются. Хотя размеры команды конечно ограничены при такой форме.
В указанной строчке поцедура присваивания. Тип переменной – инстанс класса. Тип, возвращаемый парсером – Anonymous Structure, но сигнатура –Dynamic. Тип Dynamic специальный, но для наглядности его можно сравнить с Any в ts, для него не работают проверки типа в момент компиляции, но это не делает значения совместимыми между собой. Если хочется использовать результат работы парсера напрямую, как контейнер данных, то для этого можно использовать typedef.
Ну, например, приватные переменные кое-где начинаются с _, в остальных местах нет. Я даже не про форматирование. В целом, стиль написания очень разношерстный: где-то используются сеттеры, где-то поля, где-то функции-акцессоры. Много неиспользуемого кода.
Не обязательно пенять на иишку, человек тоже может накопипастить что-то со стековерфлоу, конвертировав синтаксис в нужный язык. Проблема с иишкой в том, что такой результат она выдает намного дешевле. От человека действительно требуется понимание и контроль. Так вот, в данном решении всего этого не хватает. Решение здесь неаккуратное и глючное. В прод такое совать нельзя, в основной репо проекта коммитить тоже не стоит. Бизнес готов платить многаденяк за человека, который умеет контролировать иишку, а не за человека, которого самого надо контролировать.
А сотни неиспользуемых строк закоммиченных в общий репо могут стоить намного дороже привнесенного решения, создавая дополнительную когнитивную нагрузку на команду.
Без текста тестового сложно что-то оценивать, иногда там бывают важные детали, которые легко пропустить.
Иногда команда просто хочет человека, который попадает под "культурный контекст".
Задание по косвенным признакам выглядит достаточно объемным, причем требуется выполнить его на определенном языке, поэтому сложно сказать, что именно важнее: понимание языка или, например, знание определенных алгоритмов.
В код я разумеется не вчитывался, но конкретно в вашем случае случае могу сделать следующие замечания:
так делать ни в коем случае нельзя с точки зрения языка. Результат работы парсера – анонимная структура, она не совместима с типом класса. Приложение просто падает на этом месте на любом статическом таргете, а на html работает по стечению обстоятельств.
Плавающий кодстайл и значительное количество странного, неиспользуемого кода намекает на значительный вклад аишки. Аишка стоит существенно дешевле программиста на "высокой вилке", а если выход сопоставим, то зачем платить больше?
Чисто визуально клики срабатывают тоже так себе – близко к границам (пикселя 3–4 на глаз может соседний объект удалить...
Начать можно было просто с evil-mode...
Так прокачайте под себя. Во-первых, сейчас есть отдельный класс устройств – самодельная механика (не обязательно самому, можно заказать готовую), который обладает двумя важными свойствами:
расположение клавиш можно выбрать какое угодно, сейчас популярны сплиты вообще без функциональных клавиш;
программируемый контроллер, который позволяет настраивать срабатывания как угодно; от использования слоев до тап-данса;
Во-вторых, можно пойти по-лайтовому и взять AHK, попробовать понастраивать всякое:
У меня вот, например, вообще на Win+j настроен. Это оказалось настолько естественнее далекой кнопки, что привыкать вообще не пришлось.
Я понял ситуацию ровно наоборот: у них был стек и идея игры, которую (предполагаю) можно было попробовать запустить наивно "в лоб" на текущем стеке. С реактом не работал, но все, что нужно по минимуму: функция-апдейт, которая будет вызываться фиксированное количество раз в секунду (30–60 fps подойдет) и возможность менять координаты десятку png-шек из этой функции. Алгоритм можно было адаптировать из примера по ссылке (первая из поисковика по запросу вывалилась).
Если знать, как на текущем стеке делать эти вещи, то адаптация решения для "попробовать" должна занять от силы пару часов.
Но это решение командой было отброшено на предварительном обсуждении из-за "тормознутости реакта", а в ход пошли тяжеловесные игровые движки, муки интеграции, билды по 800 мб и прочие ужасы, от которых волосы шевелятся.
А кончилось все:
Если цель была – опробовать технологии для внедрения сложных игр в приложение на реакте, то решение может и оправданное. Если же просто зашипить "флапи берд"...
Может показаться неочевидным, но если речь идет о конкретной ситуации в конкретной компании, то разрабатывать сервис быстрее/дешевле на том языке, который знает разработчик/команда, а не на том, который в тестах гугла набрал больше попугаев.
И даже если какой-то инструмент объективно лучше подходил для решения задачи, то для бизнеса может оказаться выгодным выбор того, который знает/любит команда.