Back to General and Gameplay Programming

Am I an OOP whore?

elis-cool · 2002-11-21T00:18:17

Ok, so ive started designing my new game, and ive learnt alot from my past one (which you lucky buggers will get to see in a day or two ) and so here are the classes that ive got so far, is going OOP overboard? CSystem // handles initing direct3D, windows code etc... CLog // log file stuffage CTerrain // handles all terrain stuff, quadtree etc CConfig // loads config/ini files and provides set, get methods etc CLight // an instance for each light in the scene CGame // game specific what nots CCamera // handles camera stuff, frustem, position etc etc CParticleSystem // particle processing, seting, manipulation funcs CEntity // player, enemys etc, handles everything about them, eg pos AI etc CObject // models etc, and trigger and stuff for them, eg trees, buildings... etc CSprite // sprite creation, drawing etc routines CSound // speaks for itself CUtilities // misc functions eg all the 'makes life easier for the programmer' type stuff CFont // font drawing, creating stuff CConsole // handles input, output, processing etc CInput // all input related functions... as well as a few internal ones eg: CTextureManager and CSpriteManager [edited by - elis-cool on October 21, 2002 5:49:23 AM]

General and Gameplay Programming Programming

Started by elis-cool October 21, 2002 04:36 AM

36 comments, last by elis-cool 21 years, 5 months ago

Matt Calabrese

122

November 20, 2002 09:40 PM

quote:Original post by JohnBSmall I''d be interested to hear what makes using singleton classes better than using namespaces.

By that I assume you mean a singleton as opposed to a global object or group of variables encapsulatied in a namespace. If not, explain a little further.

--

There are several reasons. The three that stand out immediately to me are:

Dynamic Construction and Destruction : You many times won''t need the object/data for the entire duration of the program so it''s good to be able to construct and destruct the object manually, especially if the object takes up a lot of space in memory.

Order of Construction : Let''s say you have global data in two separate files, but the construction of one requires data directly or indirectly from the other group. For instance, what if you had a global window object and a global renderer object in different files. Let''s say the renderer needs to be associated with a window. It''s hard to be certain which object is being created first, but in order for your program to work properly, it is essential that the window is created first. With 2 singletons you can construct and destruct them in the order you want in whatever functions you want.

Varying Constructors/Arguments : You may want your object to be initialized with different values depending on user input, etc. If it was a fixed global object then you''d be limited to a single construction with fixed parameters, which you often times don''t want.

LordElectro

122

November 20, 2002 09:50 PM

I don''t like the monster inheritence example because I am a fan of having one piece of code be versatile enough to be a demon or hell lord or whatever. If I were writing this game, I would have a CMonster class and have a monster data file format versatile enough to define all sorts of great monsters. With DLLs or a scripting language, it''s possbile to impliment this stuff without any real loss of flexibility while not hard coding a single create in the game.

Granted, such a class might be more work in a small game, but the extensibility this provides is worth it imho.

BetaShare - Run Your Beta Right!

Cold_Steel

835

November 20, 2002 10:02 PM

quote:Original post by LordElectro
I don''t like the monster inheritence example because I am a fan of having one piece of code be versatile enough to be a demon or hell lord or whatever. If I were writing this game, I would have a CMonster class and have a monster data file format versatile enough to define all sorts of great monsters. With DLLs or a scripting language, it''s possbile to impliment this stuff without any real loss of flexibility while not hard coding a single create in the game.

Granted, such a class might be more work in a small game, but the extensibility this provides is worth it imho.

I agree, I would never hard code things like that in my program. I want one class for monsters, one for NPC''s etc, and that''s it. I would not break it down to monster types through inheritance. I try to make my code as extensible and as general as possible. I do this to create a general engine that can be used for all sorts of things.

However, if you are creating a game where the engine will be a one time use thing, then I would hard code things like that in. If you don''t need extensibility, then don''t bother.

I don''t see the whole fuss about whether or not something is OOP or not. It shouldn''t really matter in game programming. Don''t go out of your way to make it OOP, just design the best solution to your problem, regardless of what type of programming structure it uses. If OOP suits your needs best, use it. If functional suits best, use it, etc (not a lot of games programmed in functional languages are there?

) You get the point.

________________________
Grab your sword, and get prepared for the SolidSteel RPG engine, coming soon...(i.e. when it''s done

)

______________________________"Man is born free, and everywhere he is in chains" - J.J. Rousseau

Matt Calabrese

122

November 20, 2002 10:02 PM

quote:Original post by LordElectro
I don''t like the monster inheritence example because I am a fan of having one piece of code be versatile enough to be a demon or hell lord or whatever.

That''s assuming 2 things:

1) You''re implicitly saying that all of your monsters are going to follow a cookie cutter pattern in terms of implementation. With inheritance + polymorphism only the member function names have to be the same, but how it''s implemented can be completely different. Some types of monsters may require more data and some monsters, for example, may attack "differently" than others. In that sense the attack function can be redone, while with just one class it can''t.

2) In order to account for all the variables that you think you need (I say think because there will most likely be more that you may want to implement later but haven''t thought of yet), then you''d have to make each class instance have many datamembers that will not necissarily be used. You''d no longer have the luxury of using static constants that would be used by all instances of a certain type of monster. Instead, you''d have to include all of that data with every single class instance. You may think that you''ve made a "great class that can handle anything" but you''re actually limiting yourself and most likely wasting more space per object than is necissary.

Cold_Steel

835

November 20, 2002 10:25 PM

quote:Original post by Matt Calabrese

That''s assuming 2 things:

1) You''re implicitly saying that all of your monsters are going to follow a cookie cutter pattern in terms of implementation. With inheritance + polymorphism only the member function names have to be the same, but how it''s implemented can be completely different. Some types of monsters may require more data and some monsters, for example, may attack "differently" than others. In that sense the attack function can be redone, while with just one class it can''t.

I would just leave that to a good scripting language, and not deal with anything explicit in my engine code.

Why can''t the attack function be redone. All you need is a very general attack function with a good scripting language to handle the variety of attacks. Then, all you have to do in the attack function is process the script.

________________________
Grab your sword, and get prepared for the SolidSteel RPG engine, coming soon...(i.e. when it''s done

)

______________________________"Man is born free, and everywhere he is in chains" - J.J. Rousseau

Matt Calabrese

122

November 20, 2002 10:45 PM

quote:Original post by Cold_Steel
I would just leave that to a good scripting language, and not deal with anything explicit in my engine code.

Nothing you can do in the scripting language can break the barrier of having those variables that are in your moster class. That''s something you''re limiting in your compiled code.

quote:Original post by Cold_Steel
Why can''t the attack function be redone. All you need is a very general attack function with a good scripting language to handle the variety of attacks. Then, all you have to do in the attack function is process the script.

That''s all well and good if you want to be able to have other people easily make monsters, but it most likely shouldn''t be the whole base for all your monsters. If anything, it''d be more efficient to make all of the monsters you''d use as child classes to the monster object and make another child the one you''d be using in scripting. It gives you more freedom, leaves you a lot more room for optimization, and gives you speed. Relying solely on a scripting language for all of your data and attack functions is just silly. You''d end up with a lot of data per object that you don''t need and you''d be losing out on all the speed.
________________________
Grab your sword, and get prepared for the SolidSteel RPG engine, coming soon...(i.e. when it''s done

)

LordElectro

122

November 21, 2002 12:16 AM

Scripting languages can do a lot more than you think, including the creation of more variables for a particular monster. Stats about the monster that need to be editable through a common editor or something could be flagged as such, and the editor could in turn open up those stats for editing. Hard coding is where you begin to limit yourself, as well as exposing your engine to many possible bugs that have to be tested for in all your monster classes. With scripting you have an extra layer between the engine and the monster code, allowing you to catch errors in monster logic without dealing with application crashes and nasty things.

Put together a scripting language (or get a ready-made one such as Lua) and each monster effectively becomes a plugin. So long as the interface that allows these "plugins" to communicate with your core engine is designed well, you are gaining functionality, not losing it.

Sorry if my sentence structure isn't up to par, I am very sleepy and need to get some sleep *yawn*

Edit: I just noticed you are also mentioning about lost speed, look into DLLs and how they are being used in modern games.

[edited by - LordElectro on November 21, 2002 1:18:17 AM]

BetaShare - Run Your Beta Right!

Shannon Barber

1,684

November 21, 2002 12:17 AM

quote:Original post by Matt Calabrese
Nothing you can do in the scripting language can break the barrier of having those variables that are in your moster class. That''s something you''re limiting in your compiled code.

Sure it could, one of the best things about the soft-architecture of a scripting language is the ability to dynamically add or define properties of objects. Have you read about how the scripting engine for Thief worked?

This isn''t really a reason why OOP code in particular is slow, but following situation is more common in OOP than in something looser.

You''ll end-up with a construct like this:
struct Blob
{
SomeDataType1 data1;
SomeDataType2 data2;
};

Blob blobs[100];

That can be less efficient to manipulate than this:

SomeDataType1 blob_data1[100];
SomeDataType2 blob_data2[100];

But it''s a special case scenario where you manipulate a property of all the blobs independantly from the other properties.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Am I an OOP whore?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Am I an OOP whore?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines