• Advertisement
Sign in to follow this  

Help me in selecting an engine

This topic is 2350 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

I m planning to make a game that uses 3d objects in the background for collision, control logic,etc while using sprites which will be used as texture mapped onto a cube
I m planning for an isometric game along with the switch of view to a side scroller like streetfighter

Basically its a game combining diablo and streetfighter
The artwork is going to be similar to wakfu.
wakfu-1.jpg

Can anyone tell me which engine can allow me this or are they any other alternatives that you may suggest.
I've tried making my own engine and have successfully mapped the texture sprites to the cubes and have only reached this far.
http://leysa.net/test.jpg
See attachment for the trick that I am trying to implement.

But it's taking too much time and I thought to give irrlicht a try.

Please help me.

Share this post


Link to post
Share on other sites
Advertisement
I've been evaluating the Horde3D engine for use in an isometric game in pretty much exactly the manner you indicate, albeit with fully 3D characters rather than sprite characters. A few things I've discovered that you might want to look out for:

In order to get the best performance, you may need to write your own scene manager. Standard engines such as Ogre, Horde3D, etc... include scene management that is built for the general 3D case, but there are plenty of optimizations to be made if you roll your own, given that the camera in an isometric never changes orientation. This becomes even more of an issue if, as I do, you use anti-aliased and smoothly-blended sprites. In a general 3D engine, these types of sprites require a sort of all objects from back to front, which can be expensive. Whereas with a special-case isometric engine, the sorting can be done for most objects as a side-effect of how the visible part of the scene is traversed for rendering, rather than a separate pass with the overhead of a sorting function.

Given the orthographic projection and the fixed camera, some of this performance overhead is mitigated. However, an isometric back-to-front scene with alpha blending also requires lots and lots of overdraw, which can use up fill-rate in a hurry. If objects are not blended using partial translucency, they can be drawn front-to-back to allow early discarding of fragments based on z-buffer testing, eliminating most of the overdraw, but in my own tests I was unable to use this optimization due to my stubborn insistence on using smoothly anti-aliased renders. After all, the ability to use alpha-blended sprites to generate a smooth scene is half the reason I like isometric games in the first place.

Another performance gain of rolling your own is that you can use a specialized scene traversal computed directly from the camera, rather than relying on a general-case engine's scene traversal which may require expensive frustum intersection tests against a large spatial graph. In a general 3D case, you can't really make any assumptions about what the camera is looking at, so non-visible-culling is done scene-wide. With an isometric camera, you can make assumptions about the visible set by pre-calculating some volume data at game start, then taking into account the translation of the camera. In my approach, I do this calculation by reverse-projecting the corners of the screen against two planes representing the upper and lower bounds of the Y coordinate in game space. This set of eight points can be used to define a volume or an area, and can then be used to calculate an iterative structure to traverse a portion of the scene graph back-to-front.

As I said earlier, I am currently in the process of evaluating Horde3D for this purpose. So far I've gotten acceptable results, but I am still in the process of deriving an actual real use-case test of it. Even though the framerate remains acceptable on my crappy lappy, it still represents a rather drastic drop in framerate compared to my custom-built isometric engine. While some aspects of using a general 3D engine are nice (encapsulation of shaders into a material system, abstraction of the underlying renderer, etc...) I strongly advise choosing a 3D library that gives you support for creating a custom-built scene manager. So check the documentation and/or source of any candidate library to see for yourself how easy or hard it might be to do so.

Share this post


Link to post
Share on other sites
Ok, thanks for the big post. Really appreciate it.
Firstly the orientation of the camera never changes since the sprites will be created for a particular angle namely isometric for the game world view and a side scroller view for the arcade battles. Also the camera will always follow the player.
What is a scene manager according to my requirements?
When I was working around the engine of my own, I learned that the faces of the objects could be culled by representing the drawing of the vertex in a specific manner(i.e clock wise or anti clock wise)
I do not know if I have to freedom to do that with some other engine where in I can specify how the polygons will be populated.
I have represented the sprites on cubes with the same technique above eliminating the 3 planes to be culled that are never shown due to back face culling.
Also, I've learned that opaque objects are to be drawn first then the ones that can become transparent.
So I've tried it out and come to a point where the transparent pixels of a cube were obscuring the geometry of another cube.
I came to know that alpha test needs to be enabled and after that I didn't need to worry about the transparent pixels of the cubes of opaque objects drawn in any order as long as they are drawn before the ones that can become transparent.
http://www.gamedev.net/topic/606079-is-depth-buffer-not-working/page__p__4833993__fromsearch__1#entry4833993
I also wrote a custom method to map the sprites to the cubes which was very complicated and tricky.
So what I think I understand is that this way of doing things make the zbuffer sort the objects in a scene automatically, the back-faces culled by the manner of population of vertices of a cube and how alpha test works.
I did not test on how many objects the scene could render.

I was using openGL(LWJGL) and java to render my scene ..

What I want to know is with horde game engine what all is possible to do from what I've learned .. i.e can I implement any of the techniques above that I've learned.
How is a level represented? In my head its just a file with what objects to place in which grid. By objects I mean cubes i.e what the cube represents, how big a cube is, how many grid will it occupy, etc all encapsulated in this file. I've never used an engine before and wanted to how difficult it is to attain this requirement.
If I've made any mistakes or senseless assumptions please correct me.

Share this post


Link to post
Share on other sites
How a scene manager in a general 3D engine is implemented is very much dependent upon the engine. They are typically designed, however, so that the scene will be drawn correctly from any given camera location/orientation, and placement of objects is typically not limited to any kind of cells on a grid. However, this does not limit you from using a grid-based structure if that is your desire. A general purpose 3D engine can draw a grid of cubes as easily as anything else.

However, if you operate on the assumption that your world is a grid of cubes, and that your camera is fixed in orientation, there are optimizations that you can make to the rendering process that a general 3D scene manager can not. If you find yourself fighting for every last bit of performance your engine can eke out, then perhaps it would behoove you to write your own scene manager. Otherwise, the general 3D engine should be fine for your needs.

Share this post


Link to post
Share on other sites
Do you want to rotate that isometric view? Otherwise just a 2D engine will do by just using isometric tiles which can be drawn or rendered from a 3D app to a texture.

Share this post


Link to post
Share on other sites
thank you JTippets. I will try to see if I need to optimize my screen manager. If so I will then revert to you.
menyo : I do not wish to rotate the isometric view. But in future if I need a rotation of 90*x degree then I just have to tweek a little bit of my code to get it running. There are many advantages of using a 3D backend as opposed to a general 2D engine. I've read many of JTippets post before and have learned the hardware are now sophisticated enough to handle 3D stuff and most of the other parts like collision detection etc can be easily computed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement