Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

no one

3d rpg games...

This topic is 5423 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello Ive been looking for information on 3d rpg''s such as whats the typical lighting, terrain, scene culling methods etc (octrees, bsp trees etc). I haven''t really been able to find any info however. I just want to learn everything I can about 3d rpg game engines and such. Anyone have Any links? Thanks a lot. -me

Share this post


Link to post
Share on other sites
Advertisement
hmm,
Muonline
Basically a 3d overhead game (you never see the sky and you see your charactor in a overhead 3rd person prespective). You click the terrain to move and click on objects to interact with them.

Share this post


Link to post
Share on other sites
Primatech publishes a pretty good book called Role Playing Game Programming with DirectX. From what I have heard, its a pretty good book on the subject.

Culling methods, lighting methods, etc would depend what the designer choses for the game. These choices would not necessarily be RPG specific, but rendering style specific.

Share this post


Link to post
Share on other sites
quote:
Original post by no one
hmm,
Muonline
Basically a 3d overhead game (you never see the sky and you see your charactor in a overhead 3rd person prespective). You click the terrain to move and click on objects to interact with them.


Limiting the engine in this fashion could simplify a lot of things for you, and could preclude the necessity of having to go with a full-blown, fully generalized scene graph management approach such as a BSP or octree architecture. Schemes such as octrees are really wasted processing in a game in which the view is limited to always be looking down at the ground. In this situation, I would be more inclined instead to use an algorithm cobbled from tile-based games techniques, by breaking the terrain into chunks (similar to tiles in some respects), pre-calculating some visible area of chunks based on the intersection of the view frustum with the ground plane, and only rendering those terrain chunks--and the objects above them--which are within the visible area. No CPU-intensive octree culling, no need for expensive terrain LOD approaches (assuming the overhead angle is at a steep enough angle, none of the terrain is ever viewed from a large enough distance to require LOD reduction), BSP tree is really unnecessary, and so forth.

More flexible camera handling, of course, would require a more flexible and generalized approach. Precalculating a display area based on intersection of the frustum with the ground plane of course assumes that the frustum does intersect the ground plane. If it doesn''t (for instance, if your viewing angle is to shallow, or your field of view is too wide) then you get wierdness on a major scale, usually fatal and invariably ugly.

Perhaps a place to start yourself thinking is this. Each corner of the view frustum (corresponding to the corners of the screen) intersects with the game world at some point relative to the location of the camera. By calculating these points, you define a 4-sided polygon defining the visible area. You can iterate through the chunks intersecting this quad area (perhaps using interpolation techniques similar to those that software polygon rasterizers perform) to render the visible chunks and their contents. This automatically excludes all non-visible chunks from consideration, without the overhead of recursive intersection testing. Just a thought, and one I haven''t fleshed out beyond the prototype stage, but that prototype nets me much better performance given the circumstances than the more general octree and quadtree based approaches I have also tested for this sort of game.

In a fixed-camera setup like this, you can really constrain the z-coordinate space, so that reverse-projecting based on the projection/view matrices and the z-buffer value at a screen coordinate (for mouse hit-testing) yields fairly accurate results. Such is not always the case for more general techniques, where the visible z-coordinate range is wider and thus more prone to error at larger z distances.

Terrain can be done however you wish, though the chunk or tile based approach lends itself to a regularly spaced heightmap of tiled nodes. You could look into such techniques as terrain splatting for the terrain, but in the case of fixed perspective views such as this, my personal experience indicates that the detail you get from this is not acceptable, being more suited for larger scale terrain views. Since a fixed-camera RPG of this sort usually draws a very localized, relatively small area of terrain, I prefer a more directly tile-based approach of assigning each terrain chunk a texture in a similar manner to more traditional tile-based isometric games. The terrain can thus be very detailed, trading off texture memory usage for quicker processing and rendering (texture splatting requires multiple rendering passes to draw the terrain) and enhanced detail in the terrain.

If you would like to see my initial prototype code for an engine of this sort (very rough, but workable) let me know and I can zip it over to you.

Good luck.

Josh
vertexnormal AT linuxmail DOT org


Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.

Share this post


Link to post
Share on other sites
quote:
Original post by VertexNormal

If you would like to see my initial prototype code for an engine of this sort (very rough, but workable) let me know and I can zip it over to you.

Good luck.

Josh
vertexnormal AT linuxmail DOT org


Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.


Please... umm can you upload it to your rpg2 site?





It''s Maxd Gaming, put in an underscore and I will beat you with a rubber ducky!
{ Check out my Forum } { My First Space Art (Ever) }{ My Second Space Art (Ever) }{ A upcoming space RTS codenamed Gruntacktica . }{ . }

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!