Re: RPG game in UML
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sun, 25 Sep 2005 16:15:04 GMT
Responding to Weer1...
I am developing an RPG game and was wondering if I would have advantages when I use some OO for the battle-engine. Actually I am now trying to model the whole game in UML, just for the fun of it.
I have a model like this now:
GameObject ^ ^ ^ | | | Hero Tree Stone
Thats about it. I also got a simple relation between hero---player. And an Action-class still hanging loose.
Probably not a good way to start. While one can usually find some concept at a high enough level of abstraction so a class can capture highly disparate objects, that is usually not a good idea in practice. (More precisely, you only want to do it for contexts where the subclasses themselves are also highly abstract.)
In this case there is an important distinction between the notion of the game mechanics and the RPG entities in the game space. So the only place where subclassing from GameObject would likely be useful is in a subsystem where one doesn't care about the RPG semantics of the entities but one does care about game implementation issues. For example, in a subsystem devoted to graphical rendering one views things like Hero as a collection of presentation attributes rather than RPG character attributes. IOW, in the rendering context Hero and Tree /do/ have very similar properties and may well have common properties that one could abstract as, say, a generic GraphicalObject.
This segues to another point. Games tend to be very complex affairs with very different subject matters. So the first thing you want to do is partition your application so that you can encapsulate those subject matters in subsystems. Some obvious candidate subject matters are: graphical rendering, movement physics, story management, overall game control, persistence, and map management. And there could be several others depending on the complexity of the game.
Each subsystem will have its own unique view of the problem space. Encapsulation allows you to model each view so that it is tailored to the subject matter so that extraneous detail is eliminated and the representation optimally matches the subject matter functionality. This makes life much simpler for dealing with the subject matter. If the subsystems are encapsulated behind pure message interfaces, the overall application will be more robust and easier to maintain.
Now the fun starts.
Lets presume there are only hero-type characters in this game so every player(user) has a hero (not A character). I think weapons play an important role. A Tree could be the weapon for a hero. Even a tree could BE a hero (yes, you can play a tree in this game!).
First identify all the entities you need and then worry about how they are related to one another. What you describe here can be handled mostly with simple association relationships. For example (lacking more specific requirements this is speculative):
* plays 1
[Player] ---------------------------- [Character]
| * | 1
| |
| |
| chooses 1 | controls
| 1 1 corresponds to * | *
[GameObject] --------------------------- [Weapon]
A A
| |
+--+----+--------+ +-----+-----+---....
| | | | |
[Hero] [Tree] [Stone] [StoneWeapon] [TreeWeapon]Note that I have included the subclassing I criticized above. The justification here is that [GameObject] is just used to categorize things like weapons. It would have no intrinsic behaviors and very limited knowledge. I would expect its main use to be for factory objects that create RPG objects and instantiate their relationships. For example, the corresponding [GameObject] might determine what flavor of [Weapon] to instantiate.
[More likely, [GameObject] will be a dataholder for basic structure information needed by the implementation. For example, it could provide a skeleton definition for articulation by rendering or movement physics. However, as Phlip points out, that view will likely involve multiple objects so the [GameObject] might will be implemented as a GoF Composite pattern rather than the simple tree shown.]
Contrast that with [Weapon] where the entities have RPG semantics. That is, a [StoneWeapon] is not a [GameObject]; it is a [Weapon] so it has appropriate RPG properties. In addition, the [Weapon] superclass will provide a polymorphic interface for abstract behaviors that are common to all weapons. In particular, note that when it comes time to, say, render the weapon graphically, one would probably need the corresponding [GameObject] composite to do that properly and [Weapon] would just provide detail instance data parametrically.
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- RPG game in UML
- From: weer1
- RPG game in UML
- Prev by Date: Re: A question about substitution principle
- Next by Date: Re: A question about substitution principle
- Previous by thread: Re: RPG game in UML
- Next by thread: Looking for some advice on No Magic's Teamwork version control server
- Index(es):
Relevant Pages
|
