Отличия игрового дизайна от процедурных и ООП языков
Вероятно, речь пойдет о том, как языки ООП и процедурные языки используются для разработки игры.
Большинство учебных пособий и страниц, которые я видел, которые используют язык ООП (например, C ++ или Java), используют объекты для создания в основном всего, что используется в игре, например, класс для контролируемого пользователем персонажа, класс для пуль на экране, класс для эффектов дыма, другой класс для летающей стрелы и т. д.
Мой первый вопрос таков: является ли идея реализации всего в игре как класса «нормальной» или «рекомендуемой» идеей для принятия? Это то, как я должен написать свою игру, если я использую язык ООП?
Мой второй вопрос: если бы кто-то написал игру на процедурном языке, таком как C, как бы вы создали такую же систему? Я не могу создать объект для каждого предмета в игре. Предположительно, я бы создал struct и есть массив сказанного structs? Кроме того, при разработке ООП каждый объект мог бы контролировать себя (например, обнаружение столкновений). Как бы я достиг этого на процедурном языке? Есть какой-то код, который проходит через каждый struct и манипулирует каждой структурой оттуда?
Решение
Относительно вашего первого вопроса: это так, как все происходит естественным путем. Когда вы думаете о своей игре, вы будете думать о игроке, врагах, сценах, комнатах, оружии, целях и т. Д. — все эти вещи естественно моделируются как объекты в том смысле, что они группируют свойства (то есть переменные-члены) и поведение (т.е. методы). Так что это обычно так, и если язык, который вы выбираете для реализации этого материала, предоставляет способ выразить это, почему бы вам не использовать его?
Что касается вашего второго вопроса: если выбранный вами язык не допускает реализации, близкой к естественной, вы захотите попытаться смоделировать его как можно ближе к этому. Чтобы подобрать пример: вы должны смоделировать ваши объекты со структурами (свойствами) и соответствующим образом реализовать поведение — либо с функциями, работающими с этими структурами (например, вэг_хит (игрок)), либо с указателями функций, содержащимися в структурах (например, игрок-> удар ( плеер, …)).
Другие решения
Чтобы добавить к другим ответам.
Парадигма ОО действительно является естественной для подхода к таким вещам, как игры, и если вы вынуждены использовать процедурную парадигму, вам, вероятно, следует попытаться имитировать поведение ОО.
Я хотел бы добавить, что объектно-ориентированные языки, помимо модульности и естественности мышления, также поддерживают полиморфизм, которым я часто пользуюсь, и на процедурных языках очень трудно ее использовать. Полиморфный код допускает слои абстракции, которые значительно упрощают разработку вашего общего поведения (оружие, персонажи и т. Д.), И затем переходите к бетону, различным реализациям (оружие стреляет как это, оружие стреляет как это и т. д.) в зависимости от ваших ситуаций. Вы можете использовать конкретные реализации, даже не зная о них (как программист, использующий чей-то API), так как вы всегда можете использовать их интерфейсы. Есть также общий программирование, которое позволяет даже более глубокие абстракции.
Аргумент с абстракциями полезен, когда вы разрабатываете чистый, расширяемый, поддерживаемый код для своей игры.
ОО — это больше, чем просто пакет данных и функций. Но в любом случае нет строгих ограничений на то, как разрабатывать игры и как их реализовывать, большинство дизайнеров не программисты, и они думают по правилам и раскадровке.