s/s:
What technogoth said was correct. It may be hard to convince you, but you misunderstood what he said. Rasm's advice was also good. Yes, you can wrap anything and make it into a class, but that is not the way people use classes for.

My thought is that, when I started learning programming, I was thinking what you are thinking right now. I thought that OO means that I can program as if I am designing a neural network. I thought that using OO means that I could write the code for each neuron, connect them, and I will get an overall running system. But this is not what OO is for. The essence of OO is data and function encapsulation. Now, this can mean a lot of things if you have never programmed with it before. In short, OO is refering to something more low level than what you are expecting.

Class literally means a group of similar items. In the sense that, if A is an RNPC, and B is also an RNPC, and there is a list of functions that model the interaction between A and B, then I can create a class to include all the data that each RNPC contains, and enumerate all the interactions between any two RNPCs. For example, if there is a sence where A kisses B, then I can conveniently call cRNPC::Kiss(A,B), which takes care of all the emotional exchanges between character A and B.

This is the usual way people think about classes when they discuss class diagrams.

Conceptually, there is nothing wrong with the way you are doing it, by making each state its own class. Code is just going to get duplicated and you will just be initializing classes with one instance. But there is something ugly that you may not know yet, which is systemcalls. You will probably find that your nicely planned classes will need to be chopped up, and you will still need to have gamestates at the upper level so that your engine will know which class should be receiving the systemcall.

If you don't know what we are talking about, just ignore us and continue. I don't mean this in a negative way. You can't really understand it unless you start thinking about the nasty stuffs beneath. What we are doing now is just making you more defensive.

On the other hand, while 5MinGaming was doing the branching story java thing, my demo was running the way you are thinking right now. Because it is the intuitive way a high level designer would want the engine to behave. But I didn't call those classes, I called those nodes and modules. It was able to do that because I wrote it following a flow simulation paradigms. But the main point to stress, is that each module is not a class, each module belong to the same class.

It means that 'start', 'end', 'explore' so on, are all INSTANCES of the class called 'Modules'. And there is indeed a 'scheduler' that controls the flow of the execution. That is why I think I know what you are trying to do. Because that was how my simulator runs. But when you call them classes it just screws up everyone.

If you would just drop calling them classes and call them states, it would save many explanations.

Bonus material

[Edited by - Estok on August 27, 2005 3:20:54 AM]

Quote:

Original post by Estok If you don't know what we are talking about, just ignore us and continue.

Lol, well there's practical advice, since, being a stubborn so-and-so, I always end up doing things my own way until I get stuck with no idea what to do next. [wink] Anyway I have been doing this, adding text boxes explaining the contents of each object to my diagram (which is getting frighteningly complicated). I didn't finish fleshing it out today, maybe I'll have a good draft to show you all tomorrow night.


About 'procdural' programming and only one class having control at a time - Well, in Xenallure the only thing that drives the game forward is the gamepad input, since events aren't triggered by the game's internal clock or anything else other than the player. And it's important to know which class is receiving the gamepad input at a particular time, because totally different things should result from the A button being pressed in different contexts. Also, if more than one class had control at a time, wouldn't require threading and bog down the processor as the different classes all demanded their turn to run? So, is procedural design really a bad approach in this case?

Quote:

Original post by sunandshadow About 'procdural' programming and only one class having control at a time - Well, in Xenallure the only thing that drives the game forward is the gamepad input, since events aren't triggered by the game's internal clock or anything else other than the player. And it's important to know which class is receiving the gamepad input at a particular time, because totally different things should result from the A button being pressed in different contexts. Also, if more than one class had control at a time, wouldn't require threading and bog down the processor as the different classes all demanded their turn to run? So, is procedural design really a bad approach in this case?

The reply you'll get to this sort of question will depend on the designer; some get almost religous in their following of a programming paradigm. However, I think procedural design would work well with a console RPG. My only concern is that from what I know about Java, it tends to force an OO approach onto you by default, which might make things a bit ugly. But as long as a design feels right to you, then you might as well go with it.

What I was trying to say about control is that with procedural design you think like the computer (by the way, I also think this is called "structured programming"). The program is designed as a kind of flow chart between states. The main drawback behind this is that it can get hard to remember which functions rely on which data, and a small change could break the design (this becomes much more of a problem if there's more than one programmer). However, if you keep all the data in objects like Java will force you to you will probably avoid all those problems.

Anyway, just go with whatever design strategy seems to suit you.

It has nothing to do with being stubborn, someimtes you simply didn't suffer enough to understand it. It is okay for the design to get complicated, but the diagrams shouldn't. It is good to get excited from seeing complicated things.

---

When I said triggers, I wasn't implying a real time game. Systemcalls exist for the simple fact that the player can press a button. There is nothing wrong with the your decribed design. That is the way I did it. Except we don't call those classes. It is not about threads.

"So, is procedural design really a bad approach in this case?"

It is not a bad approach. It is pretty standard. We would probably refer to what you have right now as a state diagram or a state design. If I was the first one to answer your starting post, I would have said the following:

---

Quote:

I'm trying to study how the philosophy of object oriented programming applies to game design. Apparently, everything is made out of objects. The whole game is the largest object, and it is made out of other smaller objects. But what are these smaller objects? Does anybody know of a diagram showing all the classes and objects an example RPG is made out of?

The classes that RPGs use are not the same kind of classes that you want, if you are trying to design the game following an OO approach completely. In many ways, your design is not similar in structure to a generic RPG. Using a storyboard as an analogy, as you look at the overall design, you have plot elements--each contain a passage, sequence of dialogue, and the corresponding choices, sometimes as complex as a minigame--and an agent that controls which element to present.

When you look at a storyline retrospectively, you can see that the storyline alternates between a segment of presentation and a segment of player choices. Each segment of presentation can be organized as an instance of a class, and each segment of choices can be an instance of another class. To further organize the structure, you can define any arbitrary network/sequence of presentations and choices to be a 'story block'. Each storyblock may also contain small storyblocks. Then, at the top level, your entire story can be described by three storyblocks--Act1, Act2, and Act3, each contain all possible story situations in the respective plot arc segment.

In terms of OO design, each storyblock is an object belong to a class, say cStoryBlock. The class cStoryBlock contains the functions common to the manipulation of story blocks, presentation segments, and player choices. What are some common functions?

1. Transition - When a player makes a choices, present the appropriate block within the current block network, or return a signal indicating the departure from the current block network

2. Randomization - Present any block within the current network satisfying a specfied condition.

3. Customization - Using the generic template blocks within the current network, create a sequence of sub network given a set of parameters.

4. Event-level path finding - Given a set of starting parameters and a set of ending parameters, verify that a path exists within the current network that can drive the starting vector to the ending vector.

How is this related to what you are thinking?

- Your 'start' box is a cStoryBlock object. You could have called it the 'Act0' block. Similarly, you could have called your 'end' box the 'Act4' block. They are not classes. They are objects of the same class.

- Your 'exploration' box can be organized in different ways. You can divide it into three blocks--Act1, Act2, Act3--or perhaps more preferably, divide it into blocks, three each for each RNPC (i.e. SkewAct1, SkewAct2, SkewAct3, ...) This will suffice if you have a modular story design where the PC's relation with RNPC A has minimal effect on its relation with RNPC B.

- If you want more interactions between RNPCs, you may either define more customization blocks, or hard wire the complex network.

Classes Mentioned:

cEngine - the one class that runs at the upper level (one instance)

cStoryBlock - a collection of presentations and choices (many instances), alternately used by cEngine

cPSegment - a unit of presentation segment, contains scripts and directives for formatting the GUI, displaying text, showing image, weather and lighting effects (real time mood controllers), playing movie and sound files. Each story block may have multiple presentation segments. (many many instances if all the blocks are loaded)

cCSegment - a unit of choices segment, contains scripts and directives for defining effects of player inputs, and what triggers are active for each on-screen objects (assuming your pc can move in 3D environment and click on stuffs). Each story block may have multiple choice segments. (many many instances if all the blocks are loaded)

Classes not mentioned:
classes for various multimedia controllers, data structure for characters and other game objects, game states, and plot arcs.

[Edited by - Estok on August 28, 2005 8:31:30 AM]

Okay. Let's call this a flowchart rather than a class diagram, and assume that it's procedural rather than object oriented. o.O That said, What do you think I should do to improve it? Do you think a lead programmer would find a flowchart like this a helpful explanation of the desired functional structure of Xenallure, and a good place to start programming the game from?

Quote:

Original post by sunandshadow Okay. Let's call this a flowchart rather than a class diagram, and assume that it's procedural rather than object oriented. o.O That said, What do you think I should do to improve it? Do you think a lead programmer would find a flowchart like this a helpful explanation of the desired functional structure of Xenallure, and a good place to start programming the game from?

Just briefly scanning over your diagram, I'm still not that sure how everything linked together. Here's a few questions based on your design.

- Are those orangey-pink boxes on the left all separate from each other? Wouldn't there be some similar code or windowing strategies between the Inventory, EquippageStatus, Diary etc.?

- My main concern is I have no idea how you are going to code the story into this thing. I've considered making my own RPG, and the bit I always get stuck on is a good way to script everything together in a nice clean way so the story triggers are easy to write and integrate into the engine. I guess those green boxes haven't been expanded yet, but I'm thinking that the stuff such as the menus will be very easy to create when compared to the code represented by the green boxes.

Quote:

Original post by Trapper Zoid - Are those orangey-pink boxes on the left all separate from each other? Wouldn't there be some similar code or windowing strategies between the Inventory, EquippageStatus, Diary etc.?

Boxes that are the same color do indeed have similar code - you could regard them as inheriting from the same parent class, I suppose. Possibly since so many things need the "Display targetGUI" function I could farm it out, just like the PlayMovie function.

Quote:

- My main concern is I have no idea how you are going to code the story into this thing. I've considered making my own RPG, and the bit I always get stuck on is a good way to script everything together in a nice clean way so the story triggers are easy to write and integrate into the engine. I guess those green boxes haven't been expanded yet, but I'm thinking that the stuff such as the menus will be very easy to create when compared to the code represented by the green boxes.

It's true that the green boxes haven't been expanded yet, and will be difficult to create. Somewhere I will need a variable that says what chapter/week the game is currently in, and I have some ideas for what should go in an RNPC object and how dialogue exchanges could trigger plot progress (including FMVs and progressing to the next chapter, but I need to think about it some more. I've been concentrating on the easier parts first because I think having the generic, easy-to-understand parts of the game engine worked out will help me understand what I ought to do with the more complicated ones. I don't think getting the story worked in will be too difficult though, because it is all pre-scripted. Worst case scenario, I could flowchart all the possible plot paths and hard-code the progression, but I don't think I'll have to resort to that, because automatically selecting appropriate dialogue exchanges and interpreting when these should trigger plot progression makes sense in my mind, I just have to sit down and work the details out on paper.

Have you looked at how existing RPGs script their events? I haven't looked too closely at it myself, but I know that some of the RPGs on the PC write their stories with an interpreted scripting language, which means you should be able to view their code. I know Neverwinter Nights does (as I've looked at the code myself), but I also think Black Isle's earlier games, like Baldur's Gate, used Lua as a scripting language which can be edited (which is why there are story mods for those games).

Edit: I also meant to say that I understand your approach; getting the framework down first is the right way to go. I tend to either just plow straight into implementation, which means my code structure is messed up, or I overplan my designs and get caught up in defining everything down to a ridiculous level, which means I tend to doubt whether my design will ever work.

Quote:

Original post by sunandshadow Okay. Let's call this a flowchart rather than a class diagram, and assume that it's procedural rather than object oriented. o.O That said, What do you think I should do to improve it? Do you think a lead programmer would find a flowchart like this a helpful explanation of the desired functional structure of Xenallure, and a good place to start programming the game from?

The two worst things in your diagram are the position of the boxes and the arrows.

Every box that is near the top of the page should have a meaning. Every box on the left of another means something. You should use their placement to highlight the overall flow, regularity, variance, and hierarchy.

Your arrows don't have a consistent meaning. If you color code your arrows, you will see that there is one loop that you can line up, and all the rest are elaboration of components involved in the main states.

Sunandshadow I think you misunderstood some of what I was saying. For one thing I was not suggesting that GameState be a good class in any way, it is merely a data storage class where all of your common and persisted data is stored. By that I mean any data that is used two or more independent class as well as any data that you might want to maintain beyond the life of a single instance of that class. By putting it all in the GameState class and having other classes access that data on a as needed basis you can ensure that the data is correctly insynch and reduce the risk of memory leaks. It also allows you to make saving and loading easy since if you want to load a save game you simply dispose of the current GameState and replace it with a saved copy.

After looking at you new diagram I can see that you still have some organizational problems. I think you should decide how the data flow of your program is going to work and what you want it to be able to do, and do classes need to know to work. Try creating a hierarchy chart showing the programs flow from the user through the classes you might find it useful. You also still have loops which are a very bad thing; at no time in a program should you have cyclic dependencies.

You mention about how the program needs to know which class has control at one time. That is what the context handler class I mentioned before is for. ContextHandler is the name of the class I use to control all of the IO between the game and the user, which amounts to screens in terms of output and key presses for input. The ContextHandler essentially has an array of screens and maintains the knowledge of which screen the user is currently viewing, passes any input to that screen, and changes the screen when instructed to. There many fancy techniques you can use to tell it which when to changes screens and to what but the simplest and most effective is to have input method on the screen class return a value from an enum.

So basically what I’m saying is that your exploration mode, subgame modes, dialog, and menu, all inherit from the screen class. While they all do different things they have some basic method that they all have in common namely activate, show, and input, which is all the ContextHandler needs to know about them. The only exception to this is the movie player class which needs to know what movie to play.

I think if you look reevaluate your design a little you will realize there is less dependency between classes then you think. Other then that it looks like you are on the right track on terms of your classes, although I think you are missing a level class which should go between exploration and trigger object. The level class is where you hold on the data regarding a game level, including objects, triggers, layout, enemies and npcs. Also you might want consider making treasureObject a type of trigger since that is what it is. Meaning that player opens a box and finds a dime is essentially the same as stepping on the invisible square that causes 3000 zombies to attack.

As to your question as to whether or not a lead programmer could use that to develop a game I would have to say no. By looking at your chart I have a rough idea of how you want things to work but I would end up just using it as reference and then go and make my own with how I want the game to work. There are just too many parts that don’t make sense to me. For instance what is the difference between startup, new game, and new game+? You have them as 3 separate classes but I can’t see why. Would they not all be part of a StartMenu class?

In terms of what a lead programmer would need to program your game, there 3 documents you should provide considering the level of control you want to have.

- A requirements document - you probably already have this is some form or another. It is a short document which outlines in point form the features you want to include in the game and any nonfunctional requirements you have. Such is it must run on a PS2.
- A class diagram - you have one a present but it still needs work.
- A functional spec - this is the document in which you describe in detail what you want each class to do.

In the end though the alot of it comes down to how much control you want on the implementation of your project. If you are going to be the only perment memeber of the team then you will probably want to have a great deal of control over the implemenation simply because if you replace your lead programer you don't want the replacement to have to spend more time then nessary getting up to speed on where the project is at.