• Advertisement
Sign in to follow this  

Anti-OOP (C++)

This topic is 4230 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

Hey everyone. I've been away from programming for some time now and I want to get back into it before school starts again. But I was wondering if it would be at all possible to create a decent text-based RPG without using classes and object oriented things? I realized it will probably be a royal mess, but i'd rather not mess with OOP yet. . . unless I have to. Any suggestions? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
any reason why you wouldn't want to use objects? They're not that hard once you get going with them, and you don't have to go insane with them. They're a tool, but not the only way. you can mix things easy enough, use classes where you need to, and don't go over board with them.

Share this post


Link to post
Share on other sites
Of course it would be possible to create a text RPG or any other project without OOP. After all, its been done this way for years.
Its better you do good function-based code than bad object oriented code. But note the productivity is greater using modern approach... so consider mastering OOP at some point.

To make the game (or any other project) even in function based code you can and should use OOP ideas -

1) try to abstract as much as you can: make a struct of data and a set of functions for stuff like Room, Monster, Weapon, Player.
2) each such element should not be aware of the inner workings of another type of element - changing the workings of one should not effect the entire project.
3) Plan well what data each elemant needs and how the framework of the game activates the different elements.
4) Im sleepy now so cant think, but this list should be longer.

Iftah.

Share this post


Link to post
Share on other sites
Quote:

1) try to abstract as much as you can: make a struct of data and a set of functions for stuff like Room, Monster, Weapon, Player.
2) each such element should not be aware of the inner workings of another type of element - changing the workings of one should not effect the entire project.
3) Plan well what data each elemant needs and how the framework of the game activates the different elements.


How is that not OOP? What do we mean when we say OOP here? The C++ syntax?

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
How is that not OOP? What do we mean when we say OOP here? The C++ syntax?


1) its not entirely OOP as it has no inheritence and no polymorphism.
2) note I did say these are OOP ideas, I didnt try to hide it.

Sometimes you need to read between the lines -
I assumed the original poster meant he masters C but not C++, so I tried to make him program some OOP style and still remain in his knowledge base.

no scary copy-ctors/destructors/operator-overloading/iterators/virtual-methods.


edit: to the orignial poster -
Talroth has a point - you can try write the elements I described above as class - which is simply the structs with the data and the functions combined. Its realy not complex at all and I highly recomend it. Later on if you do learn OOP and C++ you can add inheritence and use polymorphism to farther organize your program.

Share this post


Link to post
Share on other sites
Quote:
Original post by Iftah
Quote:
Original post by mikeman
How is that not OOP? What do we mean when we say OOP here? The C++ syntax?

1) its not entirely OOP as it has no inheritence and no polymorphism.
2) note I did say these are OOP ideas, I didnt try to hide it.

In my understanding - which is admitedly not perfect - inheritance and polymorphism are language feature, not OO features. You can perfectly use OO in a language that don't have these features. OO is a programming paradigm, where you differentiate data and actions. The data are represented as properties while the actions are represented by messages that are sent to the data holder (I don't use the word "message" without reason: this is the real OO terminology for C++ methods). I'm with mikeman with this one - but this is not really important because I believe that metal_kid43 used the term OOP ambiguously.

I use the OO paradigm quite extensively, even when I program in C: in this case, I will use structs to store the object properties and functions to handle them. Semantically, there is no difference between this approach and the other major OO language approach.

That said, I agree with the rest of your post: I'd suggest metal_kid43 to use the OO paradigm without the difficult syntax of the OO languages (although C# tend to be very simple; it can be a good introduction to OO languages). The paradigm itself is not very hard to understand: to simplify, we consider that everything is an object. We give them properties and actions. In fact, this is often what we do when we use a procedural language like C or pascal, but we don't give it its proper name because we often think that OOP can only be done using a OO language.

To answer to metal_kid43's question, I'd like to add that most older MUDs were written in C, so it's definitely possible to create a good, complex text RPG using a procedural language. The approach, however, is likely to be a OO-like approach, as they tend to simplify the design of such program.

HTH,

Share this post


Link to post
Share on other sites
Quote:
Original post by Emmanuel Deloget
Quote:
Original post by Iftah
Quote:
Original post by mikeman
How is that not OOP? What do we mean when we say OOP here? The C++ syntax?

1) its not entirely OOP as it has no inheritence and no polymorphism.
2) note I did say these are OOP ideas, I didnt try to hide it.

In my understanding - which is admitedly not perfect - inheritance and polymorphism are language feature, not OO features. You can perfectly use OO in a language that don't have these features. OO is a programming paradigm, where you differentiate data and actions. The data are represented as properties while the actions are represented by messages that are sent to the data holder (I don't use the word "message" without reason: this is the real OO terminology for C++ methods). I'm with mikeman with this one - but this is not really important because I believe that metal_kid43 used the term OOP ambiguously.

I use the OO paradigm quite extensively, even when I program in C: in this case, I will use structs to store the object properties and functions to handle them. Semantically, there is no difference between this approach and the other major OO language approach.

That said, I agree with the rest of your post: I'd suggest metal_kid43 to use the OO paradigm without the difficult syntax of the OO languages (although C# tend to be very simple; it can be a good introduction to OO languages). The paradigm itself is not very hard to understand: to simplify, we consider that everything is an object. We give them properties and actions. In fact, this is often what we do when we use a procedural language like C or pascal, but we don't give it its proper name because we often think that OOP can only be done using a OO language.
HTH,


Well, polymorphism is a cornerstone of OOP, but inheritance isn't. It's just a way of implementing polymorphism in static-typed languanges. The thing is, in the RPG the character may hold a Weapon that can be a sword,a crossbow,a hammer,etc. and each one has different behaviour. So the OP will most definately end up doing something like this:


enum Weapon_Type{Sword,CrossBow,Hammer};
struct Weapon
{
//stuff here...
Weapon_Type type;
};

void Weapon_Use(Weapon *weapon)
{
//here goes code common for all types of weapons...

switch (weapon->type)
{
case Sword:
//handle sword here...
case CrossBow:
//handle crossbow here...
case Hammer:
//handle hammer here...
}
}





which is an implementation of a polymorphism scheme.

Share this post


Link to post
Share on other sites
Quote:
Original post by metal_kid43
[..]I was wondering if it would be at all possible to create a decent text-based RPG without using classes and object oriented things? I realized it will probably be a royal mess, but i'd rather not mess with OOP yet. . . unless I have to.


Yes. Infact, you can create a MMORPG without any OOP design, even in a OO language (Have a look at my Fleurin project some time).

If you don't want to use OOP, you don't have to. Remember, it is a preference.

Share this post


Link to post
Share on other sites
If you're going to try to do anything at all complicated, you better have a good way of organizing things. OOP happens to be a good way of handling a lot of problems in the general area of "organizing things", but is certainly not the only way.

That said, what do you have *against* OOP? What do you think "OOP" *is*, anyway? o_O A lot of people have some *very* strange concepts of it...

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
Well, polymorphism is a cornerstone of OOP, but inheritance isn't. It's just a way of implementing polymorphism in static-typed languanges. The thing is, in the RPG the character may hold a Weapon that can be a sword,a crossbow,a hammer,etc. and each one has different behaviour. So the OP will most definately end up doing something like this:

*** Source Snippet Removed ***

which is an implementation of a polymorphism scheme.

I should note that most people don't actually know OO/OOD/OOP at all, as demonstrated by the fact that most people don't even know about the 5 principles of Object Orientation. On that note however, no one with any serious design experience would write C code like that. It would be more like:
typedef struct WeaponT{
/*... stuff*/
void (*WeaponHandlerPtr)(struct WeaponT*);
}Weapon;

void UseWeapon(Weapon* p) {
p->WeaponHandlerPtr(p);
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Quote:
Original post by mikeman
Well, polymorphism is a cornerstone of OOP, but inheritance isn't. It's just a way of implementing polymorphism in static-typed languanges. The thing is, in the RPG the character may hold a Weapon that can be a sword,a crossbow,a hammer,etc. and each one has different behaviour. So the OP will most definately end up doing something like this:

*** Source Snippet Removed ***

which is an implementation of a polymorphism scheme.

I should note that most people don't actually know OO/OOD/OOP at all, as demonstrated by the fact that most people don't even know about the 5 principles of Object Orientation. On that note however, no one with any serious design experience would write C code like that. It would be more like:
*** Source Snippet Removed ***


I know, actually I initally wrote my post exactly like that. I decided I didn't want to give that example though because it's basically a virtual function table, so you're basically implementing a full-blown OO design using C. I wanted to show that even in you insist in a more procedural programming(using switches and type identifiers like enums), you will still end up implementing polymorphism one way or the other, since we're talking about an RPG with all its character classes and subclasses and item types and whatnot.

As for the 5 principles of OO, of course I know them but I still believe that inheritence is not really essential for OOP. That's strictly my opinion though.

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
I know, actually I initally wrote my post exactly like that. I decided I didn't want to give that example though because it's basically a virtual function table, so you're basically implementing a full-blown OO design using C. I wanted to show that even in you insist in a more procedural programming(using switches and type identifiers like enums), you will still end up implementing polymorphism one way or the other, since we're talking about an RPG with all its character classes and subclasses and item types and whatnot.

Might as well go all the way:
struct TypeVTable {
void (*ConstructorMethodPtr)(void *);
void (*DestructorMethodPtr)(void *);
};

struct WeaponVTable {
struct TypeVTable typeVTable;
void (*UseWeaponMethodPtr)(struct WeaponT*);
};

typedef struct WeaponT {
struct WeaponVTable* vtbl;
/* data */
}Weapon;

void SwordWeaponConstructor(struct WeaponT* p) {
}
void SwordWeaponDestructor(struct WeaponT* p) {
}
void SwordUseWeapon(struct Weapon* p) {
}

void HammerWeaponConstructor(struct WeaponT* p) {
}
void HammerWeaponDestructor(struct WeaponT* p) {
}
void HammerUseWeapon(struct Weapon* p) {
}

void TentacleWeaponDestructor(struct WeaponT* p) {
}
void TentacleWeaponConstructor(struct WeaponT* p) {
}
void TentacleUseWeapon(struct Weapon* p) {
}

void ConstructType(void* p) {
size_t* ip = (size_t*)p;
((struct TypeVTable*)ip[0])->ConstructorMethodPtr(p);
}
void DestroyType(void* p) {
size_t* ip = (size_t*)p;
((struct TypeVTable*)ip[0])->DestructorMethodPtr(p);
}

enum WeaponType {
WT_SWORD,
WT_HAMMER,
WT_TENTACLE
};

Weapon* CreateWeapon(enum WeaponType type) {
static struct WeaponVTable vtables[] = {{{SwordWeaponConstructor, SwordWeaponDestructor}, SwordUseWeapon},
{{HammerWeaponConstructor, HammerWeaponDestructor}, HammerUseWeapon},
{{TentacleWeaponConstructor, TentacleWeaponDestructor}, TentacleUseWeapon}
};

Weapon* w = malloc(sizeof(Weapon));
w->vtbl = &vtables[type];

ConstructType(w);

return w;
}


Quote:
As for the 5 principles of OO, of course I know them but I still believe that inheritence is not really essential for OOP. That's strictly my opinion though.

Inheritance isn't mentioned in the 5 principles. For the most part they deal with the concept of modules, not classes, nor "objects" (quoted because most peoples conception of what an object is, is wrong). Some like LSP make reference to inheritance and polymorphism, but the original statement does not make any mention of those terms:
Quote:
What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
Note that objects could be construed as anything here, modules, methods, classes, etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
Quote:
As for the 5 principles of OO, of course I know them but I still believe that inheritence is not really essential for OOP. That's strictly my opinion though.

Inheritance isn't mentioned in the 5 principles. For the most part they deal with the concept of modules, not classes, nor "objects" (quoted because most peoples conception of what an object is, is wrong). Some like LSP make reference to inheritance and polymorphism, but the original statement does not make any mention of those terms:
Quote:
What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
Note that objects could be construed as anything here, modules, methods, classes, etc.


Sorry, what sources I've read stated that the principles are Encapsulation,Composition,Classes,Inheritence,and Polymorphism so I though you were reffering to those.

Share this post


Link to post
Share on other sites
He's probably referring to the alphabet soup principles: SRP, OCP, LSP, DIP and ISP. (Single Responsibility, Open-Closed, Liskov Substituion, Dependency Inversion and Interface Segregation Principles)

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
Sorry, what sources I've read stated that the principles are Encapsulation,Composition,Classes,Inheritence,and Polymorphism so I though you were reffering to those.

Actually none of those are in the five basic principles of the paradigm.

EDIT: nevermind I didn't see that SiCrane had already answered this.

Share this post


Link to post
Share on other sites
Quote:
Original post by SiCrane
He's probably referring to the alphabet soup principles: SRP, OCP, LSP, DIP and ISP. (Single Responsibility, Open-Closed, Liskov Substituion, Dependency Inversion and Interface Segregation Principles)

Those are the correct principles I was refering to.
Quote:
Original post by mikeman
Sorry, what sources I've read stated that the principles are Encapsulation,Composition,Classes,Inheritence,and Polymorphism so I though you were reffering to those.

Those aren't principles of OO, they are terms that get used a lot by people who don't know a whole hell of a lot about OO. "Classes" is one of those terms that I see getting tossed around as being "something object oriented". When in reality they have nothing at all to do with OO, although they CAN be used in that fashion. To be frank, if you don't know those 5 principles, what they mean and how to apply them, then you don't know OO. Typically people associate them with "design" (because they are fairly abstract), but in reality those are guidelines for coding an OO application along with designing it. If you were never taught those, but took an OO course in school...you should complain. Because they weren't teaching you Object Orientation, but "Classes and all the funky shit you can do with them."

Some decent introductory material on them:
The Single Responsibility Principle
The Liskov Substitution Principle
The Interface Segregation Principle
The Dependency Inversion Principle
The Open Closed Principle

Share this post


Link to post
Share on other sites
Wow, thanks for all the response. Just for clarification. . . I guess my thread title is a bit misleading. I dont have anything agains OOP, i just dont know how to use it yet.

Share this post


Link to post
Share on other sites
I wrote a Graphical Final Fantasy 2-like RPG engine in QuickBASIC 4.5 (a procedural, non-OO language) that was nearly 100k of source code and quite complete. Even though it was a BASIC variant, I encorporate many OO features and philosophies by leveraging what the language made available. My sub-systems were isolated frome one another with only neccesary API functions exposed to the rest of the game engine and with their own state information, essentially making them a class unto themselves. By writing similar subsystems to a common set of exposed API functions I managed something akin to polymorphism or derivation from a common interface, where I could swap my Dragon-quest style battle system for my final-fantasy-like battle system. I'm a little pressed to think of any more examples since its been some 7 years or so, but I'm certain that there are many more examples within that code.

While its entirely possible to impliment a large game in a language without builtin OO concepts, good designs tend to incorporate OO features into the codebase anyway. As weve already seen, C function pointers can be used to impliment a form of virtual functions for instance. You find this type of thing alot in old C codebases, just take a look at the doom/quake source... In the end, its generally easier to just use an OO language unless you have a compelling argument or preference against it. Games tend to be very object oriented in nature, RPGs I would argue most of all, so limiting yourself to proceedural techniques is a bit like trying to drive a nail with a screwdriver. Non-OO languages have their place tackling non-OO problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Washu
that fashion. To be frank, if you don't know those 5 principles, what they mean and how to apply them, then you don't know OO.


Well, to be honest I've never heard of them by name, but I read the material you provided(many thanks!) and I recognized in all of them things I try to do every day when I'm coding. It's also interesting that some problems can't seem to be solved very elegantly in C++ while respecting those principles, especially the open-closed principle.

Share this post


Link to post
Share on other sites
Quote:
Original post by mikeman
Quote:
Original post by Washu
that fashion. To be frank, if you don't know those 5 principles, what they mean and how to apply them, then you don't know OO.


Well, to be honest I've never heard of them by name, but I read the material you provided(many thanks!) and I recognized in all of them things I try to do every day when I'm coding. It's also interesting that some problems can't seem to be solved very elegantly in C++ while respecting those principles, especially the open-closed principle.


Trueness inside.

It is true that the OO principle really help when you are designing softwares. There are also other tools that might heklp (for example, the law of demeter - which is a simple coding rule; give it a try, it is worth it). This codeguru thread lists some other design tools (and misuse the term principle, sorry for the inconvenience; RC Martin is a great guy but he tends to abuse the term "principle").

Regards,

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
>I was wondering if it would be at all possible to create
>a decent text-based RPG without using
>classes and object oriented things?

Of course it's wonderfully possible.
( Lots of games were written in programing langauges that
didn't support Object Oriented programming.
Quake 1,2, and 3 were written in C. )

> I realized it will probably be a royal mess,

You can write wonderfully organized and functional code using functions or procedures.

Don't let anyone else stifle your creativity.
If your "gut" tells you to use a procedural programming style,
I say go for it!

Users of your game could care less about HOW you wrote the game.
All they care about is if it's good or not.




Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement