Комментарии 19
Как утверждают классики политэкономии, если одна компания выстраивает все процессы так, что ее продукт получается в два раза дешевле, чем у других, то при прочих равных она получает в два раза больше прибыль, чем другие.
Классики политэкономии плохо учили математику.
П = В - Р
П1 = В1 - 2*Р
П2 = В2 - Р
П2 - 2*П1 = 0
В2 - Р = 2*В1 - 4*Р
В2 = 2*В1 - 3Р
Только при этом условии прибыль второй в два раза прибыли первой.
Допустим прочие равные означают что В2 = В1.
3Р = В1
Даже в этом случае нужно чтобы выручка была равна утроенным расходам.
Тут основная идея в том, что стоимость продукта всегда определяется средними затратами труда на данном рынке. Если ты нашел способ сделать дешевле, то средние затраты не уменьшаются, и ты можешь продавать по той же цене, получая дополнительную прибыль за счет уменьшения издержек.
Например, если взять случай, когда расходы больше прибыли в 2 раза: В1 = П1 + Р1 = П + 2 * П, и мы уменьшаем их в те же 2 раза, то при равенстве выручек все деньги перетекают в прибыль: В2 = П2 + Р2 = 2 * П + П.
Хотя формулировка у меня в тексте не очень точная, согласен -- решил не перегружать его оговорками. Классики ни при чем.
А где обещанное: сделать одним и уволить 9 разработчиков?
В данной редакции выпало... Но из текста это прямо вытекает. Если в компании есть хотя бы 3 проекта по 4 разработчика -- по одному для каждой платформы,-- то уже на этапе использования одного кросс-платформенного ЯП, мы можем оставить по одному. Это уже минус 9. А если проекты -- продолжение предыдущих, из которых были сделаны движки, тобольше одного разраба и не нужно.
А что за компания где все так прекрасно работает если не секрет?
В том-то и дело, что я не знаю таких компаний, кроме тех, что пишут на C++. Но и там неизвестно, как внутри код построен.
Ну только С++ программист стоит дороже C#, который может клепать на той же кроссплатформенной Unity, то есть мы уже повышаем расходы.
В статье просто накиданы разнородные Best Practices без конкретных условий когда их стоит применять, и если закинуть это все в проект то он гарантированно не доживет до релиза. Нет ответа как заменить 10 программистов на 1, тупо теория как жить лучше, которая моментально разобьется об реалии реализации. Приведу три примера, но их гораздо больше
1) "Все модули выносятся в библиотеки и используются повторно в других приложениях.".
Нет, для всех этих модулей и библиотек чтобы ими повторно пользоваться нужна документация и поддержка, что превращает 1 программиста в 2, причем те кто пишут хороший код редко любят заниматься документацией. И воображения геймдизайнеров таково, что порой даже логика три в ряд одного проекта несовместима с логикой три в ряд другого.
2) "Если слои отображения и бизнес-логики изначально будут общаться между собой не посредством вызовов методов друг друга, а через систему команд, как это делается в сетевых играх, то мы сразу получим сетевой режим игры для всех новых игр практически даром."
Ничего не бывает даром, делая настолько несвязанный код везде вы максимально усложняете понимание и отладку кода, и даже хорошему джуну будет проблематично в нем разобраться, а те кто уровнем повыше поработают поплюются и при первой же возможности свалят на другой проект.
3) для дурака или ведьмы — модуль карточных игр. А вот для покера или блэкджека уже не нужно ничего писать — достаточно одновременно использовать два предыдущих модуля.
Невозможно сделать модуль карточных игр, который будет включать в себя ВСЕ карточные игры, ну это совсем глупость. Вместо недели рабочего времени на дурака вы потратите два месяца на такой модуль и он все равно не будет работать везде и всегда так как нужно.
Можете попробовать и если за два месяца управитесь готов взять свои слова назад. А так статья прям плохая.
С++ я не беру в расчет -- это особый случай, просто его нельзя не упомянуть тут.
Спасибо за C#, забыл добавить.
В статье просто накиданы разнородные Best Practices без конкретных условий когда их стоит применять
Так и есть. Это статья -- подведение итогов серии статей про написание фреймворка. Большинство практик там не только раскрываются, но и выводятся теоретически -- с эволюционной точки зрения.
И да, это "тупо теория" (что плохого в теории?), некий идеал, который если внедрить хотя бы частично, сильно упрощает жизнь.
По примерам:
1) Код в библиотеках реализует только существенные стороны функционала, без которых он не был бы тем, чем является. И делает это в максимально простом и универсальном виде так, чтобы он подходил для любых случаев. Так логика отображения для игр 3-в-ряд состоит только из расположения и перемещения клеток и камней на игровом поле. Способ расположения или скорость перемещения можно изменить в конфигах, а добавить более сложную логику или изменить анимацию можно в подклассах. Задача программиста в том и состоит, чтобы уметь обобщить все возможные фантазии гейм-дизайнеров в одном простом решении.
2) Спорно. Если сделать качественное разделение функционала на модули, всегда будешь знать, где что выполняется.
3) Почему нет? На игровом столе размещаем метки для колоды, отбоя, выложенных на стол карт и карт на руках каждого игрока. Каждая метка (пустой контейнер) имеет свой размер и угол поворота, которые выставляет художник. Вся остальная логика -- это всего лишь добавление, удаление и перемещение карт от одной метки к другой. Еще нужно располагать карты в линию, веером, стопкой или кучкой внутри метки (настраивается в конфигах). Из команд достаточно обрабатывать add, remove, move, change (чтобы показывать/скрывать лицо карты). Если рука набита, две недели за глаза. (Включу данный пример в текст для ясности.)
Речь идет только о модуле отображения. Контроллер с правилами для каждой игры разный.
Было бы интересно узнать и по другим примерам, чем статья прям так плоха. Внесу пояснения. Что не ясно для одного, не ясно и для многих других.
Вы лучше расскажите на каких проектах вы работали, и где и как это удалось удачно применить, тогда другие люди смогут сделать по вашим заветам. А догадываться, что вы имели в виду без примеров рабочего кода это гадание на кофейной гуще.
"Задача программиста в том и состоит, чтобы уметь обобщить все возможные фантазии гейм-дизайнеров в одном простом решении"
Это фраза создает ощущение будто вы никогда не работали с геймдизайнерами, либо это были маленькие проекты имеющие жесткие ограничения, как тот же карточный дурак..
Хорошо, а если вас попросят сделать пролет камеры под столом с возможностью вытащить карту из штанов соперника, а туда закинуть файербол. Или написать карточкую игру a-ля Hearthstone. Для этих случаев ваш двухнедельный модуль тоже подойдет?
Все расписывать совсем долго и больно и переубедить мне вас вряд ли получится, так что еще и бессмысленно. Надеюсь вы просто со временем прокачаетесь, осознаетесь и позднее перепишете эту статью так, чтобы она была чуть актуальнее для остальных пользователей.
Около 10 лет разрабатывал игры на ActionScript, начиная еще с Flash 4 и до самого конца (потом перешел на Haxe и бэкенд, теперь еще на TypeScript). Делал игры и приложения для порталов, образования, потом — социальных сетей. Данный подход применялся на протяжении всего этого времени постепенно, по мере своего формирования. Например, игру PerfectPoker (facebook) я переписывал с AS1 на AS3 около двух месяцев, а вот уже последующие аналогичные приложения занимали 1-2 недели — большая часть времени уходила на адаптирование новой графики. Выигрыш в 4 раза, хотя там вводилась только концепция слоев и повторного использования компонентов.
Позже применял тот же подход на играх 3-в-ряд (ButtonMix, DreamlikeMix и другие). Так, если разработка игры по разным причинам могла затягиваться на несколько лет, то уже после частичного внедрения фреймворка игры начали делаться за полгода. При этом сразу делались и веб- и мобильные версии (Adobe AIR). Все, чем отличались платформы, выносилось в отдельные подслои, поэтому путаницы не было.
В то время вся концепция еще только формировалась. До многих идей я дошел только в этом году и еще не успел их опробовать как следует в деле. Хотя пока не вижу особых проблем, почему бы их нельзя было воплотить. Да, некоторые вещи влекут за собой дополнительные сложности или просто непривычны. Но все это с лихвой компенсируется выгодами, которые они дают.
Хорошо, а если вас попросят сделать пролет камеры под столом с возможностью вытащить карту из штанов соперника, а туда закинуть файербол. Или написать карточкую игру a-ля Hearthstone. Для этих случаев ваш двухнедельный модуль тоже подойдет?
Большинство игр реализуется достаточно стандартно, без пролета камеры из штанов соперников. Стандартным играм — стандартное решение. И для Hearthstone обычный карточный модуль вполне подойдет. Его придется только расширить новыми анимациями, партиклами и лэйаутами. В остальном там все так же перемещаются карты.
Конечно, фреймворк не подойдет разработчикам AAA-игр: они пишутся на уже развитых движках, вроде UnrealEngine, и вся разработка отталкивается от особенностей этих движков. Но большинства онлайн-игр использование таких монстров избыточно. И для не существует каких-либо универсальных архитектурных решений, которые были бы признаны стандартом. Каждый пишет как может. Я лишь попытался создать такой стандарт для себя, для более комфортной работы "майселфа".
Свою точку зрения не навязываю и не пытаюсь кого-то переубедить. Скорее ищу единомышленников и тех, кому это также интересно. Хотя и критику тоже очень приветствую.
Работаю с OpenFL и Haxe, и могу сказать что кроссплатформенность имеет свои плюсы и минусы. И не было ни одного проекта, где не приходилось бы решать какие то проблемы, после компиляции на требуемые платформы. А проблемы связаны обычно с требованиями или ограничениями платформы.
Лет 10 назад мне тоже казалось, что повторное использование кода это круто. Жизнь показала, что уже через пару лет код протухает. Выходят новые версии языков\движков\e.t.c. и лучше выходит написать свежий код который отвечает новым требованиям.
Сыровата статья. Много выделений жирным.
Именно для этого и вводится разделение кода на слои. Например, слой логики никак не зависит от платформы, а только от самого языка. Поэтому если логика полностью отделена от отображения, то у нас уже появляется целый пласт платформонезависимого кода. От конкретной графической библиотеки зависит только ряд компонентов из логики отображения. (И то не все -- есть компоненты, которые оперируют только другими компонентами.) В результате весь платформозависимый код находится только в определенных слоях, реализации которых можно легко заменять другими.
Если разделение на слои соблюдается неукоснительно и бескомпромиссно, то код "протухать" не будет.
Так я ж не против отделения логики от отображения. Я против универсального кода. Для примера, за 6 лет работы с HAXE вышло две новых версии языка 3 и 4 (не беру в расчет промежуточные). И я не могу оставить приложения на старых версиях, по тому что для мобильных сторов, мне нужны новые фичи языка. Я не хочу обновлять графичексую часть - мне нужно обновить только логику. Но с новой версией языка, я должен лезть в графическую часть, потому что там что то отвалилось(((
С Unity примерно та же самая беда. Люди заказывали портирование игр с Unity на что угодно, потому что обновить старые проекты до новой версии движка очень больно.
Не вижу, как связаны универсальность кода и версия языка. И без фреймворка при изменении языка придется менять и логику, и код для графики. Только с фреймворком это можно сделать один раз для всех игр, а без "универсальности" — для каждой игры отдельно.
Код — зло. Чем меньше кода, тем лучше. Минимум кода при поточном производстве — это когда все в библиотеках.
Мной написаны различные модули. Ни один не пригодился в чистом виде, так так все мои проекты в разных жанрах. Больше модули не пишу. Если вы пилите карточные/матч3 игры и у вас получается эффективно переиспользовать код, я за вас очень рад. Но не во всех ситуациях стоит так делать. Вот эту мысль я пытаюсь донести.
Причем в арсенале команды есть свой фреймворк. Но игровые модули туда не входят.
И получите вы 100500 похожих друг на друга игр с разным оформлением. Геймдев это всегда компромисс. Хотите интересную игру, с уникальными механиками, сюжетом и прочим, которая запомнится, которую будут хотеть перепроходить – тогда придется делать долго, кропотливо и вдумчиво. Хотите быстро заработать денег - нашлепайте разных клонов известных игр, накачайте трафиком и быстро срубите с рекламы пока не разбежались. Это конечно немного утрированно, но думаю мысль ясна.
Сделать удобный фреймворк части которого можно переиспользовать в новых играх это одно, а загнать все под одну систему это другое.
Публикации
Оптимальный процесс разработки онлайн игр