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