Различия в дизайне игры с процедурными языками и языками ООП

0

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

Большинство обучающих программ и страниц, которые я видел, которые используют язык ООП (например, C++ или Java) используют объекты для создания в основном всего, что используется в игре, например класс для управляемого пользователем символа, класс для пули на экране, класс для эффектов дыма, еще один класс для летающей стрелы и т.д.

Мой первый вопрос заключается в следующем: является ли идея реализации всего в игре как класса "нормальной" или "рекомендуемой" идеи принять? Это как я должен написать свою игру, если я использую язык ООП?

Мой второй вопрос заключается в следующем: если кто-то должен был написать игру на процедурном языке, таком как C, как бы вы начали создавать ту же систему? Я не могу создать объект для каждого элемента игры. Предположительно, я бы создал struct и имел массив указанных structs? Кроме того, с дизайном ООП у меня будет каждый объект, способный контролировать себя (например, обнаружение столкновения). Как я могу достичь этого на языке процедур? Есть какой-то код, который выполняет итерацию через каждую struct и управляет каждой структурой оттуда?

  • 0
    Вы можете написать OO-код на языке C. И хотя OO является де-факто шаблоном проектирования в наше время, это не означает, что вы всегда неизбежно должны думать обо всем как об объектах.
Теги:
oop
procedural-programming

3 ответа

5
Лучший ответ

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

Что касается вашего второго вопроса: если язык по вашему выбору не позволяет приблизиться к естественной реализации, вы захотите попытаться смоделировать его как можно ближе к этому. Чтобы подобрать свой пример: вы бы моделировали свои объекты с помощью структур (свойств) и соответственно выполняли поведение - либо с функциями, работающими над этими структурами (например, enemy_hit (player)), либо с указателями функций, содержащимися в структурах (т.е. player-> hit (игрок,...)).

  • 0
    Это было очень информативно, спасибо. Принято как ответ.
2

Чтобы добавить к другим ответам.

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

Я хотел добавить, что, помимо того, что они настолько модулярны и естественны, объектно-ориентированные языки также поддерживают полиморфизм, который я использую много и очень трудно использовать в процедурных языках. Полиморфный код позволяет использовать слои абстракции, которые упрощают проектирование вашего общего поведения (оружие, персонажи и т.д.), А затем переходят к конкретным, различным реализациям (стрельба, стреляющая таким образом, стрельба пушками и т.д.) В зависимости от ваших ситуаций. Вы можете использовать конкретные реализации, даже не требуя знать о них (как программист, использующий API-интерфейс), поскольку вы всегда можете использовать их интерфейсы. Там также есть общее программирование, которое допускает даже более глубокие абстракции.

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

0

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню