🔒 Locked

Seeking OOD advice/guidance....

Started by core-nuts Dec 18, 2005 at 12:17 PM 4 replies 600+ views

Original Post

Dec 18, 2005 at 12:17 PM

Okay, this is a rather general question, I was just hoping to get a little bit of feedback from people more experienced than I. I learned how to program in C, taking a more procedural approach to any application/game I've written. And now, naturally, this is the way I tend to approach anything I code while I try to figure it out in my head, or put the design on paper. I would like to ween myself off of this approach, and start to use a more object oriented design...and am trying to get more comfortable with C++ and classes and objects. My question is: I am currently completing a connect 4 game that I wrote, and I am not having any problems with the game itself. I have it mostly broken up into classes, and its working fine. However, I have about 6 functions that all relate to the computer AI. All I do is call one function which calls these other functions on its own, and then it returns the best move to me. Now it seems a bit constraining for me to have to put this all in a class, and then declare a new instance of this class, just for one method call...the class doesn't contain any variables or anything besides the functions. I guess I was just hoping for some guidance...from an 'object-oriented' standpoint, would I still want to make a class of this? Would it be okay just to put the functions all in a seperate .cpp file but not within a class. Maybe use a namespace? Or is it just totally preference and what works for me? I am trying to develope my style so that it would be logical, as well as easy for other people to use if I were to work in a group or at a job. Any suggestions/advice would be MUCH appreciated. Thanks!

BobV

Dec 18, 2005 at 12:25 PM

It's not uncommon to create utility classes with static methods. You can create a simple AI Utility class and add all of these methods there for now.

You'll see that type of design used with many libraries. It's very common in maths libraries where a bunch of static functions have been tied to a particular class for organizational purposes.

hplus0603

Dec 18, 2005 at 12:30 PM

Note that a utility class with static functions is not any more object oriented than a utility file with global functions -- it just uses the "class" as a convenient way of bundling the global functionality (instead of, say, naming prefixes).

You don't need to make everything a little object to benefit from object oriented design. In fact, most systems that go all the way and make everything an object suffer from pretty poor performance, compared to a system that uses the right abstraction for the right problem.

In the end, you should learn a bunch of different kinds of design (procedural, object oriented, functional, dynamic, etc) and choose the right tool for each design job.

Now, when it comes to AI: Is "AI" a service in your application? Do you expose services, such that you could ask for the "AI" service, and register interested clients of the service? Assume that you needed to run your "AI" on more than one entity (not just the player), and perhaps it will turn out that the AI service makes sense as an object of its own -- not static!

GDKnight

Dec 18, 2005 at 12:39 PM

One good way to learn Object Orientated design is to learn UML. I finished a class on it just recently it was pretty good.

Now I tend to break all my code into objects, your talking about taking your AI functions and composing a class. This is a good idea, most of my engines have an AI manager that handles all of the AI throughout the game, by accessing other classes that relate to the AI. For example the AI Manager might have a Monster class it uses that defines the type of monster etc.

Now if your code really is not that complex you really don't need to do it. Object orientated programming has its place and time, it really is not always needed. You can do it if you want it really shouldn't matter that much, I really like object orientated programming so I probably would have already done it.

BobV

Dec 18, 2005 at 12:42 PM

After rereading your post, this sounds like more of a design issue.

Your basic structure for player/ai would be something like this:

Player -> you abstract base class
PlayerHuman -> extends the base class and retrieves it's input from keyboard/mouse
PlayerComputer -> extends the base class and retrieves it's input from the ai (which is probably where you'd stick your ai methods)

As you extend your game you can easily create
PlayerNetwork -> Just like player/playerhuman but reads it's input from a socket

Then the difference between having a human/human at the same computer or human/network or human/ai would be what you casted your player objects from.

core-nuts

Dec 18, 2005 at 12:55 PM

Wow, thanks for the quick replies!

And to the last reply...I am sure that my design is far from 'ideal'...that's my problem right now. I know the syntax of C++ and I can get just about anything 'working.' But my brain thinks procedurally, and I have a hard time with the actual design aspects.

That said, the game was really simple. I basically just have a class dealing with the game loop and setting everything up for the game. A class that deals with the graphical aspects, and then a class that deals with all the AI and figuring out where the computer should move. In the game loop, if it is the computer's turn it will call the AI 'getMove' function, and then do that move. If it is the player's turn, it just goes to the event handler.

I can see where having the more abstract player class would make the program much more extendable and easier to design, I guess I just didn't even think about that for a project this small. I guess thats why I'm struggling a bit with the object oriented approach.

I think I just need to continue to just do it, and read more about it and eventually it will start to come a little more naturally...heh.

Anyways, thanks so much for the replies.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.