Некоторое время назад я работал в одной игровой компании, которой руководил немец. Создание игр не было основным бизнесом этого немца. Основные доходы он получал от продажи косметики и от сдачи коммерческой недвижимости в аренду. Наличие игровой компании было способом выделиться среди своих знакомых бизнесменов.
Игровая компания немца разрабатывала 3 вида игр:
Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
Игры для платформы Nintendo Wii.
В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.
С самого начала была понятна только общая канва игры. Маленькая фея ходит по саду, встречает своих подруг (других фей), разговаривает с ними и приглашает на вечеринку. Подготовка к этой вечеринке занимает значительную часть игры: фея украшает сад, собирает яблоки, готовит из них праздничный пирог. Вечеринка проходит весело: фея и ее подруги играют на музыкальных инструментах, а затем — танцуют.
Предполагалось, что игра будет представлять собой последовательность мини-игр. Каждая мини-игра посвящена определенной теме: украшению сада, сбору яблок, приготовлению праздничного пирога, исполнению музыки и танцам. Не смотря на то, что были понятны темы мини-игр, не были понятны их детали. Геймдизайнера в команде не было.
Поначалу над игрой работало два программиста и один 3D-моделлер. Когда я присоединился к команде, не было ни проработанного игрового дизайна (или человека за него отвечающего), ни платформы, на которой можно было бы сделать игру.
На второй день после моего устройства на работу ко мне подошел владелец компании и спросил: “Когда будет готова игра?”. К тому времени у меня был опыт работы в игровой индустрии и, согласно этому опыту, разработка такой несложной игры командой из 3-4 человек занимала около года. Так я и сказал, что потребуется где-то около года.
На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.
Здравствуйте, Кирилл Лебедев, Вы писали: КЛ>С самого начала была понятна только общая канва игры. Маленькая фея ходит по саду, встречает своих подруг (других фей), разговаривает с ними и приглашает на вечеринку. Подготовка к этой вечеринке занимает значительную часть игры: фея украшает сад, собирает яблоки, готовит из них праздничный пирог. Вечеринка проходит весело: фея и ее подруги играют на музыкальных инструментах, а затем — танцуют.
. Я же говорил, что "каждый" пытается сделать свой город с феями и прочими ночными бабочками. А мужики, которые в неё играли сказали, что хотели бы тоже самое, только ещё чтобы можно было стрелять из автоматов. КЛ>Далее
чтение может стать причиной развития мозга
"Архитектура корпоративных программных приложений" Мартина Фаулера отличная книга, в моей библиотеке она у меня находится в топе по архитектуре в целом, а не только энтерпрайза. А редакторы надо смотреть, всё это сугубо специфично, хотя и однообразно. Написано слишком подробно для обсуждения в стиле псевдоинтеллигенции и слишком поверхностно для обсуждения программирования. Сейчас тоже что-нибудь скину, вроде старых изображений завалявшихся на форуме. А то ещё другие подумают, что я полное нубло.
А я им такой, хопа, смотрите, я знаю, чем уровни отличаются от слоёв, и тут у меня сразу стало на 3 см больше.
слои и уровни
Или что я что-то понимаю в данных, хотя уже давно отформатировал себе мозг.
данные по CRUD
А ещё непонятно зачем приплету нагло экспроприированное изображение методологии разработки RUP.
Скрытый текст
Что-то напомнили мне про хабр, по данным самого хабра я с него ушёл ещё 7 лет назад. А хабр смотрю меня не забыл, была карма -120, но кто в последние годы дрочил на мёртвые души, и она уже -130 и далее. Читать, что ли нечего стало, если уж начали появляться некрокармофилы. Ладно RSDN толерантный, в блогах, форумах и так далее даёте ссылку на хабр и вас модеры не банят перманентно. А хабр может запросто забанить за ссылку на RSDN. Сами же понимаете, времена "нонче" не те, все забились в уютные щёлочки и не хотят вылезать, блогегры в свои бложики, ютуберы переходят на стримы. Время агрегаторов постепенно уходит и неизвестно вернётся ли. Как говорится хочешь 0 комментариев, пиши в/на агрегатор.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Некоторое время назад я работал в одной игровой компании, которой руководил немец. Создание игр не было основным бизнесом этого немца. Основные доходы он получал от продажи косметики и от сдачи коммерческой недвижимости в аренду. Наличие игровой компании было способом выделиться среди своих знакомых бизнесменов.
... КЛ>На это немец мне ответил: “Такого срока нет. Игра должна быть сделана через 3 месяца”. Немного офигевая, я спросил: “А почему через три месяца?” На что немец мне ответил: “У меня будет день рождения, и нужно, чтобы к моему дню рождения игра была сделана”.
какой прекрасный персонаж!
а я думал, только в самых трэшовых отечественных компаниях такое можно встретить.
ну да ладно. у меня вопрос.
зачем трёхслойную архитектуру порезали мельче в части представления(сложность?), добавили сторонние либы в архитектуру(нонсенс!) и переименовали бизнес-слой?
чем это вообще помогло?
по-моему, усложнение на ровном месте. не, я понимаю, что так можно посмотреть на архитектуру "поближе", но в то же время это слишком уж пристально.
Здравствуйте, neFormal, Вы писали:
F>зачем трёхслойную архитектуру порезали мельче в части представления(сложность?),
А из статьи это неясно? Я постарался объяснить на примерах. Если неясно, то где — в каком примере?
F>добавили сторонние либы в архитектуру(нонсенс!)
Архитектура основывается на некотором базисе. Почему Вы считаете, что так делать нельзя или не надо?
F>и переименовали бизнес-слой?
Бизнес-слой (по крайней мере, у Фаулера) содержит не только бизнес-функции, но и бизнес-объекты. Здесь же бизнес-объекты перенесены на уровень модели данных.
Ну и почему Вы считаете, что, например, компиляция относится к бизнес-слою? Редактор может существовать и без нее.
F>чем это вообще помогло?
Например, помогло тем, что мы создаем разные приложения по одному и тому же шаблону и переиспользуем уже написанные библиотеки.
Здравствуйте, Кирилл Лебедев, Вы писали:
F>>зачем трёхслойную архитектуру порезали мельче в части представления(сложность?), КЛ>А из статьи это неясно? Я постарался объяснить на примерах. Если неясно, то где — в каком примере?
примеры отвечают на вопрос "что?" или "как?", но не отвечают на вопрос "зачем?"
F>>добавили сторонние либы в архитектуру(нонсенс!) КЛ>Архитектура основывается на некотором базисе. Почему Вы считаете, что так делать нельзя или не надо?
сторонние библиотеки, утилитные классы не влияют на построение приложения. они могут использоваться на любом уровне.
F>>и переименовали бизнес-слой? КЛ>Бизнес-слой (по крайней мере, у Фаулера) содержит не только бизнес-функции, но и бизнес-объекты. Здесь же бизнес-объекты перенесены на уровень модели данных.
в смысле, вы логику положили в объекты, которые пишутся в БД?
КЛ>Ну и почему Вы считаете, что, например, компиляция относится к бизнес-слою? Редактор может существовать и без нее.
я не говорил про компиляцию.
для меня она одно из двух:
— утилита из "инфраструктуры". если конвертация из одного формата в другой происходит незаметно при сохранении
— рендерилка из слоя представления. если результат отдаётся юзеру в руки, например.
редактор может существовать даже без загрузки и сохранения или без добавления дополнительных эмиттеров частиц, или, наоборот, только через добавление... короче, крайностей много.
а я определяю бизнес-логику, как реализацию требований, выдвинутых при составлении задания на ПО.
в рамках примера с редактором патиклов — это все операции с состоянием редактора(настройки эмиттеров, состояние окон, етк).
F>>чем это вообще помогло? КЛ>Например, помогло тем, что мы создаем разные приложения по одному и тому же шаблону и переиспользуем уже написанные библиотеки.
мм... так все же это делают? ._.
я просто не понимаю... допустим есть у меня трёхуровневая архитектура. если я перейду на описанную 5-уровневую, какие профиты я получу? как мне их заметить и оценить?
Здравствуйте, neFormal, Вы писали:
F>примеры отвечают на вопрос "что?" или "как?", но не отвечают на вопрос "зачем?"
У каждого слоя (уровня абстракции) свои обязанности, а также — свои используемые шаблоны проектирования, свои подходы и методики для выявления классов.
F>сторонние библиотеки, утилитные классы не влияют на построение приложения. они могут использоваться на любом уровне.
В данном случае, нам было удобнее выделить утилитные классы в отдельный слой, потому что они используются в остальных слоях тоже. Ну и сторонние библиотеки из архитектуры не выкинешь. Если в игре требуется модуль, ответственный за симуляцию физики, то вам придется либо использовать physx, либо havok, дибо bullet, либо писать его самому.
Здравствуйте, neFormal, Вы писали:
F>я не говорил про компиляцию. F>для меня она одно из двух: F>- утилита из "инфраструктуры". если конвертация из одного формата в другой происходит незаметно при сохранении F>- рендерилка из слоя представления. если результат отдаётся юзеру в руки, например.
Компилятор должен иметь доступ к модели данных, т.к. он преобразует эти данные в другой формат. Следовательно, он должен располагаться либо выше модели данных, либо на одном уровне с ней. Но расположение компилятора на уровне модели данных тоже как-то нелогично, потому что модель данных может обойтись и без него.
С другой стороны, компилятор не должен находиться на уровне взаимодействия с пользователем или на уровне редактирования, т.к. он никак не зависит от него. Поэтому компилятор и располагается на уровне сервисов.
F>редактор может существовать даже без загрузки и сохранения или без добавления дополнительных эмиттеров частиц, или, наоборот, только через добавление... короче, крайностей много.
Без загрузки и сохранения редактор никому не нужен.
F>а я определяю бизнес-логику, как реализацию требований, выдвинутых при составлении задания на ПО.
Это абстрактное правило. С моей точки зрения, редактор отвечает за изменение модели данных пользователем. Т.е. данные могут измениться и с помощью внешней программы. Но редактор позволяет это сделать пользователю. А уровень сервисов позволяет оказывать пользователю (человеку или сторонней программе) услуги на основе модели данных без внесения в нее изменений.
F>мм... так все же это делают? ._. F>я просто не понимаю... допустим есть у меня трёхуровневая архитектура. если я перейду на описанную 5-уровневую, какие профиты я получу? как мне их заметить и оценить?
Я не предлагаю переходить на пятиуровневую архитектуру в любой ситуации. Я лишь написал, что при разработке клиентских приложений (преимущественно, редакторов) может быть использована пятиуровневая архитектура. Какие преимущества? На каждом уровне используются свои шаблоны проектирования и свои подходы к выявлению классов.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Компилятор должен иметь доступ к модели данных, т.к. он преобразует эти данные в другой формат.
это уровень представления
КЛ>С другой стороны, компилятор не должен находиться на уровне взаимодействия с пользователем или на уровне редактирования, т.к. он никак не зависит от него. Поэтому компилятор и располагается на уровне сервисов.
а он ни от кого и не должен зависеть. это представление данных. чистая ф-ция конвертации.
F>>редактор может существовать даже без загрузки и сохранения или без добавления дополнительных эмиттеров частиц, или, наоборот, только через добавление... короче, крайностей много. КЛ>Без загрузки и сохранения редактор никому не нужен.
слишком смелое заявление. потому что такие редакторы есть. и они могут передавать состояние по сети. или даже только сделать скриншот своего состояния.
КЛ>Это абстрактное правило. С моей точки зрения, редактор отвечает за изменение модели данных пользователем. Т.е. данные могут измениться и с помощью внешней программы. Но редактор позволяет это сделать пользователю. А уровень сервисов позволяет оказывать пользователю (человеку или сторонней программе) услуги на основе модели данных без внесения в нее изменений.
по-моему, в такой схеме коллаборация по сети становится невозможна.
F>>мм... так все же это делают? ._. F>>я просто не понимаю... допустим есть у меня трёхуровневая архитектура. если я перейду на описанную 5-уровневую, какие профиты я получу? как мне их заметить и оценить? КЛ>Я не предлагаю переходить на пятиуровневую архитектуру в любой ситуации. Я лишь написал, что при разработке клиентских приложений (преимущественно, редакторов) может быть использована пятиуровневая архитектура. Какие преимущества? На каждом уровне используются свои шаблоны проектирования и свои подходы к выявлению классов.
Здравствуйте, neFormal, Вы писали:
КЛ>>Компилятор должен иметь доступ к модели данных, т.к. он преобразует эти данные в другой формат. F>это уровень представления
Каковы критерии для принятия такого решения?
КЛ>>С другой стороны, компилятор не должен находиться на уровне взаимодействия с пользователем или на уровне редактирования, т.к. он никак не зависит от него. Поэтому компилятор и располагается на уровне сервисов. F>а он ни от кого и не должен зависеть. это представление данных. чистая ф-ция конвертации.
Компилятор использует модель данных. Поэтому он зависит от неё.
КЛ>>Без загрузки и сохранения редактор никому не нужен. F>слишком смелое заявление. потому что такие редакторы есть. и они могут передавать состояние по сети. или даже только сделать скриншот своего состояния.
Если понимать загрузку и сохранение, как чтение данных из локального файла или запись данных в локальный файл, то да. Но данные можно хранить и на сервере, и в БД. Важно, чтобы пользователь имел возможность сохранять свою работу, чтобы затем использовать её где-то или чтобы мог выполнить её не за один сеанс редактирования.
КЛ>>Это абстрактное правило. С моей точки зрения, редактор отвечает за изменение модели данных пользователем. Т.е. данные могут измениться и с помощью внешней программы. Но редактор позволяет это сделать пользователю. А уровень сервисов позволяет оказывать пользователю (человеку или сторонней программе) услуги на основе модели данных без внесения в нее изменений. F>по-моему, в такой схеме коллаборация по сети становится невозможна.
Почему же? Смотрите пример про редактор частиц. Там была коммуникация с сервером.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>>>Компилятор должен иметь доступ к модели данных, т.к. он преобразует эти данные в другой формат. F>>это уровень представления КЛ>Каковы критерии для принятия такого решения?
по сути поведение ничем особо не отличается от рендера страницы для веб-приложения.
потому и считаю их похожими.
КЛ>>>Это абстрактное правило. С моей точки зрения, редактор отвечает за изменение модели данных пользователем. Т.е. данные могут измениться и с помощью внешней программы. Но редактор позволяет это сделать пользователю. А уровень сервисов позволяет оказывать пользователю (человеку или сторонней программе) услуги на основе модели данных без внесения в нее изменений. F>>по-моему, в такой схеме коллаборация по сети становится невозможна. КЛ>Почему же? Смотрите пример про редактор частиц. Там была коммуникация с сервером.
я про коллаборацию — одновременное редактирование одной сущности.
хотя может и реально. просто фраза "услуги на основе модели данных без внесения в нее изменений" немного путает.
Здравствуйте, neFormal, Вы писали:
КЛ>>Каковы критерии для принятия такого решения? F>по сути поведение ничем особо не отличается от рендера страницы для веб-приложения. F>потому и считаю их похожими.
Это не критерий, а Ваши оценки: "не отличается" и "считаю похожими". Критерий — это то, на основании чего делаются такие оценки.
