ООП не главный злодей, он просто не дает такой свободы и простоты, а это значит, что порог вхождения для людей выше. И я не обвинял его в убийстве ( никто пока никого не убил, да и не убьет, скорее всего), я говрил, что он это пытается сделать.
Ну, по-крайней мере заметка так воспринимается.
Если вокргу столько инноваций и классных ММО, то почему на ММОзге постоянно пишут статьи о том, что: как-то не видно масштаба, все как-то повторяется, мало новых идей и т.д. Я считаю, что ответ именно где-то в области статистики, результаты которой определяются теми самыми порогом вхождения и сложностью, которые можно было бы сильно снизить.
Могу говорить только за себя. Я в принципе считаю ММО сомнительным жанром, в плане эффективности создания сетевых экспириенсов. Вопросы масштаба меня не сильно заботят, по этой же причине. А ограничение инноваций, как в вашей же заметке и сказано, лишь следствие недостатка инвесторов, которые готовы в них вкладываться.
Начнем с того, что это разные парадигмы, а не методы, это важно.
Верно, я говорю про методики, принципы, а не про конкретно ООП методы (as in method vs function).
вы просто получите bottleneck, который будет вас ограничивать
Вот. Вы сами подобрали более подходящее слово. Именно ограничениями, или затруднениями, как я уже сказал комментарием выше. Но никак не «убийством». А с ограничениями мы сталкиваемся в любом случае. Какими именно уже зависит от эффективности составленного кода (т.е. возможностей инструментария и навыков пишущего).
Собственно, говоря о уже готовых движках, вроде Unity, UE и прочих, то надо всегда помнить, что они, как и вообще высокоуровневое программирование в принципе (если сравнивать с низкоуровневым), предоставляют упрощения юзабилити (во множестве его проявлений) в ущерб производительности. Кастомный движок, созданный специально для какой-то цели по определению имеет смысл существовать именно для улучшения производительности и для избавления от ненужного функционала и мусора.
Когда мне, например, достаточно производительности Unity для реализации задуманного, то это осознанный выбор инструмента, способного дать возможность реализовать все, что я хочу. Когда пара студентов взяла Java и стала работать над H&H, у них получилось реализовать кучу интересных механик, при том, что они не гнались за созданием огромного мира с тысячами игроков. Когда у CCP Games была необходимость делать единый сервер для большого мира, они стали использовать Stackless Python, который удовлетворял их нуждам. При чем здесь ограничения ООП, когда их никто ни на кого не накладывает? Люди пользуются методиками и инструментами в рамках поставленной задачи. Да, цена входа разная, конечно, но она соответствует уровню сложности задачи, что вполне закономерно. Хотя, опять же, технологии не стоят на месте, и тренд идет лишь в сторону снижения цены (как в примере введения обозначенных вами технологий в Unity 2018).
Вы почему-то пропустили части про виртуальные функции и таблицы, которые вы все еще пиликаете в рантайме, ну да удобно.( я не знаю, может у нас разное понимание ООП, но это как бы основа) Простите, полиморфизм есть полиморфизм, если у вас его нет или практически нет, то это не ООП в чистом виде.
Далее, никакого внимания на упоминание абстракций с нулевой стоимостью.
Да, пропустил, поскольку вы упоминаете эти частности в контексте заданного мною уточнения. Я посмотрел, о чем вы говорили и теперь хочу обсудить другое.
Когда вы говорите про ООП, у меня складывается ощущение, что вы имеете ввиду, что весь код, от и до, должен состоять из его атрибутов, и манипулировать только ими. Что все должно упираться в иерархии классов и объекты. Я правильно вас понимаю?
Давайте разграничивать. Языки программирования поддерживают множество парадигм и методов написания кода, даже если они ориентированы в большинстве своем на какую-то конкретную. Код должен быть в первую очередь эффективен. Поэтому вполне логично использовать другие методы в тех местах, где это принесет лучший эффект.
Когда вы ставите ООП главным злодеем и обвиняете в убийстве возможности создавать инновационные игры и расширять функционал, вы, мало того, что игнорируете уже созданные проекты, которые своим существованием просто напросто кричат об обратном, так еще и делаете вид будто программисты ограничены единым методом формирования кода и шаг влево, шаг вправо — расстрел.
Вы пишете про то как удобно наследовать, что это надо делать правильно и аккуратно, но наследование и полиморфизм не просто «группируют» функционал, они тащат за собой много того, что вам не нужно.
Дык в том то и дело, что нужно группировать так, чтоб ненужный мусор не тащился. Я уже перечислил в первом комментарии — low coupling/high cohesion структура, использование компонентов, контейнеров и т.д.
ООП языки позволяют писать хороший, «бодрый» код. Да и совсем не обязательно всегда использовать объекты. Здесь уже упоминали structs.
Я погуглил DoD. Собственно, начиная с Unity 2018, если я правильно понимаю, идет адаптация ECS/DoD:
Я взялся за Unity поздней осенью и все еще учу Unity 2017, поэтому руками не щупал, не скажу ничего.
Боттом лайн, это все вопрос оптимизации и производительности, а не экзистенциальный кризис какой-то. Ваш изначальный посыл с использованием слова «убивает» просто не соответствует действительности. «Затрудняет» или «усложняет» — может быть. Но не более.
Ну, давайте тогда начнем с конкретных фраз, по порядку.
Иерархии убивают расширяемость.
— наследование убивает расширяемость системы. Не пугайтесь, это не попытка вас запутать или глупо пошутить. Все дело в том, что эти самые сложные иерархии не могут увеличивать свою сложность до бесконечности по многим причинам, как просто из-за того, что с таким кодом становится очень сложно работать, так и из-за того, что сам код начинает работать хуже. И тут речь уже о масштабируемости системы, то есть возможность выдержать большие нагрузки.
Иерархии это лишь способ группировать данные/функционал. Для удобства восприятия и работы с ними. Чем лучше сгруппируешь, тем меньше будет конечного кода. Наследование и полиморфизм — тоже способы уменьшить ненужное дублирование, сократить/упростить код, уменьшить работу. Это, в купе с модульностью, и есть шаги к улучшению масштабируемости системы. Плюс, к упрощению одновременной работы над ней множеству людей. Т.е. абсолютно противоположное тому, о чем говорите вы.
Стоит сказать, что я кроме как ООП языками не владею, кроме, разве что, BASIC, которым я последний раз пользовался… м… лет так двадцать назад, будучи школьником. Поэтому никаких контрпримеров с использованием других парадигм я привести не могу. Как именно они могут дать лучшую масштабируемость и простоту работы?
Повторю свою ключевую мысль. Вопросы производительности важны, но они решаемы, причем даже в одно-два лица/разработчика, при мизерном бюджете (см кейс Haven & Hearth). В случае хорошей команды и бюджета побольше они решаемы с очень крутым результатом (см кейс EVE-Online). Поэтому я не вижу особого смысла рассуждать о технической стороне вопроса.
Финансирование и инвестиции в то, что не факт что стабильно заработает или будет интересным — вот это вопрос, да. Но он не имеет отношения к ООП, архитектурам процессоров или гейм дизайну.
Понятное дело, что софт не создается путем бросания денег в монитор. Но, как и со всем остальными предприятиями в жизни, это вопрос знаний, навыков, профессионализма, управления, эффективности, которые и определяют успех.
Я согласен лишь только с одним тезисом — масштабируемость — проблема, требующая серьезного внимания и затрат. В остальном — не согласен. Статья, с неоправданно длинным и self-centered вступлением, похожа на попытку вступиться за коллег (что я лично сам очень даже понимаю, been there, done that), манипулируя «магическими» словами, малопонятными для неподготовленного читателя, в попытке обосновать свой тезис.
Несмотря на все это, автор приходит к правильным выводам:
куда проще и дешевле, ведь у вас есть инвесторы. А как известно, инвесторы не хотят тратить годы на реализацию каких-то новых технологий, писать что-то с нуля, переписывать и внедрять фичи, использовать новые парадигмы. От вас не хотят инноваций, ведь для инвестора важна надежность, а что может быть надежнее проверенного велосипеда?
Внезапно оказывается, что это всё бизнес, и дешевле копировать, чем создавать что-то новое. Но в этом то и отличие индустрии от искусства. Приоритеты разные. Только архитектура и гейм-дизайн здесь не при чем.
ООП лишь принцип. Как его применять — отдельная тема. Знание основ Software Engineering для гейм-дизайнера важно (и обязательно в случае с независимыми разработчиками, которые носят множество шляп одновременно). Можно делать плохие системы, а можно и хорошие, регулируя количество внутренних и внешних связей, используя контейнеры и компоненты, и т.д.. Это, в буквальном смысле, целая наука. Требующая профессионального подхода.
Точно также и гейм-дизайн постепенно начинают преподавать в университетах, это же тоже целая наука. А упрощение дизайна систем, в ней, на мой взгляд, не стоит подавать как нечто плохое.
А вы, поразмыслив вместе с ним, начинаете ее крамсать, сокращать, упрощать и видоизменять так, чтобы вам не пришлось переписывать весь ваш код или заниматься тем, что называется велосипедостроением.
Наоборот, упрощение — крайне полезно. Если можно что-то упростить, не теряя сути, то это плюс, а не минус. Игры должны быть доступны и понятны.
Ведь игра — набор механик, которые призваны создавать некий опыт. Как именно они это делают, иногда скрываясь от взгляда окружающих и срезая углы, там, где это можно сделать, не важно.
PS: начинающий независимый гейм дизайнер/софт инженер, адепт C#/Unity
Прочитал все что тут скинули. Ужаснулся. Особенно охренел, прочитав про 60 лямов на разработку и 60 лямов на маркетинг. Делать рекламу, конечно, гораздо проще, чем делать хороший продукт.
Да, прозрачность не бывает абсолютной, вопрос в её количестве. И в случае W2, описания скиллов есть, а перки, которые с их помощью открываются видны только по названиям. Описания их эффектов на отдельном экране уже в самой игре. С теми же Pillars настолько все плохо не было %)
Выше я рассказываю, как авторы AAA-игр публично заявляли, что микротранзакции им нужны из-за сложностей финансирования проектов, стоимость производства которых постоянно, по их словам, растёт. Ты говоришь — не, это я знаю, я о другом.
Нет. Я говорю — я такого ни разу не слышал ни от кого. И прошу привести конкретные примеры, где разработчики такое говорят. С цитатами/ссылками, а не в пересказе. Все что я помню, это как выходит Чайка и перед камерой рассказывает как хочет сделать Еву более доступной для как можно большего количества игроков. Или Брайан Фарго, рассказывающий, про то что и до покупки их Майкрософт, у него были планы B, C и D на случай финансовых проблем. Я вижу разработчиков, которые в одно-два-три лица делают хорошие игры. Но я не игровой журналист, и, уж тем более, не любитель ММО, поэтому и спрашиваю про вещи, которые тебе лучше известны.
я могу поискать конкретные цитаты, если хочешь
Да, если не трудно, это именно то, что я спрашиваю.
Мне кажется, с этим тихо согласятся многие разработчики. Звучит красиво и стройно. Но затем они смогут вам рассказать много интересного по поводу того, как устроена внутренняя кухня разработки, о рисках, которые есть у любого проекта, об уровне зарплат, об условиях труда, офисах, медицинских страховках и поиске сотрудников. При всей принципиальности Марка Джейкобса, суровая правда жизни заключается в том, что, даже получив дополнительные инвестиции, City State Entertainment, насколько мне известно, не могут найти нужных специалистов в рамках своего бюджета. А бюджет их не может быть больше, потому что нет таких инвесторов, которые готовы вложить кучу денег в схему пускай и более справедливую, но менее прибыльную, если повсеместно другая схема используется и принимается большинством участников.
Ну, нет же. Понятное дело что речь идет о сложностях финансирования, а не буквальном вопросе еды и голода. Странно, что ты спрашиваешь такое.
Я просто пытаюсь понять, откуда исходит вышеупомянутый тезис. Его здесь часто произносят вслух, в том числе и ты, но я ни разу не видел, чтоб так на самом деле говорили сами разработчики. Так понятно? Я не знаю, как еще иначе спросить.
Может быть. Но мой вопрос был не об этом. Повторюсь. Я постоянно вижу здесь слова о том, что разработчики оправдывают свою модель монетизации необходимостью «кушать». Хотя ни разу не видел таких слов ни от одного разработчика. Кроме, разве что, товарища, который сподвиг Ата написать данную заметку. Мне кажется важным подкреплять слова фактами. Поэтому я хотел бы увидеть хотя бы несколько примеров такого оправдания со стороны разработчиков.
Я не хотел бы спойлерить что-либо или портить впечатление. Но раз уж вы спрашиваете, я скажу. В первый Wasteland я не играл. А первые два Fallout обожаю, конечно.
В Wasteland 2 на старте нужно создавать 4 персонажей. Можно, конечно, использовать тех, что были созданы разработчиками, но это вариант не для всех. Самая большая проблема здесь в том, что игра дает довольно мало информации на этом этапе. Даже перки, открываемые скиллами, непонятно что делают. Это можно будет прочитать уже только после старта. А вот сбросить/пересоздать/создать новых персонажей вам уже не дадут.
Решения подобных проблем уже давно придуманы до нас. Создаем одного персонажа на старте. Делаем более видимым набор выбираемых возможностей. А уже после старта игры, через некоторое время, разрешаем создавать новых компаньонов и сбрасывать прогресс с возможностью перенастройки персонажа. За игровые деньги, конечно же. Но увы, не в W2.
Сама структура скиллов и перков вызывает недоумение. Не то, чтоб я был против «ширины»… Например, Alarm Disarming, Lockpicking, Safecracking — это отдельные навыки. Еще три разных навыка для «убеждения», и так далее. Их довольно много. Это, в общем то, допустимо. Но вот раскидать их по 4 стартовым персонажам, да еще и с расчетом на то, чтоб иметь возможность их всех в макс выкачать, нет. Создавать попутчиков после старта нельзя. Кого ты встретишь в игре, и кого сможешь пригласить в группу — вопрос неоднозначный. Некоторых персонажей ты не встретишь из-за сделанного тобой выбора в процессе игры, и тебе на него ответа никто не даст заранее, если не ходить и не читать интернеты самому, что есть дурной той. Так, если ты не раскидываешь большинство скиллов по стартовым 4 персонажам, можно остаться без них на очень долгое время. Я лично проходил так, что получил второго снайпера, но потерял возможность получить медика. Но мне не нужен второй снайпер. Мне нужен взломщик сейфов. В общем, как я уже сказал, этот вопрос уже продуман и реализован до нас, в тех же Pillars of Eternity, Expeditions: Viking и т.д.
Скилл Heavy Weapons отображен иконкой с ручным гранатометом. Хотя влияет только на пулеметы. А вот перки на гранаты и гранатометы скрыты за скиллом Demolitions, который используется для обезвреживания мин. Модификации к оружию есть даже для палки с гвоздями (например, grip tape). А пулеметы модифицировать нельзя. За что их, пулеметы, на просторах интернетов сильно не любят. Хотя, стоит сказать, незаслуженно.
Баланс также заслуживает внимания. Тяжелая броня практически бесполезна. Оружие разных тиров имеет показатели настолько отличные друг от друга, что страшно представить что происходит в энд гейме. Пушки из начального этапа игры просто мусор в сравнении с энд гейм предметами. Один из двух, если я внимательно смотрел, перк для пользователей тяжелой брони требует прокачки blunt weapons.
В чем сакральный смысл нажимать на рацию и вызывать базу каждый раз, когда персонаж получает новый уровень? Лишние клики. Максимум персонажей — 7. Кол-во уровней — 50. Не у всех левелинг идет равномерно. Сколько раз нужно вызывать базу для осуществления процесса лвл-апа можно посчитать в уме.
Вообще, я долго так могу бурчать. Но, пожалуй, хватит. Игра не обязательно прям плохая. Она заслуживает внимания. Я просто хотел сказать, что можно делать лучше.
Не, ты не понял. Я прекрасно понимаю о каких вещах ты говоришь. Ты зря объясняешь суть явления :) Мне было интересно увидеть конкретные заявления со стороны разработчиков, где они открытым текстом говорят «ну вы же понимаете, нам надо кушать, поэтому мы...», которое на ММОЗГе постоянно, как я уже заметил, приписывают сферическим «разработчикам». Потому что я сам реально ни разу не видел таких эм… каминг аутов. Серьезно. Поэтому и спрашиваю о конкретных примерах. Есть наиболее яркие какие-то? У меня чисто академический интерес. Да и справедливости ради. Уж слишком часто здесь это звучит.
Вот кого я, кстати, видел, так это разработчиков, которые не боятся ставить высокие ценники на свои игры. Все настолки стоят дорого (хотя это, скорее, связано с затратами на их издание). И нишевых разработчиков. У которых меньше аудитория. Старые паблишеры, вроде Matrix/Slitherine и Battlefront. У них часто можно встретить игры с ценниками 100 USD и даже выше. Но да, это не ММО жанр, конечно. Но все же.
они часто тут же попытаются вызвать в нас жалость аргументом о необходимости кушать
Я видел вашу дискуссию с отдельно взятым индивидуумом, чья цитата была взята за заголовок этой заметки. Но вот в общем и целом, я уже неоднократно встречал подобные заявления на ММОЗГе. Но ни разу не видел еще ни одного заявления разработчиков, оправдывающих свою финансовую модель необходимостью «кушать». Поэтому, чисто из интереса, можно конкретные примеры?
А вообще, в целом, я в какой-то степени рад тому, что есть плохие геймдевы. Почему? На их фоне проще выделиться. Проще создавать качественный продукт, когда конкуренты не top notch. Я, конечно, лично, еще очень далек до завершения хотя бы одного собственного геймдев проекта и самопубликации, но наличие хреновых гейм дизайнеров в топе мотивирует. Вот, серьезно. Я знаю, что могу лучше. Это ведь тоже, наверное, эволюция?
Далеко за примерами идти не надо. Буквально недавно решил вернуться к Wasteland 2, которую бросил когда-то не пройдя до конца. Посмотрел теперь на нее взглядом гейм-дизайнера. Вспомнил, почему не допрошел. Понял, что Брайан Фарго и ко сделали не так, где, и как можно сделать лучше/исправить. Потом увидел новости, что их купил Майкрософт. И это мотивирует. Потому что можно делать игры лучше, чем они. Работы Обсидиан, к слову, на порядок выше, на мой взгляд. За них вот теперь даже немного страшно.
Помимо того, что моя реакция соответствует большинству реакций людей в комментариях ролика на ютубе, интересно вот что…
1. ССР поняли, что делать физическую привязку к существующему продукту в новой игре не добавляет ему шансов «выстрелить» (что я понял в первый же миг, увидев Dust 514 и сказав — он не взлетит, несмотря ни на какую привязку к EVE). Теперь поняли и они. И не стали связывать РС ММО и новую мобильную ММО. Вау. Они учатся? Или это случайность?
2. Это классический случай большой компании, которая создавая новый продукт… клонирует уже существующий, потому что нельзя же рисковать большим бюджетом! См выпуск Extra Credits посвященный этому вопросу.
3. Сегодня же точно не 1 апреля, да? Уже второй раз проверяю, на всякий случай.
4. Хахахахахахаха…
Я не играл в его старые игры, и последние его (и его студии) проекты тоже не сильно люблю, кроме Ace Patrol, но трудно отрицать его достижения и признание. Спасибо за пересказ. Очень добротное содержание.
Во-первых, мысли излагает (а не диктует истину) гейм дизайнер, а не филолог. Поэтому лингвистический анализ тут излишен.
Во-вторых, ваше пренебрежительно-националистически-дискриминационное необоснованное обобщение (blanket statement) про «американцев», вкупе с минимальным количеством у меня свободного времени, отбивает какое-либо желание детально отвечать вам. Но я постараюсь, насколько меня хватит.
В-третьих,
Итого, в само слово «game» оказывается вложена изрядная доля агрессии и противостояния (при этомуменьшая факторы интереса, развлечения, даже просто совершенствования навыков, не относящихся к ПвП) по сравнению с этим же понятием в других языках или игровом контексте.
подобные пассажи у меня просто вызывают недоумение и желание развести руками. Это даже и близко не филологический анализ. Это какая-то ерунда, простите.
Поехали дальше…
Хотя всё равно ведь были и игры просто с физическими объектами, не поддающимися полному контролю (но, видимо, с позиции англоязычного автора, это либо «toys», либо требует живого соперника, чтобы хотя бы получился «contest»).
Противостояние и соревнование совсем не требует наличие живого противника. Вы можете соревноваться хоть с самим собой. Про то, что «PvE» расшифровывается как «Player versus Environment» вы тоже забыли.
А вот дальше проскакивает интересное слово «контекст». О влиянии действий и последствиях решений… но дальше автор статьи сразу заворачивает всё в сторону противостояния, утверждая, что симулятор — это не игра, если он не пытается постоянно противостоять игроку.
Вы невнимательно читали (возможно, всю статью целиком). Автор пишет дословно:
In the end, one of the interesting differences between a simulator and a game is that it's not a valid complaint to say that a simulator isn't fun. Simulators really have no inherent requirement to be fun — they only need to simulate something.
В чем и описывает отличия симулятора от игры. Игра должна приносить фан. Симулятор не обязан этого делать. Хотя и может.
Придерживаясь своего определения «игры», автор просто выкидывает огромные пласты геймплея, например создание решения (уникального из огромного множества возможных, но труднодостижимых, а не расшифровка единственного задуманного автором)
Ох. Возвращаемся на первую страницу. И читаем:
I define this thing — a game — as «a system of rules in which agents compete by making ambiguous decisions.» Note that «agents» don't necessarily have to both be human, one is often the system (as in a single-player game). But the «ambiguous decisions» part is really crucial, and I am here to argue that it's the single most important aspect in a game.
ambiguous — двусмысленный; неясный; неопределённый; допускающий двоякое толкование; неоднозначный;
В то время как у пазлов может быть только один правильный ответ/решение. Страница номер два:
Puzzles (Examples: a Portal level, a jigsaw puzzle, a math problem) — A puzzle is another word for «a problem». A puzzle has a single correct answer — a «solution».
— So do puzzles have «decision-making»? I argue that they do not — at least, certainly not at all in the same way that games do. Puzzles are not games, because while some puzzles allow players to make decisions, this is actually rather irrelevant to the outcome. All that matters for a puzzle is whether or not the player gave the correct answer.
Именно такая узость мышления и есть проблема
Да, такая узость мышления, которая позволяет использовать blanket statements, характеризуя целую нацию каким-то специфическим способом, и невнимательно читать, приходя к абсолютно противоположным (упор на ложным) выводам.
Могу говорить только за себя. Я в принципе считаю ММО сомнительным жанром, в плане эффективности создания сетевых экспириенсов. Вопросы масштаба меня не сильно заботят, по этой же причине. А ограничение инноваций, как в вашей же заметке и сказано, лишь следствие недостатка инвесторов, которые готовы в них вкладываться.
Вот. Вы сами подобрали более подходящее слово. Именно ограничениями, или затруднениями, как я уже сказал комментарием выше. Но никак не «убийством». А с ограничениями мы сталкиваемся в любом случае. Какими именно уже зависит от эффективности составленного кода (т.е. возможностей инструментария и навыков пишущего).
Собственно, говоря о уже готовых движках, вроде Unity, UE и прочих, то надо всегда помнить, что они, как и вообще высокоуровневое программирование в принципе (если сравнивать с низкоуровневым), предоставляют упрощения юзабилити (во множестве его проявлений) в ущерб производительности. Кастомный движок, созданный специально для какой-то цели по определению имеет смысл существовать именно для улучшения производительности и для избавления от ненужного функционала и мусора.
Когда мне, например, достаточно производительности Unity для реализации задуманного, то это осознанный выбор инструмента, способного дать возможность реализовать все, что я хочу. Когда пара студентов взяла Java и стала работать над H&H, у них получилось реализовать кучу интересных механик, при том, что они не гнались за созданием огромного мира с тысячами игроков. Когда у CCP Games была необходимость делать единый сервер для большого мира, они стали использовать Stackless Python, который удовлетворял их нуждам. При чем здесь ограничения ООП, когда их никто ни на кого не накладывает? Люди пользуются методиками и инструментами в рамках поставленной задачи. Да, цена входа разная, конечно, но она соответствует уровню сложности задачи, что вполне закономерно. Хотя, опять же, технологии не стоят на месте, и тренд идет лишь в сторону снижения цены (как в примере введения обозначенных вами технологий в Unity 2018).
Когда вы говорите про ООП, у меня складывается ощущение, что вы имеете ввиду, что весь код, от и до, должен состоять из его атрибутов, и манипулировать только ими. Что все должно упираться в иерархии классов и объекты. Я правильно вас понимаю?
Давайте разграничивать. Языки программирования поддерживают множество парадигм и методов написания кода, даже если они ориентированы в большинстве своем на какую-то конкретную. Код должен быть в первую очередь эффективен. Поэтому вполне логично использовать другие методы в тех местах, где это принесет лучший эффект.
Когда вы ставите ООП главным злодеем и обвиняете в убийстве возможности создавать инновационные игры и расширять функционал, вы, мало того, что игнорируете уже созданные проекты, которые своим существованием просто напросто кричат об обратном, так еще и делаете вид будто программисты ограничены единым методом формирования кода и шаг влево, шаг вправо — расстрел.
ООП языки позволяют писать хороший, «бодрый» код. Да и совсем не обязательно всегда использовать объекты. Здесь уже упоминали structs.
Я погуглил DoD. Собственно, начиная с Unity 2018, если я правильно понимаю, идет адаптация ECS/DoD:
unity.com/unity/features/job-system-ECS
Я взялся за Unity поздней осенью и все еще учу Unity 2017, поэтому руками не щупал, не скажу ничего.
Боттом лайн, это все вопрос оптимизации и производительности, а не экзистенциальный кризис какой-то. Ваш изначальный посыл с использованием слова «убивает» просто не соответствует действительности. «Затрудняет» или «усложняет» — может быть. Но не более.
Иерархии это лишь способ группировать данные/функционал. Для удобства восприятия и работы с ними. Чем лучше сгруппируешь, тем меньше будет конечного кода. Наследование и полиморфизм — тоже способы уменьшить ненужное дублирование, сократить/упростить код, уменьшить работу. Это, в купе с модульностью, и есть шаги к улучшению масштабируемости системы. Плюс, к упрощению одновременной работы над ней множеству людей. Т.е. абсолютно противоположное тому, о чем говорите вы.
Стоит сказать, что я кроме как ООП языками не владею, кроме, разве что, BASIC, которым я последний раз пользовался… м… лет так двадцать назад, будучи школьником. Поэтому никаких контрпримеров с использованием других парадигм я привести не могу. Как именно они могут дать лучшую масштабируемость и простоту работы?
Повторю свою ключевую мысль. Вопросы производительности важны, но они решаемы, причем даже в одно-два лица/разработчика, при мизерном бюджете (см кейс Haven & Hearth). В случае хорошей команды и бюджета побольше они решаемы с очень крутым результатом (см кейс EVE-Online). Поэтому я не вижу особого смысла рассуждать о технической стороне вопроса.
Финансирование и инвестиции в то, что не факт что стабильно заработает или будет интересным — вот это вопрос, да. Но он не имеет отношения к ООП, архитектурам процессоров или гейм дизайну.
Понятное дело, что софт не создается путем бросания денег в монитор. Но, как и со всем остальными предприятиями в жизни, это вопрос знаний, навыков, профессионализма, управления, эффективности, которые и определяют успех.
Несмотря на все это, автор приходит к правильным выводам:
Внезапно оказывается, что это всё бизнес, и дешевле копировать, чем создавать что-то новое. Но в этом то и отличие индустрии от искусства. Приоритеты разные. Только архитектура и гейм-дизайн здесь не при чем.
ООП лишь принцип. Как его применять — отдельная тема. Знание основ Software Engineering для гейм-дизайнера важно (и обязательно в случае с независимыми разработчиками, которые носят множество шляп одновременно). Можно делать плохие системы, а можно и хорошие, регулируя количество внутренних и внешних связей, используя контейнеры и компоненты, и т.д.. Это, в буквальном смысле, целая наука. Требующая профессионального подхода.
Точно также и гейм-дизайн постепенно начинают преподавать в университетах, это же тоже целая наука. А упрощение дизайна систем, в ней, на мой взгляд, не стоит подавать как нечто плохое.
Наоборот, упрощение — крайне полезно. Если можно что-то упростить, не теряя сути, то это плюс, а не минус. Игры должны быть доступны и понятны.
Ведь игра — набор механик, которые призваны создавать некий опыт. Как именно они это делают, иногда скрываясь от взгляда окружающих и срезая углы, там, где это можно сделать, не важно.
PS: начинающий независимый гейм дизайнер/софт инженер, адепт C#/Unity
Спасибо за ссылки.
Да, прозрачность не бывает абсолютной, вопрос в её количестве. И в случае W2, описания скиллов есть, а перки, которые с их помощью открываются видны только по названиям. Описания их эффектов на отдельном экране уже в самой игре. С теми же Pillars настолько все плохо не было %)
Да, если не трудно, это именно то, что я спрашиваю.
Это твои слова, а не разработчика.
Я просто пытаюсь понять, откуда исходит вышеупомянутый тезис. Его здесь часто произносят вслух, в том числе и ты, но я ни разу не видел, чтоб так на самом деле говорили сами разработчики. Так понятно? Я не знаю, как еще иначе спросить.
В Wasteland 2 на старте нужно создавать 4 персонажей. Можно, конечно, использовать тех, что были созданы разработчиками, но это вариант не для всех. Самая большая проблема здесь в том, что игра дает довольно мало информации на этом этапе. Даже перки, открываемые скиллами, непонятно что делают. Это можно будет прочитать уже только после старта. А вот сбросить/пересоздать/создать новых персонажей вам уже не дадут.
Решения подобных проблем уже давно придуманы до нас. Создаем одного персонажа на старте. Делаем более видимым набор выбираемых возможностей. А уже после старта игры, через некоторое время, разрешаем создавать новых компаньонов и сбрасывать прогресс с возможностью перенастройки персонажа. За игровые деньги, конечно же. Но увы, не в W2.
Сама структура скиллов и перков вызывает недоумение. Не то, чтоб я был против «ширины»… Например, Alarm Disarming, Lockpicking, Safecracking — это отдельные навыки. Еще три разных навыка для «убеждения», и так далее. Их довольно много. Это, в общем то, допустимо. Но вот раскидать их по 4 стартовым персонажам, да еще и с расчетом на то, чтоб иметь возможность их всех в макс выкачать, нет. Создавать попутчиков после старта нельзя. Кого ты встретишь в игре, и кого сможешь пригласить в группу — вопрос неоднозначный. Некоторых персонажей ты не встретишь из-за сделанного тобой выбора в процессе игры, и тебе на него ответа никто не даст заранее, если не ходить и не читать интернеты самому, что есть дурной той. Так, если ты не раскидываешь большинство скиллов по стартовым 4 персонажам, можно остаться без них на очень долгое время. Я лично проходил так, что получил второго снайпера, но потерял возможность получить медика. Но мне не нужен второй снайпер. Мне нужен взломщик сейфов. В общем, как я уже сказал, этот вопрос уже продуман и реализован до нас, в тех же Pillars of Eternity, Expeditions: Viking и т.д.
Скилл Heavy Weapons отображен иконкой с ручным гранатометом. Хотя влияет только на пулеметы. А вот перки на гранаты и гранатометы скрыты за скиллом Demolitions, который используется для обезвреживания мин. Модификации к оружию есть даже для палки с гвоздями (например, grip tape). А пулеметы модифицировать нельзя. За что их, пулеметы, на просторах интернетов сильно не любят. Хотя, стоит сказать, незаслуженно.
Баланс также заслуживает внимания. Тяжелая броня практически бесполезна. Оружие разных тиров имеет показатели настолько отличные друг от друга, что страшно представить что происходит в энд гейме. Пушки из начального этапа игры просто мусор в сравнении с энд гейм предметами. Один из двух, если я внимательно смотрел, перк для пользователей тяжелой брони требует прокачки blunt weapons.
В чем сакральный смысл нажимать на рацию и вызывать базу каждый раз, когда персонаж получает новый уровень? Лишние клики. Максимум персонажей — 7. Кол-во уровней — 50. Не у всех левелинг идет равномерно. Сколько раз нужно вызывать базу для осуществления процесса лвл-апа можно посчитать в уме.
Вообще, я долго так могу бурчать. Но, пожалуй, хватит. Игра не обязательно прям плохая. Она заслуживает внимания. Я просто хотел сказать, что можно делать лучше.
Вот кого я, кстати, видел, так это разработчиков, которые не боятся ставить высокие ценники на свои игры. Все настолки стоят дорого (хотя это, скорее, связано с затратами на их издание). И нишевых разработчиков. У которых меньше аудитория. Старые паблишеры, вроде Matrix/Slitherine и Battlefront. У них часто можно встретить игры с ценниками 100 USD и даже выше. Но да, это не ММО жанр, конечно. Но все же.
А вообще, в целом, я в какой-то степени рад тому, что есть плохие геймдевы. Почему? На их фоне проще выделиться. Проще создавать качественный продукт, когда конкуренты не top notch. Я, конечно, лично, еще очень далек до завершения хотя бы одного собственного геймдев проекта и самопубликации, но наличие хреновых гейм дизайнеров в топе мотивирует. Вот, серьезно. Я знаю, что могу лучше. Это ведь тоже, наверное, эволюция?
Далеко за примерами идти не надо. Буквально недавно решил вернуться к Wasteland 2, которую бросил когда-то не пройдя до конца. Посмотрел теперь на нее взглядом гейм-дизайнера. Вспомнил, почему не допрошел. Понял, что Брайан Фарго и ко сделали не так, где, и как можно сделать лучше/исправить. Потом увидел новости, что их купил Майкрософт. И это мотивирует. Потому что можно делать игры лучше, чем они. Работы Обсидиан, к слову, на порядок выше, на мой взгляд. За них вот теперь даже немного страшно.
Помимо того, что моя реакция соответствует большинству реакций людей в комментариях ролика на ютубе, интересно вот что…
1. ССР поняли, что делать физическую привязку к существующему продукту в новой игре не добавляет ему шансов «выстрелить» (что я понял в первый же миг, увидев Dust 514 и сказав — он не взлетит, несмотря ни на какую привязку к EVE). Теперь поняли и они. И не стали связывать РС ММО и новую мобильную ММО. Вау. Они учатся? Или это случайность?
2. Это классический случай большой компании, которая создавая новый продукт… клонирует уже существующий, потому что нельзя же рисковать большим бюджетом! См выпуск Extra Credits посвященный этому вопросу.
3. Сегодня же точно не 1 апреля, да? Уже второй раз проверяю, на всякий случай.
4. Хахахахахахаха…
Даже мой любимый Чаппи отстаёт! Хотя, возможно, разница в количестве fps видео. Видео с большим кол-вом кажется более живым.
Во-первых, мысли излагает (а не диктует истину) гейм дизайнер, а не филолог. Поэтому лингвистический анализ тут излишен.
Во-вторых, ваше пренебрежительно-националистически-дискриминационное необоснованное обобщение (blanket statement) про «американцев», вкупе с минимальным количеством у меня свободного времени, отбивает какое-либо желание детально отвечать вам. Но я постараюсь, насколько меня хватит.
В-третьих,
подобные пассажи у меня просто вызывают недоумение и желание развести руками. Это даже и близко не филологический анализ. Это какая-то ерунда, простите.
Поехали дальше…
Противостояние и соревнование совсем не требует наличие живого противника. Вы можете соревноваться хоть с самим собой. Про то, что «PvE» расшифровывается как «Player versus Environment» вы тоже забыли.
Вы невнимательно читали (возможно, всю статью целиком). Автор пишет дословно:
В чем и описывает отличия симулятора от игры. Игра должна приносить фан. Симулятор не обязан этого делать. Хотя и может.
Ох. Возвращаемся на первую страницу. И читаем:
ambiguous — двусмысленный; неясный; неопределённый; допускающий двоякое толкование; неоднозначный;
В то время как у пазлов может быть только один правильный ответ/решение. Страница номер два:
Да, такая узость мышления, которая позволяет использовать blanket statements, характеризуя целую нацию каким-то специфическим способом, и невнимательно читать, приходя к абсолютно противоположным (упор на ложным) выводам.
Занавес. Давайте не будем больше так?