Неплохо было бы, чтобы такие книги существовали и для начинающих, но эту идею тяжело воплотить в жизнь
Для начинающих есть English by the Nature Method (по другим языкам тоже есть). Поскольку в начале все слова простые, их можно понять просто из контекста, поэтому дополнительных пояснений и перевода не требуется.
Возможно, суть даже не в эмоциональной привязанности, а в том, что физическая усталость очевидна, ее легко определить и сложно преодолеть без отдыха, а усталость мозга можно спутать с ленью и, преодолевая, исчерпать все резервы. И заказчику не всякому объяснишь, т.к. он, может, и не доходил никогда до такого уровня сосредоточения растянутого во времени.
В разработке постоянно нужно думать. А когда на пару часов перестаешь и делаешь на автомате, все начинает идти под откос, и тогда эффективнее вообще ничего не делать. (По крайней мере меньше убытков, чем написать Г-код и потом с ним мучиться, пока не выкинешь.) В этом основное отличие работы программиста, от крановщика и других профессий. Крановщик может успешно работать и на автомате, не думая.
Выгорание же начинается тогда, когда нужно работать, когда устал и котелок не варит. Работа через силу, без огонька для программиста подобна смерти.
Не вижу, как связаны универсальность кода и версия языка. И без фреймворка при изменении языка придется менять и логику, и код для графики. Только с фреймворком это можно сделать один раз для всех игр, а без "универсальности" — для каждой игры отдельно.
Код — зло. Чем меньше кода, тем лучше. Минимум кода при поточном производстве — это когда все в библиотеках.
Около 10 лет разрабатывал игры на ActionScript, начиная еще с Flash 4 и до самого конца (потом перешел на Haxe и бэкенд, теперь еще на TypeScript). Делал игры и приложения для порталов, образования, потом — социальных сетей. Данный подход применялся на протяжении всего этого времени постепенно, по мере своего формирования. Например, игру PerfectPoker (facebook) я переписывал с AS1 на AS3 около двух месяцев, а вот уже последующие аналогичные приложения занимали 1-2 недели — большая часть времени уходила на адаптирование новой графики. Выигрыш в 4 раза, хотя там вводилась только концепция слоев и повторного использования компонентов.
Позже применял тот же подход на играх 3-в-ряд (ButtonMix, DreamlikeMix и другие). Так, если разработка игры по разным причинам могла затягиваться на несколько лет, то уже после частичного внедрения фреймворка игры начали делаться за полгода. При этом сразу делались и веб- и мобильные версии (Adobe AIR). Все, чем отличались платформы, выносилось в отдельные подслои, поэтому путаницы не было.
В то время вся концепция еще только формировалась. До многих идей я дошел только в этом году и еще не успел их опробовать как следует в деле. Хотя пока не вижу особых проблем, почему бы их нельзя было воплотить. Да, некоторые вещи влекут за собой дополнительные сложности или просто непривычны. Но все это с лихвой компенсируется выгодами, которые они дают.
Хорошо, а если вас попросят сделать пролет камеры под столом с возможностью вытащить карту из штанов соперника, а туда закинуть файербол. Или написать карточкую игру a-ля Hearthstone. Для этих случаев ваш двухнедельный модуль тоже подойдет?
Большинство игр реализуется достаточно стандартно, без пролета камеры из штанов соперников. Стандартным играм — стандартное решение. И для Hearthstone обычный карточный модуль вполне подойдет. Его придется только расширить новыми анимациями, партиклами и лэйаутами. В остальном там все так же перемещаются карты.
Конечно, фреймворк не подойдет разработчикам AAA-игр: они пишутся на уже развитых движках, вроде UnrealEngine, и вся разработка отталкивается от особенностей этих движков. Но большинства онлайн-игр использование таких монстров избыточно. И для не существует каких-либо универсальных архитектурных решений, которые были бы признаны стандартом. Каждый пишет как может. Я лишь попытался создать такой стандарт для себя, для более комфортной работы "майселфа".
Свою точку зрения не навязываю и не пытаюсь кого-то переубедить. Скорее ищу единомышленников и тех, кому это также интересно. Хотя и критику тоже очень приветствую.
Именно для этого и вводится разделение кода на слои. Например, слой логики никак не зависит от платформы, а только от самого языка. Поэтому если логика полностью отделена от отображения, то у нас уже появляется целый пласт платформонезависимого кода. От конкретной графической библиотеки зависит только ряд компонентов из логики отображения. (И то не все -- есть компоненты, которые оперируют только другими компонентами.) В результате весь платформозависимый код находится только в определенных слоях, реализации которых можно легко заменять другими.
Если разделение на слои соблюдается неукоснительно и бескомпромиссно, то код "протухать" не будет.
С++ я не беру в расчет -- это особый случай, просто его нельзя не упомянуть тут.
Спасибо за C#, забыл добавить.
В статье просто накиданы разнородные Best Practices без конкретных условий когда их стоит применять
Так и есть. Это статья -- подведение итогов серии статей про написание фреймворка. Большинство практик там не только раскрываются, но и выводятся теоретически -- с эволюционной точки зрения.
И да, это "тупо теория" (что плохого в теории?), некий идеал, который если внедрить хотя бы частично, сильно упрощает жизнь.
По примерам:
1) Код в библиотеках реализует только существенные стороны функционала, без которых он не был бы тем, чем является. И делает это в максимально простом и универсальном виде так, чтобы он подходил для любых случаев. Так логика отображения для игр 3-в-ряд состоит только из расположения и перемещения клеток и камней на игровом поле. Способ расположения или скорость перемещения можно изменить в конфигах, а добавить более сложную логику или изменить анимацию можно в подклассах. Задача программиста в том и состоит, чтобы уметь обобщить все возможные фантазии гейм-дизайнеров в одном простом решении.
2) Спорно. Если сделать качественное разделение функционала на модули, всегда будешь знать, где что выполняется.
3) Почему нет? На игровом столе размещаем метки для колоды, отбоя, выложенных на стол карт и карт на руках каждого игрока. Каждая метка (пустой контейнер) имеет свой размер и угол поворота, которые выставляет художник. Вся остальная логика -- это всего лишь добавление, удаление и перемещение карт от одной метки к другой. Еще нужно располагать карты в линию, веером, стопкой или кучкой внутри метки (настраивается в конфигах). Из команд достаточно обрабатывать add, remove, move, change (чтобы показывать/скрывать лицо карты). Если рука набита, две недели за глаза. (Включу данный пример в текст для ясности.)
Речь идет только о модуле отображения. Контроллер с правилами для каждой игры разный.
Было бы интересно узнать и по другим примерам, чем статья прям так плоха. Внесу пояснения. Что не ясно для одного, не ясно и для многих других.
Тут основная идея в том, что стоимость продукта всегда определяется средними затратами труда на данном рынке. Если ты нашел способ сделать дешевле, то средние затраты не уменьшаются, и ты можешь продавать по той же цене, получая дополнительную прибыль за счет уменьшения издержек.
Например, если взять случай, когда расходы больше прибыли в 2 раза: В1 = П1 + Р1 = П + 2 * П, и мы уменьшаем их в те же 2 раза, то при равенстве выручек все деньги перетекают в прибыль: В2 = П2 + Р2 = 2 * П + П.
Хотя формулировка у меня в тексте не очень точная, согласен -- решил не перегружать его оговорками. Классики ни при чем.
В данной редакции выпало... Но из текста это прямо вытекает. Если в компании есть хотя бы 3 проекта по 4 разработчика -- по одному для каждой платформы,-- то уже на этапе использования одного кросс-платформенного ЯП, мы можем оставить по одному. Это уже минус 9. А если проекты -- продолжение предыдущих, из которых были сделаны движки, тобольше одного разраба и не нужно.
И все же я не знаю ни одной компании, где бы это было реализовано, хотя, кажется, все лежит на поверхности. Данная статья -- это скорее способ узнать -- почему, что я упускаю.
Создается впечатление, что есть только два типа личности по тому, как они решают это вопрос. На самом деле, думаю, правильнее было бы начать с: "На определенном этапе психического развития человека...". Потому что вряд ли можно какого-нибудь Будду и других причислить к данным категориям. Иначе с такой философией только в петлю.
Хотя я допускаю, что большинство людей так и живет. А большинство структурирует вокруг себя то, что обычно называют "системой", которая заставляет и остальных действовать так же. Поэтому и может возникнуть соблазн сделать обобщение, что так живут все.
Разделение на т.н. психотиков (откуда этот термин?) и невротиков больше похоже на знание из древнеримского культа Двуликого Януса. Согласно нему у обычного человека нет определенного постоянного характера, а он ведет себя тем или иным образом в зависимости от того, кто рядом с ним находится, какую роль он сумел занять. Например, скверный начальник может продавить своего подчиненного и за счет этого улучшить себе настроение и поднять тонус. Но подчиненный, приходя домой, сам занимает позицию начальника и, чтобы скомпенсировать потерю энергии, ругает жену. Жена поднимает себе настроение за счет более слабого ребенка, а тот отрывается на домашних животных, если есть. (Не потому ли в детстве многим так хочется собаку?) Ребенок с детства привыкает воспринимать такую схему как норму и воспроизводит ее в следующем поколении. Так и живем. Каждый слой повыше вампирит на тех, кого может запихнуть в слой пониже.
Кстати, в Древнем Риме солдат, идущих на войну, проводили через ворота храма Януса (вероятно, чтобы некоторые из них задумались, а зачем, и какое знание стоит за этим культом). И закономерно возникает вопрос, не в этом ли главная составляющая непобедимости римской армии? А еще Юлий Цезарь, когда он изменял календарь, назвал первый месяц каждого года Януарием, как раз в честь бога Януса. Если предположить, что и тогда начало нового года ассоциировалось с началом новой жизни, то можно заключить, что по мнению Цезаря новая жизнь должна начинаться с понимания принципа Двуликого Януса. Иначе ребенку с картинки выше так и не выйти из "системы". (У кота заранее никаких шансов нет, его жалко больше всех.)
ПС. Статью не мешало бы хотя бы один раз перечитать и отредактировать, иначе приходится читателям самим перечитывать по нескольку раз, чтобы понять некоторые места.
ППС. Подробнее про Двуликого Януса см. Меняйлова. Хотя многие не выдерживают его "радикальной честности", но на хабре, вроде, слабаков нету).
То есть, никакого спонтанного действия в игре не происходит и не может произойти. Все определено наперед. Это касается всех диалогов, чередований событий, предательства со стороны близких друзей (что просто бесит и надоедает при повторном прохождении игры), якобы «внезапной» пропажи вещей из кармана (наступил четверг, за окном дождь, а я ОПЯТЬ потеряла ключи от машины) и т.д.
Прямо, как в книге. И кто только читает эти книги?!
Я искренне считаю, что Веб-Агентство приложило все усилия при работе над моим проектом. Мне не кажется, что меня пытались обмануть или стрясти побольше денег.
И все же они вас обманывали, чтобы стрясти побольше денег. Ох, и плуты.
Спасибо за честный рассказ! Многое становится понятным в работе агентств.
Я думаю, что в наличии большого тех. долга виноват менеджер полностью.
Да, вот только от этого не легче. Мучиться с кодом все равно нам. Поэтому тут и подводится к мысли о необходимости искать решение проблемы своими силами, не надеясь на хороших менеджеров (все равно их не найдешь).
А решение в создании фреймворка и методологии, которые позволят делать и качественно, и дешево (по крайней мере для самого программиста), и быстро. По крайней мере для одной предметной области, в данном случае -- разработке игр.
Построение велосипедов -- это прежде всего лучший способ самообучения и развития в профессии. Но в работе тоже помогает.
Для начинающих есть English by the Nature Method (по другим языкам тоже есть). Поскольку в начале все слова простые, их можно понять просто из контекста, поэтому дополнительных пояснений и перевода не требуется.
Возможно, суть даже не в эмоциональной привязанности, а в том, что физическая усталость очевидна, ее легко определить и сложно преодолеть без отдыха, а усталость мозга можно спутать с ленью и, преодолевая, исчерпать все резервы. И заказчику не всякому объяснишь, т.к. он, может, и не доходил никогда до такого уровня сосредоточения растянутого во времени.
Все, кому на работе нужно выкладываться, считают свою работу особенной. Иначе какой смысл выкладываться?
В разработке постоянно нужно думать. А когда на пару часов перестаешь и делаешь на автомате, все начинает идти под откос, и тогда эффективнее вообще ничего не делать. (По крайней мере меньше убытков, чем написать Г-код и потом с ним мучиться, пока не выкинешь.) В этом основное отличие работы программиста, от крановщика и других профессий. Крановщик может успешно работать и на автомате, не думая.
Выгорание же начинается тогда, когда нужно работать, когда устал и котелок не варит. Работа через силу, без огонька для программиста подобна смерти.
Не вижу, как связаны универсальность кода и версия языка. И без фреймворка при изменении языка придется менять и логику, и код для графики. Только с фреймворком это можно сделать один раз для всех игр, а без "универсальности" — для каждой игры отдельно.
Код — зло. Чем меньше кода, тем лучше. Минимум кода при поточном производстве — это когда все в библиотеках.
Около 10 лет разрабатывал игры на ActionScript, начиная еще с Flash 4 и до самого конца (потом перешел на Haxe и бэкенд, теперь еще на TypeScript). Делал игры и приложения для порталов, образования, потом — социальных сетей. Данный подход применялся на протяжении всего этого времени постепенно, по мере своего формирования. Например, игру PerfectPoker (facebook) я переписывал с AS1 на AS3 около двух месяцев, а вот уже последующие аналогичные приложения занимали 1-2 недели — большая часть времени уходила на адаптирование новой графики. Выигрыш в 4 раза, хотя там вводилась только концепция слоев и повторного использования компонентов.
Позже применял тот же подход на играх 3-в-ряд (ButtonMix, DreamlikeMix и другие). Так, если разработка игры по разным причинам могла затягиваться на несколько лет, то уже после частичного внедрения фреймворка игры начали делаться за полгода. При этом сразу делались и веб- и мобильные версии (Adobe AIR). Все, чем отличались платформы, выносилось в отдельные подслои, поэтому путаницы не было.
В то время вся концепция еще только формировалась. До многих идей я дошел только в этом году и еще не успел их опробовать как следует в деле. Хотя пока не вижу особых проблем, почему бы их нельзя было воплотить. Да, некоторые вещи влекут за собой дополнительные сложности или просто непривычны. Но все это с лихвой компенсируется выгодами, которые они дают.
Большинство игр реализуется достаточно стандартно, без пролета камеры из штанов соперников. Стандартным играм — стандартное решение. И для Hearthstone обычный карточный модуль вполне подойдет. Его придется только расширить новыми анимациями, партиклами и лэйаутами. В остальном там все так же перемещаются карты.
Конечно, фреймворк не подойдет разработчикам AAA-игр: они пишутся на уже развитых движках, вроде UnrealEngine, и вся разработка отталкивается от особенностей этих движков. Но большинства онлайн-игр использование таких монстров избыточно. И для не существует каких-либо универсальных архитектурных решений, которые были бы признаны стандартом. Каждый пишет как может. Я лишь попытался создать такой стандарт для себя, для более комфортной работы "майселфа".
Свою точку зрения не навязываю и не пытаюсь кого-то переубедить. Скорее ищу единомышленников и тех, кому это также интересно. Хотя и критику тоже очень приветствую.
Именно для этого и вводится разделение кода на слои. Например, слой логики никак не зависит от платформы, а только от самого языка. Поэтому если логика полностью отделена от отображения, то у нас уже появляется целый пласт платформонезависимого кода. От конкретной графической библиотеки зависит только ряд компонентов из логики отображения. (И то не все -- есть компоненты, которые оперируют только другими компонентами.) В результате весь платформозависимый код находится только в определенных слоях, реализации которых можно легко заменять другими.
Если разделение на слои соблюдается неукоснительно и бескомпромиссно, то код "протухать" не будет.
С++ я не беру в расчет -- это особый случай, просто его нельзя не упомянуть тут.
Спасибо за C#, забыл добавить.
Так и есть. Это статья -- подведение итогов серии статей про написание фреймворка. Большинство практик там не только раскрываются, но и выводятся теоретически -- с эволюционной точки зрения.
И да, это "тупо теория" (что плохого в теории?), некий идеал, который если внедрить хотя бы частично, сильно упрощает жизнь.
По примерам:
1) Код в библиотеках реализует только существенные стороны функционала, без которых он не был бы тем, чем является. И делает это в максимально простом и универсальном виде так, чтобы он подходил для любых случаев. Так логика отображения для игр 3-в-ряд состоит только из расположения и перемещения клеток и камней на игровом поле. Способ расположения или скорость перемещения можно изменить в конфигах, а добавить более сложную логику или изменить анимацию можно в подклассах. Задача программиста в том и состоит, чтобы уметь обобщить все возможные фантазии гейм-дизайнеров в одном простом решении.
2) Спорно. Если сделать качественное разделение функционала на модули, всегда будешь знать, где что выполняется.
3) Почему нет? На игровом столе размещаем метки для колоды, отбоя, выложенных на стол карт и карт на руках каждого игрока. Каждая метка (пустой контейнер) имеет свой размер и угол поворота, которые выставляет художник. Вся остальная логика -- это всего лишь добавление, удаление и перемещение карт от одной метки к другой. Еще нужно располагать карты в линию, веером, стопкой или кучкой внутри метки (настраивается в конфигах). Из команд достаточно обрабатывать add, remove, move, change (чтобы показывать/скрывать лицо карты). Если рука набита, две недели за глаза. (Включу данный пример в текст для ясности.)
Речь идет только о модуле отображения. Контроллер с правилами для каждой игры разный.
Было бы интересно узнать и по другим примерам, чем статья прям так плоха. Внесу пояснения. Что не ясно для одного, не ясно и для многих других.
Тут основная идея в том, что стоимость продукта всегда определяется средними затратами труда на данном рынке. Если ты нашел способ сделать дешевле, то средние затраты не уменьшаются, и ты можешь продавать по той же цене, получая дополнительную прибыль за счет уменьшения издержек.
Например, если взять случай, когда расходы больше прибыли в 2 раза: В1 = П1 + Р1 = П + 2 * П, и мы уменьшаем их в те же 2 раза, то при равенстве выручек все деньги перетекают в прибыль: В2 = П2 + Р2 = 2 * П + П.
Хотя формулировка у меня в тексте не очень точная, согласен -- решил не перегружать его оговорками. Классики ни при чем.
В данной редакции выпало... Но из текста это прямо вытекает. Если в компании есть хотя бы 3 проекта по 4 разработчика -- по одному для каждой платформы,-- то уже на этапе использования одного кросс-платформенного ЯП, мы можем оставить по одному. Это уже минус 9. А если проекты -- продолжение предыдущих, из которых были сделаны движки, тобольше одного разраба и не нужно.
В том-то и дело, что я не знаю таких компаний, кроме тех, что пишут на C++. Но и там неизвестно, как внутри код построен.
И все же я не знаю ни одной компании, где бы это было реализовано, хотя, кажется, все лежит на поверхности. Данная статья -- это скорее способ узнать -- почему, что я упускаю.
Ссылка на казино. Спам тут не удаляется?
Да, только это не хвост...
Создается впечатление, что есть только два типа личности по тому, как они решают это вопрос. На самом деле, думаю, правильнее было бы начать с: "На определенном этапе психического развития человека...". Потому что вряд ли можно какого-нибудь Будду и других причислить к данным категориям. Иначе с такой философией только в петлю.
Хотя я допускаю, что большинство людей так и живет. А большинство структурирует вокруг себя то, что обычно называют "системой", которая заставляет и остальных действовать так же. Поэтому и может возникнуть соблазн сделать обобщение, что так живут все.
Разделение на т.н. психотиков (откуда этот термин?) и невротиков больше похоже на знание из древнеримского культа Двуликого Януса. Согласно нему у обычного человека нет определенного постоянного характера, а он ведет себя тем или иным образом в зависимости от того, кто рядом с ним находится, какую роль он сумел занять. Например, скверный начальник может продавить своего подчиненного и за счет этого улучшить себе настроение и поднять тонус. Но подчиненный, приходя домой, сам занимает позицию начальника и, чтобы скомпенсировать потерю энергии, ругает жену. Жена поднимает себе настроение за счет более слабого ребенка, а тот отрывается на домашних животных, если есть. (Не потому ли в детстве многим так хочется собаку?) Ребенок с детства привыкает воспринимать такую схему как норму и воспроизводит ее в следующем поколении. Так и живем. Каждый слой повыше вампирит на тех, кого может запихнуть в слой пониже.
Кстати, в Древнем Риме солдат, идущих на войну, проводили через ворота храма Януса (вероятно, чтобы некоторые из них задумались, а зачем, и какое знание стоит за этим культом). И закономерно возникает вопрос, не в этом ли главная составляющая непобедимости римской армии? А еще Юлий Цезарь, когда он изменял календарь, назвал первый месяц каждого года Януарием, как раз в честь бога Януса. Если предположить, что и тогда начало нового года ассоциировалось с началом новой жизни, то можно заключить, что по мнению Цезаря новая жизнь должна начинаться с понимания принципа Двуликого Януса. Иначе ребенку с картинки выше так и не выйти из "системы". (У кота заранее никаких шансов нет, его жалко больше всех.)
ПС. Статью не мешало бы хотя бы один раз перечитать и отредактировать, иначе приходится читателям самим перечитывать по нескольку раз, чтобы понять некоторые места.
ППС. Подробнее про Двуликого Януса см. Меняйлова. Хотя многие не выдерживают его "радикальной честности", но на хабре, вроде, слабаков нету).
Прямо, как в книге. И кто только читает эти книги?!
И все же они вас обманывали, чтобы стрясти побольше денег. Ох, и плуты.
Спасибо за честный рассказ! Многое становится понятным в работе агентств.
На одном дыхании
Да, вот только от этого не легче. Мучиться с кодом все равно нам. Поэтому тут и подводится к мысли о необходимости искать решение проблемы своими силами, не надеясь на хороших менеджеров (все равно их не найдешь).
А решение в создании фреймворка и методологии, которые позволят делать и качественно, и дешево (по крайней мере для самого программиста), и быстро. По крайней мере для одной предметной области, в данном случае -- разработке игр.