Это как-то сложно, у многих людей из очереди скорее всего есть мобильные телефоны и их можно использовать для определения местоположения и оценки очереди в пределах действия wifi роутеров например. О существовании очереди можно будет догадаться по характеру движения телефона, даже если он один в очереди. Я конечно так себе как искусственный интеллект, но думаю что есть масса других косвенных показателей наличия очереди и любая аномалия может быть проверена "контрольным посетителем", а лучше несколькими независимыми :)
Увы, сейчас конкретная реализация BSP в Doom и Doom2 не выглядит особо логичной для графики, поскольку развитие видеокарт ушло в сторону прорисовки треугольников.
Из-за этого современные порты добавляют к картам дополнительные предварительно рассчитанные блоки GL_VERT, GL_SEGS, GL_SSECT, GL_NODES и GL_PVS, делая алгоритм прорисовки более похожим на Quake, нежели на оригинальный Doom.
Так произошло из-за специфики прорисовки пола / потолка и VSD — оригинальный Doom не задумывался какой они формы, поскольку для него это всего-лишь область экрана, которую нужно «залить» текстурой пола или потолка, проецированной на нужном уровне. Однако для того, чтобы нарисовать пол или потолок в том же OpenGL, его надо сначала разбить на треугольники, это уже не «заливка» плоской фигуры на экране, а реальная поверхность в 3Д.
Проблема с VSD заключается в том, что видимые поверхности определялись для каждого столбца, гуляя по BSP дереву (правда далеко зайти не разрешали) пока столбец не заполнится. Однако для полного 3Д, где можно крутить камерой — это не годилось. Нормального оcclusion query ещё не было, поэтому утащили PVS из Quake.
Учитывая эти доработки напильником в современных портах Doom, решение было классным для рендерера тех времён, но сейчас бы так скорее всего не делали.
Наверное хотели сказать не активна, однако в моём представлении Idle игра должна «продолжаться» даже когда компьютер вообще выключен.
В самом простом случае это просто сохранённое время, например в localStorage. При загрузке игры она мгновенно «проматывается» исходя из разницы во времени, а для этого endOfTurnCalc нужно переписать с учётом что пройдёт намного больше одного «хода».
Сохранение игры тоже можно сделать автоматическое, на каком-нибудь window.onbeforeunload
P.S. Я не против авторского подхода, тем более что ни одной Idle игры я не выпустил, просто принцип работы представлял несколько иначе.
Почему-то считал что Idle игры обязательно должны быть завязаны на реальном времени. Что игру можно забросить на день, потом вечерком выбрать апгрейдов и опять оставить на сутки. А setInterval это как-то слишком жёстко для жанра на мой взгляд — держать вкладку активной!?
Статья так и не отвечает на поставленный в заголовке вопрос «усложненность архитектуры».
Вместо этого уводит в сторону производственного конвейера, типа он «сложный», потому что у нас куча анализаторов кода, CI, всё покрыто тестами и код-ревью.
В моём понимании архитектура вообще не об инструментах и процессах. При абсолютно тех же производственных процессах и инструментах архитектура приложения может быть как простой, логичной и понятной, так и нет.
архитектура вторична, первичны результат и процесс разработки
Результат непосредственно зависит от архитектуры, а разработка по сути стандартна — там ничего «архитектурного» нету, это лишь набор процессов и инструментов.
P.S. Проект организации строительства монолитных зданий примерно одинаков как для безвкусной бетонной коробки, так и для памятника архитектуры.
Кстати это объясняет зачем «одноразовую» и безымянную лямбду записали в переменную с именем :). На мой взгляд def выглядел бы уместнее, пусть даже и на строку больше.
Кроме спискового включения (list comprehension) есть ещё set и dict comprehension,
a = {x for x in 'abracadabra' if x not in 'abc'}
b = {x: x**2 for x in (2, 4, 6)}
(можно добавить в 1).
А также выражение генератор, которое от спискового включения отличается круглыми скобками вместо квадратных (можно добавить в 4).
На практике ещё работает производный от 3го вариант.
Поскольку в это время была большая очередь, то «Самые умные» в это время не пойдут, а раз их там не будет, то и очереди тоже :)
Ну это по сути что mipmap нет, и при уменьшении текстура может пестрить.
Я имел ввиду честный NEAREST_MIPMAP_NEAREST, поскольку в статье приводится код Python для генерации палитровой текстуры, то там же можно было генерировать ещё и все mipmap т.к. стандартный generateMipmap для этого не подходит.
Как-то пропустили что текстура должна читаться без интерполяции выбирая ближайшего соседа, да и тема генерации mipmap для палитровых текстур не раскрыта.
Кроме первого пункта «Поддержка ICU грамматики», парсер которой скрыт в недрах @eo-locale/core, и в npm ссылки на гитхаб нету, остальное есть в стандартном Intl (ну и коленка + 10 минут комментатора ниже :) ).
Я не понимаю почему это важно, поскольку мне не известны профессиональные CAT утилиты, нормально обрабатывающие ICU формат. Ни SDL Trados, ни MemoQ этим похвастаться не могут, колупаться среди непереводимых select и plural не приносит переводчикам радости. В теории ICU форматтер это круто и гибко, но на практике несколько простых текстов для plural или select без разметки переводить проще и быстрее.
Пока переводчик это коллега — программист и текстов мало — всё хорошо. Когда проект станет больше, например, несколько десятков тысяч слов которые нужно будет переводить на десятки языков работа с ICU грамматикой будет источником проблем.
В Python есть аннотация типов, а также механизмы приведения и проверки. Да, это не особо удобно или красиво, но почему «не даёт возможности» тестирования?
Возможности же есть!
Я думаю стоит ещё учитывать что ж/д вокзалы часто находятся ближе к центру города, в то время как до аэропорта нужно ещё добираться, приезжать на регистрацию заранее, ждать багаж.
Прокатившись на «Невском экспрессе» задумался что хоть самолёт и быстрее(дешевле?), но поезд всё-же удобнее. Экологичность тут не на первом месте, но если бы поезд шёл 2 часа вместо 4х, то самолёт по сути и не нужен для таких поездок.
Не нужно осознанно разрушать рабочий бизнес — это бред. Развивать какие-то новые направления это да. Если они хорошо себя покажут, то основной бизнес пойдет туда, а старые направления органично сдохнут сами. А если нет, то хоть не останешься у разбитого корыта.
А почему нельзя просто загрузить всё минимального качества, а потом постепенно догружать и заменять картинки?
У меня например под wifi скорость пляшет. Получается что если мне повезло — то я попал на полноценные картинки, а если нет то застрял с низким качеством?
Это как-то сложно, у многих людей из очереди скорее всего есть мобильные телефоны и их можно использовать для определения местоположения и оценки очереди в пределах действия wifi роутеров например. О существовании очереди можно будет догадаться по характеру движения телефона, даже если он один в очереди. Я конечно так себе как искусственный интеллект, но думаю что есть масса других косвенных показателей наличия очереди и любая аномалия может быть проверена "контрольным посетителем", а лучше несколькими независимыми :)
Из-за этого современные порты добавляют к картам дополнительные предварительно рассчитанные блоки GL_VERT, GL_SEGS, GL_SSECT, GL_NODES и GL_PVS, делая алгоритм прорисовки более похожим на Quake, нежели на оригинальный Doom.
Так произошло из-за специфики прорисовки пола / потолка и VSD — оригинальный Doom не задумывался какой они формы, поскольку для него это всего-лишь область экрана, которую нужно «залить» текстурой пола или потолка, проецированной на нужном уровне. Однако для того, чтобы нарисовать пол или потолок в том же OpenGL, его надо сначала разбить на треугольники, это уже не «заливка» плоской фигуры на экране, а реальная поверхность в 3Д.
Проблема с VSD заключается в том, что видимые поверхности определялись для каждого столбца, гуляя по BSP дереву (правда далеко зайти не разрешали) пока столбец не заполнится. Однако для полного 3Д, где можно крутить камерой — это не годилось. Нормального оcclusion query ещё не было, поэтому утащили PVS из Quake.
Учитывая эти доработки напильником в современных портах Doom, решение было классным для рендерера тех времён, но сейчас бы так скорее всего не делали.
Наверное хотели сказать не активна, однако в моём представлении Idle игра должна «продолжаться» даже когда компьютер вообще выключен.
В самом простом случае это просто сохранённое время, например в localStorage. При загрузке игры она мгновенно «проматывается» исходя из разницы во времени, а для этого endOfTurnCalc нужно переписать с учётом что пройдёт намного больше одного «хода».
Сохранение игры тоже можно сделать автоматическое, на каком-нибудь window.onbeforeunload
P.S. Я не против авторского подхода, тем более что ни одной Idle игры я не выпустил, просто принцип работы представлял несколько иначе.
Вместо этого уводит в сторону производственного конвейера, типа он «сложный», потому что у нас куча анализаторов кода, CI, всё покрыто тестами и код-ревью.
В моём понимании архитектура вообще не об инструментах и процессах. При абсолютно тех же производственных процессах и инструментах архитектура приложения может быть как простой, логичной и понятной, так и нет.
Результат непосредственно зависит от архитектуры, а разработка по сути стандартна — там ничего «архитектурного» нету, это лишь набор процессов и инструментов.
P.S. Проект организации строительства монолитных зданий примерно одинаков как для безвкусной бетонной коробки, так и для памятника архитектуры.
(можно добавить в 1).
А также выражение генератор, которое от спискового включения отличается круглыми скобками вместо квадратных (можно добавить в 4).
Поскольку в это время была большая очередь, то «Самые умные» в это время не пойдут, а раз их там не будет, то и очереди тоже :)
Ну это по сути что mipmap нет, и при уменьшении текстура может пестрить.
Я имел ввиду честный NEAREST_MIPMAP_NEAREST, поскольку в статье приводится код Python для генерации палитровой текстуры, то там же можно было генерировать ещё и все mipmap т.к. стандартный generateMipmap для этого не подходит.
Старый вариант, который был просто «No.» только лаконично отвечал на поставленный вопрос.
Ещё можно было написать более явно:
Как-то пропустили что текстура должна читаться без интерполяции выбирая ближайшего соседа, да и тема генерации mipmap для палитровых текстур не раскрыта.
Кроме первого пункта «Поддержка ICU грамматики», парсер которой скрыт в недрах @eo-locale/core, и в npm ссылки на гитхаб нету, остальное есть в стандартном Intl (ну и коленка + 10 минут комментатора ниже :) ).
Я не понимаю почему это важно, поскольку мне не известны профессиональные CAT утилиты, нормально обрабатывающие ICU формат. Ни SDL Trados, ни MemoQ этим похвастаться не могут, колупаться среди непереводимых select и plural не приносит переводчикам радости. В теории ICU форматтер это круто и гибко, но на практике несколько простых текстов для plural или select без разметки переводить проще и быстрее.
Пока переводчик это коллега — программист и текстов мало — всё хорошо. Когда проект станет больше, например, несколько десятков тысяч слов которые нужно будет переводить на десятки языков работа с ICU грамматикой будет источником проблем.
Если именно «под разные», то это интернационализация. Локализация всегда под конкретный язык/культуру.
Скорее текущую локаль (Язык+регион) — форматы даты/времени зависят не только от языка, а ещё и от региона.
Возможности же есть!
Прокатившись на «Невском экспрессе» задумался что хоть самолёт и быстрее(дешевле?), но поезд всё-же удобнее. Экологичность тут не на первом месте, но если бы поезд шёл 2 часа вместо 4х, то самолёт по сути и не нужен для таких поездок.
Choice, draw, ничего, ничьих.
Не нужно осознанно разрушать рабочий бизнес — это бред. Развивать какие-то новые направления это да. Если они хорошо себя покажут, то основной бизнес пойдет туда, а старые направления органично сдохнут сами. А если нет, то хоть не останешься у разбитого корыта.
А почему нельзя просто загрузить всё минимального качества, а потом постепенно догружать и заменять картинки?
У меня например под wifi скорость пляшет. Получается что если мне повезло — то я попал на полноценные картинки, а если нет то застрял с низким качеством?