Game design differences with procedural and OOP languages [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

This is probably going to be more of a question about how OOP languages and procedural languages are used to design a game.

Most tutorials and pages I've seen that are using an OOP language (eg. C++ or Java) use objects to create basically everything used in the game, for example a class for the user controllable character, a class for bullets on screen, a class for smoke effects, another class for a flying arrow etc.

My first question is this: Is the idea of implementing everything in the game as a class a "normal" or "recommended" idea to adopt? Is this how I should write my game if I'm using a OOP language?

My second question is this: If someone was to write a game in a procedural language such as C, how would you go about creating the same system? I can't create an object for each in game item. Presumably, I would create a struct and have an array of said structs? Also, with a OOP design I would have each object being able to control itself (eg. collision detection). How would I achieve this in a procedural language? Have some kind of code which iterates through each struct and manipulates each struct from there?

Answer 1

Regarding your first question: This is just how things come along the natural way. When you think about your game, you will think about the player, enemies, scenes, rooms, weapons, objectives etc. pp. - all those things are naturally modeled as objects in the sense that they group properties (i.e. member variables) and behavior (i.e. methods). So that is just the way it usually is, and if the language that you choose to implement that stuff provides a way to express this, why would you not use it?

Regarding your second question: if the language of your choice does not allow a close to natural implementation, you will want to try to model it as closely as possible to that. To pick up your example: you would model your objects with structs (properties) and implement behavior accordingly - either with functions operating on those structs (e.g. enemy_hit(player)) or with function pointers contained in the structs (i.e. player->hit(player,...)).

Answer 2

To add to the other answers.

The OO paradigm is indeed a natural one to approach with things such as games, and if you are forced to use a procedural paradigm, you should probably try to mimic an OO behavior.

What I wanted to add is that, apart from being so modular and natural to think in, object-oriented languages also support polymorphism, which I use a lot and find very hard to make use of in procedural languages. Polymorphic code allows for abstraction layers that make it so much easier to design your general behaviors (guns, characters etc), and then move on to concrete, different implementations (guns firing like this, guns firing like that etc) depending on your situations. You can use concrete implementations without even needing to know about them (as a programmer using someone's API), as you can always use their interfaces. There's also generic programming, which allows even deeper abstractions.

The argument with abstractions is useful when you're designing clean, expandable, maintainable code for your game.

Answer 3

OO is more than just a package of data and functions. But anyway there is no strict restriction on how to design game and how to implement them, most designers are not programmer, and they think by rules and story boards.