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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Обнаружение столкновений
• Столкновение Ответ
• физика
• Анимация
• Графика (2D и 3D)
• Искусственный интеллект
• Пользовательский ввод
• Ввод / вывод файла
• сетей

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

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

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

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

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

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

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

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