Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

element2001

To OOP or not to OOP, that is the question

This topic is 6086 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m new to programming in C++ and opengl. I see in NeHe''s tuts he doesn''t use OOP. I do understand OOP code its just that I''m not how shall I say, fluent in it. So I open up the newest Zelda code and it has been converted to OOP. Well my question is, what is the point to use OOP? I mean if one can code all those tuts without using OOP, then one can also code an entire game without OOP correct? Maybe its just me, because its new to me and I''m used to reading non-OOP code that reading and following OOP code is more difficult, and writing OOP just seems like more unnecessary and complex work compared to writing non-OOP code. Is this just because I''m new to it or does everyone share my views on this? Thanks for responding.

Share this post


Link to post
Share on other sites
Advertisement
OOP is very useful when writing large programs. It allows the programmer to break the game into smaller pieces of code that are easier to write and debug. It also allows the programmer to change parts of code without needing to recompile the entire project.
The most useful feature (and why most people use it) is it allows for code reuse. If you use OOP you can write a code segment, like a engine, and use it in many different programs. This allows you to write programs much faster and easier than if you wrote a special engine for every game you make.


"cogito, ergo sum" -Descartes

Share this post


Link to post
Share on other sites
Along the lines of what what he was saying, if you think about it, everything breaks down into objects.

For example, you have a human object. Then you have arms, legs and feet, and then fingers and toes. Each part controls the other part, and thus, OOP is created.

I find it very easy to implement OOP rather than just functions and variables. It does make maintaining large projects extremely easy.

Just wanted to add that.

-Vic

Go away or I will replace you with a regular expression.

Share this post


Link to post
Share on other sites
It''s a small hill to climb over when your making the transition from procedural to OO programming, but when your on the other side, your glad you made the trip. Just as an example, when writing a game similar to the classic (ect)Mario(ect) sidescrollers:

PROCEDURAL:
Mario''s position is defined in a struct/ globals/ whatever, likewise with all his enemies. All of the functions that deal with that data (jumping, collision detection, firing fireballs, ect) are called somewhere else in the code. In effect, poor mario is spread out all over the place. As far as adding/removing anything goes- you''ll have to hunt for the right location, given that you have functions called from functions called... all the way back to WinMain(); Finally, the function names: Jump(Mario, JUMP_SUPER);
OBJECT-ORIENTATED:
You define a class "character" in character.cpp/.h that has attributes such as screen position, size, health, or whathaveyou... and any functions that deal with that data (move to the left, CheckFalling, ThrowFireball). Everything is in a nice, neat, sorted package. It gets much easier to read, as well- Mario.Jump(JUMP_SUPER);

Anyways... do what you like... but oop definately gets my vote as the way to go.
-Tok.

Share this post


Link to post
Share on other sites
Ah I see. Very nice explanations, thanks very much. Only thing I don''t yet get is in what way 1 class is derived from another. Or even if that need be done in all situations or just in some. But I still have a lot of reading to do on the subject so I''m sure I''ll get there eventually.

Share this post


Link to post
Share on other sites
Just some. To continue with the Mario/character example:

You have a class named Character that contains screen position, size, health...basically anything that all characters would have.

Then you have a class named Mario which has the jump ability, the ability to toss things (since the screen is of SMB2), and so forth. This class is derived from Character since Mario also needs to keep track of screen position, size, health, etc.

You have another class, Monster (since I don''t remember that boss''s name) that is derived from Character and has the functions for spitting eggs.

You also have a generic Character for each of the little monsters that appear on the level that don''t do anything special.

And thus, you have an OOP design (OOD) of both derived classes and non-derived classes.

Hope that made sense : )

Share this post


Link to post
Share on other sites
I love OOP. When I think of making a program, I think in terms of what classes I''ll need to create. That way, if I give up building a program, I''ll have already created classes that I can use elsewhere, even if the program never gets finished. One example I can think of is I designed and coded a whole thing that implements LAN connectivity (both TCP and UDP) with classes for client and server and auto-server-finding capabilities, but to date I haven''t used the code. (Anyone interested?)

Anyway, OOP is good.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Silvanis
You have another class, Monster (since I don''t remember that boss''s name)...

Trivia: Bowser.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!