S40 были тоже разные. У меня был Nokia 6300, там был точно 1МБ на весь JAR. Какую-то игру путем подмены PNG-картинок я даже патчил, чтобы влезала в это ограничение. Но на других S40-телефонах, наверное, были другие лимиты.
На самом деле, в "больших" JVM память настолько не фрагментируется - там перемещающие GC, они сдвигают выжившие объекты друг к другу так, что свободное место (в каждом поколении) всегда одним куском.
Подозреваю, что конкретно для мобильных телефонов это могли посчитать расточительным, и сделать, грубо говоря, просто malloc/free.
В дополнение к этому: рекомендуемые расширения можно сохранить в сами исходники проекта (в папке .vscode в корне, аналогично .idea). Тогда при первом открытии проекта будет предложено установить их все одной кнопкой.
Возможно, я просто более оптимистичный геймер :) Просто немного удивляюсь, что мировоззрение статьи настолько похоже на описанный мной собирательный образ.
А ссылки на LinkedIn я, к сожалению, не могу нормально посмотреть, не зарегавшись там.
Спасибо за статью! Очень интересно было взглянуть на внутренний мир автора, который, кажется, совсем перестал играть в игры в начале десятых. И теперь судит всю современную игровую индустрию по тем нескольким высокобюджетным проектам, которые попадают в его инфополе - а "старые времена", конечно же, по лучшим их образцам через розовые очки.
Ниже будут заметки к нескольким из пунктов, которые выглядят как ну уж слишком брюзжание, а не хоть сколько-то взвешенная критика.
Четкие цели
У всех игр (что я играл) где-то до конца 10-х была цель.
Автор пропустил The Sims? Пропустил большинство космических симуляторов? Пропустил "многопользовательские миры" вроде Second Life? Пропустил Garry's Mod, наконец? Все эти, и многие другие "игры без цели" выходили до десятых годов.
На этом безосновательном утверждении автор, насколько я понял, строит каждый свой следующий тезис.
Системный дизайн
Размытие или отсутствие целей в играх, привело к тому, что стало возможным делать игры неполностью, перейти на так называемый несистемный дизайн - это когда вы создаете механики в отрыве друг от друга, и надеетесь, что ближе к релизу оно срастется в одно целое.
Автор несколько странно использует понятие "системного гейм-дизайна". В большинстве остальных публикаций под ним понимают подход к гейм-дизайну, основанный на эмерджентном взаимодействии отдельных более простых игровых систем. Это, во-первых, как раз позволяет частично "создавать механики в отрыве друг от друга" - в том числе, на уровне паттернов кода. А во-вторых, такой подход как раз лучше всего работает в так нелюбимых автором "играх без цели" вроде Minecraft - ведь привлекательность "песочниц", во многом, и построена на том, что в них можно наблюдать сложные взаимодействия простых и относительно понятных правил.
Утверждение "отсутствие системного гейм-дизайна позволяет легче продавать игру по частям" на фоне этого вообще выглядит смешно. В "системную" игру, как раз напротив, весьма легко просто добавить что-то новое, ведь все основные правила уже есть и уже работают! Посмотрите, сколько обновлений уже было у того же Minecraft. Или сколько стоят дополнения к стратегиям Paradox.
Миссии и открытый мир
А про двойное дно и серую мораль с разными концовками в квестах (в квестах, не в игре) и подавно забыли.
Далеко не каждой истории нужно какое-то двойное дно или серая мораль. А агентность игрока, способность его влиять на мир, можно показать многими другими способами, не только разными концовками квестов.
Но взамен мы получили открытый мир и зачистку территорий. (...) десятками однотипных заданий подай-принеси-заруби (...) И так раз за разом, в каждом втором проекте.
Как я уже писал, автор подает почти всю свою критику как "раньше было лучше, а потом все испортили". При этом очень удобно пропускает все то множество игр "той самой" эпохи, которые очень хорошо подходят про это описание.
Уровень врагов
Повсеместно избавляясь от системного дизайна, в плане создания игры как единой целой системы, а не множества мелких с попытками подружить их перед релизом, многие разработчики столкнулись с тем, что приходится убирать систему уровней врагов (...) После "практически идеальной и вылизанной" системы уровней, как игрока так и врагов, в Morrowind, выходит TES4
Автору стоит определиться, это все-таки Minecraft в 2009 году так "испортил" все игры, или же все началось еще с TES4 в 2006?
Сложность
Игры перестали делать сложными, потому что от аудитории нет запроса на такие игры.
И "моду на сложность", начавшуюся еще с выходом Dark Souls, автор, видимо, тоже пропустил.
Как мне кажется, стоит выбирать представление имени в зависимости от способа его использования, которых, грубо говоря, три - и они не обязательно исключают друг друга:
ответ на вопрос "как вас называть?". Это просто непрозрачная строка, опционально - отдельно полный и сокращённый вариант. В идеале, никогда не должен заменяться другими перечисленными вариантами или генерироваться из них. К примеру, не очень хорошо составлять его из паспортных ФИО.
интеграции с другими системами. Тут нужно смотреть, что требует эта система. Государства и документооборот я тоже включаю сюда - к примеру, для РФ это будут три "паспортных" поля: имя, фамилия, и необязательное отчество. А если нужна интеграция с несколькими системами, у которых слишком сильно отличаются ожидания от имен, то нужно несколько вариантов имени - к примеру, для другого государства может потребоваться другой набор полей.
способ отличить одного человека от другого. Это во многих системах работает не очень хорошо - слишком много потенциальных коллизий, к примеру. Но в обиходе используется часто, поэтому для каких-то систем имеет смысл. Это представление будет зависеть, в первую очередь, от ожиданий и желаний пользователей/операторов системы. К примеру, в школьном электронном журнале для этого могут использовать пару "фамилия, имя". Другой пример - в телефонной книжке я ожидаю возможность ввести "Иван дрова", чтобы отличить его от "Иван работа 2" - и при этом ожидаю отдельного поля (или полей) для полных имён этих Иванов.
И, кстати, чисто технически, отчества у Жерара и Стивена всё-таки есть. Даже если они сами об том не знают.
Не очень правильно "изобретать" для человека имя, которого ни в документах нет, ни он сам им не пользуется. Говорить, что у Стивена Сигала есть отчество - все равно, что называть его Степаном.
Как мне кажется, поиск по фамилии - если он вдруг действительно нужен - почти в любой системе лучше как раз заменить поиском через LIKE по полному имени. Это будет более затратно, но более корректно.
Где-то здесь в комментариях, к примеру, уже приводили случай двух фамилий в испанских именах.
Так ведь если мы не знаем, что именно значат first/middle/last, то это получается почти эквивалентно просто одному полю name, разве нет? Просто разделенному на тре части полу-произвольным образом.
А если от этих полей всё-таки есть какие-то ожидания, то лучше их как раз и выразить в названии поля.
Разработчики Wayland посчитали, что съезжающая веб-камера - это уязвимость протокола, поэтому запретили поворачивать монитор на такие углы :)
Но вообще, насколько я понимаю, аналоги xrandr для Wayland специфичны для конкретных композиторов. Вот здесь есть список этих аналогов, можно попробовать что-то из них.
Потому что это просто пример того, как это можно реализовать, написанный автором статьи. В самом Rust он реализован по-другому. Если в двух словах: в случае перечисления элементов, вектор создаётся из boxed slice - то есть, как раз за одну аллокацию нужного размера.
Steam Deck - это портативная консоль вроде Nintendo Switch с поддержкой почти чего угодно :)
Плюс есть нишевые вещи вроде Playdate, которые специально делают ставку, в том числе, на удобство разработки.
S40 были тоже разные. У меня был Nokia 6300, там был точно 1МБ на весь JAR. Какую-то игру путем подмены PNG-картинок я даже патчил, чтобы влезала в это ограничение. Но на других S40-телефонах, наверное, были другие лимиты.
На самом деле, в "больших" JVM память настолько не фрагментируется - там перемещающие GC, они сдвигают выжившие объекты друг к другу так, что свободное место (в каждом поколении) всегда одним куском.
Подозреваю, что конкретно для мобильных телефонов это могли посчитать расточительным, и сделать, грубо говоря, просто malloc/free.
Из первого попавшегося - Nokia 6700 classic
В дополнение к этому: рекомендуемые расширения можно сохранить в сами исходники проекта (в папке .vscode в корне, аналогично .idea). Тогда при первом открытии проекта будет предложено установить их все одной кнопкой.
Возможно, я просто более оптимистичный геймер :) Просто немного удивляюсь, что мировоззрение статьи настолько похоже на описанный мной собирательный образ.
А ссылки на LinkedIn я, к сожалению, не могу нормально посмотреть, не зарегавшись там.
Спасибо за статью! Очень интересно было взглянуть на внутренний мир автора, который, кажется, совсем перестал играть в игры в начале десятых. И теперь судит всю современную игровую индустрию по тем нескольким высокобюджетным проектам, которые попадают в его инфополе - а "старые времена", конечно же, по лучшим их образцам через розовые очки.
Ниже будут заметки к нескольким из пунктов, которые выглядят как ну уж слишком брюзжание, а не хоть сколько-то взвешенная критика.
Автор пропустил The Sims? Пропустил большинство космических симуляторов? Пропустил "многопользовательские миры" вроде Second Life? Пропустил Garry's Mod, наконец? Все эти, и многие другие "игры без цели" выходили до десятых годов.
На этом безосновательном утверждении автор, насколько я понял, строит каждый свой следующий тезис.
Автор несколько странно использует понятие "системного гейм-дизайна". В большинстве остальных публикаций под ним понимают подход к гейм-дизайну, основанный на эмерджентном взаимодействии отдельных более простых игровых систем. Это, во-первых, как раз позволяет частично "создавать механики в отрыве друг от друга" - в том числе, на уровне паттернов кода. А во-вторых, такой подход как раз лучше всего работает в так нелюбимых автором "играх без цели" вроде Minecraft - ведь привлекательность "песочниц", во многом, и построена на том, что в них можно наблюдать сложные взаимодействия простых и относительно понятных правил.
Утверждение "отсутствие системного гейм-дизайна позволяет легче продавать игру по частям" на фоне этого вообще выглядит смешно. В "системную" игру, как раз напротив, весьма легко просто добавить что-то новое, ведь все основные правила уже есть и уже работают! Посмотрите, сколько обновлений уже было у того же Minecraft. Или сколько стоят дополнения к стратегиям Paradox.
Далеко не каждой истории нужно какое-то двойное дно или серая мораль. А агентность игрока, способность его влиять на мир, можно показать многими другими способами, не только разными концовками квестов.
Как я уже писал, автор подает почти всю свою критику как "раньше было лучше, а потом все испортили". При этом очень удобно пропускает все то множество игр "той самой" эпохи, которые очень хорошо подходят про это описание.
Автору стоит определиться, это все-таки Minecraft в 2009 году так "испортил" все игры, или же все началось еще с TES4 в 2006?
И "моду на сложность", начавшуюся еще с выходом Dark Souls, автор, видимо, тоже пропустил.
(кажется, я даже в своем комменте их умудрился перепутать - во втором абзаце говорю про
zx, конечно же)В связи с недавними событиями с
xz, сначала подумал, что гугл выпустил свою совместимую библиотеку сжатия :)А сам
xzвыглядит довольно интересно. Искал что-то подобное раньше, но конкретно на него не натыкался, толькоshelljsзнал из подобных.Так а разве здесь есть какие-то проблемы? Статья, наоборот, описывает, что за счёт этого можно удобно реализовать многие вещи.
Как мне кажется, стоит выбирать представление имени в зависимости от способа его использования, которых, грубо говоря, три - и они не обязательно исключают друг друга:
ответ на вопрос "как вас называть?". Это просто непрозрачная строка, опционально - отдельно полный и сокращённый вариант. В идеале, никогда не должен заменяться другими перечисленными вариантами или генерироваться из них. К примеру, не очень хорошо составлять его из паспортных ФИО.
интеграции с другими системами. Тут нужно смотреть, что требует эта система. Государства и документооборот я тоже включаю сюда - к примеру, для РФ это будут три "паспортных" поля: имя, фамилия, и необязательное отчество. А если нужна интеграция с несколькими системами, у которых слишком сильно отличаются ожидания от имен, то нужно несколько вариантов имени - к примеру, для другого государства может потребоваться другой набор полей.
способ отличить одного человека от другого. Это во многих системах работает не очень хорошо - слишком много потенциальных коллизий, к примеру. Но в обиходе используется часто, поэтому для каких-то систем имеет смысл. Это представление будет зависеть, в первую очередь, от ожиданий и желаний пользователей/операторов системы. К примеру, в школьном электронном журнале для этого могут использовать пару "фамилия, имя". Другой пример - в телефонной книжке я ожидаю возможность ввести "Иван дрова", чтобы отличить его от "Иван работа 2" - и при этом ожидаю отдельного поля (или полей) для полных имён этих Иванов.
Так существование таких апих - часто как раз следствие того параграфа, что вы цитируете :)
Но не спорю с вами в том, что если вдруг жизненно необходимы именно first и last, то лучше явно спросить у пользователя, как дробить его имя.
Не очень правильно "изобретать" для человека имя, которого ни в документах нет, ни он сам им не пользуется. Говорить, что у Стивена Сигала есть отчество - все равно, что называть его Степаном.
Как мне кажется, поиск по фамилии - если он вдруг действительно нужен - почти в любой системе лучше как раз заменить поиском через LIKE по полному имени. Это будет более затратно, но более корректно.
Где-то здесь в комментариях, к примеру, уже приводили случай двух фамилий в испанских именах.
Роли обоих родителей в очень многих, если не в большинстве информационных систем полностью эквивалентны. В отличие от имени и фамилии.
Так ведь если мы не знаем, что именно значат first/middle/last, то это получается почти эквивалентно просто одному полю
name, разве нет? Просто разделенному на тре части полу-произвольным образом.А если от этих полей всё-таки есть какие-то ожидания, то лучше их как раз и выразить в названии поля.
То, что вы описываете, похоже скорее на const fn, которые в Rust тоже есть.
Если кот прям знакомый и прикормленный, то, наверное, лучше всего сработает ошейник с чем-то вроде rfid.
Разработчики Wayland посчитали, что съезжающая веб-камера - это уязвимость протокола, поэтому запретили поворачивать монитор на такие углы :)
Но вообще, насколько я понимаю, аналоги
xrandrдля Wayland специфичны для конкретных композиторов. Вот здесь есть список этих аналогов, можно попробовать что-то из них.Потому что это просто пример того, как это можно реализовать, написанный автором статьи. В самом Rust он реализован по-другому. Если в двух словах: в случае перечисления элементов, вектор создаётся из boxed slice - то есть, как раз за одну аллокацию нужного размера.