After just reading what must be the hundreth thread in which someone wants to write an MMORPG, I'm curious: is there anyone seriously writing an RPG/action adventure at the moment? Open source? That is, a game in which you:
- walk round in a big world
- kill critters, pickup up the items they leave behind to sell them later in the local store
- can talk to npc's in the streets to get missions
- aim to gain XP, thereby leveling up, so you can wear better armour and cast better spells
- follow an interesting storyline in which you're a no good nothing who grows to be a powerful war-god you saves the planet or the universe, discovering your true origins in the process (or something else )
- need to find keys to open doors
Seeing how many people would be interested in writing such a game, a my-first-rpg project might be of more interest to the people in this community. I might join in myself if someone started such a project...
Yes, after initial excitement playing MMOs (Everquest and DAoC) I drained out. I'm watching some in development, but I'm not too excited about them. I've fallen back on good-storied singleplayer RPGS (Elder Scrolls is my GOD!) and FPS games.
Right now, I'm currently making an engine for an action/rpg that would be third-person with light RPG elements and heavy action. RPGs usually suffer in the area of combat so I'm attempting to make something with good action. So yeah, I'm on the same page. Right now the engine's core module is pretty polished, I'm integrating ogre under it step-by-step, the physics...,...,... lots to do. Just know you're not alone!
I want to make a similar game. In it, the "action" would refer not only to shooting or kicking but especially to jumping, rolling climbing, as in Prince of Persia. I image that when you level, you can choose to increase your maximum jumping or falling height, so you can go back to where you were before and reach new places. What I have right now is:
- a map made from 3 layers or RAW images (height, texture, objects), which renders into this
- the possibility to have a multiple choice conversation with an entity and have that conversation global fire events with certain asnwers
- the possiblility to pickup items
- the main character that you can walk around with
- the camera you control
- other characters that walk around aimlessly but don't get stuck
It's not enough to combine with other code, but there's a few nice classes in there, mostly for mesh generating, since I've had some XP with that.
I've started to get the hang of Ogre (at least with no animation - that's the next hurdle). I suspect finishing the core graphics part of my unified engine will not take too much longer. The hard part comes with the physics (i'm gonna do custom ODE integration, so no OgreOde) and the shaders. I think, since I want to do large outdoor scene with very realistic weather I'll be spending a LOT of time playing with shaders.
Anyway, the general idea for now is to focus on getting the combat right. I plan on making all player-player and player-world interaction physics-based (including damage). Other interaction will use a dialogue interface (including, duh, dialogue). Think KOTOR. Their dialogue system was used fairly well for all sorts of interactions.
I also plan on NOT using a level-based system. It will be skill-based. Level-based systems are not very conducive to a fast-paced action-oriented RPG.
The only demo type things I have finished are remakes of the examples that come with Ogre, only done using my framework (a data-driven architecture).
Well, to explain my motives, the whole issue comes from my architecture. I chose to use a combination of Model-View-Controller and Data-driven. As I said, I have a central data component. This is surrounded by the various game modules that each in turn read and write to that store. Their behavior is determined by that data and scripts. On top of that, the way these modules interact with the data is through Controllers. Each module can have multiple controllers within it, that act as the bridges to and from the data. The graphics module, however, has no controllers. It is passive in the sense it only reads data (hence, it is the View). Since physics is a module all on its own, in service of a clean architecture it must be separated from the View.
On top of all this, I've been programming for a while, and I'm a Software Engineering student. So, while I decided to use a lot of 3rd party tools this is a learning experience and I want to do a lot of stuff myself.
Obviously, a lot of physics will depend on the geometry of the objects, which may only be available through the graphics engine. I'm looking into that interaction, but I wanted to achieve a much looser coupling than your integrations. Keep in mind I haven't started coding the physics yet, though, and I also haven't really looked into gangsta. If I discover anything novel either regarding my architecture or my custom physics integration (if there is one) i might just post back about it.
bugshake wrote:That's a lot of plans, I'd be curious to see the combat stuff when you have it ready. Good luck with all that!
That's nothing! To be clear, this is an educational project. My first game, but it's never that simple. I just have to "engineer" it right, which takes time... But since I'm out of school for the next six months, I have lots of time! The goal is a complete game engine, so that little bit above is nothing!
But since combat is so important, I plan on getting started quickly. I'm looking at gansta right now, but I'm still not sure. It seems with a custom callback interface I can separate it from ogre enough, but I'm not yet sure. I'm still working on the graphics module. Here's a small roadmap:
- Finish new camera system
- Stich in particle effects
- Stitch in terrain and define an outdoor "World" (a generic world is already in use)
- Animated meshes and the "actor" object type
- Data hierarchy model (inheritence, and data verification for my data module)
- physics
- combat
- combat
- combat
So really, once I get physics and some animation-type stuff in my engine I can start working on the combat. I'll be sure to keep you guys updated, cause I think realistic melee combat is something sorely lacking in games.
Praetor, how did you model your central data component and the interaction with the components? Is it based on some generic standard (does such a thing exists?) that defines how the data and various components interact or do you have your own custom approach?
I am looking for a 'MVC standard for games'. I'm afraid that if I design something by myself, I'm making the wrong choices (how can I prevent that the various components in the end are forced to interact with each other, should I use some kind of facade in front of my model that also deals with thread that change the date, etc.)
I knew that one, but this is currently my only source and I could use some directions to 'standards in game design' (just to avoid pitfalls). Isn't there some kind of OMG group or a GOF in game design?
There is no "standard" no. There are a lot of factors to take into account here when designing any software architecture, not just games. It all depends on what you want. If you already know about software design just skip this, but I'll attempt to justify my design choices thus far. I've been doing documentation as I go too, so a lot of this is elaborated in my design doc (yeah documentation DURING the development phase, that never would have happened before, lol).
General goals for all software:
Increase cohesion - Keep like behavior/data together, separate unlike stuff out. Example: a Car class may have references to its Tires, behavior to change tires, move around. It should NOT be able to calculate the wear in the road its currently driving on. This is handled in the Road class.
Decrease coupling - Keep the number of external dependencies of each component to a minumum. In a system with high coupling changes to one component can ripple out and affect multiple other components. Changes should only affect components that should truly be affected!
Data WITH behavior - Not a hard-and-fast rule like the ones above, but a strong strong suggestion. Behavior in one component should generally not operate on data inside another. The data that is intrinsically associated with the component should inside that component.
So my personal goals with my engine that really affect the architecture choice:
Abstracted components: Each module can be thought as a separate entity, with NO direct coupling between implementations. The graphics module is hidden behind an almost double abstraction layer. This means if the graphics module is changed (even if I swap out Ogre entirely) NO changes should have to be made in the other modules.
Data-driven: Behavior should not be hard-coded. Meaning my compiled C++ code should not be the driving force behind game behavior. Data-driven programming means decisions are made based on data and customized through interpreted scripts (well, that's what data-driven means in this context).
Obviously all the other game-type functionl and nonfunctional requirements exist. Modules and their interactions can't be ungodly inefficient, etc.
Obviously I focused on the central data module first, since it was, well, the center. Within this module are some key classes that drive everything. Remember, these components should never assume anything about the modules that surround it. Module-specific things are decided as much as possible at run-time through the data, even though at compile-time the exact implementations that sit behind the abstractions is already chosen.
The core class is Object, which is managed by...ObjectManager! Object stores things every module needs. More data can be stored within the modules themselves if need be, of course. Things like position, orientation, name (unique) and type. Also present is a generic data map. This is where all the real gritty data gets put in key value pairs. I've been using C++ for a while, and so I have a lot of little utility classes from previous nongame projects. A generic data component is one of them.
Anyway, beyond the Object is the concept of an Area: a geographical collection of objects. Area is charged with initializing and releasing objects. These will be loaded from xml area files. There's also an Application class in there, Trigger classes, and my abstract base class Controller.
Conventional game designs feature a game object. This game object incorporates all its behavior into one place. A game object:
Knows how to draw itself
Knows how to do its own physics
Knows how to run its own scripts
And the list goes on. At first this seems right, the ole' data-with-behavior trick. But wait! Oh the humanity! Oh the coupling! It's out of control!
Okay, what about this MVC business? Well, MVC is very popular right now. I personally don't think its all that great, which is why I use a watered down version. Its sort of superimposed over my module-data-driven thingy. The graphics module (and I suppose the as yet uncreated sound module) is the view, the data module is the model, and everything is the controllers. The controllers reside within the other modules, inherit from the base Controller class, and serve as two-way communications to the Objects. The view has no Controllers, it just receives updates and reads the Object data
Okay, there are draw-backs. I'm about 1/3 the way (i'm guessing) to integrating Ogre, 85% with the data, and maybe 90% with the input. What I've noticed so far:
- Data is complex. The data-centered idea makes for very complicated data collections. That generic data store has a lot of stuff in it. Good documentation and keeping track of what needs what kind of data helps here
- Some interaction is always needed between modules. So, added to the central module is a Message, MessageHandler, and MessageServer classes. If communciation is needed, send a message! MessageHandlers registered to receive those message get notified immediately (I could do it by frame...but I haven;t look into it yet). Messages contain the same generic data goodness that the Objects use.
Okay, if you look a the link jacmoe gives you you'll see the paper that made me look hard at a data-centered approach. I believe I am using a slightly hybrid approach that I think works well. I'm constantly refactoring, and we'll see how it turns out. If you want me to go into more design specifics, I can. I'm not ready to release any documentation yet (my design doc needs a lot of work) and definitely not any source yet. But if anyone finds this useful I'd be happy to here it!
How about the normal GOF? Those patterns are just as good for software! Currently using:
Proxy - abstract way to bridge the gap from graphics with cameras
Factory - Within the graphics module to create the right type of object representations
Composite - Objects may contain sub-Objects, which are just Objects!
Pseudo-Chain of Responsibility - Not fully implemented with the messages yet
Command - Was used in the input system, taken out, but it will be used again and again later on! (replaced with simpler listeners)
Can't think of any more, but they are there. That book is my bible!
I'm looking at gansta right now, but I'm still not sure. It seems with a custom callback interface I can separate it from ogre enough, but I'm not yet sure.
Indeed. Gangsta is not related to Ogre at all, as you point out the supplied callback interface is simply a (somewhat comprehensive) example of how to integrate Gangsta with Ogre. In fact if your architecture is as abstracted and modular as you're describing then you'd have a callback interface specific to your engine, it wouldn't need to know that it's using Ogre at all. I know that's possible because I've already done exactly that for another (as yet undisclosed) application framework.
monster wrote:I've already done exactly that for another (as yet undisclosed) application framework.
Oho! Cat's outa the bag now! I checked out the latest source of gangsta, and I'll take a look at it tonight. I read the readme a little, but I guess I just have to dig into the examples to get the hang of it. What I'm worried about is once I've separated the physics from the graphics, I need some way to get at geometry data to set up collision and such. Hmmm, but I'd have to solve that problem with a custom solution too. Im just wondering if writing a custom callback interface is more work than a custom ODE integration. After all, I'd first have to understand your interfaces!
GoF is the "Gang of Four". They are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Their book Design Patterns, Elements of Object-Oriented Software is the classic text on the topic, and is often just called the GoF book.
I didn't know that.
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
writing a custom callback interface is more work than a custom ODE integration
Err, no. A custom callback interface would be a tiny fraction of the work of an entire ODE integration. Plus you get 3 other physics engines integrated for free!
Documentation is, as you say, rather lacking currently though.
Well, I'll be working a little tonight. But it is friday, so I suppose I might have a little social life. I may not get to really digging into gangsta for a while (weeks even, though probably more like days). I like that callback interfaces are so simple. You seem to have the same sorts of design goals as me!
Since the game is intended to be very physics-oriented my only concern is gansta's relative youth, and the possible lack of features. Meaning, with something so dependant on physics, there needs to be a whole lot of wrapped functionality. So, how about it? In the readme, you claim to have "common" functionality wrapped. I assume that's basic collision, dynamics and such. How far along are the joints, more advanced dynamics? What kinds of collisions are available (primitives, arbitrary meshes?). I suppose, the more I talk about the more I'm convinced, that if any area is lacking I can just sorta start modifying gangsta to include those features. You've convinced me, sir!
One more thing, since I'm getting all these nice physics packages (well, ODE and Newton, for free) which one would suit my needs best? There's going to be some dynamics, but nothing too complex, but the collision needs to be very good. I'm looking at a simpler character-terrain collision, but very complex character-object and character-character collisions. I'd assume I'd need some very detailed collision models around my characters, and since they're animated, it adds even more problems. What would be your suggestion?
Praetor,
Thanks for your information. I do know how to design an application and I´m always interested in design patterns and application architecture in general. Much of these concepts can be applied to game design, as you point out. But games are not the kind of applications that I normally design. Obviously specific game design patterns are developed (i.e. Finite-State Machine pattern) and there must be (somewhere) a lot of experience with certain design decision (what works and what doesn´t). This is the kind of information I need (and preferably in one book or on 1 site). Well, maybe there comes a time that a standard FPS design can be bought off the shell (you ´only´ have to add your specific requirements and implement it). For now, I will try to gather the information here and there.
Yeah, pretty much there is no standard in the sense that there is any one right answer. That's what makes software engineering so great, and so hard. There are always multiple ways to do something, and any two solutions may be equally good.
Hrrmmm I was just thinking about how Ogre and the other modules will fit together with my design, and I thought of a new hybrid. Since I have no one to bounce ideas off of, I'll use you guys!
I retain the an Object type, which contains configuration-type data, just as before. However, dynamic, simulation data (like position and such) will go into a sibling class. This class is like the traditional "game object" in that it can shell out behavior to the modules. This now uses a push model rather a pull model. These dynamic "Elements" may or may not be the ones receiving updates (not sure yet) but they definitely control their own access to the modules. This centralizes some of the behavior to make things easier, and keep abstraction by making the modules layered. This also means modules still would not need to communicate with each other, like I wanted...Hmm
Element <-- ElementManager (config data like "mesh", "material", etc.)
^
|
|
Object <-- ObjectManager (dynamic object)
|
|
+--> Graphics module
+--> Physics module
+--> AI module
+--> Input module
Alternatively, the modules could call behavior methods on the Object, so the arrows would go the other way. Access could be controlled again by Controllers, but final behavior would be delegated to the Object class, and the behavior could still be dictated by the data in the Element class.
Hmmm, I see some definite benefits here....Like that previously, the data Objects couldn't really use inheritance, but now Object classes could. Like a Player, which is an Actor which is an AnimatedObject, which is an Object. Hmmmm....what do you guys think? A little MVC meshed with data-centered mixed with traditional game object?
What about some kind of dispatcher between objects and modules? The object only communicates with the dispatcher and the dispatcher on its turn decides with which modules it must communicate. This can also be with one or more other objects (i.e. broadcast). This means that you can leave communication of the (game)objects more or less abstract (objects performs action ´jump´ and the dispatcher translates this to interaction with the various modules). This way you have a cleaner separation between the game objects and the modules.
Well, how would the Object know to jump? Communication has to go both ways, since the Input module needs to tell the player object to jump, or just that the jump key was pressed.
I think adding a dispatcher is a little overboard, since now you'd have three central objects: Element which stores config-type data, Object which uses the data and the surrounding modules to embody a game object, and a dispatcher to communicate from Object -> Modules. Instead, since Object is supposed to encompass the behavior, just use C++ features or design patterns to add in the dispatching behavior. A GraphicsObject inherits from Object as contains references into the graphics module. An ObjectFactory can take care of instantiating the right one for the area at runtime. And, if you ever need to dynamically add behavior: Decorator pattern to the rescue!
)
