Я вот в геймдеве полный ноль. Но мне было бы интересно почитать больше кишок. Были ли какие-то иные варианты распределения процентов вариативности? Другие способы считать, например, что будет если "кубик" бросить один раз: выпало больше 50ти - хлам, иначе если больше 25ти - обычный предмет, иначе если больше 12ти - редкий и так далее. Почему именно такие числа (простое деление на 2), были ли проведены тесты по балансировке?
Я, может, пропустил, это серия статей по игре или Вы просто вырвали интересную для себя единичную тему? Если это первая статья по игре, было бы полезно начать сначала, а не с лута..
Есть ли какие-то иные способы реализаций инвентаризации и генерации предметов на карте, подкрепленные мировой практикой? Если оные отличаются от Вашей реализации, то в чем отличие, превосходство?..
Ну во-первых, как уже говорили выше, в статье нет ни слова по еф. Ликью можно использовать не только для генерации скл-запросов, но и для работы со списками.
По поводу того, почему в продукте не оказалось категории:
Представьте себе ситуацию, когда вы получаете данные с двух систем. Эти системы знать не знают про друг дружку, но в одной из них в записях хранятся внешние ключи на записи из другой системы. И в таком случае, получив списки данных с обоих систем, нужно их сджонить, чтобы дальше осуществить какие-либо действия. Например, чтобы отобразить, если в действие происходит на клиенте, либо отдать в ответе, если это аггрегатор типа gateway
Щачем тогда вообще скоуп тормошить, если, по сути, у тебя один инстанс на все приложение получается. Возми та сделай статик класс. Только это будет все равно говнецо
Очень много тут вижу по делу пишут о недостатках. Сам пва не пользуюсь, интересно, есть ли плюсы, о которых может сказать пользователь, а не сотрудник?
Языковая модель, если судить по этому переводу, довольно ахренительна. Хотя бы потому что у Гугла есть ресурсы на то, чтобы выделить мощный бэк и достаточно данных на обучение, и им удалось реализовать такую систему, которая может качественно отвечать на вопросы и заставлять верить простодушных людей в свою осознанность. Поэтому на счет дрянности с Вами не согласен. На счет несвязности текста тоже не согласен. Но, опять же, это если судить из перевода и того, что "ничего не вырезано, ничего не вставлено".
Я могу быть неправ, но мое мнение об этом всем такое:
Да, логику фильтрации/валидации нужно отделять от процессов обработки
Да, енумы лучше констант инт/стринг, потому что не позволит просто взять и присвоить недопустимое значение (для языков с типизацией: можно, но придется извратиться, для языков без типизации - не знаю, не уверен)
Как всегда, красивая теория над простыми примерами. В жизни все немного (много) сложнее. Код с отложенной реализацей сложнее отлаживать, хоть и проще читать, если не нужно вникать в саму реализацию. Но это, опять же, на простых примерах. На энтерпрайзе у меня пока не было такой практики, при которой условия со свичами были бы переписаны на объектную модель и при этом это и легко читается, и легко дополняется, и легко отлаживается. Это как с тем треугольником консистентности прям.
Каждому языку - своя ниша. Есть c/cpp/asm/rust для этих целей и, мб, еще какие. Здесь же разговор идет о том, как можно было бы написать такой же мощный инструмент как 1С. А выбор языка - дело второе. Ну и к слову, паскаль не так плох, как вы о нем отзываетесь. Я в свое время на нем написал дофига графического софта, пока учился программированию. И в том числе на Лазарусе, когда уже прошел знакомство с мс аксесом, пхп и связкой хтмл+джаваскрипт. На тот момент от паскаля ловил кайф, пока ни познакомился с шарпом.
Как вариант, можно было бы выпустить первую вводную, а потом растянуть на несколько частей, где были бы рассмотрены подробности реализации и использования. В вводной статье можно было бы добавить оглавление со ссылками на следующие статьи. Плюс, последующие главы можно было бы разделить по версиям рассматриваемого фреймворка. А сравнение разных версий вынести в отдельные посты,которые могли бы помочь в миграции на новую версию.
А то вы пишите-пишите, а тут уже 5-ого Net поддержку прекратили и 7 "на подлете"
Поддерживаю. Тоже как-то использовал такой подход. Получается очень компактно не только при передачи по сети, но и при хранении в бд. И работать с таким форматом удобно
Затем блоки операций и ресурсов можно дополнить типом, способом реализации и описанием:
Так ведь в начале Вы пишите:
если наблюдаемое поведение системы останется неизменным, то это будет просто очередная версия всё той же системы. Если же кардинально изменить её взаимодействие с внешним миром, то это будет уже другая система.
В связи с этим я подумал, что как раз-таки описание конкретной реализации не должно быть включено в диаграмму. Максимум - вынесено в заметки. А в примере теперь всего намешано и если менять реализацию, то меняется и схема.
Может, альфа третьей версии?)
Я вот в геймдеве полный ноль. Но мне было бы интересно почитать больше кишок. Были ли какие-то иные варианты распределения процентов вариативности? Другие способы считать, например, что будет если "кубик" бросить один раз: выпало больше 50ти - хлам, иначе если больше 25ти - обычный предмет, иначе если больше 12ти - редкий и так далее. Почему именно такие числа (простое деление на 2), были ли проведены тесты по балансировке?
Я, может, пропустил, это серия статей по игре или Вы просто вырвали интересную для себя единичную тему? Если это первая статья по игре, было бы полезно начать сначала, а не с лута..
Есть ли какие-то иные способы реализаций инвентаризации и генерации предметов на карте, подкрепленные мировой практикой? Если оные отличаются от Вашей реализации, то в чем отличие, превосходство?..
Спасибо
Ну во-первых, как уже говорили выше, в статье нет ни слова по еф. Ликью можно использовать не только для генерации скл-запросов, но и для работы со списками.
По поводу того, почему в продукте не оказалось категории:
Представьте себе ситуацию, когда вы получаете данные с двух систем. Эти системы знать не знают про друг дружку, но в одной из них в записях хранятся внешние ключи на записи из другой системы. И в таком случае, получив списки данных с обоих систем, нужно их сджонить, чтобы дальше осуществить какие-либо действия. Например, чтобы отобразить, если в действие происходит на клиенте, либо отдать в ответе, если это аггрегатор типа gateway
Щачем тогда вообще скоуп тормошить, если, по сути, у тебя один инстанс на все приложение получается. Возми та сделай статик класс. Только это будет все равно говнецо
Очень много тут вижу по делу пишут о недостатках. Сам пва не пользуюсь, интересно, есть ли плюсы, о которых может сказать пользователь, а не сотрудник?
А я думал, что они теперь каждый раз генерят новый краткосрочный/одноразовый qr
Языковая модель, если судить по этому переводу, довольно ахренительна. Хотя бы потому что у Гугла есть ресурсы на то, чтобы выделить мощный бэк и достаточно данных на обучение, и им удалось реализовать такую систему, которая может качественно отвечать на вопросы и заставлять верить простодушных людей в свою осознанность. Поэтому на счет дрянности с Вами не согласен.
На счет несвязности текста тоже не согласен. Но, опять же, это если судить из перевода и того, что "ничего не вырезано, ничего не вставлено".
никто не знает С++ на отлично
Я могу быть неправ, но мое мнение об этом всем такое:
Да, логику фильтрации/валидации нужно отделять от процессов обработки
Да, енумы лучше констант инт/стринг, потому что не позволит просто взять и присвоить недопустимое значение (для языков с типизацией: можно, но придется извратиться, для языков без типизации - не знаю, не уверен)
Как всегда, красивая теория над простыми примерами. В жизни все немного (много) сложнее. Код с отложенной реализацей сложнее отлаживать, хоть и проще читать, если не нужно вникать в саму реализацию. Но это, опять же, на простых примерах. На энтерпрайзе у меня пока не было такой практики, при которой условия со свичами были бы переписаны на объектную модель и при этом это и легко читается, и легко дополняется, и легко отлаживается. Это как с тем треугольником консистентности прям.
Если бы я хотел сделать самый быстрый файловый сервер, я бы его не делал, а пошел искать готовое решение на рынке ))
Каждому языку - своя ниша. Есть c/cpp/asm/rust для этих целей и, мб, еще какие. Здесь же разговор идет о том, как можно было бы написать такой же мощный инструмент как 1С. А выбор языка - дело второе. Ну и к слову, паскаль не так плох, как вы о нем отзываетесь. Я в свое время на нем написал дофига графического софта, пока учился программированию. И в том числе на Лазарусе, когда уже прошел знакомство с мс аксесом, пхп и связкой хтмл+джаваскрипт. На тот момент от паскаля ловил кайф, пока ни познакомился с шарпом.
Что-то я нифига не понял. Начал за одно, закончил совсем другим. Что из второй половины статьи решает проблему, описанную в начале тоже не понял
Круто видеть, что раст выбирают студенты вместо питонов и прочих "простых для изучения"
Привет, спасибо за статью.
Как вариант, можно было бы выпустить первую вводную, а потом растянуть на несколько частей, где были бы рассмотрены подробности реализации и использования. В вводной статье можно было бы добавить оглавление со ссылками на следующие статьи. Плюс, последующие главы можно было бы разделить по версиям рассматриваемого фреймворка. А сравнение разных версий вынести в отдельные посты,которые могли бы помочь в миграции на новую версию.
А то вы пишите-пишите, а тут уже 5-ого Net поддержку прекратили и 7 "на подлете"
Хороший материал, спасибо за литературу.
Хотелось бы видеть практическое исследование с разверткой тестовой среды
Похоже пора менять пароли
³⅖³³33я21в ³32веке 1²
Поддерживаю. Тоже как-то использовал такой подход. Получается очень компактно не только при передачи по сети, но и при хранении в бд. И работать с таким форматом удобно
Так ведь в начале Вы пишите:
В связи с этим я подумал, что как раз-таки описание конкретной реализации не должно быть включено в диаграмму. Максимум - вынесено в заметки. А в примере теперь всего намешано и если менять реализацию, то меняется и схема.
Противоречие получается
Тот самый коммент, который полезней всей статьи