My advice would be to avoid OO programming until you need it. You know you need it (or some other kind of design paradigm) when you can't clearly detail the structure of your program.

Only read the first post and skimmed the rest but It seems like you're doing (and horrendously enough) getting advice advocating the use of a GodClass. That generally regarded an anti-pattern by experienced OO folks.
Robert Martin has a lucid article based on his experience teaching OO and one exercise there, it's about building a CoffeMaker as trivial as the example seems if you read the article you'll see that the usual solution inexperienced designers come up with very closly resembles what have drawn up in this thread, he then goes to remedy the whole situation somewhat and arrive at a cleaner sounder design.

BUFD is out XP is in ;)

Okay... I read the coffeemaker lesson, and some other intro to UML stuff, and I am attempting to use this to make a UML diagram for my game. What I want to know now is, where does the data go? Object oriented design philosophy suggests that each object should contain its own data. This is fine for read-only data that is only used by one object - for example FMVs are only used by the FMV player. But what about data that can be accessed by more than one object - for example my RNPCs' current relationship scores? I want to keep all my game state data in a database so it's organized, compact, easy to change, and easy to write to a save game file. My roommate says this is a bad idea. What do you all think?

Your game object graph IS a database. In fact, you should probably even have a means of querying it for information. One common way of implementing this is through the Interpreter pattern [GOF]. Assuming that your RNPC relation ship data is in the object graph, and hence the database, you should be able to query it.

*blink* Um, but aren't objects supposed to contain functions and data, while databases are not supposed to contain functions, only data?

Quote:

Original post by sunandshadow *blink* Um, but aren't objects supposed to contain functions and data, while databases are not supposed to contain functions, only data?

You could represent a database as an object whose functions represent the operations you could preform on it (like selecting an element, adding an element, etc).

Do NPCs have relationships with each other? Sounds like you need to put a relationship matrix (2D array) somewhere. That or give a linked list of existing relationship scores for each NPC to another NPC.
For the matrix, something like "NPC_Manager::CheckFirstToSecond(int firstNpcID, int secondNpcID)"?

Quote:

Original post by sunandshadow *blink* Um, but aren't objects supposed to contain functions and data, while databases are not supposed to contain functions, only data?

Not at all, if you think of a SQL database, then yes. But a "database" is not nearly so limited as to exclude functionality. In fact, ORDBS are a common form of database that integrate the ideas of an object, and the ideas of using relational storage idioms. The objects are not just serialized types, but actual functioning objects with methods you can query. A filesystem could be considered both an object, and a database. It has functionality for creation and manipulation, at the same time it stores data about the things in it.

A graph of objects, stored in memory, is a database. It's not your usual relational database, but a database none the less. Having a means of querying said database is important. Equally as important is the ability to have the queries be fairly dynamic, hence the use of the Interpreter pattern. The Interpreter pattern allows you to expose a series of objects that give you the ability to query for certain conditions, attributes, nodes, and other features of your graph. You can then combine these objects in a variety of ways for form your ultimate query. In case you haven't read up on it, it's basically building a tree of execution.
Example:

Okay! [smile] After 4 drafts I have a class diagram which is hopefully not too horrible to show you guys!

Color Key:
Anything orangey is a menu. Anything green has to do with objects in the gameworld. Hopefully the rest is self-explanatory. [wink]

Feedback please?

s/s: Some of your classes don't make a lot of sense, your 'start' and 'end' boxes resemble game states.

For your question about OO, you can use OO for NPCs relations interactions in the following sense: (if you try to do it completely OO)

Each RNPC contains a list of cProfile objects, each cProfile object contains all the data that RNPC A knows about RNPC B. For example, if character A knows B, C, and D, then, under character A's cProfile list there will be three cProfile objects for B, C, and D.

Functions are encapsulated in the sense that if you put A and B together for a 'generic romatic dinner with meal course X', then, under cProfile, there is a function called like this:

cProfile::GenericRomaticDinnerMealCourseX(cProfile* npcXY, cProfile* npcYX)

This is a class function that deals with all the profile simulation and changes during the course of the romatic dinner, where npcXY is npc X's profile of Y, and npcYX is npc Y's profile of X.

Suppose there are more than one meal plans, and you want to OO it. Then your class function may look like this:

cProfile::RomaticDinnerTemplate(cProfile* npcXY, cProfile* npcYX, cMealPlan* m)

And this function handles all the relationship changes between X and Y due to a dinner together with mealplan m.

A more generic class function maybe probably like this:

cPresent::Meeting_XY(cEvent* e, cCharacter* x, cCharacter* y)

where cEvent contains data specifying what kind of event it is, (dinner is a type of event, duel is another type). Within the code of Meeting_XY, there will be function calls to various dialogues and cutscene class functions. For example, the meeting may begin with a call to

cCutscene::EventSpecificGreetings(cEvent* e, cCharacter* x, cCharacter* y)

It is a function that generates a cutscene object where x and y are greeting each other for event e.

You can contruct a class tree by listing all the data that can be grouped and be changed. For every arguement for a function that has a template, there is a class. It is unclear what your arrows mean. In general arrows indicate inheriance or containment. They don't form cycles.

[Edited by - Estok on August 26, 2005 2:34:08 AM]