Чем разработка игр отличается от разработки других программ? [закрыто]

18

Для серьезного разработчика программного обеспечения общего назначения, что конкретно отличается в разработке игр, фундаментально или просто различия в степени?

Я занимался игрушечными играми, такими как Tic-tac-toe, Tetris и решатель судоку грубой силы (с пользовательским интерфейсом), и сейчас я начинаю проект среднего размера (среднего размера, чтобы быть одним разработчиком и не иметь Я сделал много игр), и одна вещь, которую я обнаружил в этом конкретном проекте, состоит в том, что разделение интересов намного сложнее, поскольку все влияет на состояние, и каждый объект может взаимодействовать с любым другим объектом множеством способов.

До сих пор мне удавалось поддерживать код достаточно чистым для моего удовлетворения, но я обнаружил, что поддерживать чистый код в нетривиальных играх намного сложнее, чем в моей повседневной работе.

Игра, над которой я работаю, является пошаговой, и графика будет довольно простой (веб-ориентированной, в основном с помощью манипуляций с DOM), поэтому работа в реальном времени и трехмерная графика на самом деле мне не подходят, но я все равно буду заинтересованы в ответах относительно тех, если они интересны. В основном интересует общая игровая логика.

PS Не стесняйтесь пометить это, я не совсем уверен, какие теги применимы.

Davy8
источник

Ответы:

23

Есть одно важное отличие. На мой взгляд, это единственная разница, которая действительно имеет значение.

Мы можем обсудить технические детали того, почему все по-другому. 3D-движки, физика элементарных частиц, много разных вещей входят в игру.

Но к множеству различных форм программного обеспечения прикреплены строки. Программное обеспечение для моделирования должно делать много одинаковых вещей. У каждого значимого программного обеспечения есть какая-то специализированная библиотека, которую он должен использовать.

Так чем же отличаются ИГРЫ?

Вот оно: Программное обеспечение предназначено для удовлетворения потребностей бизнеса. Вы хотите систему инвентаря? Вы можете определить, какие типы предметов вы должны обрабатывать. Вы можете определить, что вы хотите для вашего производственного планирования. Вы можете сделать все это. Или, если вы хотите банковское программное обеспечение, вы можете определить, что вы хотите с ним делать.

С играми ваш бизнес нужен "весело". Попробуйте написать техническую спецификацию для «развлечения».

По моему скромному мнению разработчика, игры отличаются от обычных программ. Вы просто не можете сказать "Отлично! Это программное обеспечение теперь полнофункционально согласно запросам клиента!" потому что все, что они хотят сделать, это повеселиться.

При этом вам не нужна трехмерная графика и экстравагантная физика, чтобы что-то было забавным. Почему люди до сих пор играют в тетрис? Его физика состоит из «сдвинуть блок вниз», «не дать блоку выйти за границы» и «остановить блок, когда он попадает во что-то», и хотя за прошедшие годы было множество версий, некоторые с более изящной графикой, чем другие, Суть в том - это весело !!

Поэтому, если вы хотите стать великим разработчиком игр, не отказывайтесь от того, что вы узнали как обычный разработчик программного обеспечения. Это все еще очень полезный материал. И @Sion прав насчет разделения ваших компонентов, как и в обычном программном обеспечении. Но самая важная особенность, которую вы можете добавить в свою игру, это развлечение. Весело, весело, весело, весело, весело. Вот почему разработка игр существует, это то, что вам нужно, чтобы ваша игра была успешной. И поверьте мне, как бы весело это ни было играть, это как минимум в 10 раз веселее!

Удачи в вашей игре! : D

corsiKa
источник
2
Если вы поменяете «удовольствие» на «полезное», я думаю, что вы столкнетесь с той же проблемой при разработке продукта (в отличие от написания программного обеспечения для клиента). Я предполагаю, что есть разница в степени, хотя. Люди иногда ошибаются относительно того, что было бы полезно, они обычно не знают, что делает что-то «забавным» для них. (+1, хотя)
Davy8
1
В 60-х годах было принято печально известное постановление Верховного суда, касающееся киноиндустрии для взрослых и того, что классифицировали как «хардкор». Судья сказал: «Я никогда не смогу [определить это], но я знаю это, когда увижу это». Я думаю, что то же самое можно сказать для удовольствия. Я имею в виду, я могу записывать то, что мне нравится в играх, но я часто играю в игру и спрашиваю себя: «Что делает это забавным?» (Очевидно, я хочу знать, чтобы я мог воссоздать это в одной из моих игр !!) Люди не знают, что делает что-то забавным, но они определенно знают, когда они нашли это!
CorsiKa
Мне очень понравился этот пост. Ты так прав. Мне очень нравится разработка игр, но у меня нет того, чтобы видеть, что «весело» для «обычных» людей. Который привел к тому, что я делаю только те игры, которые нравятся мне и некоторым другим гадам, таким как я :)
Phil
1
@Phil, и это нормально. Если вы знаете, что вам нравится, вы должны помнить, что в этом мире есть всего пара сотен архетипов персонажей. Осмотрите свое рабочее место и сравните личности ваших коллег с теми, с кем вы учились в средней школе или колледже. Вы найдете, что большинство из них могут быть сопоставлены. Так что, если вам что-то доставляет удовольствие, то, вероятно, будет веселее для большего количества людей, чем вы думаете Хитрость заключается в том, чтобы они узнали об игре, чтобы они могли наслаждаться ею!
CorsiKa
Это лучший ответ, который я когда-либо видел. Существует масса статей для идей нишевого программного обеспечения и так далее, но не так много о разработке игр. Хммм.
Джонни
21

Я прежде всего разработчик игр, а не традиционный разработчик программного обеспечения, но я думаю, что есть несколько ключевых отличий.

Это, очевидно, несколько обобщений и не всеобъемлющих:
большие команды. Более разнообразные фоны (художники, программисты, продюсеры, у каждого есть еще больше вариаций). Более длительные циклы разработки. Более высокие стандарты производительности. Большой масштаб проектов. Больший и более дорогой риск отказа. Более стрессовая среда.

Что касается взаимодействия объектов и размещения вашей архитектуры, вы все равно можете правильно разделить системы. Ваши игровые объекты и поведение будут явно зависеть друг от друга и от этих систем. Такова природа игры (хотя и каламбур), она объединяет все эти системы в единое целое, и в этом нет ничего плохого. Может показаться, что масштаб всего этого больше, чем вы привыкли.

Некоторые легко идентифицируемые и разделенные системы?

  • Обнаружение столкновений
  • Столкновение Ответ
  • физика
  • Анимация
  • Графика (2D и 3D)
  • Искусственный интеллект
  • Пользовательский ввод
  • Ввод / вывод файла
  • сетей
Сион Шеевок
источник
+1 за хороший ответ на вопрос, хотя для моей конкретной игры мне не приходится иметь дело с большинством из них (пошаговыми и плиточными, поэтому никаких реальных столкновений, никакой физики, графика состоит из спрайтов и бросает больше JQuery на нем 2 игрока, так что AI пока нет, пользовательский ввод обрабатывается в основном RESTful способом, который также охватывает сетевой аспект) Я не совсем уверен, что вы подразумеваете под File IO, хотя, кроме как сказать, что сохранение / загрузка игры виды IO нужны в типичных играх?
Davy8
4
Я согласен с большей частью этого поста и получаю от меня +1, но я бы поставил под сомнение линию «больший и более дорогой риск отказа». Если вы работаете в банке, крупной производственной фирме или на веб-сайте с очень высоким трафиком, ваш сбой может быть измерен сотнями тысяч в минуту простоя в результате сбоя. В течение часа вы можете потерять (в результате упущенных продаж, потерянных клиентов и т. Д.) Больше, чем заработная плата нескольких игровых магазинов в месяц. Я не говорю, что оно не может быть большим, я просто говорю, что не уверен, что оно больше, чем традиционное программное обеспечение.
CorsiKa
@glowcoder Я знаю, что вы говорите, но я также понимаю, что Сион пытается понять, что с играми, как правило, либо весь проект успешен, либо неудачен, и это обычно является фактором того, что вы упомянули в своем ответе : Это весело? Вы можете исправлять ошибки, но не можете исправлять недостаток веселья.
Davy8
3
Я совсем не уверен, что «большие команды» верны даже в качестве обобщения. Конечно, в играх ААА есть большие команды, но и в неигровых программных продуктах. Огромное количество игр производится отдельными лицами или командами из двух или трех человек.
Питер Тейлор
@ Davy8 о, если бы только коммерческий успех игры был пропорционален тому, как это весело. :)
tenpn
2

Я не думаю, что программирование игр отличается от других областей приложений с точки зрения того, что сложнее выбрать правильное разделение интересов. Каждый раз, когда вы переносите свои навыки в область приложения другого типа, вы обнаружите, что переход не так гладок, как вы могли бы надеяться, потому что всегда есть различия. То, что работало в вашем приложении базы данных, имеет много шаблонов / идиом, которые не так хорошо работают во встроенном приложении, которое имеет много шаблонов / идиом, которые не очень хорошо работают в той системе реального времени, которая также имеет много шаблонов / идиом, которые не работайте в программировании игр. Однако у программистов игр возникают те же проблемы, когда они покидают свою область программирования игр. Это всего лишь вопрос того, к чему вы привыкли.

С учетом вышесказанного, я думаю, что программирование игр многим кажется сложнее, потому что оно требует от вас работы с частями компьютера, с которыми большинству программистов никогда не приходится иметь дело на реальной работе (низкоуровневая графика и звуки) и прикладная математика, чем у многих люди чувствуют себя комфортно, а не из-за разделения интересов. Несмотря на то, что всегда трудно определить правильный выбор для разделения интересов, я думаю, что проблема с разделением проблем, с которыми вы сталкиваетесь, просто переходит в новую проблемную область. После того, как вы создадите несколько приложений, это будет, как и все остальное, вы узнаете, что вам нравится, и не будете использовать то, что вы не делаете.

Замочить
источник
0

и одна вещь, которую я обнаружил в этом конкретном проекте, заключается в том, что разделение интересов намного сложнее, поскольку все влияет на состояние, и каждый объект может взаимодействовать с любым другим объектом множеством способов.

Я думаю, что у вас есть ответ, есть много взаимодействий. Я сделал несколько игр с XNA (C #), сейчас я играю в игру среднего размера, как вы говорите, в игру-симулятор стратегии, работаю над ней уже почти 2 месяца, и я делаю это самостоятельно, без посторонней помощи, поэтому я должен держать мой код простым. Я считаю, что одно огромное различие заключается в том, чтобы понять и спроектировать некоторые классы для функциональности, а другие для рисования, это помогает и делает вашу программу чище. Конечно, если вы играете в игру, вам нужно иметь больше ресурсов, таких как изображения (2D или 3D) и музыка (или звуки). Так что есть различия, я думаю, что это сложнее, но это очень забавно.

Zukki
источник
0

Я думаю, что программирование игр веселее. Вы можете постоянно тестировать свою игру, вы реализуете другую физику, что приводит к разному поведению.

По моему опыту, игровое программирование на самом деле намного веселее, чем разработка программного обеспечения. При разработке программного обеспечения у вас есть определенные бизнес-правила, которым нужно следовать, это становится немного скучным. Вы создаете программное обеспечение, это не весело. Использование программного обеспечения - это здорово, полезно, полезно, но не весело.

Игры веселые. Может быть, это только я, но я нахожу разработку игр намного более интригующей и захватывающей, чем традиционная разработка программного обеспечения, независимо от используемых инструментов.

PS: я использую новейшие инструменты для разработки программного обеспечения, HTML5, Asp.Net, C # и т. Д. Я все еще нахожу DirectX, UDK, XNA, Unity более забавным для кода.

harsimranb
источник