Я сейчас читаю «Чистую архитектуру» Роберта Мартина — он бы точно одобрил такой подход.
Во-первых, подход через прототип в первую очередь необходим самим программистам. Отделив конкретную реализацию от базовых механик, мы получаем время на работу с кучей багов и усовершенствований на этом базовом уровне. Они все равно всплывут, поэтому чем раньше программеры сделают рабочий прототип и устранят там баги — тем лучше. Заряжать на прототип программистов нужно как можно раньше.
Во-вторых, отделив базовые механики от конкретных реализаций, мы, как правило, получаем более независимые слои архитектуры. Художники и творцы будут постоянно придумывать что-то и правки в финальный контент будут требоваться постоянно. Поэтому, чтобы эти правки не превращались в мучительные кранчи — надо отделять ядро игры от конкретной реализации.
То есть Роберт Мартин согласился бы с вами, но с обязательным условием — прототип должен быть сделан как достаточно независимый компонент, на который будет легко повесить любую конкретную реализацию. Потому что понятно, что прототип можно развить в финальную игру без всяких архитектурных изысков, просто делая «хардкодную» реализацию того, что увидит игрок, прямо в код прототипа.
В идеале в этом смысле нам нужен не просто прототип — а такой прототип, который будет использовать конкретный набор моделей, спрайтов и правил взаимодействий между ними как легко заменяемые скины (Роберт Мартин употребляет слово «плагины», но для игр привычнее скины ))
Спасибо за статью, но теперь очень хочется увидеть статью про тот самый "дизайн на абстрактных классах в typeScript", чтобы понять, что произошло. В комментариях выше уже обсудили, но непонятно, что имеет в виду автор. Может быть, выложите хотя бы код на Гитхабе, чтобы можно было посмотреть? А лучше статью, чтобы можно было уютно посидеть в комментариях и ознакомиться со взглядами всех экспертов )
списки дел работают не всегда
к примеру, сейчас у меня есть список
проблема в том, что я точно знаю, что не успею сделать сегодня все, что задумал
это убивает мотивацию, не хочется браться даже за первое дело
(задумавшись)
по идее, я могу попробовать разбить дела на еще более мелкие задачи
и попутно внушать себе, что дела в принципе не делаются за сутки
надо попробовать
В каких-то видеинтервью с разработчиками языка я слышал, что у Kotlin есть какие-то особые планы и на разработку игр. Скажите, в этом направлении еще ведутся работы и исследования, или решили пока не идти?
говорят, что Netflix дает сериалы в 4K
качество не проверял, все ли сериалы идут в нем — тоже
но как один из массовых источников интересного контента — известен Netflix
я просто поленился развернуть всю сумму причин. Пожалуй, сейчас, когда я обдумал все, главной является такая причина, что одно дело недокументированный самописный скрипт, а другое — известная документированная система, которую легко расширять. Сейчас я перешел на TypeScript и нормальную систему модулей, так что обратно на самодельный коллектор файлов вряд ли уже перейду, разве что сойду с ума и захочу сделать собственный реализатор модулей и транспайлер с TypeScript впридачу ))
Полгода назад для сборки HTML5-игр у меня был 1 маленький JS-скрипт, который работал очень быстро и занимал всего несколько килобайт. Этого было вполне достаточно.
Летом, для совместимости с Jenkins, перешли на Webpack. Добавилась папка node_modules в сотни тысяч файлов и десятки мегабайт. Скорость сборки вебпаком — дольше в несколько раз. Это уже не говоря о зависимости от Интернета, которая требуется для npm install. Так что я могу понять ситуацию в начале статьи.
Но… совместимость с промышленным стандартом (и другими разработчиками) и системами автоматизированной сборки решает. Так что я могу понять и тех, кто использует webpack даже для ситуаций, которые по сути заключается в копировании файлов и замене текстов (скрипт для ноды пишется меньше чем за сутки, ты получаешь полный контроль над процессом и ультимативную скорость, но привыкшие к webpack смотрят на тебя, как на вомбата ))
Но знаете, мой предыдущий коммент можно даже не читать ))
Дело в том, что можно использовать «пивной аргумент». Он заключается вот в чем — у нас уже есть куча альтернативных коммерческих пивоварен. И хотя некоторые из них стараются, все равно такой стабильности и такого качества пива, как в Чехии и Германии, у нас нет.
Значит, корень проблемы лежит глубже, чем наличие «альтернативных коммерческих перевозчиков»
расскажите, как может работать конкуренция на жд, если два пункта на Транссибе, к примеру, соединены одной линией? И в этом фундаментальное отличие жд сети России от Германии и Чехии, где сеть сделана именно как сеть, а не как одна линия.
Вы понимаете, что людям нужно попасть из пункта А в пункт Б к определенному сроку? Транссибирскость нашей сети убивает конкуренцию по пространству. А желание сэкономить время — убивает конкуренцию по расписанию. Люди в массе не будут выбирать перевозчика с лучшими вагонами — все равно большая часть будет садиться на то, что удобнее по времени.
Здравствуйте, приехали.
Ваш проект я как раз и назвал полноценным опен-сорсным генератором.
Под поделкой подразумевается то, что каждый начинающий программист может написать за 1-2 дня.
collectFiles(srzPath).forEach(fillPatternAndCopyToOut) — примерный алгоритм такой поделки на любом языке.
Вопрос стоял так — вот я пишу такое за 1 день, если не беру предыдущий генератор. Зачем мне нужно тратить 1 день на изучение чужих генераторов? Что в них такого? Поддержка фреймворков? Это закладывается на уровне шаблона?
Удачи вам в вашем проекте в любом случае. Я может неясно выразился, но никогда не спешите принимать мутные слова именно на свой счет. Я не хотел вас обидеть и никак не оценивал ваше детище.
Уважаю людей, которые делают полноценные open-source проекты и понимаю, что полноценный генератор статических сайтов — это большой и удобный инструмент.
Но… разве ни разу в голове ни у кого не мелькнула мысль, что рекурсивно обойти дерево исходников и запихать их в размеченный шаблон в указанной папке — это даже для начинающего программиста задача на 1, ну максимум, 2 дня.
Нужно больше информации, чем статические генераторы лучше таких быстрых наколенных поделок. При том, что такие поделки можно лепить на любом удобном для тебя языке, который (если ты программер), уже стоит на твоей системе, и не нужно ставить ноду (это уже не мой случай, нода стоит, но N лет назад не стояла и я делал для таких случаев генераторы на PHP или дажe Java)
Можете ответить, какой функционал в статическом генераторе явно превосходит то, что я описал, его киллер, а точнее — seller-функции? :)
по моему опыту — в любой компании всегда есть пакет задач, в которых нужно поправить запятую, поменять цвет кнопки, исправить опечатки
как минимум один джун мог бы на этом сидеть, пока старшие решают хорошие проблемы
Ну и можно давать джуну время от времени настоящие задачи — чтобы рос
исходя из этого, можно сказать, что это архитектура с нарушением инверсии зависимости
Во-первых, подход через прототип в первую очередь необходим самим программистам. Отделив конкретную реализацию от базовых механик, мы получаем время на работу с кучей багов и усовершенствований на этом базовом уровне. Они все равно всплывут, поэтому чем раньше программеры сделают рабочий прототип и устранят там баги — тем лучше. Заряжать на прототип программистов нужно как можно раньше.
Во-вторых, отделив базовые механики от конкретных реализаций, мы, как правило, получаем более независимые слои архитектуры. Художники и творцы будут постоянно придумывать что-то и правки в финальный контент будут требоваться постоянно. Поэтому, чтобы эти правки не превращались в мучительные кранчи — надо отделять ядро игры от конкретной реализации.
То есть Роберт Мартин согласился бы с вами, но с обязательным условием — прототип должен быть сделан как достаточно независимый компонент, на который будет легко повесить любую конкретную реализацию. Потому что понятно, что прототип можно развить в финальную игру без всяких архитектурных изысков, просто делая «хардкодную» реализацию того, что увидит игрок, прямо в код прототипа.
В идеале в этом смысле нам нужен не просто прототип — а такой прототип, который будет использовать конкретный набор моделей, спрайтов и правил взаимодействий между ними как легко заменяемые скины (Роберт Мартин употребляет слово «плагины», но для игр привычнее скины ))
к примеру, сейчас у меня есть список
проблема в том, что я точно знаю, что не успею сделать сегодня все, что задумал
это убивает мотивацию, не хочется браться даже за первое дело
(задумавшись)
по идее, я могу попробовать разбить дела на еще более мелкие задачи
и попутно внушать себе, что дела в принципе не делаются за сутки
надо попробовать
lua.vm.js
ну все, держите меня семеро!
качество не проверял, все ли сериалы идут в нем — тоже
но как один из массовых источников интересного контента — известен Netflix
возможно, вы спасли мне не один вечер в будущем
Полгода назад для сборки HTML5-игр у меня был 1 маленький JS-скрипт, который работал очень быстро и занимал всего несколько килобайт. Этого было вполне достаточно.
Летом, для совместимости с Jenkins, перешли на Webpack. Добавилась папка node_modules в сотни тысяч файлов и десятки мегабайт. Скорость сборки вебпаком — дольше в несколько раз. Это уже не говоря о зависимости от Интернета, которая требуется для npm install. Так что я могу понять ситуацию в начале статьи.
Но… совместимость с промышленным стандартом (и другими разработчиками) и системами автоматизированной сборки решает. Так что я могу понять и тех, кто использует webpack даже для ситуаций, которые по сути заключается в копировании файлов и замене текстов (скрипт для ноды пишется меньше чем за сутки, ты получаешь полный контроль над процессом и ультимативную скорость, но привыкшие к webpack смотрят на тебя, как на вомбата ))
Дело в том, что можно использовать «пивной аргумент». Он заключается вот в чем — у нас уже есть куча альтернативных коммерческих пивоварен. И хотя некоторые из них стараются, все равно такой стабильности и такого качества пива, как в Чехии и Германии, у нас нет.
Значит, корень проблемы лежит глубже, чем наличие «альтернативных коммерческих перевозчиков»
Вы понимаете, что людям нужно попасть из пункта А в пункт Б к определенному сроку? Транссибирскость нашей сети убивает конкуренцию по пространству. А желание сэкономить время — убивает конкуренцию по расписанию. Люди в массе не будут выбирать перевозчика с лучшими вагонами — все равно большая часть будет садиться на то, что удобнее по времени.
Ваш проект я как раз и назвал полноценным опен-сорсным генератором.
Под поделкой подразумевается то, что каждый начинающий программист может написать за 1-2 дня.
collectFiles(srzPath).forEach(fillPatternAndCopyToOut) — примерный алгоритм такой поделки на любом языке.
Вопрос стоял так — вот я пишу такое за 1 день, если не беру предыдущий генератор. Зачем мне нужно тратить 1 день на изучение чужих генераторов? Что в них такого? Поддержка фреймворков? Это закладывается на уровне шаблона?
Удачи вам в вашем проекте в любом случае. Я может неясно выразился, но никогда не спешите принимать мутные слова именно на свой счет. Я не хотел вас обидеть и никак не оценивал ваше детище.
Но… разве ни разу в голове ни у кого не мелькнула мысль, что рекурсивно обойти дерево исходников и запихать их в размеченный шаблон в указанной папке — это даже для начинающего программиста задача на 1, ну максимум, 2 дня.
Нужно больше информации, чем статические генераторы лучше таких быстрых наколенных поделок. При том, что такие поделки можно лепить на любом удобном для тебя языке, который (если ты программер), уже стоит на твоей системе, и не нужно ставить ноду (это уже не мой случай, нода стоит, но N лет назад не стояла и я делал для таких случаев генераторы на PHP или дажe Java)
Можете ответить, какой функционал в статическом генераторе явно превосходит то, что я описал, его киллер, а точнее — seller-функции? :)
как минимум один джун мог бы на этом сидеть, пока старшие решают хорошие проблемы
Ну и можно давать джуну время от времени настоящие задачи — чтобы рос